Perguntas frequentes sobre o AWS Lambda

Para melhorar o desempenho, o AWS Lambda pode escolher reter uma instância de sua função e reutilizá-la para atender a uma solicitação posterior em vez de criar uma nova cópia. Para saber mais sobre como o Lambda reutiliza instâncias de função, acesse a nossa documentação. Seu código não deve assumir que isso sempre acontecerá novamente.

É possível configurar cada função Lambda com armazenamento temporário próprio, entre 512 MB e 10.240 MB, em incrementos de 1 MB. O armazenamento temporário fica disponível em cada diretório /tmp da função.

Cada função tem acesso a 512 MB de armazenamento sem custo adicional. Ao configurar suas funções com mais de 512 MB de armazenamento temporário, a cobrança será feita com base no volume de armazenamento que você configurar e no tempo de execução da sua função, calculados em incrementos de 1 ms. Comparativamente, na região Leste dos EUA (Ohio), o preço do armazenamento temporário do AWS Fargate é de USD 0,000111 por GB/hora, ou USD 0,08 por GB/mês. O preço do volume de armazenamento gp3 do Amazon EBS no Leste dos EUA (Ohio) é de USD 0,08 por GB/mês. O preço do armazenamento temporário do AWS Lambda é de USD 0,0000000309 por GB/segundo, ou USD 0,000111 por GB/hora e USD 0,08 por GB/mês. Para saber mais, consulte Preços do AWS Lambda.

É possível usar as métricas do Lambda Insights do AWS CloudWatch para monitorar o seu uso do armazenamento temporário. Para saber mais, consulte a documentação do Lambda Insights do AWS CloudWatch.

Se a sua aplicação precisar de um armazenamento persistente e durável, considere usar o Simple Storage Service (Amazon S3) ou o Amazon EFS. Se a sua aplicação exigir que o armazenamento de dados necessários seja feito por código em uma única invocação de função, considere usar o armazenamento temporário do AWS Lambda como um cache transitório. Para saber mais, consulte Choosing between AWS Lambda data storage options in web apps (Escolha de opções de armazenamento de dados do AWS Lambda em aplicações da Web).

Sim. Contudo, se a sua aplicação precisar de um armazenamento persistente, considere usar o Amazon EFS ou o Simple Storage Service (Amazon S3). Quando você habilitar a simultaneidade provisionada para a sua função, o código de inicialização da sua função será executado durante a alocação e em intervalos de poucas horas, à medida que as instâncias em execução da sua função forem recicladas. Depois que uma instância processar uma solicitação, você poderá visualizar o tempo de inicialização nos logs e rastreamentos. Contudo, a inicialização será cobrada mesmo que a instância nunca processe solicitações. O comportamento de inicialização da simultaneidade provisionada pode afetar a maneira como a sua função interage com os dados que você mantém no armazenamento temporário, mesmo que sua função não esteja processando solicitações. Para saber mais sobre a simultaneidade provisionada, consulte a documentação relevante.

É possível usar as métricas do Lambda Insights do AWS CloudWatch para monitorar o seu uso do armazenamento temporário. Para saber mais, consulte a documentação do Lambda Insights do AWS CloudWatch.

Se você estiver usando o Node.js ou o Python, poderá criar o código para sua função usando o editor de códigos no console do AWS Lambda. Esse editor permite a criação e o teste das suas funções e também a visualização dos resultados das execuções das funções em um ambiente robusto e semelhante ao IDE. Vá para o console para começar.

Você também pode empacotar o código (e quaisquer bibliotecas dependentes) como um arquivo ZIP e carregá-lo usando o console do AWS Lambda do seu ambiente local ou especificar uma localização do Amazon S3 onde o arquivo ZIP esteja. Os arquivos para upload não devem ter mais de 50 MB (total comprimido). É possível usar o plugin do AWS Eclipse para criar e implantar funções do Lambda em Java. É possível usar o plugin do Visual Studio para criar e implantar funções do Lambda em C# e Node.js.

Você pode empacotar o código (e quaisquer bibliotecas dependentes) como um arquivo ZIP e carregá-lo usando o AWS CLI do seu ambiente local ou especificar uma localização do Amazon S3 onde o arquivo ZIP esteja. Os arquivos para upload não devem ter mais de 50 MB (total comprimido). Consulte o Guia de conceitos básicos do Lambda para começar.

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 servidor 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.

Você pode ajustar e proteger os recursos associados à sua função do Lambda usando a API ou o console do Lambda. Para saber mais sobre isso, consulte a documentação.

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 através 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.

O AWS Lambda integra-se automaticamente ao Amazon CloudWatch logs, criando um grupo de logs para cada função do Lambda e fornecendo entradas de log de eventos básicos do ciclo de vida do aplicativo, inclusive registrando os recursos consumidos para cada uso dessa função. Você pode inserir facilmente instruções de log adicionais em seu código. Pode também chamar APIs de log de terceiros em sua função do Lambda. Consulte a Solução de problemas de funções do Lambda para saber mais. As tarifas de logs do Amazon CloudWatch serão aplicadas.

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 definição de preço 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 níveis de preços com desconto para durações de funções sob demanda mensais acima de determinados limites. A precificação progressiva está disponível para funções em execução nas arquiteturas x86 e Arm. Os níveis de preço do Lambda são aplicados à duração sob demanda mensal agregada das suas funções em execução na mesma arquitetura (x86 ou Arm, respectivamente), na mesma região, na conta. Se você estiver usando faturamento consolidado no AWS Organizations, os níveis de preço serão aplicados à duração mensal agregada das suas funções em execução na mesma arquitetura, na mesma região, nas contas da organização. Por exemplo, quando você executa funções Lambda em x86 na região Leste dos EUA (Ohio), paga USD 0,0000166667 por cada GB-segundo para os primeiros 6 bilhões de GB-segundos por mês, USD 0,0000150000 por GB-segundo para os próximos 9 bilhões de GB-segundos por mês e USD 0,0000133334 por GB-segundo acima de 15 bilhões de GB-segundos por mês nessa região. Os preços de solicitações, simultaneidade provisionada e duração de simultaneidade provisionada não foram alterados. Para obter mais informações, consulte Preços do AWS Lambda

Sim. O uso do Lambda coberto pelo compromisso do seu plano de economia por hora é cobrado de acordo com a taxa e o desconto do CSP aplicável. O uso restante que não for coberto por este compromisso será cobrado na taxa correspondente ao nível em que a duração da função agregada mensal se enquadra.

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

Os eventos são passados para uma função do Lambda como um parâmetro de entrada de evento. Para origens de eventos em que os eventos chegam em lotes, como o Amazon SQS, Amazon Kinesis e Amazon DynamoDB Streams, o parâmetro de evento pode conter vários eventos em uma única chamada, com base no tamanho do lote que você solicitar. Para saber mais sobre notificações de eventos do Amazon S3, visite Configurar notificações para eventos do Amazon S3. Para saber mais sobre o Amazon DynamoDB Streams, acesse o Guia dos desenvolvedores do DynamoDB Stream. Para saber mais sobre como invocar funções do Lambda usando o Amazon SNS, acesse o Guia dos desenvolvedores do Amazon SNS. Para obter mais informações sobre eventos do Amazon Cognito, acesse Amazon Cognito. Para obter mais informações sobre logs do AWS CloudTrail e auditoria de chamadas de API em serviços da AWS, consulte AWS CloudTrail.

O AWS Lambda permite que você execute agregações baseadas em tempo (como contagem, máximo, soma, média etc.) em uma janela curta de até 15 minutos para os dados no Amazon Kinesis ou Amazon DynamoDB Streams, em uma única partição lógica, como um fragmento. Isso lhe dá a opção de configurar facilmente análises simples para a aplicação baseada em eventos sem adicionar complexidade de arquitetura, já que a lógica de negócios e a análise de dados podem estar localizadas na mesma função. O Lambda permite agregações em um período máximo de 15 minutos, com base no carimbo de data/hora do evento. O Amazon Kinesis Data Analytics permite criar aplicações analíticas mais complexas compatíveis com opções de processamento flexíveis e tolerância a falhas robusta com processamento exatamente uma vez sem duplicatas e com análises que podem ser realizadas em um fluxo de dados inteiro em várias partições lógicas. Com o KDA, é possível analisar dados em vários tipos de janelas de agregação (janela rotante, janela escalonada, janela deslizante, janela de sessão) usando o tempo do evento ou o tempo de processamento.
 

Primeiro, configure o alerta para enviar notificações do Amazon SNS. Em seguida, no console do AWS Lambda, selecione uma função e associe-a a esse tópico do Amazon SNS. Consulte o Guia para desenvolvedores do Amazon CloudWatch para obter mais detalhes de como configurar alertas do Amazon CloudWatch.

No console do AWS Lambda, você pode selecionar uma função para acionar quando qualquer conjunto de dados associado a um pool de identidades do Amazon Cognito for sincronizado. Essa mesma funcionalidade também está disponível no AWS SDK e no CLI. Acesse Amazon Cognito para obter mais informações sobre como usar o Amazon Cognito para compartilhar e sincronizar dados entre os dispositivos de um usuário.

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.

Faça o upload do código que deseja executar no AWS Lambda e invoque-o da sua aplicação móvel usando o SDK do AWS Lambda, fornecido com o AWS Mobile SDK. Você pode fazer chamadas diretas (síncronas) para recuperar ou verificar dados em tempo real, bem como chamadas assíncronas. Além disso, é possível definir uma API personalizada usando o Amazon API Gateway e invocar as funções Lambda por meio de qualquer cliente compatível com REST. Para saber mais sobre o AWS Mobile SDK, visite a página do AWS Mobile SDK. Para saber mais sobre o Amazon API Gateway, visite a página do Amazon API Gateway.

Você tem uma coleção de aplicações sem servidor publicados por desenvolvedores, empresas e parceiros na comunidade AWS para escolher usando o AWS Serverless Application Repository. Após encontrar uma aplicação, você pode configurá-la e implantá-la diretamente do console do Lambda.

Você pode automatizar seu processo de lançamento de aplicações sem servidor usando o AWS CodePipeline e o AWS CodeDeploy. O CodePipeline é um serviço de entrega contínua que permite modelar, visualizar e automatizar as etapas necessárias para liberar a aplicação sem servidor. O CodeDeploy fornece um mecanismo de automação de implantação para aplicativos baseados em Lambda. O CodeDeploy permite orquestrar implantações de acordo com as metodologias de melhores práticas estabelecidas, como implantações canary e lineares, e ajuda você a estabelecer os guardrails necessários para verificar a segurança, a estabilidade e a disponibilidade do código recém-implantado para ser totalmente lançado em produção.
 

Para saber mais sobre a CI/CD sem servidor, consulte a nossa documentação.

Para começar, acesse o console do AWS Lambda e faça o download de um dos nossos modelos. O arquivo que você fez download conterá um arquivo do AWS SAM (que define os recursos da AWS no seu aplicativo), e um arquivo .ZIP (que inclui o código da função). Você poderá usar os comandos do AWS CloudFormation para empacotar e implantar a aplicação sem servidor que você acabou de fazer download. Para obter mais detalhes, acesse a nossa documentação.

É possível usar o AWS Step Functions para coordenar uma série de funções do AWS Lambda em uma ordem específica. É possível invocar várias funções do Lambda sequencialmente, passando a saída de uma para a outra, e/ou em paralelo, e o Step Functions manterá o estado durante as execuções para você.

É possível habilitar a função do Lambda para rastreamento com o AWS X-Ray ao adicionar permissões do X-Ray à atribuição de execução da função do Lambda e alterar o "modo de rastreamento" da função para "ativo". Quando o X-Ray estiver habilitado para a sua função Lambda, o AWS Lambda emitirá informações de rastreamento para o X-Ray a respeito da sobrecarga de serviço do Lambda gerada ao chamar a função. Isso disponibilizará informações, como a sobrecarga de serviço do Lambda, a hora de inicialização da função e o tempo de execução. Além disso, é possível incluir o X-Ray SDK no pacote de implantação do Lambda para criar segmentos próprios de rastreamento, anotar rastreamentos ou visualizar segmentos de rastreamento para chamadas downstream feitas por meio da função do Lambda. No momento, os X-Ray SDKs estão disponíveis para Node.js e Java. Consulte a seção Solução de problemas de aplicações baseadas no Lambda para saber mais. As taxas do AWS X-Ray serão aplicadas.

Sim. Você pode criar aplicações sem servidor altamente escaláveis, seguros e baseados em Lambda que se conectam a bancos de dados relacionais usando o Amazon RDS Proxy, um proxy de banco de dados altamente disponível que gerencia milhares de conexões simultâneas com bancos de dados relacionais. Atualmente, o RDS Proxy oferece suporte para bancos de dados MySQL e Aurora. Você pode começar a usar o RDS Proxy através do console do Amazon RDS ou do console do AWS Lambda. Aplicações sem servidor que usam grupos de conexão totalmente gerenciados do RDS Proxy serão faturadas de acordo com os Preços do RDS Proxy.

A especificação no Apache 2.0 é de código aberto, o que permite que você e outros adotem e incorporem o AWS SAM em ferramentas de criação, implantação, monitoramento e gestão com uma licença para uso comercial. Você pode acessar o repositório do AWS SAM no GitHub aqui.

Existem três diferenças principais entre as funções criadas usando arquivos ZIP e imagens de contêiner:

1. As funções criadas usando arquivos ZIP têm um tamanho máximo de pacote de código de 250 MB descompactado e aquelas criadas usando imagens de contêiner têm um tamanho máximo de imagem de 10 GB. 
2. O Lambda usa Amazon ECR como o armazenamento de código subjacente para funções definidas como imagens de contêiner, portanto, uma função pode não ser invocável quando a imagem subjacente é excluída do ECR. 
3. As funções ZIP são corrigidas automaticamente para a segurança de tempo de execução e as correções de erros mais recentes. As funções definidas como imagens de contêiner são imutáveis e os clientes são responsáveis pelos componentes empacotados nas funções. Os clientes podem aproveitar as imagens de base fornecidas pela AWS, que são regularmente atualizadas pela AWS para segurança e correções de erros, usando os patches mais recentes disponíveis.

Não há cobrança adicional para empacotar e implantar funções como imagens de contêiner para AWS Lambda. Ao invocar a função implantada como uma imagem de contêiner, você paga o preço normal pelas solicitações e duração da execução. Para saber mais, consulte a preços do AWS Lambda. Você será cobrado por armazenar as imagens de contêiner no Amazon ECR de acordo com os preços do ECR padrão. Para saber mais, consulte a Preços do Amazon ECR.

O Lambda Runtime Interface Emulator é um proxy para a API Runtime do Lambda, que permite aos clientes testarem localmente sua função do Lambda empacotada como uma imagem de contêiner. Ele é um servidor da Web leve que converte solicitações HTTP em eventos JSON e emula a API Runtime do Lambda. Ele permite testar localmente suas funções usando ferramentas familiares, como cURL e Docker CLI (ao testar funções empacotadas como imagens de contêiner). Ele também simplifica a execução de sua aplicação em serviços de computação adicionais. É possível incluir o Lambda Runtime Interface Emulator na imagem de contêiner para que ele aceite solicitações HTTP nativamente em vez dos eventos JSON necessários para implantação no Lambda. Este componente não emula o orquestrador do Lambda, ou configurações de segurança e autenticação. O Runtime Interface Emulator é um código aberto no GitHub. Comece fazendo o download e instalando-o em sua máquina local.

Os clientes podem adicionar o Runtime Interface Emulator como o ponto de entrada para a imagem do contêiner ou empacotá-lo como um arquivo secundário para garantir que a imagem do contêiner agora aceite solicitações HTTP em vez de eventos JSON. Isso simplifica as mudanças necessárias para executar a imagem de contêiner em serviços de computação adicionais. Os clientes serão responsáveis por garantir que todas as melhores práticas de segurança, performance e concorrência sejam seguidas para o ambiente escolhido. O RIE é pré-empacotado nas imagens fornecidas pelo AWS Lambda e está disponível por padrão no AWS SAM CLI. Os provedores de imagens base podem usar a documentação para fornecer a mesma experiência para as imagens base deles.

É possível implantar uma aplicação em contêiner no AWS Lambda se ela atender aos requisitos abaixo:

1. A imagem do contêiner deve implementar a API Lambda Runtime. Criamos um conjunto de pacotes de software em código aberto, o Runtime Interface Clients (RIC), que implementa a API Runtime do Lambda. Isso permite que você estenda perfeitamente as imagens base preferidas para que sejam compatíveis com o Lambda.
2. A imagem do contêiner deve ser executada em um sistema de arquivos somente leitura. O código de função pode acessar um armazenamento de diretório gravável /tmp de 512 MB. Se você estiver usando uma imagem que requer um diretório raiz gravável, configure-a para gravar no diretório /tmp.
3. Os arquivos necessários para a execução do código de função podem ser lidos pelo usuário Lambda padrão. O Lambda define um usuário Linux padrão com permissões de privilégios mínimos que seguem as práticas recomendadas de segurança. Verifique se o código da aplicação não depende de arquivos restritos por outros usuários do Linux para execução.
4. É uma imagem de contêiner baseada em Linux.

O AWS 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.

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 tempos de execução, 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 tempos de execução serão compatíveis após serem lançadas. Para obter todos os tempos de execução compatíveis com o Lambda, consulte a documentação de tempos de execução 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ê pode configurar o Lambda SnapStart para funções executadas em arquiteturas x86 e Arm.

Sim. Se o seu código assume a exclusividade do estado, você precisa avaliar a resiliência do código para operações de snapshot (como ser clonado e retomado). Para saber mais sobre considerações de exclusividade com o Lambda SnapStart, consulte a documentação e o blog sobre compreensão da exclusividade em snapshots de VM com o Lambda SnapStart.

Sim. Você pode implementar sua própria lógica de software antes de criar (verificar) um snapshot e depois de restaurá-lo usando ganchos de tempo de execução. Para saber mais, consulte a documentação do Lambda SnapStart.

Sim, você será cobrado pelo armazenamento em cache de um instantâneo 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 sua função. Você também é cobrado 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.

Como todas as funções do Lambda, as cobranças de duração se aplicam às funções do SnapStart. Para funções que usam o SnapStart, a duração inclui o tempo de carregamento do tempo de execução, qualquer código executado em um hook de runtime e o código de inicialização executado ao criar cópias instantâneas para resiliência.

Com o Lambda SnapStart para Python e .NET, seus snapshots de função permanecem ativos enquanto sua função estiver ativa. Para funções Java, o instantâneo associado a uma função publicada expira se ela permanecer inativa por mais de 14 dias.

Os snapshots são criptografados por padrão com chaves exclusivas do AWS Key Management Service (KMS) pertencentes e gerenciadas pelo serviço do Lambda. Também é possível criptografar snapshots usando uma chave KMS pertencente e gerenciada pelo cliente.

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.

Linguagens interpretadas como Python, Java e Node geralmente não requerem recompilação, a menos que seu código faça referência a bibliotecas que usem componentes específicos da arquitetura. Nesses casos, você precisaria fornecer as bibliotecas destinadas à arquitetura arm64. Para obter mais detalhes, consulte a página Conceitos básicos do AWS Graviton. Linguagens não interpretadas exigirão a compilação de seu código para a arquitetura arm64 de destino. Embora compiladores mais modernos produzam código compilado para a arquitetura arm64, você precisará implantá-lo em um ambiente baseado na arquitetura ARM para teste. Para saber mais sobre como usar as funções do Lambda com o Graviton2, consulte a documentação.

Na ativação, os clientes podem usar Python, Node.js, Java, Ruby, .Net Core, tempo de execução personalizado (provided.al2) e imagens OCI. Para saber mais, consulte os runtimes do AWS Lambda.

Cada workload é única, e recomendamos que os clientes testem suas funções para determinar a melhoria da performance de preço que podem verificar. Para fazer isso, recomendamos o uso da ferramenta AWS Lambda Power Tuning. Recomendamos começar com backends da Web e móveis, dados e processamento de fluxo ao testar suas workloads para verificar possíveis melhorias de performance de preço.

Os desenvolvedores podem conectar facilmente um sistema de arquivos EFS existente a uma função do Lambda por meio de um Ponto de acesso do EFS usando o console, CLI ou SDK. Quando a função é invocada pela primeira vez, o sistema de arquivos é montado e disponibilizado automaticamente para o código da função. Você pode saber mais na documentação.

Não há custo adicional para o uso do Amazon EFS para AWS Lambda. Os clientes pagam o preço padrão pelo AWS Lambda e pelo Amazon EFS. Ao usarem o Lambda e o EFS na mesma zona de disponibilidade, os clientes não são cobrados pela transferência de dados. No entanto, se eles usarem o emparelhamento da VPC para acesso entre contas, taxas de transferência de dados serão cobradas. Para saber mais, consulte Preços.

Você pode configurar um URL de função no Console de Gerenciamento da AWS, pela API do AWS Lambda, pela AWS Command Line Interface (AWS CLI), pelo AWS CloudFormation e pelo AWS Serverless Application Model (SAM). URLs de função podem ser habilitados na versão $LATEST não qualificada da sua função ou em qualquer alias de função. Para saber mais sobre como configurar um URL de função, consulte a documentação.

Sim. URLs de funções Lambda podem ser habilitados em uma função ou em um alias de função. Se nenhum alias for especificado, por padrão, o URL indicará $LATEST. URLs de funções não podem ser direcionados para uma versão de função específica.

Não há custo adicional para o uso de URLs de funções. Será pago o preço padrão do AWS Lambda. Para saber mais, 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.

As funções serão acionadas automaticamente em resposta aos seguintes eventos do Amazon CloudFront:

• Solicitação do visualizador: este evento ocorre quando um usuário final ou um dispositivo na Internet faz uma solicitação de HTTP(S) ao CloudFront e a solicitação chega ao local da borda mais próximo do usuário.
• Resposta do visualizador – esse evento ocorre quando o servidor CloudFront no ponto de presença está pronto para responder ao usuário final ou dispositivo que enviou a solicitação.
• Solicitação para origem: este evento ocorre quando o servidor CloudFront na borda não tem o objeto solicitado no cache e a solicitação do visualizador está pronta para ser enviada ao servidor Web de origem no backend (por exemplo, Amazon EC2, Application Load Balancer ou Amazon S3).
• Resposta da origem: este evento ocorre quando o servidor CloudFront na borda recebe uma resposta do servidor Web de origem no backend.

A diferença é que o API Gateway e o Lambda são serviços regionais. O uso do Lambda@Edge e do Amazon CloudFront permite executar lógica em vários locais da AWS de acordo com o posicionamento dos visualizadores finais.

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 do 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á sendo cobrado 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.

É possível ativar o Application Signals para a função com um único clique na seção “ferramentas operacionais e de monitoramento” na guia de configuração do console do Lambda. Depois de ativar o Application Signals, é possível visualizar os painéis pré-criados, mapas de serviços e muito mais, além de analisar o desempenho e a integridade de suas aplicações sem servidor no console do CloudWatch. Para saber mais, acesse o guia do desenvolvedor do Lambda e o guia do desenvolvedor do Application Signals. Acesse a página de preços do CloudWatch para saber mais detalhes sobre como o uso do Application Signals com as funções do Lambda é cobrado.

O CloudWatch Logs é um recurso interativo de fluxo e analytics 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.

Para usar o Live Tail para a função do Lambda, acesse o console do Lambda e clique no botão “Abrir CloudWatch Live Tail” no editor de código. Para obter mais informações, consulte o guia do desenvolvedor. Acesse a página de preços do CloudWatch para saber mais detalhes sobre como o uso do Live Tail com as funções do Lambda é cobrado.

Você pode usar ferramentas padrão como Maven ou Gradle para compilar a sua função do Lambda. O seu processo de compilação deve imitar o mesmo processo de compilação usado para qualquer código Java que depende do AWS SDK. Execute a sua ferramenta de compilação Java nos arquivos fonte e inclua o AWS SDK 1.9 ou posterior com dependências transitivas no seu classpath. Para obter mais detalhes, consulte a nossa documentação.

Sim. Você pode usar pacotes NPM, bem como pacotes personalizados. Saiba mais aqui.

Sim. O sandbox interno do Lambda permite executar scripts (“shell”) em lote, outros runtimes de linguagem, rotinas de utilitários e executáveis. Saiba mais aqui.

Sim. Qualquer módulo nativo vinculado estaticamente pode ser incluído no arquivo ZIP para upload, bem como módulos compilados dinamicamente com rpath apontando para o diretório raiz da função do Lambda. Saiba mais aqui.

Sim. Você pode usar o comando child_process do Node.js para executar um binário incluído em sua função ou qualquer executável do Amazon Linux que seja visível para sua função. Como alternativa, existem vários pacotes NPM que encapsulam binários de linha de comando, como node-ffmpeg. Saiba mais aqui.

Para implantar uma função do Lambda codificada em Node.js, basta empacotar o código Javascript e as bibliotecas dependentes como um arquivo ZIP. Você pode fazer o upload do ZIP do seu ambiente local ou especificar uma localização do Amazon S3 onde o arquivo ZIP esteja. Para obter mais detalhes, consulte a nossa documentação.

Um pacote de implantação do Lambda para PowerShell é um arquivo ZIP que contém o script do PowerShell, os módulos do PowerShell necessários para o seu script do PowerShell e as montagens necessárias para hospedar o PowerShell Core. Assim, use o módulo PowerShell do AWSLambdaPSCore, que pode ser instalado da PowerShell Gallery, para criar seu pacote de implantação do PowerShell Lambda.

Faça o upload de seu artefato executável do Go como um arquivo ZIP por meio do console do AWS CLI ou Lambda e selecionar o tempo de execução go1.x. Com o Lambda, você pode usar as ferramentas nativas do Go para criar e empacotar seu código. Leia nossa documentação para obter mais detalhes. 

É possível ver a lista de versões compatíveis aqui.

Não, o AWS Lambda oferece uma única versão do sistema operacional e tempo de execução de linguagem gerenciada para todos os usuários do serviço. Você pode trazer seu próprio tempo de execução de linguagem para usar no Lambda.

É possível usar o Amazon Step Functions para coordenar várias invocações de funções do Lambda. É possível invocar várias funções do Lambda em série, passando a saída de uma para a outra, ou em paralelo. Consulte a nossa documentação para obter mais detalhes.