Geral

P: O que é o AWS Lambda?

O AWS Lambda permite que você execute código sem provisionar ou gerenciar servidores. Você paga apenas pelo tempo de computação que utilizar. Não haverá cobranças quando o seu código não estiver em execução. Com o Lambda, você pode executar o código para praticamente qualquer tipo de aplicação ou serviço de backend, tudo sem precisar de administração. Basta fazer upload do código e o Lambda se encarrega de todos os itens necessários para executar e alterar a escala do código com alta disponibilidade. Você pode configurar o seu código para que ele seja acionado automaticamente por meio de outros produtos da AWS ou chamá-lo diretamente usando qualquer aplicação móvel ou da Web.

P: O que é computação sem servidor?

A computação sem servidor permite criar e executar aplicativos e serviços sem preocupações com servidores. Com a computação sem servidor, seu aplicativo ainda é executado em servidores, mas todo o gerenciamento do servidor é feito pela AWS. A base da computação sem servidor é o AWS Lambda, que permite executar seu código sem provisionar ou gerenciar servidores.

P: Quais eventos podem acionar uma função do AWS Lambda?

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

P: Quando devo usar o AWS Lambda em vez do Amazon EC2?

O Amazon Web Services oferece um conjunto de serviços de computação para atender a uma variedade de necessidades.

O Amazon EC2 oferece flexibilidade, com uma grande variedade de tipos de instâncias e a opção de personalizar o sistema operacional, as configurações de rede e de segurança e toda a pilha de software, permitindo mover facilmente as aplicações existentes para a nuvem. Com o Amazon EC2, você é responsável pelo provisionamento de capacidade, monitoramento da saúde e do desempenho da frota e por projetar tolerância a falhas e escalabilidade. O AWS Elastic Beanstalk oferece um serviço fácil de usar para implantar e dimensionar aplicações Web nas quais você mantém a propriedade e total controle sobre as instâncias do EC2 subjacentes. O Amazon EC2 Container Service é um serviço de gerenciamento escalável que oferece suporte para os contêineres Docker e permite que você execute facilmente aplicações distribuídas em um cluster gerenciado de instâncias do Amazon EC2.

O AWS Lambda facilita a execução de código em resposta a eventos, como alterações nos buckets do Amazon S3, atualizações em uma tabela do Amazon DynamoDB ou eventos personalizados gerados por suas aplicações ou dispositivos. Com o Lambda, você não precisa provisionar suas próprias instâncias, o Lambda faz todas as tarefas operacionais e administrativas em seu nome, inclusive provisionamento de capacidade, monitoramento da saúde da frota, aplicação de patches de segurança aos recursos de computação adjacentes, implementação do seu código, execução de um serviço de front-end de Web e monitoramento e registro do seu código. O AWS Lambda oferece escalabilidade fácil e alta disponibilidade para o seu código sem esforço adicional da sua parte.

P: Que tipo de código pode ser executado no AWS Lambda?

O AWS Lambda oferece uma maneira fácil de realizar muitas atividades na nuvem. Por exemplo, você pode usar o AWS Lambda para criar back-ends móveis que recuperam e transformam dados do Amazon DynamoDB, manipuladores que compactam ou transformam objetos conforme eles são carregados no Amazon S3, auditoria e relatórios de chamadas de API feitas para qualquer Amazon Web Service e processamento sem servidor de dados de streaming usando o Amazon Kinesis.

P: Que linguagens são compatíveis com o AWS Lambda?

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

P: Posso acessar a infraestrutura em que o AWS Lambda é executado?

Não. O AWS Lambda opera a infraestrutura de computação em seu nome, permitindo realizar verificações da saúde, aplicar patches de segurança e fazer outras tarefas de rotina de manutenção.

P: Como o AWS Lambda isola o meu código?

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

P: Como o AWS Lambda protege meu código?

O AWS Lambda armazena o código no Amazon S3 e o criptografa quando está ocioso. O AWS Lambda realiza outras verificações de integridade enquanto seu código está em uso.

P: Quais regiões da AWS estão disponíveis para o AWS Lambda?

Consulte a tabela de regiões da infraestrutura global da AWS.

Funções do AWS Lambda

P: O que é uma função do 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.

P: O AWS Lambda reutilizará instâncias de função?

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. O seu código não deverá assumir que isso sempre acontecerá.

P: E se eu precisar de espaço de Scratch em disco para a minha função do AWS Lambda?

É 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ço do AWS Lambda.

P: Como configuro a minha aplicação para usar o armazenamento temporário 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.

P: O armazenamento temporário do AWS Lambda é criptografado?

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

P: Quais métricas posso usar para monitorar meu uso do armazenamento temporário 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.

P: Quando devo usar o armazenamento temporário do Simple Storage Service (Amazon S3), do Amazon EFS ou do AWS Lambda para minhas aplicações sem servidor?

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

P: Posso usar o armazenamento temporário quando a simultaneidade provisionada estiver habilitada para a minha função?

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.

P: Como configuro a minha aplicação para usar o armazenamento temporário 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.

P: O armazenamento temporário do AWS Lambda é criptografado?

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

P: Quais métricas posso usar para monitorar meu uso do armazenamento temporário 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.

P: Por que as funções do AWS Lambda devem ser sem estado?

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 stateless, seu código pode acessar dados com estado chamando outros serviços web, como o Amazon S3 ou o Amazon DynamoDB.

P: Posso usar threads e processos no código de função do AWS Lambda?

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.

P: Quais restrições se aplicam ao código da função do AWS Lambda?

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.

P: Como faço para criar uma função do AWS Lambda usando o console do Lambda?

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.

P: Como faço para criar uma função do AWS Lambda usando a ILC do Lambda?

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). Visite o Guia de conceitos básicos do Lambda para começar.

P: O AWS Lambda é compatível com variáveis de ambiente?

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.

P: Posso armazenar informações confidenciais nas variáveis de ambiente?

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.

P: Como posso gerenciar minhas funções do AWS Lambda?

Você pode listar, excluir, atualizar e monitorar facilmente suas funções do Lambda usando o painel no console do AWS Lambda. Você também pode usar o AWS CLI e o AWS SDK para gerenciar suas funções do Lambda. Consulte o guia para desenvolvedores do Lambda para saber mais.

P: Posso compartilhar o código entre funções?

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.

P: Como faço para monitorar uma função do AWS Lambda?

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.

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

P: Como faço para solucionar falhas em uma função do AWS 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. Acesse a Solução de problemas de funções do Lambda para saber mais. As tarifas do Amazon CloudWatch Logs serão aplicadas.

P: Como faço para alterar a escala de uma função do AWS Lambda?

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.

P: Como os recursos de computação são atribuídos a uma função do AWS Lambda?

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

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

P: Quando devo usar as funções do AWS Lambda com mais de 3008 MB de memória?

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.

P: Por quanto tempo uma função do AWS Lambda pode ser executada?

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.

P: Como serei cobrado pelo uso das funções do AWS Lambda?

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

P: Posso economizar dinheiro no AWS Lambda com um Compute Savings Plan?

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.

P: O AWS Lambda é compatível com versionamento?

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.

P: Em quanto tempo depois de fazer upload do meu código a minha função do AWS Lambda estará pronta para chamar?

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.

P: Posso usar minha própria versão de uma biblioteca compatível?

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.

P: Como a precificação progressiva funciona?

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.

P: Posso usufruir da precificação progressiva e do Savings Plans para computação?

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.

Uso do AWS Lambda para processar eventos da AWS

P: O que é uma fonte de evento?

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 obter registros de um stream do Amazon Kinesis ou de uma fila do Amazon SQS e executar uma função do Lambda para cada mensagem recuperada.

Muitos outros serviços, como o AWS CloudTrail, podem agir como fontes de eventos simplesmente registrando para o Amazon S3 e usando notificações do bucket do S3 para acionar funções do AWS Lambda.

P: Que fontes de eventos podem ser usadas com o AWS Lambda?

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

P: Como os eventos são representados no AWS Lambda?

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

P: Como faço para que uma função do AWS Lambda responda a alterações em um bucket do Amazon S3?

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.

P: Como faço para que uma função do AWS Lambda responda a atualizações em uma tabela do Amazon DynamoDB?

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.

P: Como faço para usar uma função do AWS Lambda para processar registros em uma transmissão do Amazon Kinesis?

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.

P: Como o AWS Lambda processa dados de Amazon Kinesis Streams do Amazon DynamoDB?

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.

P: Como devo escolher entre o AWS Lambda e o Amazon Managed Service for Apache Flink para minhas necessidades de análises de dados?

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 e hora do evento. O Amazon Managed Service for Apache Flink 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

P: Como faço para usar uma função do AWS Lambda para responder às notificações enviadas pelo Amazon Simple Notification Service (SNS)?

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.

P: Como faço para usar uma função do AWS Lambda para responder aos e-mails enviados pelo Amazon Simple Email Service (SES)?

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.

P: Como faço para usar uma função do AWS Lambda para responder a alertas do Amazon CloudWatch?

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.

P: Como faço para usar uma função do AWS Lambda para responder a alterações em dados de usuários ou dispositivos gerenciados pelo Amazon Cognito?

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.

P: Como meu aplicativo pode disparar uma função do AWS Lambda diretamente?

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.

P: Qual é a latência para invocar uma função do AWS Lambda em resposta a um evento?

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 Lambda ou se ela não tiver sido usada recentemente.

P: Como faço para criar um backend móvel usando o AWS Lambda?

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.

P: Como faço para invocar uma função do AWS Lambda por meio de HTTPS?

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

P: Como minha função do AWS Lambda pode personalizar seu comportamento para o dispositivo e a aplicação que está fazendo a solicitação?

Quando são chamadas pelo AWS Mobile SDK, as funções do AWS Lambda ganham insight imediatamente no dispositivo e na aplicação que fez a chamada por meio do objeto “context”.

P: Como minha função do AWS Lambda pode personalizar seu comportamento com base na identidade do usuário final de uma aplicação?

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. 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 do Amazon Cognito, ou como uma chave para armazenar e recuperar dados no Amazon DynamoDB ou outros serviços da web.

P: Como posso criar uma habilidade da Alexa usando o AWS Lambda?

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.

P: O que acontecerá se minha função falhar ao processar um evento?

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.

Como usar o AWS Lambda para criar aplicações

P: O que é um aplicativo sem servidor?

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.

P: Como posso implantar e gerenciar uma aplicação sem servidor?

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

P: Como posso descobrir aplicações sem servidor já existentes que foram desenvolvidas pela comunidade AWS?

Você tem uma coleção de aplicativos 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.

P: Como automatizar a implantação para uma aplicação sem servidor?

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.

P: Como posso começar a criar uma aplicação sem servidor?

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.

P: Como coordenar chamadas entre várias funções do AWS Lambda?

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

P: Como posso solucionar problemas de uma aplicação sem servidor?

É possível habilitar a função Lambda para rastreamento com o AWS X-Ray ao adicionar permissões do X-Ray à atribuição de execução da função 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. Acesse 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.

P: Posso criar aplicativos sem servidor que se conectam a bancos de dados relacionais?

Sim. Você pode criar aplicativos 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. Aplicativos sem servidor que usam grupos de conexão totalmente gerenciados do RDS Proxy serão faturados de acordo com a Definição de preço do RDS Proxy.

P: Como é o licenciamento do AWS SAM?

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.

Compatibilidade com imagens de contêiner

P: O que é suporte de imagem de contêiner para AWS Lambda?

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.

P: Como utilizar o suporte de imagem de contêiner para AWS Lambda?

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.

P: Quais tipos de imagem de contêiner são compatíveis?

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

P: Quais imagens de base posso usar?

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.

P: Quais ferramentas de contêiner posso usar para empacotar e implantar funções como imagens de contêiner?

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.

P: Quais recursos do AWS Lambda estão disponíveis para funções implantadas como imagens de contêiner?

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.

P: O AWS Lambda corrigirá e atualizará minha imagem de contêiner implantada?

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 tempos de execução atualizados antes de implantar a imagem para produção.

P: Quais são as diferenças entre as funções criadas usando arquivos ZIP e imagens de contêiner?

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.

P: Há diferença de performance entre as funções definidas como zip e imagens de contêiner?

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.

P: Como serei cobrado pela implantação de funções Lambda como imagens de contêiner?

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.

P: O que é o Lambda Runtime Interface Emulator (RIE)?

O Lambda Runtime Interface Emulator é um proxy para a API Runtime do Lambda, que permite aos clientes testarem localmente sua função 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.

P: Por que eu preciso do Lambda Runtime Interface Emulator (RIE) durante o teste 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.

P: Quais comportamentos de função posso testar localmente com o emulador?

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.

P: Como o Runtime Interface Emulator (RIE) me ajuda a executar minha imagem compatível com Lambda em serviços de computação adicionais?

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.

P: Como posso implantar minha aplicação em contêiner existente para AWS Lambda?

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

AWS Lambda SnapStart

P: O que é o AWS Lambda SnapStart?
 
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.
 
P: Como configuro a função do Lambda para usar o Lambda SnapStart?
 
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.
 
P: Como escolher entre o Lambda SnapStart e a Simultaneidade provisionada (SP)?

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.

P: Com quais tempos de execução o Lambda SnapStart é compatível?
 
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.
 
P: Posso habilitar o Lambda SnapStart e a Simultaneidade provisionada na mesma função?

Não. Lambda SnapStart e Simultaneidade provisionada não podem ser ativados ao mesmo tempo, na mesma função.
 
P: Posso configurar uma função do Lambda SnapStart com uma nuvem privada virtual (VPC)?
 
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.
 
P: Posso configurar o Lambda SnapStart nas arquiteturas x86 e Arm?

Não. Por enquanto, você pode configurar o Lambda SnapStart apenas para funções em execução na arquitetura x86.
 
P: Posso habilitar o Lambda SnapStart com o Amazon Elastic File System (EFS)?

Não. Não é possível, neste momento, habilitar o Lambda SnapStart com o Amazon EFS.
 
P: Posso habilitar o Lambda SnapStart com armazenamento temporário maior (/tmp), além de 512 MB?
 
Não. Você não pode habilitar o Lambda SnapStart com armazenamento temporário maior (/tmp), que ultrapasse 512 MB.
 
P: O processo de armazenamento em cache e retomada de snapshots apresenta considerações de compatibilidade de software?

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.

P: Posso executar meu próprio código antes da criação de um snapshot ou quando a função é retomada a partir do snapshot?

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.

P: Serei cobrado pelo 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.

P: Por quanto tempo os snapshots da versão da função publicada permanecem armazenados em cache com o Lambda SnapStart?

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.

P: Como posso criptografar os snapshots do ambiente de execução inicializado criado pelo Lambda SnapStart?

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.

P: Há um limite de tempo para a execução da inicialização do meu código com o Lambda SnapStart?

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.
 

Simultaneidade provisionada

P: O que é a Simultaneidade provisionada do AWS Lambda?

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.

P: Como configurar e gerenciar a Simultaneidade provisionada?

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.

P: Eu preciso mudar meu código se quiser usar a Simultaneidade provisionada?

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.

P: Como serei cobrado pela 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 Definição de preço do AWS Lambda.

P: Quando a Simultaneidade provisionada deve ser usada?

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.

P: O que acontecerá se uma função receber chamadas acima do nível configurado da simultaneidade provisionada?

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.

Funções do AWS Lambda com processadores Graviton2

P: Quais são as funções do AWS Lambda com processadores Graviton2?

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.

P: Por que devo usar funções do AWS Lambda com processadores Graviton2?

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.

P: Como faço para configurar minhas funções para serem executadas em processadores Graviton2?

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.

P: Como faço para implantar minha aplicação criada usando funções baseadas em processadores Graviton2?

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.

P: Uma aplicação pode usar funções baseadas em processadores Graviton2 e processadores x86?

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.

P: O AWS Lambda oferece suporte a imagens de contêiner multiarquitetura?

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

P: Posso criar camadas do AWS Lambda que visem funções baseadas em processadores AWS Graviton2?

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

P: Quais linguagens e tempos de execução são compatíveis com funções Lambda em execução em processadores Graviton2?

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 tempos de execução do AWS Lambda.

P: Qual é o preço das funções do AWS Lambda baseadas em processadores AWS Graviton2? O nível gratuito do AWS Lambda se aplica a funções baseadas no Graviton2?

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.

P: Como faço para escolher entre executar minhas funções em processadores Graviton2 ou processadores x86?

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.

P: Preciso de uma máquina de desenvolvimento baseada em ARM para criar, desenvolver e testar funções com processadores Graviton2 localmente?

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 Lambda com o Graviton2, consulte a documentação.

Amazon EFS para AWS Lambda

P: O que é o Amazon EFS para AWS Lambda?

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.

P: Como configuro o Amazon EFS para o Lambda?

Os desenvolvedores podem conectar facilmente um sistema de arquivos EFS existente a uma função 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.

P: Preciso definir minha função com as configurações de VPC antes de poder usar meu sistema de arquivos do Amazon EFS?

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.

P: Quem deve usar o Amazon EFS para Lambda?

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.

P: Meus dados serão criptografados em trânsito?

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.

P: Meus dados são criptografados em repouso?

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.

P: Como serei cobrado pelo Amazon EFS para AWS Lambda?

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 a Preços.

P: Posso associar mais de um sistema de arquivos do Amazon EFS à minha função do AWS Lambda?

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

P: Posso usar o mesmo sistema de arquivos do Amazon EFS em várias funções, contêineres e instâncias?

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.  

Extensões do Lambda

P: O que são as extensões do AWS Lambda?

As extensões do AWS Lambda permitem integrar o Lambda a ferramentas favoritas para fins de monitoramento, observação, segurança e governança. As extensões permitem que você e os fornecedores de suas ferramentas favoritas conectem-se ao ciclo de vida do Lambda e se integrem mais completamente ao ambiente de execução do Lambda.

P: Como funcionam as extensões do Lambda?

As extensões são processos complementares executados no ambiente de execução do Lambda, o mesmo local em que o código das funções é executado. Além disso, elas podem ser executadas fora da invocação da função. Ou seja, elas começam antes da inicialização da função, executam em paralelo com a função, podem ser executadas após a conclusão da execução da função e também antes que o Lambda encerre o ambiente de execução.

P: Qual a utilidade das extensões do Lambda?

Você pode usar extensões para suas ferramentas favoritas de monitoramento, observabilidade, segurança e governança da AWS, bem como os seguintes parceiros: AppDynamics, Coralogix, Datadog, Dynatrace, Epsagon, HashiCorp, Honeycomb, Imperva, Lumigo, Check Point CloudGuard, New Relic, Thundra, Splunk, Sentry, Site24x7, Sumo Logic, AWS AppConfig, Amazon CodeGuru Profiler, Amazon CloudWatch Lambda Insights, AWS Distro for OpenTelemetry. Para saber mais sobre essas extensões, acesse a publicação de blog sobre o lançamento.

P: Como configuro e gerencio as extensões do Lambda?

Você pode implantar as extensões usando camadas em uma ou mais funções do Lambda por meio do ferramentas de console, ILC ou infraestrutura como código, como CloudFormation, AWS Serverless Application Model e Terraform. Para começar a usar, consulte a documentação.

P: Com quais tempos de execução posso usar as extensões do AWS Lambda?

É possível ver a lista dos tempos de execução que oferecem suporte a extensões aqui.

P: As extensões são consideradas no limite de pacotes de implantação?

Sim. O tamanho total descompactado da função e de todas as extensões não pode exceder o limite de tamanho de do pacote de implantação descompactado de 250 MB.

P: O uso de uma extensão afeta a performance?

As extensões podem afetar a performance da função porque compartilham recursos, como CPU, memória e armazenamento, com a função e porque são inicializadas antes do código da função. Por exemplo, se uma extensão executa operações com uso intenso de computação, o tempo de execução da função pode aumentar, pois a extensão e o código da função compartilham os mesmos recursos de CPU. Como o Lambda aloca CPU proporcional com base na configuração de memória escolhida, você pode ver um aumento na duração da execução e da inicialização em configurações de memória mais baixas à medida que mais processos competem pelos mesmos recursos da CPU.

Você pode usar a métrica PostRuntimeExecutionDuration para medir o tempo extra de execução da extensão após a execução da função e pode usar a métrica MaxMemoryUsed para medir o aumento da memória utilizada. Para compreender o impacto de uma extensão específica, você também pode usar a métrica Duration. No momento, a resposta da execução da função é retornada após o término da execução da função e da extensão. Para saber mais, consulte a documentação para desenvolvedores do Lambda.

P: Como serei cobrado pelo uso das extensões do Lambda?

As extensões compartilham o mesmo modelo de faturamento das funções do Lambda. Quando você usa funções do Lambda com extensões, paga pelas solicitações atendidas e pelo tempo de computação combinado usado para executar o código e todas as extensões, em incrementos de 1 milissegundo. O tempo de computação será cobrado de acordo com a definição de preço da duração do Lambda em vigor. Para saber mais, consulte Preços do AWS Lambda.

O ciclo de vida do Lambda consiste em três fases distintas: “início”, quando o AWS Lambda inicializa a função, as dependências e as extensões; “invocação”, quando o Lambda executa o código da função e da extensão como resposta a acionadores; e encerramento, após a conclusão da execução da função, mas o código da extensão pode ainda estar em execução e pode durar até dois segundos. Você será cobrado pelo tempo de computação usado para executar seu código de extensão durante todas as três fases do ciclo de vida do Lambda. Para saber mais sobre o ciclo de vida do Lambda, consulte a documentação sobre o ambiente de execução do Lambda.

Não há custo adicional pela instalação de extensões, mas as ofertas de parceiros podem ser cobradas. Veja o site do parceiro relevante para obter mais detalhes.

P: Posso criar minhas próprias extensões do Lambda?

Sim, usando a API Runtime Extensions do AWS Lambda. Consulte a documentação para saber mais.

P: Como as extensões funcionam com o Provisioned Concurrency habilitado?

O Provisioned Concurrency mantém as funções inicializadas e prontas para responder em menos de 100 milissegundos. Quando habilitado, o Provisioned Concurrency também inicializa as extensões e as mantêm prontas para executar juntamente com o código da função.

P: Quais são as permissões das extensões?

Como as extensões são executadas no mesmo ambiente que a função Lambda, elas têm acesso aos mesmos recursos que a função. As permissões são compartilhadas entre a função e a extensão. Portanto, elas compartilham variáveis de credenciais, função e ambiente. As extensões têm acesso somente leitura ao código da função e podem ler e gravar em /tmp.

P: O que é a API Telemetry do AWS Lambda?

A API Telemetry do AWS Lambda permite que você use extensões para capturar dados sobre monitoramento e observabilidade aprimorados diretamente do Lambda e enviá-los a um destino de sua escolha.

P: Como a API Telemetry funciona?

O serviço do Lambda captura automaticamente e transmite dados de telemetria para o Amazon CloudWatch e o AWS X-Ray. A API Telemetry fornece uma interface simples de HTTP ou TCP para que as extensões recebam os mesmos dados de telemetria junto com eventos de ciclo de vida do ambiente de execução do Lambda e métricas de função no nível da invocação. As extensões podem usar a API Telemetry para consumir tais fluxos de telemetria diretamente do Lambda e, em seguida, processá-los, filtrá-los e enviá-los para qualquer destino de preferência.

P: Como faço para começar a usar a API Telemetry?

Você pode implantar extensões habilitadas para a API Telemetry para as suas funções do Lambda por meio do console do AWS Lambda, da AWS CLI ou de ferramentas de infraestrutura como código, como o AWS CloudFormation, o AWS Serverless Application Model (SAM) e a Terraform. Você não precisa fazer alterações de código para usar a extensão habilitada para a API Telemetry com a sua função do Lambda. Basta adicionar uma extensão de um fornecedor de ferramentas de sua preferência na sua função do Lambda.  Para começar a usar extensões dos parceiros da APN, siga os links fornecidos na publicação do blog sobre lançamentos. Você também pode desenvolver a sua pró´ria extensão que use a API Telemetry. Para saber mais, consulte o AWS Lambda Developer Guide (Guia do desenvolvedor do AWS Lambda).

P: O uso de uma API Telemetry afeta a performance?

Você só pode usar a API Telemetry dentro das extensões do AWS Lambda. As extensões podem afetar a performance da sua função porque compartilham recursos com a função, como CPU, memória e armazenamento. O uso da memória aumenta linearmente conforme o número de assinaturas à API Telemetry aumenta, pois cada assinatura abre um novo buffer de memória para armazenar os dados de telemetria. Contudo, você pode otimizar o uso de memória ajustando a configuração de buffer na solicitação de assinaturas da API Telemetry. Nós recomendamos que os provedores de extensões publiquem o consumo de recursos esperados para que os desenvolvedores de funções consigam escolher uma extensão adequada mais facilmente. Consulte a documentação do provedor sobre a sua extensão para compreender a potencial sobrecarga na performance pelo uso de sua extensão.

P: Como receberei cobranças pelo uso da API Telemetry?

Não há custo adicional para o uso da API Telemetry do AWS Lambda. As extensões que usam a API Telemetry compartilham o mesmo modelo de cobrança que outras extensões e funções do Lambda. Para saber mais sobre a preços de extensões, veja a página de preço do Lambda.

P: O uso da API Telemetry desativa o envio de logs para o Amazon CloudWatch Logs?

Não. Por padrão, p serviço do Lambda envia todos os dados de telemetria para o CloudWatch Logs e o uso da API Telemetry não desabilita a saída para o CloudWatch Logs.

URLs da função do Lambda

P: As funções do AWS Lambda são compatíveis com endpoints HTTP(S)?

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.

P: Como faço para configurar um URL de função Lambda para minha função?

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.

P: Como faço para proteger o URL da função Lambda?

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.

P: Como faço para invocar minha função com um URL de função Lambda?

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.

P: Os URLs de funções Lambda funcionam com versões e aliases das funções?

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.

P: Posso habilitar domínios personalizados para o URL da minha função Lambda?

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.

P: URLs de funções Lambda podem ser usados para invocar uma função em uma VPC?

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

P: Qual o preço para o uso de URLs de funções Lambda?

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.

Lambda@Edge

P: O que é o Lambda@Edge?

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 consultando nossa documentação.

P: Como usar o Lambda@Edge?

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 consultando nossa documentação.

P: Quando o Lambda@Edge deve ser usado?

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.

P: É possível implantar funções atuais do Lambda para invocação global?

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.

P: Quais eventos do Amazon CloudFront podem ser usados para acionar minhas funções?

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: este evento ocorre quando o servidor CloudFront na borda 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.

P: Qual é a diferença entre o AWS Lambda@Edge e o AWS Lambda por trás do Amazon API Gateway?

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.

Escalabilidade e disponibilidade

P: Qual é o nível de disponibilidade das funções do AWS Lambda?

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.

P: Minhas funções do AWS Lambda permanecem disponíveis quando eu altero meu código ou sua configuração?

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.

P: Existe um limite para o número de funções do AWS Lambda que eu posso executar de uma vez?

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). Também é possível controlar o máximo de execuções simultâneas para funções individuais do AWS Lambda, as quais podem ser usadas para reservar um subconjunto do limite de simultaneidade da sua conta para funções críticas ou taxas limitar taxas de tráfego para o downstream de 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. 

P: O que acontecerá se minha conta exceder o limite padrão para execuções simultâneas?

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. O Amazon Kinesis e o Amazon DynamoDB Streams retêm dados por 24 horas.

P: Os limites máximos padrão de execução simultânea são aplicados em um nível por função?

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

P: Com que rapidez minhas funções do AWS Lambda escalam?

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.

P: O que acontecerá se minha função do Lambda falhar ao processar um evento?

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.

P: O que acontecerá se as invocações da função do Lambda excederem a política disponível?

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.

P: Quais recursos é possível configurar como uma dead letter queue para uma função do Lambda?

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

Controle de segurança e acesso

P: Como faço para permitir que minha função do AWS Lambda acesse outros recursos da AWS?

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.

P: Como controlo quais buckets do Amazon S3 podem chamar quais funções do AWS Lambda?

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

P: Como posso controlar qual tabela do Amazon DynamoDB ou transmissão do Amazon Kinesis pode ser pesquisada por uma função do AWS 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.

P: Como eu controlo qual fila do Amazon SQS pode ser sondada por uma função do AWS Lambda?

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.

P: Como faço para acessar recursos no Amazon VPC a partir da minha função do AWS Lambda?

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.

P: O que é assinatura de código para o AWS Lambda?

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

P: Como criar artefatos de código assinados digitalmente?

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.

P: Como configurar as funções Lambda para habilitar a assinatura de código?

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.

P: Quais verificações de assinatura o AWS Lambda realiza 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.

P: Posso habilitar a assinatura de código para funções existentes?

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.

P: Existe algum custo adicional para usar a assinatura de código para o AWS Lambda?

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

Controles avançados de logs

P: Quais controles avançados de logs são compatíveis com o Lambda?

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.

P: Para que posso usar os controles avançados de log?

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.

P: Como faço para usar controles avançados de logs?

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.

P: Posso usar minhas bibliotecas de logs para gerar logs estruturados em JSON para minha função 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.

P: Como serei cobrado pelo uso dos controles avançados de logs?

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.

Funções do AWS Lambda em Java

P: Como faço para compilar o código Java da minha função do AWS Lambda?

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.

P: Qual é o ambiente de JVM usado pelo Lambda para executar a minha função?

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

Funções do AWS Lambda no Node.js

P: Posso usar pacotes com o AWS Lambda?

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

P: Posso executar outros programas em minha função do AWS Lambda codificada em Node.js?

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.

P: É possível usar módulos nativos com funções do AWS Lambda escritas em Node.js?

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.

P: Posso executar binários codificados em Node.js com o AWS Lambda?

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.

P: Como faço para implantar o código da função do AWS Lambda codificado em Node.js?

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.

Funções do AWS Lambda no Python

P: Posso usar pacotes do Python com o AWS Lambda?

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

Funções do AWS Lambda em C#

P: Como empacotar e implantar uma função do AWS Lambda em C#?

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”

Funções do AWS Lambda no PowerShell

P: Como faço para implantar o código da função do AWS Lambda codificado em PowerShell?

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.

P: Como faço para implantar o código da função do AWS Lambda codificado em PowerShell?  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.
P: Como faço para implantar o código da função do AWS Lambda codificado em PowerShell?  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.

Funções do AWS Lambda em Go

P: Como empacotar e implantar uma função do AWS Lambda em Go? 

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. 

Funções do AWS Lambda em Ruby

P: Como implantar o código da função do AWS Lambda codificado em Ruby? 

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.

Outros tópicos

P: Quais versões de Amazon Linux, Node.js, Python, JDK, .NET Core, SDKs e outras bibliotecas são compatíveis com o AWS Lambda?

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

P: É possível mudar a versão do Amazon Linux ou de qualquer tempo de execução de linguagem?

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.

P: Como posso gravar e auditar chamadas feitas para a API do AWS 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.

P: Como coordenar chamadas entre várias funções do 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.

P: O AWS Lambda é compatível com Advanced Vector Extensions 2 (AVX2)?

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

Saiba mais sobre a definição de preço do AWS Lambda

Acesse a página de definição de preço
Pronto para começar?
Cadastrar-se
Tem outras dúvidas?
Entre em contato conosco