Perguntas frequentes sobre o AWS Lambda

Consulte nossa documentação para obter uma lista completa de fontes de evento.

O AWS Lambda oferece suporte nativamente aos códigos Java, Go, PowerShell, Node.js, C#, Python e Ruby, bem como fornece uma API de tempo de execução que permite usar qualquer linguagem de programação adicional para criar suas funções. Leia nossa documentação sobre o uso de Node.js, Python, Java, Ruby, C#, Go e PowerShell.

Cada função do AWS Lambda é executada em seu próprio ambiente isolado, com seus próprios recursos e visualização de sistema de arquivo. O AWS Lambda usa as mesmas técnicas do Amazon EC2 para fornecer segurança e separação nos níveis de infraestrutura e de execução. Para saber mais, consulte a documentação.

O AWS Lambda armazena o código no Amazon S3 e o criptografa quando está ocioso. O AWS Lambda realiza outras verificações de integridade enquanto seu código está em uso. Para informações confidenciais, como senhas de banco de dados, recomendamos usar a criptografia no lado do cliente com o AWS Key Management Service e armazenar os valores resultantes como texto cifrado na sua variável de ambiente. Será necessário incluir lógica no código de função do AWS Lambda para descriptografar esses valores. Para saber mais, consulte a documentação.

Sim. Você pode criar e modificar facilmente variáveis de ambiente por meio do Console, da CLI ou dos SDKs do AWS Lambda. Para saber mais sobre variáveis de ambiente, consulte a documentação.

Para informações confidenciais, como senhas de banco de dados, recomendamos usar a criptografia no lado do cliente com o AWS Key Management Service e armazenar os valores resultantes como texto cifrado na sua variável de ambiente. Será necessário incluir lógica no código de função do AWS Lambda para descriptografar esses valores.

Sim, é possível empacotar qualquer código (frameworks, SDKs, bibliotecas e mais) como uma Camada Lambda e gerenciá-lo e compartilhá-lo facilmente em múltiplas funções.

O AWS Lambda monitora automaticamente as funções do Lambda em seu nome, gerando métricas em tempo real por meio do Amazon CloudWatch que incluem total de solicitações, uso concomitante no nível da conta e da função, latência, taxas de erro e solicitações suspensas. Você pode ver as estatísticas de cada uma de suas funções do Lambda no console do Amazon CloudWatch ou no console do AWS Lambda. Você também pode chamar APIs de monitoramento de terceiros em sua função do Lambda.
 

Consulte a Solução de problemas de métricas do CloudWatch para saber mais. As cobranças padrão do AWS Lambda se aplicam para o uso de métricas internas do Lambda.

No modelo de recurso do AWS Lambda, você seleciona a quantidade de memória que quer para sua função e potência de CPU e outros recursos proporcionais são alocados. Por exemplo, escolher 256 MB de memória aloca aproximadamente duas vezes a potência de CPU para sua função do Lambda usada ao solicitar 128 MB de memória e metade da potência de CPU alocada ao solicitar 512 MB de memória. Para saber mais, veja nossa documentação de Configuração de função.

É possível definir sua memória de 128 MB a 10.240 MB.

O preço do AWS Lambda é baseado em pagamento por uso. Consulte a página de preços do AWS Lambda para obter mais detalhes.

Sim. Como padrão, cada função do AWS Lambda tem uma versão única e atual do código. Os clientes da sua função Lambda podem chamar uma versão específica ou obter a implementação mais recente. Leia a documentação sobre versionamento de funções do Lambda.

O AWS Lambda oferece opções flexíveis de implantação: funções de empacotamento e implantação como arquivos de arquivo.zip que você pode carregar diretamente por meio do console, da CLI ou dos SDKs, ou como imagens de contêiner. Ambos os métodos oferecem o mesmo ambiente de execução, ajuste de escala e simplicidade operacional, proporcionando a flexibilidade de escolher a abordagem mais adequada ao seu fluxo de trabalho.

Você pode invocar uma função Lambda usando um evento personalizado por meio da API invoke do AWS Lambda. Apenas o proprietário da função ou outra conta da AWS à qual o proprietário tenha concedido permissão pode invocar a função. Consulte o Guia para desenvolvedores do Lambda para saber mais.

O AWS Lambda SnapStart pode melhorar o desempenho da inicialização de alguns segundos para menos de um segundo para aplicações sensíveis à latência. O SnapStart funciona capturando o estado da memória (e do disco) inicializados da sua função e armazenando esse snapshot em cache para acesso de baixa latência. Quando sua função é invocada posteriormente, o Lambda retoma os ambientes de execução a partir desse snapshot pré-inicializado em vez de inicializá-los do zero, melhorando a latência de inicialização. Para maior resiliência, o Lambda mantém cópias em cache do seu snapshot e aplica automaticamente atualizações de software, como upgrades de runtime e patches de segurança. Para saber mais, consulte a documentação.

O Lambda SnapStart é uma configuração simples em nível de função que pode ser configurada para funções novas e existentes usando a API do Lambda, o Console de Gerenciamento da AWS, a AWS Command Line Interface (CLI), o AWS SDK, o kit de desenvolvimento em nuvem (CDK) da AWS, o AWS CloudFormation e o AWS Serverless Application Model (SAM). Ao configurar o Lambda SnapStart, todas as versões de função publicadas posteriormente se beneficiarão da melhora na performance de inicialização oferecida. Para saber mais sobre o Lambda SnapStart, consulte a documentação.

O Lambda SnapStart é uma otimização de desempenho que ajuda suas funções a obter tempos de inicialização mais rápidos, reduzindo a latência variável incorrida durante a execução do código de inicialização única. Embora o Lambda SnapStart reduza a latência de inicialização, ele funciona como uma otimização de melhor esforço e não garante a eliminação de inicializações a frio. Se a aplicação tiver requisitos de latência rígidos e exigir tempos de inicialização abaixo de 10 milissegundos, recomendamos o uso de Simultaneidade provisionada.

O Lambda SnapStart oferece suporte a vários runtimes, incluindo Java 11 (e versões mais recentes), Python 3.12 (e versões mais recentes) e .NET 8 (e versões mais recentes). Versões futuras de runtimes serão compatíveis após serem lançadas. Para obter conferir todos os runtimes compatíveis com o Lambda, consulte a documentação de runtimes do Lambda.

Sim. Você pode configurar uma função do Lambda SnapStart para acessar recursos em uma nuvem privada virtual (VPC). Para obter mais informações sobre como configurar sua função com uma VPC, consulte a documentação do Lambda.

Sim, você receberá cobranças pelo armazenamento em cache de um snapshot durante o período em que sua versão da função estiver ativa, por no mínimo 3 horas e por milissegundo a partir de então. O preço depende da quantidade de memória que você alocar para a função. Você também recebe cobranças toda vez que o Lambda retoma um ambiente de execução restaurando seu snapshot, com o preço dependendo da quantidade de memória alocada para sua função. Para saber mais sobre os preços do SnapStart, acesse Preços do AWS Lambda.

Os preços do SnapStart não se aplicam aos runtimes gerenciados Java com suporte, que só podem armazenar em cache um snapshot por até 14 dias.

A Simultaneidade provisionada oferece maior controle sobre o desempenho dos seus aplicativos sem servidor. Quando habilitada, a simultaneidade provisionada mantém as funções inicializadas e prontas para responder em questão de milissegundos.

Você pode configurar a simultaneidade na sua função por meio do Console de Gerenciamento da AWS, da API do Lambda, da CLI da AWS e do AWS CloudFormation. A maneira mais simples de se beneficiar com a Simultaneidade provisionada é usando o AWS Auto Scaling. Você pode usar o Auto Scaling de aplicativos para configurar agendamentos ou fazer com que o Auto Scaling ajuste automaticamente o nível de Simultaneidade provisionada em tempo real conforme a demanda mudar. Para saber mais sobre a Simultaneidade provisionada, consulte a documentação.

A Simultaneidade provisionada adiciona uma dimensão de preço, de "Simultaneidade provisionada", para manter as funções inicializadas. Quando ela está habilitada, você paga pela quantidade de simultaneidade configurada e pelo período em que a configura. Quando sua função é executada enquanto a Simultaneidade provisionada está configurada, você também paga pelas solicitações e pela duração da execução. Para saber mais sobre a definição de preço para Simultaneidade provisionada, consulte Preços do AWS Lambda.

O Lambda@Edge permite que você execute códigos nas localizações da AWS globalmente sem a necessidade de provisionar ou gerenciar servidores, respondendo aos usuários finais com a mais baixa latência de rede. Basta fazer upload do código Node.js ou Python no AWS Lambda e configurar a função para que seja acionada em resposta a solicitações do Amazon CloudFront (ou seja, quando uma solicitação do visualizador for recebida, uma solicitação for encaminhada para a origem, ou recebida de volta dela, e logo antes de a resposta ser enviada de volta para o usuário final). Depois disso, o código estará pronto para ser executado nas localizações da AWS globalmente quando uma solicitação de conteúdo for recebida, além de fazer o ajuste de escala de acordo com o volume das solicitações do CloudFront recebidas do mundo todo. Saiba mais em nossa documentação.

Para usar o Lambda@Edge, basta fazer upload do código no AWS Lambda e associar uma versão de função para que seja acionada em resposta a solicitações do Amazon CloudFront. O código deve cumprir com os service limits do Lambda@Edge. No momento, o Lambda@Edge oferece suporte para o Node.js e o Python para invocação global feita por eventos do CloudFront. Saiba mais em nossa documentação.

O Lambda@Edge é otimizado para casos de uso que dependem da latência e cujos visualizadores estejam distribuídos globalmente. Todas as informações necessárias para tomar uma decisão devem estar disponíveis na borda CloudFront, dentro da função e da solicitação. Isso significa que os casos de uso de tomada de decisões sobre como distribuir conteúdo com base nas características do usuário (por exemplo, localização, dispositivo do cliente etc.) já podem ser executados e distribuídos perto dos usuários, sem que seja necessário acessar um servidor centralizado.

Você pode associar funções do Lambda a eventos do CloudFront para invocação global, desde que a função atenda aos requisitos e limites de serviço do Lambda@Edge. Leia mais aqui para saber como atualizar propriedades da função.

Não. O AWS Lambda foi projetado para executar várias instâncias de suas funções em paralelo. No entanto, o AWS Lambda tem um controle de segurança padrão para o número de execuções simultâneas por conta por região (acesse aqui para obter informações sobre os limites do controle de segurança padrão). Você também pode controlar o máximo de execuções simultâneas para funções individuais do AWS Lambda a serem usadas para reservar um subconjunto do limite de concomitância da sua conta para funções críticas, ou taxas de tráfego de capacidade para fazer o downstream dos recursos.

Se quiser enviar uma solicitação para aumentar o limite de execução simultânea, você poderá usar o Service Quotas para solicitar o aumento de limite.

Quando o limite de execuções simultâneas máximo for excedido, as funções do AWS Lambda invocadas de forma síncrona retornarão um erro de controle de utilização (código de erro 429). As funções do Lambda que estiverem sendo invocadas de forma assíncrona poderão absorver intermitências de tráfego razoáveis por cerca de 15 a 30 minutos. Após esse intervalo, os eventos recebidos serão rejeitados como suspensos. Caso a função do Lambda esteja sendo invocada em resposta a eventos do Amazon S3, eventos rejeitados pelo AWS Lambda poderão ser retidos e repetidos pelo S3 por 24 horas. Eventos do Amazon Kinesis Streams e do Amazon DynamoDB Streams serão repetidos até que a função do Lambda seja bem-sucedida ou os dados expirem. Os streams do Amazon Kinesis e do Amazon DynamoDB retêm os dados por 24 horas.

O limite máximo padrão de execução simultânea é aplicado no nível da conta. No entanto, você também pode definir limites para funções individuais (acesse aqui para obter informações sobre Simultaneidade reservada).

Cada função do Lambda invocada de forma síncrona pode ser escalada a uma taxa de até 1000 execuções simultâneas a cada 10 segundos. Embora a taxa de escalabilidade do Lambda seja adequada para a maioria dos casos de uso, ela é especialmente ideal para aqueles com picos de tráfego previsíveis ou imprevisíveis. Por exemplo, o processamento de dados vinculado ao SLA exigiria um dimensionamento previsível, mas rápido, para atender à demanda de processamento. Da mesma forma, veicular notícias de última hora ou vendas instantâneas pode gerar níveis imprevisíveis de tráfego em um curto período de tempo. A taxa de escalabilidade do Lambda pode facilitar esses casos de uso sem configurações ou ferramentas adicionais. Além disso, o limite de escalonamento de simultaneidade é um limite de nível de função, o que significa que cada função em sua conta é dimensionada independentemente de outras funções.

Se a política de repetição de invocações assíncronas for excedida, será possível configurar uma "dead letter queue" (DLQ) em que o evento será inserido. Caso não exista uma DLQ configurada, o evento poderá ser rejeitado. Se a política de repetição de invocações com base em streams for excedida, os dados já terão expirado e, portanto, serão rejeitados.

Você concede permissões à sua função do Lambda para acessar outros recursos usando uma função do IAM. O AWS Lambda assume a função enquanto executa sua função do Lambda, para que você sempre mantenha controle total e seguro de quais recursos da AWS ela pode usar exatamente. Visite Configuração do AWS Lambda para saber mais sobre funções.

Quando você configura um bucket do Amazon S3 para enviar mensagens para uma função do AWS Lambda, uma regra de política de recursos é criada para conceder acesso. Consulte o Guia para desenvolvedores do Lambda para saber mais sobre as políticas de recursos e os controles de acesso das funções do Lambda.

Os controles de acesso são gerenciados pela função Lambda. O papel que você atribui à sua função Lambda também determina quais recursos o AWS Lambda pode sondar em seu nome. Consulte o Guia para desenvolvedores do Lambda para saber mais.

Você pode habilitar as funções do Lambda para acessar recursos em sua VPC especificando a sub-rede e o grupo de segurança como parte da configuração da função. Na configuração padrão, as funções do Lambda configuradas para acessar recursos em uma determinada VPC não têm acesso à Internet. Para conceder internet a essas funções, use gateways da internet. Por padrão, as funções do Lambda se comunicam com os recursos em uma VPC de pilha dupla via IPv4. Você pode configurar suas funções para acessar recursos em uma VPC de pilha dupla via IPv6. Para obter mais detalhes sobre as funções do Lambda configuradas com a VPC, consulte Rede privada do Lambda com a VPC.

A assinatura de código para o AWS Lambda oferece controles de confiança e integridade que permitem verificar se apenas o código inalterado de desenvolvedores aprovados é implantado nas funções Lambda. Use o AWS Signer, um serviço de assinatura de código totalmente gerenciado, para artefatos de código assinados digitalmente e configure suas funções do Lambda para verificar as assinaturas na implantação. A assinatura de código para o AWS Lambda está atualmente disponível apenas para funções empacotadas como arquivos ZIP.

Crie artefatos de código assinados digitalmente usando um Perfil de assinatura por meio do console do AWS Signer, da API Signer, do SAM CLI ou da AWS CLI. Para saber mais, consulte a documentação do AWS Signer.

O AWS Lambda pode realizar as seguintes verificações de assinatura na implantação:

• Assinatura corrompida: isto ocorre se o artefato do código foi alterado desde a assinatura.
• Assinatura incompatível – ocorre se o artefato de código for assinado por um perfil de assinatura que não foi aprovado.
• Assinatura expirada – ocorre se a assinatura já tiver passado da data de expiração configurada.
• Assinatura revogada – ocorre se o proprietário do perfil de assinatura revogar os trabalhos de assinatura.

Para saber mais, consulte a documentação do AWS Lambda.

Não há custo adicional ao usar a assinatura de código para AWS Lambda. Será pago o preço padrão pelo AWS Lambda. Para saber mais, consulte Preços.

Para oferecer uma experiência de logs simplificada e aprimorada por padrão, o AWS Lambda fornece controles avançados como a capacidade de capturar de modo nativo os logs de função do Lambda no formato estruturado JSON, controlar a filtragem no nível de log de função do Lambda sem alterar o código e personalizar o grupo de logs do Amazon CloudWatch para o qual o Lambda envia os logs.

Você pode capturar logs de função do Lambda no formato estruturado JSON sem precisar usar suas bibliotecas de logs. Os logs estruturados em JSON facilitam a pesquisa, a filtragem e a análise de grandes volumes de entradas de log. Você pode controlar a filtragem no nível do log de função do Lambda sem alterar o código, o que permite escolher o nível de granularidade de log exigido para as funções do Lambda sem filtrar grandes volumes de logs ao depurar e solucionar erros. Você também pode definir para qual grupo de logs do Amazon CloudWatch o Lambda envia logs, facilitando a agregação de logs de várias funções em uma aplicação em um só lugar. Em seguida, você pode aplicar políticas de segurança, governança e retenção aos logs no nível da aplicação, em vez de individualmente em cada função.

Você pode especificar controles avançados de logs para suas funções do Lambda usando a API do AWS Lambda, o console do AWS Lambda, a AWS CLI, o AWS Serverless Application Model (SAM) e o AWS CloudFormation. Para saber mais, acesse a publicação do blog de lançamento para ver os controles avançados de logs ou o Guia do desenvolvedor do Lambda.

Sim, você pode usar suas bibliotecas de logs para gerar logs do Lambda no formato estruturado JSON. Para garantir que suas bibliotecas de logs funcionem perfeitamente com o recurso de registro estruturado JSON nativo do Lambda, o Lambda não codificará duas vezes qualquer log gerado por sua função que já esteja codificado em JSON. Você também pode usar o Powertools para a biblioteca AWS Lambda para capturar logs do Lambda no formato estruturado JSON.

Não há cobrança adicional pelo uso de controles avançados de log no Lambda. Você continuará recebendo cobranças pela ingestão e armazenamento de seus logs do Lambda pelo Amazon CloudWatch Logs. Consulte a página de preços do CloudWatch para obter detalhes sobre preços de logs.

O CloudWatch Application Signals é uma solução de monitoramento de desempenho de aplicações (APM) que permite o fácil monitoramento por desenvolvedores e operadores da integridade e desempenho de aplicações sem servidor criados com o Lambda. O Application Signals fornece painéis pré-criados e padronizados para métricas críticas de aplicações, rastreamentos correlacionados e interações entre as funções do Lambda e suas dependências, tudo isso sem exigir instrumentação manual ou alterações de código dos desenvolvedores.

O CloudWatch Logs é um recurso interativo de fluxo e análise de logs que oferece visibilidade de logs em tempo real para facilitar o desenvolvimento e a solução de problemas de funções do Lambda. Isso permite que os desenvolvedores testem e validem rapidamente as alterações de código ou a configuração em tempo real para acelerar o ciclo autor-teste-implantação (também conhecido como “loop interno de desenvolvimento”) ao criar aplicações com o Lambda. A experiência do Live Tail também permite que operadores e equipes de DevOps detectem e depurem falhas e erros críticos no código de função do Lambda com mais eficiência para reduzir o tempo médio de recuperação (MTTR) ao solucionar erros de função do Lambda.

Use funções duráveis do Lambda quando quiser criar lógica dentro do modelo de programação familiar do Lambda, com testes locais, integração com IDE e sua linguagem de programação preferida. Use o AWS Step Functions quando precisar de design visual de fluxo de trabalho, visibilidade entre equipes, mais de 220 integrações de serviços nativos ou infraestrutura sem manutenção. Muitos aplicativos se beneficiam do uso dos dois juntos.

Atualmente, as funções duráveis do AWS Lambda oferecem suporte a JavaScript, TypeScript, Python e Java. Saiba mais sobre os runtimes compatíveis.

Para saber a disponibilidade mais recente, acesse a página de recursos da AWS por região.

Sim. Embora o tempo limite por invocação permaneça em 15 minutos, as funções duráveis do Lambda podem ser suspensas e retomadas em várias invocações usando recursos de espera, como temporizadores, retornos de chamada e condições de pesquisa. Quando você invoca funções duráveis de forma assíncrona, o tempo limite de execução durável pode se estender por até um ano, permitindo casos de uso como fluxos de trabalho de aprovação humana, lembretes programados e canais de processamento de vários dias. Para funções sob demanda, não há cobranças de computação durante a suspensão.

O tempo limite de execução (até 1 ano) determina quanto tempo uma execução dura. O período de retenção (até 90 dias) determina por quanto tempo os dados de histórico e de ponto de verificação são retidos após a execução atingir o estado terminal. A retenção não afeta as execuções em execução em andamento. Consulte Configuração de função durável.

Não. Para funções sob demanda, ao usar os recursos de espera do SDK de execução durável, não há cobranças de computação durante a suspensão. Para obter mais informações, consulte a página de preços e o guia do desenvolvedor.

Você pode agrupar cada unidade de trabalho em uma etapa com novas tentativas automáticas. Se uma etapa falhar depois de tentar novamente, seu código de gerenciador poderá detectar o erro e executar etapas de compensação, como reembolsar um pagamento ou liberar uma reserva. Como cada etapa concluída é verificada, incluindo compensações, o trabalho concluído com êxito não é repetido na nova tentativa. Esse padrão ajuda você a criar processos confiáveis de várias etapas, como fluxos de trabalho de atendimento de pedidos ou pagamento, sem criar uma lógica personalizada de repetição e rastreamento de estado.

O estado de execução é armazenado em um armazenamento de estado interno totalmente gerenciado. Cada operação com ponto de verificação, como uma etapa ou um retorno de chamada, pode armazenar até 256 KB de dados. Esse limite se aplica aos dados retornados da operação. Os dados operados em uma operação, como ler e gravar objetos grandes do S3, não contam para esse limite. Se uma operação precisar retornar um resultado grande, você poderá configurar serializadores personalizados no SDK para descarregar cargas para o Amazon S3 ou o Amazon DynamoDB e passar somente uma referência pelo ponto de verificação.

As funções duráveis do Lambda usam o mesmo pool de simultaneidade no nível da conta que as funções padrão do Lambda. Os slots de simultaneidade são liberados durante as esperas, então milhares de execuções podem esperar sem consumir simultaneidade. Saiba mais sobre as cotas do AWS Lambda.

Você pode testar funções duráveis localmente sem credenciais da AWS usando o SDK de execução durável para sua linguagem de programação compatível. A CLI do AWS SAM também oferece suporte a invocações locais, retornos de chamada e gerenciamento de execução durável, facilitando o desenvolvimento e a depuração antes da implantação. Saiba mais sobre como testar funções duráveis.