Perguntas frequentes sobre o AWS Lambda

O código que você executa no AWS Lambda é carregado como uma "função do Lambda". Cada função tem informações de configuração associadas, como nome, descrição, ponto de entrada e requisitos de recurso. O código deve ser escrito em estilo "stateless", ou seja, deve assumir que não há afinidade com a infraestrutura de computação adjacente. O acesso ao sistema de arquivo local, processos filhos e itens semelhantes não podem se estender além da duração da solicitação, e qualquer estado persistente deve ser armazenado no Amazon S3, no Amazon DynamoDB, Amazon EFS ou em outro serviço de armazenamento disponível na Internet. As funções do Lambda podem incluir bibliotecas, até mesmo nativas.

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 configurar cada função Lambda com seu próprio armazenamento temporário entre 512 MB e 10.240 MB em incrementos de 1 MB usando o console do AWS Lambda, a API do AWS Lambda ou o modelo do AWS CloudFormation na criação ou atualização da função.

Sim. Todos os dados mantidos no armazenamento temporário são criptografados quando inativos com uma chave gerenciada pela AWS.

É 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 configurar cada função Lambda com seu próprio armazenamento temporário entre 512 MB e 10.240 MB em incrementos de 1 MB usando o console do AWS Lambda, a API do AWS Lambda ou o modelo do AWS CloudFormation na criação ou atualização da função.

Sim. Todos os dados mantidos no armazenamento temporário são criptografados quando inativos com uma chave gerenciada pela AWS.

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

Manter as funções como stateless permite que o AWS Lambda lance rapidamente quantas cópias da função forem necessárias para oferecer escalabilidade para a taxa de eventos de entrada. Embora o modelo de programação do AWS Lambda seja sem estado, seu código pode acessar dados com estado chamando outros serviços web, como o Amazon S3 ou o Amazon DynamoDB.

Sim. O AWS Lambda permite que você use linguagem normal e recursos do sistema operacional, como criação de threads e processos adicionais. Os recursos alocados para a função do Lambda, inclusive memória, tempo de execução, disco e uso de rede, devem ser compartilhados entre todos os threads/processos que ela utiliza. É possível iniciar processos utilizando qualquer linguagem suportada pelo Amazon Linux.

O Lambda tenta impor o menor número possível de restrições sobre as atividades normais da linguagem e do sistema operacional, mas algumas atividades são desativadas: conexões de rede de entrada são bloqueadas pelo AWS Lambda e, para conexões de saída, apenas os soquetes TCP/IP e UDP/IP são permitidos, e as chamadas de sistema ptrace (depuração) são bloqueadas. O tráfego da porta 25 do TCP também é bloqueado como medida antispam.

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.

Você não precisa obter escalabilidade das suas funções do Lambda – o AWS Lambda faz a escalabilidade automaticamente para você. Toda vez que uma notificação de evento é recebida para sua função, o AWS Lambda rapidamente localiza capacidade livre na sua frota de computação e executa seu código. Como seu código é stateless, o AWS Lambda pode iniciar quantas cópias de sua função forem necessárias sem implementações demoradas e atrasos de configuração. Não há limites fundamentais de escalabilidade para uma função. O AWS Lambda alocará capacidade dinamicamente para atender à taxa de eventos de entrada.

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.

Os clientes que executam workloads com uso intenso de memória ou computação agora podem usar mais memória para as funções. Funções de memória maiores ajudam aplicações que usam multiencadeamento a rodar mais rápido, tornando-os ideais para dados e aplicações de computação intensiva, como machine learning, trabalhos em lote e ETL, modelagem financeira, genômica, HPC e processamento de mídia.

As funções do AWS Lambda podem ser configuradas para execução por até 15 minutos de cada vez. Você pode definir o tempo limite em qualquer valor entre 1 segundo e 15 minutos.

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. Além de economizar dinheiro no Amazon EC2 e no AWS Fargate, você também pode usar o Compute Savings Plans para economizar no AWS Lambda. Os Compute Savings Plans oferecem até 17% de desconto em Duração, Simultaneidade provisionada e Duração (Simultaneidade provisionada). Os Compute Savings Plans não oferecem desconto em Solicitações na sua fatura do Lambda. No entanto, seu compromisso com os Compute Savings Plans pode ser aplicado às Solicitações sob as taxas regulares.

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.

Os tempos de implementação podem variar com o tamanho do seu código, mas as funções do AWS Lambda estão tipicamente prontas em segundos após o upload.

Sim. Você pode incluir sua própria cópia de uma biblioteca (incluindo o AWS SDK) para usar uma versão diferente da versão padrão disponibilizada pelo AWS 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.

Uma fonte de evento é um serviço da AWS ou aplicativo criado por desenvolvedor que gera eventos que acionam a execução de uma função do AWS Lambda. Alguns serviços publicam esses eventos no Lambda invocando a função de nuvem diretamente (por exemplo, o Amazon S3). O Lambda também pode sondar recursos em outros serviços que não publicam eventos no Lambda. Por exemplo, o Lambda pode extrair registros de um stream do Amazon Kinesis ou de uma fila do Amazon SQS e executar uma função do Lambda para cada mensagem retornada. Muitos outros serviços, como o AWS CloudTrail, podem atuar como fontes de eventos simplesmente fazendo login no Amazon S3 e usando notificações de buckets do S3 para acionar funções do AWS Lambda

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.

No console do AWS Lambda, você pode selecionar uma função e associá-la a notificações de um bucket do Amazon S3. Como alternativa, você pode usar o console do Amazon S3 e configurar as notificações do bucket para enviar para sua função do AWS Lambda. Essa mesma funcionalidade também está disponível no AWS SDK e no CLI.

Você pode acionar uma função Lambda em atualizações de tabela do DynamoDB assinando a função Lambda para a transmissão do DynamoDB associada à tabela. Você pode associar uma transmissão do DynamoDB com uma função Lambda usando o console do Amazon DynamoDB, o console do AWS Lambda ou a API registerEventSource do Lambda.

No console do AWS Lambda, você pode selecionar uma função e associá-la a um stream do Amazon Kinesis pertencente à mesma conta. Essa mesma funcionalidade também está disponível no AWS SDK e no CLI.

Os registros do Amazon Kinesis e do Streams do DynamoDB enviados à função do AWS Lambda são rigorosamente serializados por fragmento. Isso significa que, se você colocar dois registros no mesmo fragmento, o Lambda garantirá que sua função do Lambda seja invocada com êxito com o primeiro registro antes de ser invocada com o segundo registro. Se o tempo limite da invocação de um registro se esgotar, for controlado ou encontrar qualquer outro erro, o Lambda tentará novamente até ter êxito (ou até que o registro alcance a expiração de 24 horas) antes de mudar para o próximo registro. A ordem dos registros entre fragmentos diferentes não é garantida, e o processamento de cada fragmento ocorre em paralelo.

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.
 

	AWS Lambda	Amazon KDA
Janela rotante	Sim	Sim
Janela escalonada	Não	Sim
Janela deslizante	Não	Sim
Janela de sessão	Não	Sim
Enriquecimento de dados	Não	Sim
Entrada conjunta e tabelas de referência	Não	Sim
Dividir fluxo de entrada	Não	Sim
Processamento exatamente uma vez	Não	Sim
Janela de tempo máximo	15 minutos	Sem limite
Escopo de agregação	Partição/fragmento	Stream
Semântica de tempo	Tempo do evento	Tempo do evento, tempo de processamento

No console do AWS Lambda, você pode selecionar uma função e associá-la a um tópico do Amazon SNS. Essa mesma funcionalidade também está disponível no AWS SDK e no CLI.

No Console do Amazon SES, você pode configurar sua regra de recebimento para fazer com que o Amazon SES entregue suas mensagens para uma função do AWS Lambda. A mesma funcionalidade está disponível no AWS SDK e no CLI.

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.

O AWS Lambda é projetado para processar eventos em alguns milissegundos. A latência será maior imediatamente após a criação ou a atualização de uma função do Lambda ou se ela não tiver sido usada recentemente.

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.

É possível invocar uma função Lambda por meio de HTTPS definindo uma API RESTful personalizada no Amazon API Gateway. O resultado é um endpoint para a sua função que pode responder a chamadas REST como GET, PUT e POST. Leia mais sobre o uso do AWS Lambda com o Amazon API Gateway.

Quando são chamadas pelo AWS Mobile SDK, as funções do AWS Lambda ganham visibilidade imediatamente do dispositivo e do aplicativo que fez a chamada através do objeto ‘context’.

Quando sua aplicação usa a identidade do Amazon Cognito, os usuários finais podem se autenticar usando uma variedade de provedores de login públicos, como o Amazon, Facebook, Google e outros serviços compatíveis com OpenID Connect. Então, a identidade do usuário é apresentada de maneira automática e segura à sua função do Lambda sob a forma de um ID do Amazon Cognito, permitindo acessar dados de usuários a partir do Amazon Cognito, ou como uma chave para armazenar e recuperar dados no Amazon DynamoDB ou outros web services.

O AWS Lambda é integrado ao Alexa Skills Kit, um conjunto de APIs, ferramentas, documentação e exemplos de código de autoatendimento que facilitam criar recursos acionados por voz (ou "habilidades") para a Alexa. Basta fazer o upload do código da função Lambda para a nova habilidade da Alexa que você está criando e o AWS Lambda fará o resto, executando esse código em resposta a interações de voz da Alexa e gerenciando automaticamente os recursos de computação para você. Leia a documentação do Alexa Skills Kit para obter mais detalhes.

Para notificações do bucket do Amazon S3 e eventos personalizados, o AWS Lambda tentará executar sua função três vezes em caso de condição de erro no seu código ou se você exceder um limite de serviço ou de recurso. Para fontes de eventos ordenados que o AWS Lambda sonda para você, como Amazon DynamoDB Streams e Amazon Kinesis Streams, o Lambda continuará tentando executar em caso de erro de código do desenvolvedor até que os dados expirem. Você pode monitorar o progresso através dos consoles do Amazon Kinesis e do Amazon DynamoDB e através das métricas do Amazon CloudWatch que o AWS Lambda gera para sua função. Você também pode definir alertas do Amazon CloudWatch com base nas taxas de erro ou de suspensão da execução.

As aplicações baseadas no Lambda (também conhecidas como aplicações sem servidor) são compostas de funções acionadas por eventos. Um aplicativo sem servidor comum consiste em uma ou mais funções acionadas por eventos, como uploads de objetos no Amazon S3, notificações do Amazon SNS ou ações de API. Essas funções podem ser independentes ou utilizar outros recursos, como tabelas do DynamoDB ou buckets do Amazon S3. A aplicação sem servidor mais básica é apenas uma função.

É possível implantar e gerenciar suas aplicações sem servidor usando o AWS Serverless Application Model (AWS SAM). O AWS SAM é uma especificação que prescreve as regras para expressar aplicações sem servidor na AWS. Essa especificação alinha-se à sintaxe usada pelo AWS CloudFormation atualmente e é compatível de modo nativo no AWS CloudFormation como um conjunto de tipos de recurso (conhecido como "recursos sem servidor"). Esses recursos facilitam para os clientes da AWS usar o CloudFormation para configurar e implantar aplicações sem servidor, usando APIs atuais do CloudFormation.

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.

O AWS Lambda agora permite empacotar e implantar funções como imagens de contêiner. Os clientes podem aproveitar a flexibilidade e familiaridade das ferramentas de contêiner e a agilidade e simplicidade operacional do AWS Lambda para criar aplicações.

Comece com imagens de base fornecidas pela AWS para o Lambda ou usando uma de suas imagens preferidas de comunidade ou empresa privada. Em seguida, basta usar o Docker CLI para construir a imagem, fazer upload para o Amazon ECR e, em seguida, criar a função usando todas as interfaces e ferramentas familiares do Lambda, como o Console de Gerenciamento da AWS, a AWS CLI, o AWS SDK, o AWS SAM e o AWS CloudFormation.

É possível implantar imagens de base do Linux de terceiros (por exemplo, Alpine ou Debian) no Lambda, além das imagens fornecidas pelo Lambda. O AWS Lambda será compatível com todas as imagens com base nos seguintes formatos de manifesto de imagem: Docker Image Manifest V2 Schema 2 (usado com Docker versão 1.10 e mais recente) ou Open Container Initiative (OCI) Spec (v1.0 e superior). O Lambda é compatível com imagens com um tamanho de até 10 GB.

O AWS Lambda fornece uma variedade de imagens de base que os clientes podem estender; eles também podem usar as imagens preferidas baseadas em Linux com um tamanho de até 10 GB.

Você pode usar qualquer ferramenta de contêiner, desde que ela seja compatível com um dos seguintes formatos de manifesto de imagem de contêiner: Docker Image Manifest V2 Schema 2 (usado com Docker versão 1.10 e mais recente) ou Especificações da Open Container Initiative (OCI) (v1.0 e superior). Por exemplo, é possível usar ferramentas de contêiner nativas (como docker run, docker compose, Buildah e Packer) para definir funções como uma imagem de contêiner e implantação no Lambda.

Todos os recursos existentes do AWS Lambda, com exceção das camadas Lambda e da assinatura de código, podem ser usados com funções implantadas como imagens de contêiner. Uma vez implantado, o AWS Lambda tratará uma imagem como imutável. Os clientes podem usar camadas de contêiner durante o processo de criação para incluir dependências.

Não neste momento. A imagem, uma vez implantada no AWS Lambda, não poderá ser modificada. O serviço não corrigirá ou atualizará a imagem. No entanto, o AWS Lambda publicará imagens de base com curadoria para todos os tempos de execução compatíveis que são baseados no ambiente gerenciado pelo Lambda. Essas imagens publicadas serão corrigidas e atualizadas junto com as atualizações dos tempos de execução gerenciados do AWS Lambda. É possível extrair e usar a imagem de base mais recente do DockerHub ou do Amazon ECR Public, reconstruir a imagem de contêiner e implantar no AWS Lambda por meio do Amazon ECR. Isso permite que criar e testar as imagens e runtimes atualizados antes de implantar a imagem para produção

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 - o AWS Lambda garante que os perfis de performance para funções empacotadas como imagens de contêiner sejam iguais àquelas empacotadas como arquivos ZIP, incluindo tempos de inicialização normalmente inferiores a um segundo.

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.

A API Runtime do Lambda no serviço do Lambda em execução aceita eventos JSON e retorna respostas. O Lambda Runtime Interface Emulator permite que a função empacotada como uma imagem de contêiner aceite solicitações de HTTP durante o teste local com ferramentas como cURL e as exiba localmente por meio da mesma interface para a função. Ele permite usar o comando docker run ou docker-compose up para testar localmente a aplicação lambda.

Use o emulador para testar se o código de função é compatível com o ambiente Lambda, se é executado com êxito e se fornece o resultado esperado. Por exemplo, é possível simular eventos de teste de diferentes origens de eventos. Também é possível usá-lo para testar extensões e agentes integrados à imagem do contêiner em relação à API Lambda Extensions.

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 Lambda SnapStart para Java oferece uma performance de inicialização da função até dez vezes mais rápida. Para funções sob demanda, a fase de inicialização (na qual o AWS Lambda carrega o código da função e inicializa as dependências externas) é a maior contribuinte para a latência de inicialização e ocorre na primeira invocação. Com o Lambda SnapStart, o Lambda inicializa o código da função de inicialização única com antecedência quando você publica uma versão da função, e não quando você invoca a função pela primeira vez. Em seguida, o Lambda faz um snapshot e armazena em cache a memória e o estado do disco do ambiente de execução inicializado. Quando você invoca a função (e conforme a escala aumenta verticalmente), o Lambda retoma a função do snapshot armazenado em cache, em vez de inicializar a função do zero.

O Lambda SnapStart é uma configuração em nível de função simples, que pode ser definida para funções Java 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 performance que ajuda suas funções Java a obter tempos de inicialização até 10 vezes mais rápidos, reduzindo a latência variável que ocorre durante a execução do código de inicialização única. O Lambda SnapStart funciona amplamente em todas as funções da aplicação ou conta, sem nenhum custo adicional. Quando um cliente publica uma versão de função com Lambda SnapStart, o código da função é inicializado antecipadamente, em vez de ser inicializado na primeira invocação. Em seguida, o Lambda faz um snapshot do ambiente de execução inicializado e o mantém em um cache em camadas para acesso de baixa latência. Quando a função é invocada pela primeira vez e depois escalada, o Lambda retoma a função do snapshot em cache, em vez de inicializar do zero, gerando uma latência de inicialização mais baixa. 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 é compatível com o tempo de execução do Java 11. Versões futuras do Java terão compatibilidade após o lançamento. Para obter todos os tempos de execução compatíveis com o Lambda, consulte a documentação de tempos de execução do Lambda.

Não. Lambda SnapStart e Simultaneidade provisionada não podem ser ativados ao mesmo tempo, na mesma função.

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.

Não. Por enquanto, você pode configurar o Lambda SnapStart apenas para funções em execução na arquitetura x86.

Não. Não é possível, neste momento, habilitar o Lambda SnapStart com o Amazon EFS.

Não. Você não pode habilitar o Lambda SnapStart com armazenamento temporário maior (/tmp), que ultrapasse 512 MB.

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.

Não. Não há custo adicional para habilitar o Lambda SnapStart. Você é cobrado com base no número de solicitações para suas funções e a duração para a execução do código, com base nos preços do Lambda atuais. As cobranças de duração se aplicam ao código que é executado no processador de uma função e nos ganchos de tempo de execução, além do código de inicialização que é declarado fora do processador. Observe que o AWS Lambda pode reciclar periodicamente ambientes de execução com patches de segurança e executar novamente seu código de inicialização. Para obter mais detalhes, consulte a documentação do Modelo de programação do Lambda.

Com o Lambda SnapStart, o Lambda mantém um snapshot do ambiente de execução inicializado para as últimas três versões de funções publicadas, desde que as versões publicadas continuem recebendo invocações. O snapshot associado a uma versão de função publicada expira se ele permanece inativo 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.

A duração máxima de inicialização permitida para o Lambda SnapStart corresponderá à duração do tempo limite de execução que você configurou para a função. O limite máximo de tempo limite de execução configurável para uma função é de 15 minutos.

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.

Você não precisa fazer alterações no seu código para usar a Simultaneidade provisionada. Ela funciona perfeitamente com todas as funções e tempos de execução existentes. Não há alterações no modelo de chamada e execução do Lambda ao usar a Simultaneidade provisionada.

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.

A Simultaneidade provisionada é ideal para criar aplicativos sensíveis à latência, como back-end da Web ou móveis, APIs invocadas de forma síncrona e microsserviços interativos. Você pode configurar facilmente a quantidade apropriada de simultaneidade com base na demanda exclusiva do seu aplicativo. Você pode aumentar a quantidade de simultaneidade durante períodos de alta demanda e reduzi-la ou desativá-la completamente quando a demanda diminuir.

Se a simultaneidade de uma função atingir o nível configurado, as chamadas subsequentes dessa função terão as características de latência e escala das funções regulares do Lambda. Você pode restringir sua função para aumentar apenas o nível configurado. Fazer isso impede que a função exceda o nível configurado de Simultaneidade provisionada. Este é um mecanismo para evitar variabilidade indesejada na sua aplicação quando a demanda exceder a quantidade prevista.

O AWS Lambda permite que você execute suas funções em processadores baseados na arquitetura x86 ou na arquitetura ARM. Os processadores AWS Graviton2 são desenvolvidos de forma personalizada pela Amazon Web Services usando núcleos ARM Neoverse de 64 bits para oferecer melhor performance de preço para suas workloads na nuvem. Os clientes obtêm as mesmas vantagens do AWS Lambda, executando código sem provisionamento ou gerenciamento de servidores, com escalabilidade automática e alta disponibilidade e pagando apenas pelos recursos consumidos.

As funções do AWS Lambda com processadores Graviton2, que utilizam uma arquitetura de processador baseada em ARM projetada pela AWS, são projetadas para oferecer performance de preço até 34% melhor em comparação com funções executadas em processadores x86, para uma variedade de workloads sem servidor, como backends da Web e móveis, dados e processamento de fluxo de dados. Com latência mais baixa, performance até 19% melhor, custo 20% menor e a maior eficiência de energia disponível atualmente na AWS, as funções do Graviton2 podem alimentar aplicações sem servidor essenciais à missão. Os clientes podem configurar funções novas e existentes para direcionar ao processador Graviton2. Eles podem implantar funções em execução no Graviton2 como arquivos zip ou imagens de contêiner.

Você pode configurar funções para serem executadas no Graviton2 por meio do Console de Gerenciamento da AWS, da API do AWS Lambda, da AWS CLI e do AWS CloudFormation definindo a referência de arquitetura como “arm64” para sua função.

Não há mudança entre as funções baseadas nas arquiteturas x86 e ARM. Basta carregar seu código por meio do Console de Gerenciamento da AWS, de um arquivo zip ou de uma imagem de contêiner, e o AWS Lambda executará automaticamente seu código quando acionado, sem exigir que você provisione ou gerencie a infraestrutura.

Uma aplicação pode conter funções em execução em ambas as arquiteturas. O AWS Lambda permite que você altere a arquitetura (“x86_64” ou “arm64”) da versão atual de sua função. Depois de criar uma versão específica de sua função, a arquitetura não poderá ser alterada.

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.

Não. Cada versão de função só pode usar uma única imagem de contêiner.

Sim. Camadas e extensões podem ser direcionadas para arquiteturas compatíveis com “x86_64” ou “arm64”. A arquitetura padrão para funções e camadas é “x86_64”.

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.

As funções do AWS Lambda baseadas no AWS Graviton2 são 20% mais baratas em comparação com as funções Lambda baseadas na arquitetura x86. O nível gratuito do Lambda se aplica às funções do AWS Lambda baseadas em arquiteturas x86 e ARM.

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.

Com o Amazon Elastic File System (Amazon EFS) para AWS Lambda, os clientes podem ler, gravar e persistir com segurança grandes volumes de dados em praticamente qualquer escala, usando um sistema de arquivos NFS elástico totalmente gerenciado que pode ser dimensionado sob demanda sem a necessidade de provisionamento ou gerenciamento de capacidade. Anteriormente, os desenvolvedores adicionavam código às suas funções para baixar dados do S3 ou de bancos de dados para o armazenamento temporário local, limitado a 512 MB. Com o EFS para Lambda, os desenvolvedores não precisam escrever código para baixar dados para armazenamento temporário para processá-los.

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.

Sim. Os destinos de montagem para o Amazon EFS estão associados a uma sub-rede em uma VPC. A função do AWS Lambda precisa ser configurada para acessar essa VPC.

Usar o EFS for Lambda é ideal para a criação de aplicações de machine learning ou para o carregamento de grandes arquivos ou modelos de referência, para o processamento ou backup de grandes quantidades de dados, para a hospedagem de conteúdo da Web ou para o desenvolvimento de sistemas de criação internos. Os clientes também podem usar o EFS for Lambda para manter o estado entre invocações em uma arquitetura de microsserviço com estado em um fluxo de trabalho do Step Functions ou compartilhar arquivos entre aplicações sem servidor e aplicações baseadas em instância ou contêiner.

Sim. A criptografia dos dados em trânsito usa o padrão de mercado Transport Layer Security (TLS) 1.2 para criptografar dados enviados entre as funções do AWS Lambda e os sistemas de arquivos do Amazon EFS.

Os clientes podem provisionar o Amazon EFS para criptografar dados em repouso. Os dados ociosos são criptografados de modo transparente enquanto são gravados, e descriptografados (também de modo transparente) quando são lidos. Dessa forma, você não precisa modificar os aplicativos. As chaves de criptografia são gerenciadas pelo AWS Key Management Service (KMS), o que elimina a necessidade de criar e manter uma infraestrutura segura de gerenciamento de chaves.

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.

Não. Cada função do Lambda poderá acessar um sistema de arquivos do EFS.

Sim. O Amazon EFS oferece suporte a funções do Lambda, contêineres do ECS e Fargate e instâncias do EC2. Você pode compartilhar o mesmo sistema de arquivos e usar a política e os pontos de acesso do IAM para controlar o que cada função, contêiner ou instância pode acessar.  

Sim. As funções Lambda podem ser configuradas com um URL de função, que é um endpoint HTTPS integrado que pode ser invocado usando o navegador, curl ou qualquer cliente HTTP. Os URLs de função são uma maneira fácil de iniciar a criação de funções acessíveis por HTTPS.

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.

URLs da função Lambda são protegidos, por padrão, por autorização IAM. Você pode optar por desabilitar a autorização do IAM para criar um endpoint público ou caso planeje a implementação de uma autorização personalizada como parte da lógica de negócios da função.

Você pode facilmente invocar sua função no navegador da Web ao navegar para o URL do Lambda, no código da aplicação do cliente usando uma biblioteca HTTP ou na linha de comando usando curl.

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.

Nomes de domínios personalizados não são, no momento, compatíveis com URLs de funções. Você pode usar um domínio personalizado com o URL da sua função ao criar uma distribuição do Amazon CloudFront e um CNAME para mapear o domínio personalizado para o nome de distribuição do CloudFront. Em seguida, mapeie o nome do domínio de distribuição do CloudFront para ser encaminhado ao URL da sua função como origem.

Sim, URLs de funções Lambda podem ser usados para invocar uma função em uma VPC.

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.

O AWS Lambda usa replicação e redundância para oferecer alta disponibilidade tanto ao próprio serviço quanto às funções que opera. Não há janelas de manutenção, nem tempos de inatividade programados.

Sim. Quando você atualizar uma função do Lambda, haverá um breve intervalo de tempo, normalmente menos de um minuto, quando as solicitações poderão ser atendidas tanto pela versão antiga da sua função quanto pela nova.

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.

Em caso de falha, as funções Lambda que estiverem sendo invocadas de forma síncrona responderão com uma exceção. As funções do Lambda invocadas de modo assíncrono são repetidas pelo menos três vezes. 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 Kinesis e do DynamoDB retêm dados por no mínimo 24 horas.

É possível configurar uma fila do Amazon SQS ou um tópico do Amazon SNS como a dead letter queue.

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.

Os controles de acesso podem ser gerenciados pela função da função Lambda ou por uma configuração de política de recursos na própria fila. Se as duas políticas estiverem presentes, serão aplicadas as permissões mais restritivas.

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.

Habilite a assinatura de código criando uma configuração de assinatura de código por meio do Console de Gerenciamento da AWS, da API Lambda, do AWS CLI, do AWS CloudFormation e do AWS SAM. A configuração de assinatura de código ajuda a especificar os perfis de assinatura aprovados. Ela também é útil na configuração de aviso ou rejeição de implantações, caso as verificações de assinatura falharem. As configurações de assinatura de código podem ser anexadas a funções individuais do Lambda para habilitar o recurso de assinatura de código. Essas funções agora verificam as assinaturas na implantação.

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.

Sim, é possível habilitar a assinatura de código para funções existentes anexando uma configuração de assinatura de código à função. Faça isso usando o console do AWS Lambda, a API Lambda, o AWS CLI, o AWS CloudFormation e o AWS SAM.

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.

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.

O Lambda oferece a compilação do openjdk 1.8 no Amazon Linux.

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.

Sim. Você pode usar o Pip para instalar os pacotes necessários do Python.

Crie uma função do C# Lambda usando o IDE do Visual Studio selecionando "Publish to AWS Lambda" (Publicar no AWS Lambda) no Solution Explorer. Como alternativa, você pode executar diretamente o comando "dotnet lambda publish" da CLI do dotnet com o [# Lambda CLI tools patch] instalado, que então cria o arquivo ZIP do seu código-fonte C# justamente com as dependências NuGet e suas próprias montagens DLL, e faz upload automaticamente dele para o AWS Lambda usando o parâmetro de runtime “dotnetcore1.0”

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. 

Para implantar uma função do Lambda codificada em Ruby, empacote seu código Ruby e gems como um 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.

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

O AWS Lambda é integrado ao AWS CloudTrail. O AWS CloudTrail pode registrar e entregar arquivos de log em seu bucket do Amazon S3 que descrevem o uso da API pela sua conta.

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

Sim, o AWS Lambda é compatível com o conjunto de instruções Advanced Vector Extensions 2 (AVX2). Para saber mais sobre como compilar seu código de aplicação para direcionar este conjunto de instruções para performance aprimorada, consulte a documentação do desenvolvedor do AWS Lambda.