# O que é o AWS Lambda?
**dica**
Junte-se a especialistas em tecnologia sem servidor em workshops práticos gratuitos para aprender como criar aplicações sem servidor com as práticas recomendadas. [Clique aqui](https://aws-experience.com/amer/smb/events/series/Get-Hands-On-With-Serverless?trk=188abe3e-9f94-4e84-aefb-398d944ad567%26sc_channel%3Del) para se inscrever.
O AWS Lambda é um serviço de computação que executa código sem a necessidade de gerenciar servidores. Seu código é executado, aumentando e diminuindo automaticamente, com preços baseados no uso. Para começar, consulte o [Criar sua primeira função](getting-started.md).
É possível usar o Lambda para:
+ **Processamento de arquivos**: processe arquivos automaticamente quando carregados no Amazon Simple Storage Service. Consulte [exemplos de processamento de arquivos](example-apps.md#examples-apps-file) para obter detalhes.
+ **Fluxos de trabalho de longa duração:** use [funções do Lambda duráveis](durable-functions.md) para criar fluxos de trabalho com várias etapas e com estado que podem ser executados por até um ano. Perfeito para processamento de pedidos, fluxos de trabalho de aprovação, processos humanos e pipelines de dados complexos que precisem lembrar seu progresso.
+ **Exemplos de operações e integração de banco de dados**: responda às alterações do banco de dados e automatize os fluxos de trabalho de dados. Consulte [exemplos de bancos de dados](example-apps.md#examples-apps-database) para obter mais detalhes.
+ **Tarefas programadas e periódicas**: execute operações automatizadas em um agendamento regular usando o EventBridge. Consulte [exemplos de tarefas agendadas](example-apps.md#examples-apps-scheduled) para obter mais detalhes.
+ **Processamento de fluxo**: processe fluxos de dados em tempo real para analytics e monitoramento. Consulte [Kinesis Data Streams](with-kinesis.md) para obter detalhes.
+ **Aplicações Web**: crie aplicações Web escaláveis que se ajustam automaticamente à demanda.
+ **Back-ends móveis**: crie backends de API seguros para aplicações móveis e da Web.
+ **Bac-ends IoT**: gerencie solicitações de API da Web, de dispositivos móveis, de IoT e de terceiros. Consulte [IoT](services-iot.md) para obter mais detalhes.
Para obter informações sobre a definição de preço, consulte [Definição de preço do AWS Lambda](https://aws.amazon.com/lambda/pricing/).
## Como o Lambda funciona
Ao usar o Lambda, você é responsável apenas pelo seu código. O Lambda executa o código em uma infraestrutura de computação de alta disponibilidade e gerencia todos os recursos computacionais, inclusive manutenção do servidor e do sistema operacional, provisionamento de capacidade, escalação automática e registro em log.
Como o Lambda é um serviço de computação orientado por eventos com tecnologia sem servidor, ele usa um paradigma de programação diferente das aplicações Web tradicionais. O modelo a seguir ilustra como o Lambda funciona:
1. Você escreve e organiza o código nas [funções do Lambda](concepts-basics.md#gettingstarted-concepts-function), que são as peças básicas que você usa para desenvolver uma aplicação do Lambda.
1. Você controla a segurança e o acesso por meio de [permissões do Lambda](lambda-permissions.md), usando [perfis de execução](lambda-intro-execution-role.md) para gerenciar com quais serviços da AWS as funções podem interagir e quais políticas de recursos podem interagir com o código.
1. As origens de eventos e serviços da AWS [acionam](concepts-event-driven-architectures.md) as funções do Lambda, transmitindo dados de eventos no formato JSON, os quais as funções processam (isso inclui mapeamentos das origens dos eventos).
1. O [Lambda executa o código](concepts-how-lambda-runs-code.md) com runtimes específicos da linguagem (como Node.js e Python) em ambientes de execução que empacotam o runtime, as camadas e as extensões.
**dica**
Para saber como construir **soluções com tecnologia sem servidor**, confira o [Guia do desenvolvedor com tecnologia sem servidor](https://docs.aws.amazon.com/serverless/latest/devguide/).
## Atributos principais
**Configurar, controlar e implantar aplicações seguras:**
+ [Variáveis de ambiente](configuration-envvars.md) modifique o comportamento da aplicação sem novas implantações de código.
+ [Versões](configuration-versions.md) teste com segurança novos recursos enquanto mantém ambientes de produção estáveis.
+ [Camadas do Lambda](chapter-layers.md) otimize a reutilização e a manutenção do código compartilhando componentes comuns entre várias funções.
+ [Assinatura de código](configuration-codesigning.md) imponha conformidade com a segurança garantindo que apenas código aprovado chegue aos sistemas de produção.
**Tenha escalação e performance confiáveis:**
+ [Controles de simultaneidade e escalação](lambda-concurrency.md) gerenciam com precisão a capacidade de resposta da aplicação e a utilização de recursos durante picos de tráfego.
+ [Lambda SnapStart](snapstart.md) reduza significativamente os tempos de inicialização a frio. O Lambda SnapStart pode ter uma performance de startup de até menos de um segundo, geralmente sem alterações no código da função.
+ [Streaming de respostas](configuration-response-streaming.md) otimize a performance da função fornecendo grandes cargas úteis em incrementos para processamento em tempo real.
+ [Imagens de contêiner](images-create.md) empacote funções com dependências complexas usando fluxos de trabalho de contêineres.
**Conecte e integre sem falhas:**
+ [As redes VPC](configuration-vpc.md) protegem recursos sensíveis e serviços internos.
+ [Sistema de arquivos](configuration-filesystem.md) integração que compartilha dados persistentes e gerencia operações com estado em todas as invocações de funções.
+ [URLs de função](urls-configuration.md) crie APIs e endpoints de interação com o público sem serviços adicionais.
+ [Extensões Lambda](lambda-extensions.md) amplie as funções com ferramentas de monitoramento, segurança e operação.
## Informações relacionadas
+ Para obter informações sobre como o Lambda funciona, consulte [Como o Lambda funciona](concepts-basics.md).
+ Para começar a usar o Lambda, consulte [Criar sua primeira função do Lambda](getting-started.md).
+ Para obter uma lista de exemplos de aplicações, consulte [Introdução com exemplos de aplicações e padrões](example-apps.md).
# Como o Lambda funciona
As funções do Lambda são as peças básicas que você usa para desenvolver aplicações do Lambda. Para escrever funções, é essencial entender os principais conceitos e componentes do modelo de programação do Lambda. Esta seção o guiará pelos elementos fundamentais que você precisa conhecer para começar a desenvolver aplicações com tecnologia sem servidor usando o Lambda.
+ **[Funções do Lambda e manipuladores de funções](#gettingstarted-concepts-function)**: uma função do Lambda é um pequeno bloco de código executado em resposta a eventos. As funções podem ser padrão (até 15 minutos) ou [duráveis](durable-functions.md) (até um ano). As funções são as peças básicas que você usa para desenvolver aplicações. Os manipuladores da função são o ponto de entrada para objetos de eventos que o código da função do Lambda processa.
+ **[Ambiente de execução e runtimes do Lambda](#gettingstarted-concepts-runtime)** - os ambientes de execução do Lambda gerenciam os recursos necessários para executar a função. Para as [funções duráveis](durable-functions.md), o ambiente de execução inclui recursos automáticos de gerenciamento de estado e pontos de verificação. Os runtimes são os ambientes específicos da linguagem nos quais as funções são executadas.
+ **[Eventos e acionadores](#gettingstarted-concepts-event)**: outros Serviços da AWS podem invocar suas funções em resposta a eventos específicos. Para funções duráveis, os eventos também podem acionar a retomada de fluxos de trabalho pausados.
+ **[Permissões e perfis do Lambda](#gettingstarted-concepts-permissions)**: controle quem pode acessar as funções e com quais outros Serviços da AWS as funções podem interagir. As funções duráveis necessitam de permissões adicionais para o gerenciamento de estado e a execução prolongada.
**dica**
Se quiser começar entendendo o desenvolvimento com tecnologia sem servidor de maneira mais geralizada, consulte [Diferença entre desenvolvimento tradicional e com tecnologia sem servidor](https://docs.aws.amazon.com/serverless/latest/devguide/serverless-shift-mindset.html), no *Guia do desenvolvedor do AWS com tecnologia sem servidor*.
## Funções do Lambda e manipuladores de funções
No Lambda, **funções** são os blocos de construção fundamentais utilizados para criar aplicações. Uma função do Lambda é um bloco de código executado em resposta a eventos, como o clique de um usuário em um botão em um site ou o upload de um arquivo em um bucket do Amazon Simple Storage Service (Amazon S3). Graças às funções duráveis, seu código pode pausar a execução entre etapas, mantendo o estado automaticamente, o que as torna ideais para fluxos de trabalho de longa duração, como o processamento de pedidos ou a moderação de conteúdo. Imagine uma função como um tipo de programa independente com as seguintes propriedades.
Um **manipulador da função** do Lambda é o método no código da função que processa eventos. Quando uma função é executada em resposta a um evento, o Lambda executa o manipulador da função. Os dados sobre o evento que causou a execução da função são transmitidos diretamente ao manipulador. Embora o código em uma função do Lambda possa conter mais de um método ou função, funções do Lambda podem conter apenas um manipulador.
Para criar uma função do Lambda, agrupe o código dessa função e suas dependências em um pacote de implantação. O Lambda oferece suporte a dois tipos de pacotes de implantação, [arquivos .zip](configuration-function-zip.md) e [imagens de contêineres](images-create.md).
+ Funções têm um trabalho ou propósito específico
+ São executadas somente quando necessário em resposta a eventos específicos
+ Param de ser executadas automaticamente quando são encerradas
## Ambiente de execução e runtimes do Lambda
Funções do Lambda são executadas em um *[ambiente de execução](lambda-runtime-environment.md)* seguro e isolado gerenciado pelo Lambda para você. Para [funções duráveis](durable-functions.md), o ambiente de execução inclui componentes adicionais para gerenciamento de estado e coordenação de fluxo de trabalho. O ambiente de execução gerencia os processos e os recursos necessários para executar sua função. Quando uma função é invocada pela primeira vez, o Lambda cria um novo ambiente de execução no qual essa função será executada. Concluída a execução da função, o Lambda não interrompe o ambiente de execução imediatamente: se a função for novamente invocada, o Lambda poderá reutilizar o ambiente de execução existente.
O ambiente de execução do Lambda também contém um *runtime*, ou seja, um ambiente específico de linguagem que retransmite informações de eventos e respostas entre o Lambda e sua função. O Lambda inclui vários [runtimes gerenciados](lambda-runtimes.md#runtimes-supported) para as linguagens de programação mais populares, ou você pode criar o seu próprio.
Para runtimes gerenciados, o Lambda aplica automaticamente atualizações e patches de segurança às funções que usam o runtime.
## Eventos e acionadores
Também é possível invocar uma função do Lambda diretamente usando o console do Lambda, a [AWS CLI](https://aws.amazon.com/cli/) ou um dos [Kits de Desenvolvimento de Software (SDKs) da AWS](https://aws.amazon.com/developer/tools/). Em uma aplicação de produção, é mais comum que a função seja invocada por outro AWS service (Serviço da AWS) em resposta a um evento específico. Por exemplo, você pode desejar que uma função seja executada sempre que um item for adicionado a uma tabela do Amazon DynamoDB.
Para fazer a função responder a eventos, você configura um **acionador**. Um acionador conecta a função a uma origem de eventos, e a função pode ter vários acionadores. Quando ocorre um evento, o Lambda recebe os dados do evento como um documento JSON e os converte em um objeto que o código possa processar. É possível definir o formato JSON a seguir para o evento, e o runtime do Lambda converte esse JSON em um objeto antes de passá-lo ao manipulador da função.
**Example evento do Lambda personalizado**
```
{
"Location": "SEA",
"WeatherData":{
"TemperaturesF":{
"MinTempF": 22,
"MaxTempF": 78
},
"PressuresHPa":{
"MinPressureHPa": 1015,
"MaxPressureHPa": 1027
}
}
}
```
Para serviços de fluxos e filas, como o Amazon Kinesis ou o Amazon SQS usa um [mapeamento da origem do evento](invocation-eventsourcemapping.md) em vez de um acionador padrão. Os mapeamentos da origem do evento sondam a origem em busca de novos dados, agrupam os registros em lotes e depois invocam a função com os eventos em lotes. Para obter mais informações, consulte [Como os mapeamentos de origem de eventos diferem dos acionadores diretos](invocation-eventsourcemapping.md#eventsourcemapping-trigger-difference).
Para entender como um acionador funciona, faça o tutorial [Usar um acionador do Amazon S3](with-s3-example.md) ou, para obter uma visão geral sobre o uso de acionadores e instruções para criar um acionador usando o console do Lambda, consulte [Integração com outros serviços](lambda-services.md).
## Permissões e perfis do Lambda
Para o Lambda, existem dois tipos principais de [permissões](permissions-granting-access.md) que você precisa configurar:
+ Permissões necessárias para a sua função acessar outros Serviços da AWS
+ Permissões necessárias para outros usuários e Serviços da AWS acessarem sua função
As próximas seções descrevem esses dois tipos de permissão e discutem as práticas recomendadas para aplicar permissões com privilégios mínimos.
### Permissões para funções acessarem outros recursos da AWS
As funções do Lambda geralmente precisam acessar outros recursos da AWS e executar ações neles. Por exemplo, uma função pode ler itens de uma tabela do DynamoDB, armazenar um objeto em um bucket do S3 ou gravar em uma fila do Amazon SQS. Para dar às funções as permissões necessárias para realizar essas ações, você deve usar um *[perfil de execução](lambda-intro-execution-role.md)*.
Um perfil de execução do Lambda é um tipo especial de [perfil](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) do AWS Identity and Access Management (IAM), uma identidade criada na conta que tem permissões específicas associadas a ela definidas em uma *política*.
Cada função do Lambda deve ter um perfil de execução, e um único perfil pode ser usado por mais de uma função. Quando uma função é invocada, o Lambda assume o perfil de execução dessa função e recebe permissão para realizar as ações definidas na política do perfil.
Quando você cria uma função no console do Lambda, o Lambda cria automaticamente um perfil de execução para essa função. A política do perfil concede permissões básicas à sua função para gravar saídas de log no Amazon CloudWatch Logs. Para dar permissão à sua função para realizar ações em outros recursos da AWS, é necessário editar o perfil de forma a adicionar as permissões extras. A maneira mais fácil de adicionar permissões é usar uma [política gerenciada](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) da AWS. Políticas gerenciadas são criadas e administradas pela AWS e fornecem permissões para diversos casos de uso comuns. Por exemplo, se a sua função executa operações de CRUD em uma tabela do DynamoDB, você pode adicionar a política [AmazonDynamoDBFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonDynamoDBFullAccess.html) ao seu perfil.
### Permissões para outros usuários e recursos acessarem sua função
Para conceder a outros AWS service (Serviço da AWS) permissão para acessar sua função do Lambda, é necessário usar uma *[política baseada em recursos](access-control-resource-based.md)*. No IAM, políticas baseadas em recurso são anexadas a um recurso (neste caso, a função do Lambda) e definem quem pode acessar esse recurso e quais ações podem ser realizadas.
Para que outro AWS service (Serviço da AWS) invoque sua função por meio de um gatilho, a política baseada em recursos dessa função deve conceder permissão a esse serviço para usar a ação `lambda:InvokeFunction`. Se você criar o gatilho usando o console, o Lambda adicionará automaticamente essa permissão.
Para conceder permissão para outros usuários da AWS acessarem sua função, você pode definir isso na política baseada em recursos da sua função da mesma maneira que para outro AWS service (Serviço da AWS) ou recurso. Também é possível usar uma *[política baseada em identidade](access-control-identity-based.md)* associada ao usuário.
### Práticas recomendadas para permissões do Lambda
Quando você define permissões usando políticas do IAM, a [prática recomendada de segurança](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) é conceder apenas as permissões necessárias para realizar uma tarefa. Isso é conhecido como o princípio do *privilégio mínimo*. Para começar a conceder permissões para sua função, você pode optar por usar uma política gerenciada pela AWS. Políticas gerenciadas podem ser a maneira mais rápida e simples de conceder permissões para realizar uma tarefa, mas também podem incluir outras permissões desnecessárias. À medida que você passa do desenvolvimento inicial para teste e produção, recomendamos limitar permissões apenas às necessárias, definindo [políticas gerenciadas pelo cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies).
O mesmo princípio é aplicável ao conceder permissões para acessar uma função usando uma política baseada em recursos. Por exemplo, se quiser dar permissão ao Amazon S3 para invocar sua função, a prática recomendada é limitar o acesso a buckets individuais, ou buckets em particular Contas da AWS, em vez de conceder permissões gerais ao serviço S3.
# Executar código com o Lambda
Quando você escreve uma função do Lambda, está criando um código que será executado em um ambiente exclusivo com tecnologia sem servidor. A compreensão de como o Lambda executa o código envolve dois aspectos principais: o modelo de programação que define como o código interage com o Lambda e o ciclo de vida do ambiente de execução que determina como o Lambda gerencia o ambiente de runtime do código.
## O modelo de programação do Lambda
O modelo de programação funciona como um conjunto comum de regras sobre como o Lambda trabalha com o código, esteja você escrevendo em Python, em Java ou em qualquer outra linguagem com suporte. O modelo de programação inclui o runtime e o manipulador.
**Para funções padrão:**
1. O Lambda recebe um evento.
1. O Lambda usa o runtime para preparar o evento em um formato que o código possa usar.
1. O runtime envia o evento formatado para o manipulador.
1. Seu manipulador processa o evento usando o código que você escreveu.
**Para funções duráveis:**
1. O Lambda recebe um evento.
1. O runtime prepara o evento e o DurableContext
1. Seu manipulador pode:
+ Processar etapas com pontos de verificação automáticos
+ Pausar a execução sem consumir recursos
+ Retomar a partir do último ponto de verificação com êxito
+ Manter o estado entre as etapas
Essencial para esse modelo é o *manipulador*, ao qual o Lambda envia os eventos para serem processados pelo código. Pense nele como o ponto de entrada para o código. Quando o Lambda recebe um evento, ele passa esse evento e algumas informações de contexto para o manipulador. O manipulador então executa o código para processar esses eventos; por exemplo, ele pode ler um arquivo quando ele é carregado no Amazon S3, analisar uma imagem ou atualizar um banco de dados. Quando o código termina de processar um evento, o manipulador está pronto para processar o próximo.
## O modelo de execução do Lambda
Embora o modelo de programação defina como o Lambda interage com o código, o ambiente de execução é onde o Lambda realmente executa a função, pois é um espaço computacional seguro e isolado criado especificamente para a função.
**Cada ambiente segue um ciclo de vida que varia entre as funções padrão e duráveis:**
**Funções padrão (até 15 minutos):**
1. **Inicialização:** configuração do ambiente e carregamento de código
1. **Invocação:** execução única do código da função
1. **Desligamento:** limpeza do ambiente
**Funções duráveis (até 1 ano):**
1. **Inicialização**: configuração de ambiente e estado durável
1. **Invocação:** várias etapas com pontos de verificação automáticos
1. **Estados de espera:** pausa a execução sem consumo de recursos
1. **Retomar:** reiniciar a partir do último ponto de verificação
1. **Desligar:** limpeza do estado durável
Esse ambiente lida com aspectos importantes da execução da função. Ele fornece à função memória e um diretório `/tmp` para armazenamento temporário. **Para funções duráveis, ele também gerencia:**
+ Persistência de estado automática entre etapas
+ Armazenamento e recuperação em pontos de verificação
+ Coordenação do estado de espera
+ Acompanhamento do andamento em execuções de longa duração
# Entender o modelo de programação do Lambda
O Lambda oferece dois modelos de programação: as funções padrão, que duram até 15 minutos, e as funções duráveis, que podem ser executadas por até um ano. Embora ambas compartilhem conceitos fundamentais, as funções duráveis adicionam recursos para fluxos de trabalho de longa duração e com estado.
O Lambda oferece um modelo de programação comum a todos os runtimes. O modelo de programação define a interface entre seu código e o sistema Lambda. Você diz ao Lambda o ponto de entrada para sua função definindo um *manipulador* na configuração da função. O runtime transmite ao handler os objetos que contêm o *evento* de invocação e o *contexto*, como o nome da função e o ID da solicitação.
**Para as funções duráveis, o manipulador também recebe um objeto DurableContext que fornece:**
+ Capacidades de ponto de verificação por meio de step()
+ Gerenciamento do estado de espera por meio de wait() e waitForCallback()
+ Persistência de estado automática entre invocações
Quando o handler termina de processar o primeiro evento, o runtime o envia outro. Para as funções duráveis, o manipulador pode pausar a execução entre as etapas, e o Lambda salvará e restaurará automaticamente o estado quando a função for retomada. A classe da função permanece na memória, de forma que é possível reutilizar clientes e variáveis que são declarados fora do método do handler no *código de inicialização*. Para economizar tempo de processamento em eventos subsequentes, crie recursos reutilizáveis como clientes do AWS SDK durante a inicialização. Uma vez inicializada, cada instância da função pode processar milhares de solicitações.
Sua função também tem acesso ao armazenamento local no diretório `/tmp`, um cache transitório que pode ser utilizado para várias invocações. Para obter mais informações, consulte [Ambiente de execução](lambda-runtime-environment.md).
Quando o [rastreamento do AWS X-Ray](services-xray.md) está habilitado, o runtime registra subsegmentos separados para inicialização e execução.
O runtime captura a saída do registro em log da função e a envia para o Amazon CloudWatch Logs. Além de registrar em log a saída da função, o runtime também registra em log as entradas quando a invocação da função é iniciada e termina. Isso inclui um log de relatório com o ID da solicitação, a duração faturada, a duração da inicialização e outros detalhes. Se a função lançar um erro, o runtime retornará esse erro para o chamador.
**nota**
O registro em log está sujeito a[Cotas CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html). Os dados de log podem ser perdidos devido a limitação ou, em certos casos, quando uma instância da sua função é interrompida.
**Principais diferenças das funções duráveis:**
+ O estado é persistido automaticamente entre as etapas
+ As funções podem pausar a execução sem consumir recursos
+ As etapas são tentadas novamente de forma automática em caso de falha
+ O andamento é monitorado por meio de pontos de verificação
O Lambda dimensiona a função executando instâncias adicionais dela à medida que a demanda aumenta, e interrompendo instâncias à medida que a demanda diminui. Esse modelo leva a variações na arquitetura da aplicação, como:
+ Salvo indicação em contrário, as solicitações de entrada poderiam ser processadas fora de ordem ou simultaneamente.
+ Não dependa de que instâncias da sua função sejam de longa duração. Em vez disso, armazene o estado da sua aplicação em algum outro local.
+ Use o armazenamento local e os objetos do nível de classe para aumentar a performance, mas mantenha no mínimo o tamanho do pacote de implantação e da quantidade de dados transferidos para o ambiente de execução.
Para obter uma introdução prática do modelo de programação na linguagem de programação de sua preferência, consulte os capítulos a seguir.
+ [Criar funções do Lambda com Node.js](lambda-nodejs.md)
+ [Criar funções do Lambda com Python](lambda-python.md)
+ [Construir funções do Lambda com Ruby](lambda-ruby.md)
+ [Construir funções do Lambda com Java](lambda-java.md)
+ [Criar funções do Lambda com Go](lambda-golang.md)
+ [Construir funções do Lambda com C\$1](lambda-csharp.md)
+ [Construir funções do Lambda com o PowerShell](lambda-powershell.md)
# Noções básicas sobre o ciclo de vida do ambiente de execução do Lambda
Os ambientes de execução do Lambda oferecem suporte a funções padrão (até 15 minutos) e funções duráveis (até um ano). Embora ambas compartilhem o mesmo ciclo de vida básico, as funções duráveis adicionam recursos de gerenciamento de estado para fluxos de trabalho de longa duração.
O Lambda invoca a função em um ambiente de execução, que fornece um ambiente do tempo de execução seguro e isolado. O ambiente de execução gerencia os recursos necessários para executar a função. O ambiente de execução também fornece suporte ao ciclo de vida para o runtime da função e qualquer [extensão externa](lambda-extensions.md) associada à função.
**Para funções duráveis, o ambiente de execução inclui componentes adicionais para:**
+ Persistência de estado entre etapas
+ Gerenciamento de pontos de verificação
+ Coordenação do estado de espera
+ Acompanhamento de andamento
**Ambiente de execução de instâncias gerenciadas do Lambda**
Se você estiver usando [instâncias gerenciadas do Lambda](lambda-managed-instances-execution-environment.md), o ambiente de execução terá diferenças importantes em comparação com as funções do Lambda (padrão). As instâncias gerenciadas oferecem suporte a invocações simultâneas, usam um modelo de ciclo de vida diferente e são executadas na infraestrutura de propriedade do cliente. Para obter informações detalhadas sobre o ambiente de execução de instâncias gerenciadas, consulte [Noções básicas sobre o ambiente de execução das instâncias gerenciadas do Lambda](lambda-managed-instances-execution-environment.md).
O runtime da função se comunica com o Lambda usando a [API de runtime](runtimes-api.md). As extensões se comunicam com o Lambda usando a [API Extensions](runtimes-extensions-api.md). As extensões também podem receber mensagens de log e outras telemetrias da função ao usar a [API de telemetria](telemetry-api.md).
![\[Diagrama de arquitetura do ambiente de execução.\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/telemetry-api-concept-diagram.png)
Quando você cria uma função do Lambda, você especifica informações de configuração, como a quantidade de memória disponível e o tempo máximo de execução permitido para sua função. O Lambda usa essas informações para configurar o ambiente de execução.
O runtime da função e cada extensão externa são processos executados dentro do ambiente de execução. Permissões, recursos, credenciais e variáveis de ambiente são compartilhados entre a função e as extensões.
**Topics**
+ [
## Ciclo de vida do ambiente de execução do Lambda
](#runtimes-lifecycle)
+ [
## Inicializações a frio e latência
](#cold-start-latency)
+ [
## Redução de inicializações a frio com simultaneidade provisionada
](#cold-starts-pc)
+ [
## Otimização da inicialização estática
](#static-initialization)
## Ciclo de vida do ambiente de execução do Lambda
![\[Fases do ciclo de vida do Lambda: inicialização, invocação, encerramento\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/Overview-Successful-Invokes.png)
Cada fase começa com um evento que o Lambda envia para o runtime e para todas as extensões registradas. O runtime e cada extensão indicam a conclusão enviando uma solicitação de API `Next`. O Lambda congela o ambiente de execução quando o runtime e cada extensão tiverem sido concluídos e não houver eventos pendentes.
**As fases do ciclo de vida das funções duráveis incluem:**
+ **Inicializar:** inicialização padrão mais configuração de estado durável
+ **Invocar:** pode incluir execuções em várias etapas com pontos de verificação automáticos
+ **Esperar:** a função pode pausar a execução sem consumir recursos
+ **Retomar:** a função é reiniciada a partir do último ponto de verificação
+ **Desligar:** limpeza do estado e dos recursos duráveis
**Topics**
+ [
### Fase de inicialização
](#runtimes-lifecycle-ib)
+ [
### Falhas durante a fase de inicialização
](#runtimes-lifecycle-init-errors)
+ [
### Fase de restauração (somente para Lambda SnapStart)
](#runtimes-lifecycle-restore)
+ [
### Fase de invocação
](#runtimes-lifecycle-invoke)
+ [
### Falhas durante a fase de invocação
](#runtimes-lifecycle-invoke-with-errors)
+ [
### Fase de desligamento
](#runtimes-lifecycle-shutdown)
### Fase de inicialização
Na fase `Init`, o Lambda executa três tarefas:
+ Iniciar todas as extensões (`Extension init`)
+ Realizar bootstrap no runtime (`Runtime init`)
+ Executar o código estático da função (`Function init`)
+ Executar qualquer [hook de runtime](snapstart-runtime-hooks.md) before-checkpoint (somente para Lambda SnapStart)
A fase `Init` termina quando o runtime e todas as extensões sinalizam que estão prontas enviando uma solicitação de API `Next`. A fase `Init` é limitada a 10 segundos. Se todas as três tarefas não forem concluídas em até dez segundos, o Lambda repetirá a fase `Init` no momento da primeira invocação de função com o tempo-limite de função configurado.
Quando o [Lambda SnapStart](snapstart.md) está ativado, a fase `Init` ocorre ao você publicar uma versão da função. O Lambda salva um snapshot do estado da memória e do disco do ambiente de execução inicializado, mantém o snapshot criptografado e o armazena em cache para acesso de baixa latência. Se você tiver um [hook de runtime](snapstart-runtime-hooks.md) before-checkpoint, então, o código será executado ao final da fase `Init`.
**nota**
O tempo limite de dez segundos não se aplica às funções que estejam usando simultaneidade provisionada, SnapStart ou instâncias gerenciadas do Lambda. Para funções de simultaneidade provisionada, SnapStart e instâncias gerenciadas, seu código de inicialização pode ser executado por até 15 minutos. O limite de tempo é de 130 segundos ou o tempo limite da função configurada (máximo de 900 segundos), o que for maior.
Quando você usa [simultaneidade provisionada](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html), o Lambda inicializa o ambiente de execução quando você define as configurações do PC para uma função. O Lambda também garante que os ambientes de execução inicializados estejam sempre disponíveis antes das invocações. É possível observar lacunas entre a invocação e as fases de inicialização da sua função. Dependendo do runtime e da configuração de memória da sua função, é possível observar uma latência variável na primeira invocação em um ambiente de execução inicializado.
Para funções que usam simultaneidade sob demanda, o Lambda pode ocasionalmente inicializar ambientes de execução antes das solicitações de invocação. Quando isso acontece, você também pode observar uma lacuna de tempo entre as fases de inicialização e invocação da função. Recomendamos que você não dependa desse comportamento.
### Falhas durante a fase de inicialização
Se uma função falhar ou atingir o tempo limite durante a fase `Init`, o Lambda emite informações de erro no log `INIT_REPORT`.
**Example — log INIT\$1REPORT para tempo limite**
```
INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: timeout
```
**Example — log INIT\$1REPORT para falha de extensão**
```
INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: error Error Type: Extension.Crash
```
Se a fase `Init` tiver êxito, o Lambda não gerará o log `INIT_REPORT`, a não ser que a função [SnapStart](snapstart.md) ou a [simultaneidade provisionada](provisioned-concurrency.md) esteja habilitada. As funções SnapStart e de simultaneidade provisionada sempre geram `INIT_REPORT`. Para obter mais informações, consulte [Monitoramento para o Lambda SnapStart](snapstart-monitoring.md).
### Fase de restauração (somente para Lambda SnapStart)
Quando você invoca uma função do [SnapStart](snapstart.md) pela primeira vez e à medida que aumenta a escala verticalmente da função, o Lambda retoma novos ambientes de execução a partir do snapshot retido, em vez de inicializar a função do zero. Se você tiver um [hook de runtime](snapstart-runtime-hooks.md) after-restore, o código será executado ao final da fase `Restore`. Serão realizadas cobranças pela duração dos hooks de runtime after-restore. O runtime deve ser carregado e os hooks de runtime after-restore devem ser concluídos dentro do limite de tempo limite (dez segundos). Caso contrário, você obterá uma SnapStartTimeoutException. Quando a fase `Restore` é concluída, o Lambda invoca o manipulador de função (a [Fase de invocação](#runtimes-lifecycle-invoke)).
#### Falhas durante a fase de restauração
Se a fase `Restore` falhar, o Lambda emite informações de erro no log `RESTORE_REPORT`.
**Example — log RESTORE\$1REPORT para tempo limite**
```
RESTORE_REPORT Restore Duration: 1236.04 ms Status: timeout
```
**Example — log RESTORE\$1REPORT para falha no hook de runtime**
```
RESTORE_REPORT Restore Duration: 1236.04 ms Status: error Error Type: Runtime.ExitError
```
Para obter mais informações sobre o log `RESTORE_REPORT`, consulte [Monitoramento para o Lambda SnapStart](snapstart-monitoring.md).
### Fase de invocação
Quando uma função do Lambda é invocada em resposta a uma solicitação de API `Next`, o Lambda envia um evento `Invoke` para o runtime e para cada extensão.
A configuração de tempo limite da função limita a duração de toda a fase `Invoke`. Por exemplo, se você definir o tempo limite da função como 360 segundos, a função e todas as extensões precisam ser concluídas em até 360 segundos. Observe que não há fase de pós-invocação independente. A duração é a soma de todo o tempo de invocação (runtime \$1 extensões) e não é calculada até que a função e todas as extensões tenham terminado a execução.
A fase de invocação termina após o runtime e todas as extensões sinalizam que elas foram concluídas enviando uma solicitação de API `Next`.
### Falhas durante a fase de invocação
Se a função do Lambda falhar ou expirar durante o`Invoke`fase, o Lambda redefine o ambiente de execução. O diagrama a seguir ilustra o comportamento do ambiente de execução do Lambda quando há falha de invocação:
![\[Exemplo de ambiente de execução: inicialização, invocação, invocação com erro, invocação, encerramento\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/Overview-Invoke-with-Error.png)
No diagrama anterior:
+ A primeira fase é a fase **INIT**, que é executada sem erros.
+ A segunda fase é a fase **INVOKE**, que é executada sem erros.
+ Suponha que, em algum momento, sua função depare-se com uma falha de invocação (causas comuns incluem tempo limite da função, erros de runtime, esgotamento da memória, problemas de conectividade com a VPC, erros de permissão, limites de simultaneidade e vários problemas de configuração). Para uma lista completa de possíveis falhas de invocação, consulte [Solucionar problemas de invocação no Lambda](troubleshooting-invocation.md). A terceira fase, chamada **INVOKE WITH ERROR**, ilustra esse caso. Quando isso ocorre, o serviço do Lambda executa uma redefinição. A redefinição se comporta como um evento `Shutdown`. Primeiro, o Lambda encerra o runtime; depois, envia um evento `Shutdown` para cada extensão externa registrada. O evento inclui o motivo do desligamento. Se esse ambiente for usado para uma nova invocação, o Lambda reinicializará a extensão e o runtime com a próxima invocação.
Observe que a redefinição do Lambda não limpa o conteúdo do diretório `/tmp` antes da próxima fase de inicialização. Esse comportamento é consistente com a fase de desligamento regular.
**nota**
A AWS atualmente está implementando alterações no serviço Lambda. Devido a essas alterações, você pode ver pequenas diferenças entre a estrutura e o conteúdo das mensagens de log do sistema e os segmentos de rastreamento emitidos por diferentes funções do Lambda na sua Conta da AWS.
Se a configuração de log do sistema da função estiver definida como texto simples, essa alteração afetará as mensagens de log capturadas no CloudWatch Logs quando a função apresentar uma falha de invocação. Os exemplos a seguir mostram saídas de log no formato antigo e no formato novo.
Essas alterações serão implementadas durante as próximas semanas, e todas as funções em todas as Regiões da AWS, exceto nas regiões China e GovCloud, passarão a usar o novo formato de mensagens de log e segmentos de rastreamento.
**Example Saída de log do CloudWatch Logs (pane de runtime ou de extensão), estilo antigo**
```
START RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Version: $LATEST
RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Error: Runtime exited without providing a reason
Runtime.ExitError
END RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1
REPORT RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Duration: 933.59 ms Billed Duration: 934 ms Memory Size: 128 MB Max Memory Used: 9 MB
```
**Example Saída de log do CloudWatch Logs (tempo limite da função), estilo antigo**
```
START RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Version: $LATEST
2024-03-04T17:22:38.033Z b70435cc-261c-4438-b9b6-efe4c8f04b21 Task timed out after 3.00 seconds
END RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21
REPORT RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Duration: 3004.92 ms Billed Duration: 3117 ms Memory Size: 128 MB Max Memory Used: 33 MB Init Duration: 111.23 ms
```
O novo formato do CloudWatch Logs inclui um campo adicional `status` na linha `REPORT`. No caso de haver uma pane de runtime ou de extensão, a linha `REPORT` também incluirá um campo `ErrorType`.
**Example Saída de log do CloudWatch Logs (pane de runtime ou de extensão), estilo novo**
```
START RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Version: $LATEST
END RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd
REPORT RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Duration: 133.61 ms Billed Duration: 214 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 80.00 ms Status: error Error Type: Runtime.ExitError
```
**Example Saída de log do CloudWatch Logs (tempo limite da função), estilo novo**
```
START RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Version: $LATEST
END RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda
REPORT RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Duration: 3016.78 ms Billed Duration: 3101 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 84.00 ms Status: timeout
```
+ A quarta fase representa a fase **INVOKE** imediatamente após uma falha de invocação. Aqui, o Lambda reinicializa o ambiente executando a fase **INIT**. Isso se chama *inicialização suprimida*. Quando ocorrem inicializações suprimidas, o Lambda não relata explicitamente uma fase adicional de **INIT** no CloudWatch Logs. Em vez disso, você perceberá que a duração na linha REPORT inclui uma duração adicional de **INIT** mais a duração de **INVOKE**. Por exemplo, digamos que você veja os seguintes logs no CloudWatch:
```
2022-12-20T01:00:00.000-08:00 START RequestId: XXX Version: $LATEST
2022-12-20T01:00:02.500-08:00 END RequestId: XXX
2022-12-20T01:00:02.500-08:00 REPORT RequestId: XXX Duration: 3022.91 ms
Billed Duration: 3000 ms Memory Size: 512 MB Max Memory Used: 157 MB
```
Neste exemplo, a diferença entre os carimbos de data e hora REPORT e START é de 2,5 segundos. Isso não corresponde à duração relatada de 3022,91 milissegundos, pois não leva em conta o **INIT** adicional (inicialização suprimida) que o Lambda executou. Neste exemplo, podemos inferir que a fase **INVOKE** exata durou 2,5 segundos.
Para obter mais insights sobre esse comportamento, você pode usar [Acessar dados de telemetria em tempo real para extensões usando a API Telemetria](telemetry-api.md). A API Telemetry emite eventos `INIT_START`, `INIT_RUNTIME_DONE` e `INIT_REPORT` com `phase=invoke` sempre que ocorrem inicializações suprimidas entre as fases de invocação.
+ A quinta fase representa a fase **SHUTDOWN**, que é executada sem erros.
### Fase de desligamento
Quando o Lambda estiver prestes a encerrar o runtime, ele enviará um evento `Shutdown` a cada extensão externa registrada. As extensões podem usar esse tempo para tarefas de limpeza finais. O evento `Shutdown` é uma resposta a uma solicitação de API `Next`.
**Limite de duração**: a duração máxima da fase `Shutdown` depende da configuração das extensões registradas:
+ 0 ms: uma função sem extensões registradas
+ 500 ms: uma função com uma extensão interna registrada
+ 2.000 ms: uma função com uma ou mais extensões externas registradas
Se o runtime ou uma extensão não responder ao evento `Shutdown` dentro do limite, o Lambda encerrará o processo usando um sinal `SIGKILL`.
Após a conclusão da função e de todas as extensões, o Lambda mantém o ambiente de execução por algum tempo à espera de uma outra invocação de função. No entanto, o Lambda encerra os ambientes de execução a cada poucas horas para permitir atualizações e manutenção do runtime, mesmo para funções que são invocadas continuamente. Você não deve presumir que o ambiente de execução persistirá indefinidamente. Para obter mais informações, consulte [Implementar a ausência de estado em funções](concepts-application-design.md#statelessness-functions).
Quando a função é invocada novamente, o Lambda descongela o ambiente para reutilização. Reutilizar o ambiente de execução tem as seguintes implicações:
+ Os objetos declarados fora do método do manipulador da função permanecem inicializados, fornecendo otimização adicional quando a função é invocada novamente. Por exemplo, se sua função do Lambda estabelecer uma conexão com o banco de dados, em vez de restabelecer a conexão, a conexão original é usada em invocações subsequentes. Recomendamos que você adicione lógica em seu código para verificar se uma há conexão existente antes de criar outra.
+ Cada ambiente de execução fornece entre 512 MB e 10.240 MB, em incrementos de 1 MB, de espaço em disco no diretório `/tmp`. O conteúdo do diretório permanece quando o ambiente de execução é congelado, fornecendo cache transitório que pode ser usado para várias invocações. É possível adicionar um código extra para verificar se o cache tem os dados que você armazenou. Para obter mais informações sobre limites de tamanho de implantação, consulte [Cotas LambdaCotas Lambda](gettingstarted-limits.md).
+ Processos em segundo plano ou retornos de chamada que foram iniciados pela função do Lambda e não foram concluídos quando a função terminou serão retomados se o Lambda reutilizar o ambiente de execução. Garanta que todos os processos em segundo plano ou retornos de chamadas no seu código sejam concluídos antes que o código seja encerrado.
## Inicializações a frio e latência
Quando o Lambda recebe uma solicitação para executar uma função por meio da API do Lambda, o serviço primeiro prepara um ambiente de execução. Durante a fase de inicialização, o serviço baixa o código, inicia o ambiente e executa qualquer código de inicialização fora do manipulador principal. Por último, o Lambda executa o código do manipulador.
![\[otimização da performance figura 1\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/perf-optimize-figure-1.png)
Nesse diagrama, as duas primeiras etapas de download do código e configuração do ambiente são frequentemente chamadas de “inicialização a frio”. Você é [cobrado por esse tempo](https://aws.amazon.com/blogs/compute/aws-lambda-standardizes-billing-for-init-phase/), e isso adiciona latência à duração total da invocação.
Após a conclusão da invocação, o ambiente de execução é congelado. Para melhorar o gerenciamento de recursos e a performance, o Lambda retém o ambiente de execução por um período de tempo. Durante esse período, se outra solicitação chegar para a mesma função, o Lambda pode reutilizar o ambiente. Essa segunda solicitação costuma terminar mais rápido, pois o ambiente de execução já está totalmente configurado. Isso é chamado de “inicialização a quente”.
Inicializações a frio geralmente ocorrem em menos de 1% das invocações. A duração de uma inicialização a frio varia de menos de 100 ms a mais de 1 segundo. Em geral, inicializações a frio são mais comuns em funções de desenvolvimento e teste do que em workloads de produção. Isso ocorre porque as funções de desenvolvimento e teste geralmente são invocadas com menos frequência.
## Redução de inicializações a frio com simultaneidade provisionada
Se você precisa de horários de início de funções previsíveis para sua workload, a [simultaneidade provisionada](provisioned-concurrency.md) é a solução recomendada para garantir a menor latência possível. Esse recurso faz a pré-inicialização dos ambientes de execução, reduzindo assim as inicializações a frio.
Por exemplo, uma função com uma simultaneidade provisionada de 6 tem 6 ambientes de execução pré-aquecidos.
![\[otimização da performance figura 4\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/perf-optimize-figure-4.png)
## Otimização da inicialização estática
A inicialização estática ocorre antes da execução do código do manipulador em uma função. Esse é o código de inicialização que você fornece, fora do manipulador principal. Esse código geralmente é usado para importar bibliotecas e dependências, definir configurações e inicializar conexões com outros serviços.
O exemplo Python a seguir mostra a importação e a configuração de módulos e a criação do cliente Amazon S3 durante a fase de inicialização, antes de a função `lambda_handler` ser executada durante a invocação.
```
import os
import json
import cv2
import logging
import boto3
s3 = boto3.client('s3')
logger = logging.getLogger()
logger.setLevel(logging.INFO)
def lambda_handler(event, context):
# Handler logic...
```
O maior fator contribuinte para a latência antes da execução da função é proveniente do código de inicialização. Esse código é executado no momento em que um novo ambiente de execução é criado pela primeira vez. O código de inicialização não será executado novamente se uma invocação usar um ambiente de execução quente. Estes são alguns dos fatores que afetam a latência do código de inicialização:
+ O tamanho do pacote de funções, em termos de bibliotecas e dependências importadas, e camadas do Lambda.
+ A quantidade de código e o trabalho de inicialização.
+ A performance de bibliotecas e outros serviços na configuração de conexões e outros recursos.
Existem várias etapas que os desenvolvedores podem seguir a fim de otimizar a latência de inicialização estática. Se uma função tiver muitos objetos e conexões, você poderá redefinir a arquitetura de uma única função em várias funções especializadas. Eles são individualmente menores e cada um tem menos código de inicialização.
É importante que as funções importem apenas as bibliotecas e dependências de que precisam. Por exemplo, se você usa apenas o Amazon DynamoDB no AWS SDK, pode exigir um serviço individual, em vez do SDK inteiro. Compare os três exemplos seguintes:
```
// Instead of const AWS = require('aws-sdk'), use:
const DynamoDB = require('aws-sdk/clients/dynamodb')
// Instead of const AWSXRay = require('aws-xray-sdk'), use:
const AWSXRay = require('aws-xray-sdk-core')
// Instead of const AWS = AWSXRay.captureAWS(require('aws-sdk')), use:
const dynamodb = new DynamoDB.DocumentClient()
AWSXRay.captureAWSClient(dynamodb.service)
```
A inicialização estática geralmente também é o melhor lugar para abrir conexões de banco de dados para permitir que uma função reutilize conexões em várias invocações no mesmo ambiente de execução. No entanto, você pode ter um grande número de objetos que são usados somente em determinados caminhos de execução em sua função. Nesse caso, você pode carregar variáveis lentamente no escopo global para reduzir a duração da inicialização estática.
Evite variáveis globais para obter informações específicas do contexto. Se sua função tiver uma variável global usada somente durante a vida útil de uma única invocação e for redefinida para a próxima invocação, use um escopo de variável que seja local para o manipulador. Isso não apenas evita vazamentos de variáveis globais nas invocações, mas também melhora a performance da inicialização estática.
# Criar arquiteturas orientadas por eventos com o Lambda
Um evento é algo que aciona a execução de uma função do Lambda. Os eventos podem acionar uma função do Lambda de duas maneiras: por meio de invocação direta (push) e mapeamentos da origem do evento (pull).
Muitos serviços da AWS podem invocar as funções do Lambda diretamente. Esses serviços fazem o *push* dos eventos para a função do Lambda. Os eventos que acionam as funções podem ser quase tudo, desde uma solicitação HTTP por meio do API Gateway, um cronograma gerenciado por uma regra do EventBridge, um evento de AWS IoT ou um evento do Amazon S3. Com o mapeamento da origem do evento, o Lambda busca (ou *extrai*) ativamente os eventos de uma fila ou de um fluxo. Você configura o Lambda para verificar eventos de um serviço compatível, e o Lambda lida com a sondagem e a invocação da função.
Quando são passados para a função, os eventos estão estruturados no formato JSON. A estrutura JSON varia dependendo do serviço que a gera e do tipo de evento. Embora invocações de funções do Lambda padrão possam durar até 15 minutos (ou até um ano com [funções duráveis](durable-functions.md)), o Lambda é mais adequado para invocações curtas que durem no máximo um segundo. Isso acontece especialmente em arquiteturas orientadas por eventos, nas quais cada função do Lambda é tratada como um microsserviço, responsável por realizar um conjunto restrito de instruções específicas.
**nota**
As arquiteturas orientadas por eventos se comunicam entre diferentes sistemas usando redes, que introduzem latência variável. Para workloads que exigem latência muito baixa, como sistemas comerciais em tempo real, esse design talvez não seja a melhor escolha. No entanto, para workloads altamente escaláveis e disponíveis, ou aquelas com padrões de tráfego imprevisíveis, as arquiteturas orientadas por eventos podem fornecer uma maneira eficaz de atender a essas demandas.
**Topics**
+ [
## Benefícios de arquiteturas orientadas por eventos
](#event-driven-benefits)
+ [
## Desvantagens das arquiteturas orientadas por eventos
](#event-driven-tradeoffs)
+ [
## Antipadrões em aplicações orientadas por eventos com base no Lambda
](#event-driven-anti-patterns)
## Benefícios de arquiteturas orientadas por eventos
O Lambda é compatível com dois métodos de invocação em arquiteturas orientadas por eventos:
1. Invocação direta (método push): os serviços da AWS acionam diretamente as funções do Lambda. Por exemplo:
+ O Amazon S3 aciona uma função quando um arquivo é carregado
+ O API Gateway aciona uma função ao receber uma solicitação HTTP
1. Mapeamento da origem do evento (método pull): o Lambda recupera eventos e invoca funções. Por exemplo:
+ O Lambda recupera as mensagens de uma fila do Amazon SQS e invoca uma função
+ O Lambda lê os registros de um fluxo do DynamoDB e invoca uma função
Ambos os métodos contribuem para os benefícios das arquiteturas orientadas a eventos, conforme descrito abaixo.
### Substituição de pesquisas e webhooks por eventos
Muitas arquiteturas tradicionais usam mecanismos de pesquisa e webhook para comunicar o estado entre diferentes componentes. A pesquisa pode ser altamente ineficiente para obter atualizações, pois há um atraso entre a disponibilização de novos dados e a sincronização com os serviços downstream. Os webhooks nem sempre são compatíveis com outros microsserviços aos quais você deseja integrar. Eles também podem exigir configurações personalizadas de autorização e autenticação. Em ambos os casos, é difícil escalar esses métodos de integração sob demanda sem trabalho adicional das equipes de desenvolvimento.
![\[arquiteturas orientadas por eventos figura 7\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/event-driven-architectures-figure-7.png)
Esses dois mecanismos podem ser substituídos por eventos, que podem ser filtrados, roteados e enviados downstream para microsserviços consumidores. Essa abordagem pode resultar em menor consumo de largura de banda, utilização da CPU e uma possível redução de custos. Essas arquiteturas também podem diminuir a complexidade, pois cada unidade funcional é menor e geralmente há menos código.
![\[arquiteturas orientadas por eventos figura 8\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/event-driven-architectures-figure-8.png)
As arquiteturas orientadas por eventos também podem facilitar o design de sistemas quase em tempo real, ajudando as organizações a se afastarem do processamento baseado em lotes. Os eventos são gerados no momento em que o estado da aplicação muda, portanto, o código personalizado de um microsserviço deve ser projetado para lidar com o processamento de um único evento. Como a escalabilidade é gerenciada pelo serviço Lambda, essa arquitetura pode lidar com aumentos significativos no tráfego sem alterar o código personalizado. À medida que a escala dos eventos aumenta, o mesmo acontece com a camada de computação que processa os eventos.
### Redução da complexidade
Os microsserviços permitem que desenvolvedores e arquitetos simplifiquem fluxos de trabalho complexos. Por exemplo, um monólito de comércio eletrônico pode ser dividido em processos de aceitação e pagamento de pedidos com serviços separados de inventário, atendimento e contabilidade. O que pode ser complexo de gerenciar e orquestrar em um monólito se torna uma série de serviços desacoplados que se comunicam de maneira assíncrona com eventos.
![\[arquiteturas orientadas por eventos figura 9\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/event-driven-architectures-figure-9.png)
Essa abordagem também possibilita a montagem de serviços que processam dados em taxas diferentes. Nesse caso, um microsserviço de aceitação de pedidos pode armazenar grandes volumes de pedidos recebidos colocando as mensagens em buffer em uma fila do Amazon SQS.
Um serviço de processamento de pagamentos, que normalmente é mais lento devido à complexidade de lidar com pagamentos, pode receber um fluxo constante de mensagens da fila do Amazon SQS. Ele pode orquestrar uma lógica complexa para lidar com novas tentativas e erros usando o AWS Step Functions e coordenar fluxos de trabalho de pagamento ativos para centenas de milhares de pedidos.
**Abordagem alternativa:** para orquestração usando linguagens de programação padrão, você pode usar as [funções duráveis do Lambda](durable-functions.md). As funções duráveis permitem que você escreva a aceitação de pedidos, o processamento de pagamentos e a lógica de notificação em código com verificação automática e repetição. Essa abordagem funciona bem quando o fluxo de trabalho envolve principalmente funções do Lambda e você prefere manter a lógica de orquestração no código.
### Aprimoramento da escalabilidade e da extensibilidade
Os microsserviços geram eventos que normalmente são publicados em serviços de mensagens, como o Amazon SNS e o Amazon SQS. Eles se comportam como um buffer elástico entre microsserviços e ajudam a lidar com a escalabilidade quando o tráfego aumenta. Serviços como o Amazon EventBridge podem então filtrar e rotear mensagens dependendo do conteúdo do evento, conforme definido nas regras. Como resultado, as aplicações baseadas em eventos podem ser mais escaláveis e oferecer maior redundância do que as aplicações monolíticas.
Esse sistema também é altamente extensível, permitindo que outras equipes ampliem recursos e adicionem funcionalidades sem afetar os microsserviços de processamento de pedidos e de pagamentos. Ao publicar eventos usando o EventBridge, essa aplicação se integra aos sistemas existentes, como o microsserviço de inventário, mas também permite que qualquer aplicação futura se integre como consumidor de eventos. Os produtores de eventos não conhecem os consumidores de eventos, o que pode ajudar a simplificar a lógica dos microsserviços.
## Desvantagens das arquiteturas orientadas por eventos
### Latência variável
Diferentemente das aplicações monolíticas, que podem processar tudo dentro do mesmo espaço de memória em um único dispositivo, as aplicações orientadas por eventos se comunicam entre redes. Esse design introduz latência variável. Embora seja possível criar aplicações para minimizar a latência, as aplicações monolíticas quase sempre podem ser otimizadas para menor latência em detrimento da escalabilidade e da disponibilidade.
As workloads que exigem performance consistente de baixa latência, como aplicações comerciais de alta frequência em bancos ou automação robótica de submilissegundos em depósitos, não são boas candidatas para uma arquitetura orientada por eventos.
### Consistência eventual
Um evento representa uma mudança no estado e, com muitos eventos fluindo por diferentes serviços em uma arquitetura em um determinado momento, essas workloads geralmente [acabam sendo consistentes](https://en.wikipedia.org/wiki/Eventual_consistency). Isso torna mais complexo processar transações, lidar com duplicatas ou determinar o estado geral exato de um sistema.
Muitas workloads contêm uma combinação de requisitos que são finalmente consistentes (por exemplo, total de pedidos na hora atual) ou altamente consistentes (por exemplo, inventário atual). Para workloads que precisam de uma alta consistência de dados, existem padrões de arquitetura para dar suporte a esse requisito. Por exemplo:
+ O DynamoDB pode fornecer [leituras altamente consistentes](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html), às vezes com maior latência, consumindo um throughput maior do que o modo padrão. O DynamoDB também pode [oferecer suporte a transações](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/transactions.html) para ajudar a manter a consistência de dados.
+ É possível usar o Amazon RDS para recursos que precisam de [propriedades ACID](https://en.wikipedia.org/wiki/ACID), embora qualquer banco de dados relacional seja em geral menos escalável do que bancos de dados NoSQL, como o DynamoDB. O [Amazon RDS Proxy](https://aws.amazon.com/rds/proxy/) pode ajudar a gerenciar o agrupamento e a escalabilidade de conexões de consumidores efêmeros, como as funções do Lambda.
As arquiteturas baseadas em eventos geralmente são projetadas com base em eventos individuais, em vez de grandes lotes de dados. Geralmente, os fluxos de trabalho são projetados para gerenciar as etapas de um fluxo individual de evento ou execução, em vez de operar em vários eventos simultaneamente. No tecnologia sem servidor, o processamento de eventos em tempo real é preferível ao processamento em lote: os lotes devem ser substituídos por muitas atualizações incrementais menores. Embora isso possa tornar as workloads mais disponíveis e escaláveis, também dificulta que os eventos reconheçam uns aos outros.
### Retorno de valores aos chamadores
Em muitos casos, as aplicações baseadas em eventos são assíncronas. Isso significa que os serviços chamadores não aguardam receber solicitações de outros serviços para dar continuidade a outros trabalhos. Essa é uma característica fundamental das arquiteturas orientadas por eventos que permite escalabilidade e flexibilidade. Isso significa que passar valores de retorno ou o resultado de um fluxo de trabalho é mais complexo do que em fluxos de execução síncrona.
A maioria das invocações do Lambda em sistemas de produção é [assíncrona](invocation-async.md), respondendo a eventos de serviços, como o Amazon S3 ou o Amazon SQS. Nesses casos, o êxito ou a falha do processamento de um evento geralmente é mais importante do que retornar um valor. Recursos como as [filas de mensagens não entregues](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html) (DLQs) no Lambda são fornecidos para garantir que você possa identificar e tentar novamente eventos com falha, sem precisar notificar o chamador.
### Depuração em vários serviços e funções
A depuração de sistemas orientados a eventos também é diferente em comparação com uma aplicação monolítica. Com diferentes sistemas e serviços transmitindo eventos, não é possível registrar e reproduzir o estado exato de vários serviços quando ocorrem erros. Como cada invocação de serviço e função tem arquivos de log separados, pode ser mais complicado determinar o que aconteceu com um evento específico que causou um erro.
Há três requisitos importantes para criar uma abordagem de depuração bem-sucedida em sistemas orientados por eventos. Primeiro, um sistema de registro de logs robusto é essencial, e ele é fornecido em todos os serviços da AWS e incorporado às funções do Lambda pelo Amazon CloudWatch. Em segundo lugar, nesses sistemas, é importante garantir que cada evento tenha um identificador de transação registrado em cada etapa da transação, para ajudar na busca por logs.
Por fim, é altamente recomendável automatizar a análise de logs usando um serviço de depuração e monitoramento, como o AWS X-Ray. Isso pode consumir logs em várias invocações e serviços do Lambda, facilitando muito a identificação da causa-raiz dos problemas. Consulte o [Passo a passo da solução de problemas](lambda-troubleshooting.md) para obter uma cobertura detalhada de como usar o X-Ray para a solução de problemas.
## Antipadrões em aplicações orientadas por eventos com base no Lambda
Ao criar arquiteturas orientadas por eventos com o Lambda, evite os seguintes antipadrões comuns. Esses padrões funcionam, mas podem aumentar os custos e a complexidade.
### O monólito do Lambda
Em muitas aplicações migradas de servidores tradicionais, como instâncias do Amazon EC2 ou aplicações do Elastic Beanstalk, os desenvolvedores “movem sem alterações (lift-and-shift)” o código existente. Frequentemente, isso resulta em uma única função do Lambda que contém toda a lógica da aplicação que é acionada para todos os eventos. Para uma aplicação Web básica, uma função do Lambda monolítico processa todas as rotas do API Gateway e se integra a todos os recursos downstream necessários.
![\[arquiteturas orientadas por eventos figura 13\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/event-driven-architectures-figure-13.png)
Essa abordagem tem várias desvantagens:
+ **Tamanho do pacote**: a função do Lambda pode ser muito maior porque contém todo o código possível para todos os caminhos, o que torna mais lenta a execução pelo serviço Lambda.
+ **Dificuldade para aplicar o privilégio mínimo**: o [perfil de execução](lambda-intro-execution-role.md) da função deve dar permissões a todos os recursos necessários para todos os caminhos, tornando as permissões muito amplas. Esta é uma preocupação de segurança. Muitos caminhos no monólito funcional não precisam de todas as permissões que foram concedidas.
+ **Dificuldade de upgrade**: em um sistema de produção, qualquer atualização para uma única função é mais arriscada e pode fazer com que toda a aplicação pare de funcionar. Atualizar um único caminho na função do Lambda significa um upgrade em toda a função.
+ **Dificuldade de manter**: é mais difícil ter vários desenvolvedores trabalhando no serviço, pois é um repositório de código monolítico. Isso também aumenta a carga cognitiva dos desenvolvedores e dificulta a criação de uma cobertura de teste apropriada para o código.
+ **Dificuldade de reutilizar código**: é mais difícil separar bibliotecas reutilizáveis de monólitos, dificultando a reutilização do código. À medida que você desenvolve e apoia mais projetos, isso pode dificultar o suporte ao código e a escalabilidade da velocidade da sua equipe.
+ **Dificuldade de testar**: à medida que as linhas de código aumentam, fica mais difícil fazer testes de unidade de todas as combinações possíveis de entradas e pontos de entrada na base do código. Geralmente, é mais fácil implementar testes de unidade para serviços menores com menos código.
A alternativa de preferência é dividir a função do Lambda monolítico em microsserviços individuais, mapeando uma única função do Lambda para uma tarefa bem definida. Nessa aplicação Web simples com alguns endpoints de API, a arquitetura baseada em microsserviços resultante pode ser baseada nas rotas do API Gateway.
![\[arquiteturas orientadas por eventos figura 14\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/event-driven-architectures-figure-14.png)
### Padrões recursivos que geram funções do Lambda descontroladas
Os serviços da AWS geram eventos que invocam funções do Lambda, e as funções do Lambda podem enviar mensagens aos serviços da AWS. Geralmente, o serviço ou recurso que invoca uma função do Lambda deve ser diferente do serviço ou recurso para o qual a função gera saídas. Não gerenciar isso pode resultar em loops infinitos.
Por exemplo, uma função do Lambda grava um objeto em um objeto do Amazon S3, que por sua vez invoca a mesma função do Lambda por meio de um evento put. A invocação faz com que um segundo objeto seja gravado no bucket, o que invoca a mesma função do Lambda:
![\[arquiteturas orientadas por eventos figura 15\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/event-driven-architectures-figure-15.png)
Embora a possibilidade de loops infinitos exista na maioria das linguagens de programação, esse antipadrão tem o potencial de consumir mais recursos em aplicações com tecnologia sem servidor. Tanto o Lambda quanto o Amazon S3 escalam automaticamente com base no tráfego, então, o loop pode fazer com que o Lambda escale para consumir toda a simultaneidade disponível e o Amazon S3 continuará gravando objetos e gerando mais eventos para o Lambda.
Este exemplo usa o S3, mas o risco de loops recursivos também existe no Amazon SNS, no Amazon SQS, no DynamoDB e em outros serviços. É possível usar a [detecção de loops recursivos](invocation-recursion.md) para encontrar e evitar esse antipadrão.
### Funções do Lambda chamando funções do Lambda
As funções permitem o encapsulamento e a reutilização de código. A maioria das linguagens de programação oferece suporte ao conceito de código chamando funções de forma síncrona dentro de uma base de códigos. Nesse caso, o chamador aguarda até a função retornar uma resposta.
**nota**
Embora funções do Lambda que chamem diretamente outras funções do Lambda geralmente sejam um antipadrão devido a questões de custo e complexidade, isso não se aplica às [funções duráveis](durable-functions.md), que são projetadas especificamente para orquestrar fluxos de trabalho de várias etapas ao invocar outras funções.
Quando isso acontece em um servidor tradicional ou uma instância virtual, o programador do sistema operacional muda para outro trabalho disponível. O fato de a CPU funcionar a 0% ou 100% não afeta o custo geral da aplicação, pois você está pagando um custo fixo pelo direito de propriedade e operação de um servidor.
Esse modelo geralmente não se adapta bem ao desenvolvimento com tecnologia sem servidor. Por exemplo, considere uma aplicação de comércio eletrônico simples que consiste em três funções do Lambda que processam um pedido:
![\[arquiteturas orientadas por eventos figura 16\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/event-driven-architectures-figure-16.png)
Nesse caso, a função *Criar pedido* chama a função *Processar pagamento*, que, por sua vez, chama a função *Criar fatura*. Embora esse fluxo síncrono possa funcionar em uma única aplicação em um servidor, ele apresenta vários problemas evitáveis em uma arquitetura distribuída com tecnologia sem servidor:
+ **Custo**: com o Lambda, você paga pela duração de uma invocação. Neste exemplo, enquanto as funções *Criar fatura* são executadas, duas outras funções também estão sendo executadas em um estado de espera, mostrado em vermelho no diagrama.
+ **Tratamento de erros**: em invocações aninhadas, o tratamento de erros pode se tornar muito mais complexo. Por exemplo, um erro em *Criar fatura* pode exigir que a função *Processar pagamento* reverta a cobrança ou, em vez disso, ela pode tentar o processo *Criar fatura* novamente.
+ **Acoplamento forte**: o processamento de um pagamento normalmente leva mais tempo do que a criação de uma fatura. Nesse modelo, a disponibilidade de todo o fluxo de trabalho é limitada pela função mais lenta.
+ **Escala**: a [simultaneidade](lambda-concurrency.md) de todas as três funções deve ser igual. Em um sistema com um grande volume de operações, isso usa mais simultaneidade do que seria necessário.
Em aplicações com tecnologia sem servidor, há duas abordagens comuns para evitar esse padrão. Primeiro, use uma fila do Amazon SQS entre as funções do Lambda. Se um processo downstream for mais lento do que um processo upstream, a fila persistirá as mensagens de forma duradoura e desacoplará as duas funções. Neste exemplo, a função *Criar pedido* publica uma mensagem em uma fila do Amazon SQS e a função *Processar pagamento* consome mensagens da fila.
A segunda abordagem é usar o AWS Step Functions. Para processos complexos com vários tipos de falha e lógica de novas tentativas, o Step Functions pode ajudar a reduzir a quantidade de código personalizado necessário para orquestrar o fluxo de trabalho. Como resultado, o Step Functions orquestra o trabalho e lida com erros e novas tentativas de forma robusta, e as funções do Lambda contêm apenas lógica de negócios.
### Espera síncrona em uma única função do Lambda
Certifique-se de que quaisquer atividades potencialmente simultâneas não sejam programadas de maneira síncrona em uma única função do Lambda. Por exemplo, uma função do Lambda pode gravar em um bucket do S3 e depois gravar em uma tabela do DynamoDB:
![\[arquiteturas orientadas por eventos figura 17\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/event-driven-architectures-figure-17.png)
Nesse design, os tempos de espera são acumulados porque as atividades são sequenciais. Nos casos em que a segunda tarefa depende da conclusão da primeira, você pode reduzir o tempo total de espera e o custo de execução com duas funções do Lambda separadas:
![\[arquiteturas orientadas por eventos figura 19\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/event-driven-architectures-figure-19.png)
Nesse design, a primeira função do Lambda responde imediatamente após colocar o objeto no bucket do Amazon S3. O serviço S3 invoca a segunda função do Lambda, que então grava dados na tabela do DynamoDB. Essa abordagem minimiza o tempo total de espera nas execuções da função do Lambda.
# Projetar aplicações do Lambda
Uma aplicação bem arquitetada e orientada a eventos usa uma combinação de serviços da AWS e códigos personalizados para processar e gerenciar solicitações e dados. Este capítulo se concentra em tópicos específicos do Lambda no design de aplicações. Há muitas considerações importantes para arquitetos que usam tecnologia sem servidor ao projetar aplicações para sistemas de produção com um grande volume de operações.
Muitas das práticas recomendadas que se aplicam ao desenvolvimento de software e sistemas distribuídos também se aplicam ao desenvolvimento de aplicações com tecnologia sem servidor. O objetivo geral é desenvolver workloads que sejam:
+ **Confiáveis**: oferece aos usuários finais um alto nível de disponibilidade. Os serviços com tecnologia sem servidor da AWS são confiáveis porque também foram projetados para falhas.
+ **Duráveis**: fornece opções de armazenamento que atendem às necessidades de durabilidade da sua workload.
+ **Seguras**: segue as práticas recomendadas e usa as ferramentas fornecidas para proteger o acesso às workloads e limitar o raio de explosão.
+ **Eficientes**: usa recursos de computação de forma eficiente e atende às necessidades de performance de seus usuários finais.
+ **Econômicas**: projeta arquiteturas que evitam custos desnecessários e que podem ser escaladas sem gastar demais, além de ser possível desativá-las, se necessário, sem gerar uma sobrecarga significativa.
Os princípios de design a seguir podem ajudar você a criar workloads que atendam a essas metas. Nem todos os princípios podem ser aplicáveis a todas as arquiteturas, mas eles devem orientar você em decisões gerais de arquitetura.
**Topics**
+ [
## Uso de serviços, em vez de código personalizado
](#services-custom-code)
+ [
## Compreender níveis de abstração do Lambda
](#level-abstraction)
+ [
## Implementar a ausência de estado em funções
](#statelessness-functions)
+ [
## Minimizar o acoplamento
](#minimize-coupling)
+ [
## Criar para dados sob demanda em vez de lotes
](#on-demand-batches)
+ [
## Escolha uma opção de orquestração para fluxos de trabalho complexos
](#orchestration)
+ [
## Implementar a idempotência
](#retries-failures)
+ [
## Usar várias contas da AWS para gerenciar cotas
](#multiple-accounts)
## Uso de serviços, em vez de código personalizado
As aplicações com tecnologia sem servidor geralmente incluem vários serviços da AWS, integrados ao código personalizado executado nas funções do Lambda. Embora o Lambda possa ser integrado à maioria dos serviços da AWS, os serviços mais usados em aplicações com tecnologia sem servidor são:
| Categoria | Serviço da AWS |
| --- | --- |
| Computação | AWS Lambda |
| Armazenamento de dados | Amazon S3 Amazon DynamoDB Amazon RDS |
| solicitações de | Amazon API Gateway |
| Integração de aplicações | Amazon EventBridge Amazon SNS Amazon SQS |
| Orquestração | Funções duráveis do Lambda AWS Step Functions |
| Dados de streaming e analytics | Amazon Data Firehose |
**nota**
Muitos serviços com tecnologia sem servidor oferecem replicação e suporte a várias regiões, incluindo o DynamoDB e o Amazon S3. As funções do Lambda podem ser implantadas em várias regiões como parte de um pipeline de implantação, e o API Gateway pode ser configurado para dar suporte a essa configuração. Confira este [exemplo de arquitetura](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/serverless-architecture-for-global-applications-ra.pdf?did=wp_card&trk=wp_card) que mostra como isso pode ser feito.
Há muitos padrões comuns e bem estabelecidos em arquiteturas distribuídas que você pode criar ou implementar por conta própria usando os serviços da AWS. Para a maioria dos clientes, há pouco valor comercial em investir tempo para desenvolver esses padrões do zero. Quando sua aplicação precisar de um desses padrões, use o serviço da AWS correspondente:
| Pattern | Serviço da AWS |
| --- | --- |
| Fila | Amazon SQS |
| Barramento de eventos | Amazon EventBridge |
| Publicação/assinatura (distribuição) | Amazon SNS |
| Orquestração | Funções duráveis do Lambda AWS Step Functions |
| solicitações de | Amazon API Gateway |
| Streams de eventos | Amazon Kinesis |
Esses serviços são projetados para se integrarem ao Lambda, e você pode usar a infraestrutura como código (IaC) para criar e descartar recursos nesses serviços. É possível usar qualquer um desses serviços por meio do [AWS SDK](https://aws.amazon.com/tools/) sem precisar instalar aplicações nem configurar servidores. Tornar-se proficiente no uso desses serviços por meio de código em suas funções do Lambda é uma etapa importante para produzir aplicações com tecnologia sem servidor bem projetadas.
## Compreender níveis de abstração do Lambda
O serviço Lambda limita seu acesso aos sistemas operacionais, hipervisores e hardware subjacentes que executam suas funções do Lambda. O serviço melhora e muda continuamente a infraestrutura para adicionar recursos, reduzir custos e tornar o serviço mais eficiente. Seu código deve presumir que não tem conhecimento de como o Lambda é arquitetado e não deve presumir nenhuma afinidade com o hardware.
Da mesma forma, as integrações do Lambda com outros serviços são gerenciadas por AWS, com apenas um pequeno número de opções de configuração expostas a você. Por exemplo, quando o API Gateway e o Lambda interagem, não há nenhum conceito de balanceamento de cargas, pois ele é totalmente gerenciado pelos serviços. Você também não tem controle direto sobre quais [zonas de disponibilidade](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) os serviços usam ao invocar funções a qualquer momento ou como o Lambda determina quando aumentar ou diminuir a escala verticalmente para onúmero de ambientes de execução.
Essa abstração ajuda você a se concentrar nos aspectos de integração da aplicação, no fluxo de dados e na lógica de negócios em que a workload fornece valor para os usuários finais. Permitir que os serviços gerenciem a mecânica subjacente ajuda você a desenvolver aplicações mais rapidamente com menos código personalizado para manter.
## Implementar a ausência de estado em funções
Para funções do Lambda padrão, é preciso presumir que o ambiente exista somente para uma única invocação. A função deve inicializar qualquer estado necessário ao ser iniciada pela primeira vez. Por exemplo, sua função pode exigir buscas de dados de uma tabela do DynamoDB. Ele deve confirmar todas as alterações permanentes de dados em um armazenamento durável, como Amazon S3, DynamoDB ou Amazon SQS, antes de sair. Ele não deve depender de nenhuma estrutura de dados ou arquivo temporário existente, nem de qualquer estado interno que seja gerenciado por várias invocações.
Ao usar as funções duráveis, o estado é preservado automaticamente entre as invocações, eliminando a necessidade de manter manualmente o estado no armazenamento externo. No entanto, você ainda deverá seguir os princípios sem estado para quaisquer dados não gerenciados explicitamente por meio do DurableContext.
Para inicializar conexões e bibliotecas de banco de dados, ou para carregar o estado, você pode tirar proveito da [inicialização estática](lambda-runtime-environment.md#static-initialization). Como os ambientes de execução são reutilizados sempre que possível para melhorar a performance, você pode amortizar o tempo necessário para inicializar esses recursos em várias invocações. No entanto, você não deve armazenar nenhuma variável nem dados usados na função dentro desse escopo global.
## Minimizar o acoplamento
A maioria das arquiteturas deve preferir muitas funções mais curtas, em vez de menos funções maiores. O objetivo de cada função deve ser lidar com o evento passado para a função, sem conhecimento ou expectativas do fluxo de trabalho geral ou do volume de transações. Isso torna a função independente da origem do evento com acoplamento mínimo a outros serviços.
Quaisquer constantes de escopo global que mudam com pouca frequência devem ser implementadas como variáveis de ambiente para permitir atualizações sem implantações. Todos os segredos ou informações confidenciais devem ser armazenados no [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) ou no [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) e carregados pela função. Como esses recursos são específicos da conta, você pode criar pipelines de compilação entre várias contas. Os pipelines carregam os segredos apropriados por ambiente, sem expô-los aos desenvolvedores nem exigir alterações no código.
## Criar para dados sob demanda em vez de lotes
Muitos sistemas tradicionais são projetados para serem executados periodicamente e processarem lotes de transações que se acumularam ao longo do tempo. Por exemplo, uma aplicação bancária pode ser executada a cada hora para processar transações de caixas eletrônicos em livros-razão centrais. Em aplicações baseadas no Lambda, o processamento personalizado deve ser acionado por cada evento, permitindo ao serviço aumentar a escala da simultaneidade conforme necessário, para fornecer processamento quase em tempo real das transações.
Embora as funções padrão do Lambda sejam limitadas a 15 minutos de tempo de execução, as funções duráveis podem ser executadas por até um ano, tornando-as adequadas às necessidades de processamento de longa duração. No entanto, o processamento orientado por eventos ainda deve ser preferido em relação ao processamento em lote, quando possível.
Embora você possa executar tarefas [cron](https://en.wikipedia.org/wiki/Cron) em aplicações com tecnologia sem servidor [usando expressões programadas](https://docs.aws.amazon.com/eventbridge/latest/userguide/scheduled-events.html) para regras no Amazon EventBridge, elas devem ser usadas com moderação ou como último recurso. Em qualquer tarefa programada que processa um lote, existe a possibilidade de o volume de transações crescer além do que pode ser processado dentro do limite de duração de 15 minutos do Lambda. Se as limitações dos sistemas externos forçarem você a usar um programador, geralmente será necessário programar para o menor período recorrente razoável.
Por exemplo, não é uma prática recomendada usar um processo em lote que aciona uma função do Lambda para buscar uma lista de novos objetos do Amazon S3. Isso ocorre porque o serviço pode receber mais objetos novos entre os lotes do que é possível processar em uma função do Lambda de 15 minutos.
![\[arquiteturas orientadas por eventos figura 10\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/event-driven-architectures-figure-10.png)
Em vez disso, o Amazon S3 deve invocar a função do Lambda sempre que um novo objeto é colocado no bucket. Essa abordagem é significativamente mais dimensionável e funciona quase em tempo real.
![\[arquiteturas orientadas por eventos figura 11\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/event-driven-architectures-figure-11.png)
## Escolha uma opção de orquestração para fluxos de trabalho complexos
Fluxos de trabalho que envolvem lógica de ramificação, diferentes tipos de modelos de falha e lógica de novas tentativas normalmente usam um orquestrador para acompanhar o estado da execução geral. Não crie orquestração ad-hoc em funções padrão do Lambda. Isso resulta em acoplamento forte, código de roteamento complexo e nenhuma recuperação automática de estado.
Em vez disso, use uma dessas opções de orquestração específicas:
+ **[Funções duráveis do Lambda](durable-functions.md):** orquestração centrada em aplicações usando linguagens de programação padrão com ponto de verificação automático, repetição integrada e recuperação de execução. Ideal para desenvolvedores que preferem manter a lógica do fluxo de trabalho em código junto com a lógica de negócios no Lambda.
+ **[AWS Step Functions](with-step-functions.md):** orquestração visual do fluxo de trabalho com integrações nativas a mais de 220 serviços da AWS. Ideal para coordenação de vários serviços, infraestrutura sem manutenção e design visual de fluxo de trabalho.
Para obter orientação na escolha entre essas opções, consulte [Funções duráveis ou Step Functions](durable-step-functions.md).
Com o [Step Functions](https://aws.amazon.com/step-functions/), você usa máquinas de estado para gerenciar a orquestração. Isso extrai a lógica de tratamento de erros, roteamento e ramificação do seu código, substituindo-a por máquinas de estado declaradas usando JSON. Além de tornar os fluxos de trabalho mais consistentes e observáveis, é possível também adicionar versionamento aos fluxos de trabalho e tornar a máquina de estado um recurso codificado que pode ser adicionado a um repositório de códigos.
É comum que fluxos de trabalho mais simples em funções do Lambda se tornem mais complexos com o tempo. Ao operar uma aplicação de produção com tecnologia sem servidor, é importante identificar quando isso está acontecendo, para que você possa migrar essa lógica para uma máquina de estado ou função durável.
## Implementar a idempotência
Os serviços da AWS com tecnologia sem servidor, incluindo o Lambda, são tolerantes a falhas e projetados para lidar com erros. Por exemplo, se um serviço invoca uma função do Lambda e há uma interrupção do serviço, o Lambda invoca sua função em uma zona de disponibilidade diferente. Se a função lançar um erro, o Lambda tentará executar a invocação mais uma vez.
Como o mesmo evento pode ser recebido mais de uma vez, as funções devem ser projetadas para terem [idempotência](https://en.wikipedia.org/wiki/Idempotence). Isso significa que receber o mesmo evento várias vezes não altera o resultado além da primeira vez em que o evento foi recebido.
É possível implementar a idempotência em funções do Lambda, usando uma tabela do DynamoDB para rastrear identificadores processados recentemente a fim de determinar se a transação já foi tratada anteriormente. A tabela do DynamoDB geralmente implementa um valor de [tempo de vida (TTL)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html) para expirar itens a fim de limitar o espaço de armazenamento usado.
## Usar várias contas da AWS para gerenciar cotas
Muitas [cotas de serviço](gettingstarted-limits.md) no AWS são definidas em nível de conta. Isso significa que, à medida que você adiciona mais workloads, pode esgotar seus limites rapidamente.
Uma maneira eficiente de resolver esse problema é usar várias contas da AWS, dedicando cada workload à sua própria conta. Isso evita que as cotas sejam compartilhadas com outras workloads ou recursos que não sejam de produção.
Além disso, usando o [AWS Organizations](https://aws.amazon.com/organizations/), você pode gerenciar centralmente o faturamento, a conformidade e a segurança dessas contas. É possível anexar políticas a grupos de contas para evitar scripts personalizados e processos manuais.
Uma abordagem comum é fornecer uma conta da AWS a cada desenvolvedor e, em seguida, usar contas separadas para uma fase de implantação beta e produção:
![\[design de aplicações figura 3\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/application-design-figure-3.png)
Nesse modelo, cada desenvolvedor tem seu próprio conjunto de limites para a conta. Portanto, seu uso não afeta o ambiente de produção. Essa abordagem também permite que os desenvolvedores testem as funções do Lambda localmente nas máquinas de desenvolvimento em relação aos recursos ativos da nuvem em suas contas individuais.