# Aprimoramento da performance de inicialização com o Lambda SnapStart 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. O SnapStart facilita a criação de aplicações altamente responsivas e escaláveis sem o provisionamento de recursos nem a implementação de otimizações complexas de performance. O maior contribuinte para a latência de inicialização (geralmente chamado de tempo de inicialização a frio) é o tempo que o Lambda demora para inicializar a função, que inclui carregar o código da função, iniciar o runtime e inicializar o código da função. Com o SnapStart, o Lambda inicializará a função quando você publicar uma versão da função. O Lambda usa um snapshot [microVM do Firecracker](https://aws.amazon.com/blogs/opensource/firecracker-open-source-secure-fast-microvm-serverless/) do estado da memória e do disco do [ambiente de execução](lambda-runtime-environment.md) inicializado, criptografa o snapshot e o armazena em cache de forma inteligente para otimizar a latência de recuperação. Para garantir a resiliência, o Lambda mantém várias cópias de cada snapshot. O Lambda atualiza automaticamente os snapshots e as cópias deles com os patches de segurança e runtime mais recentes. Quando você invoca a versão da função pela primeira vez e à medida que aumenta a escala verticalmente das invocações, o Lambda retoma novos ambientes de execução do snapshot armazenado em cache, em vez de realizar a inicialização do zero, melhorando a latência de inicialização. **Importante** Se suas aplicações dependerem da exclusividade de estado, você deverá avaliar o código da função e verificar se ele é resiliente às operações de snapshots. Para obter mais informações, consulte [Tratamento da exclusividade com o Lambda SnapStart](snapstart-uniqueness.md). **Topics** + [ ## Quando usar o SnapStart ](#snapstart-use-cases) + [ ## Recursos compatíveis e limitações ](#snapstart-runtimes) + [ ## Regiões com suporte ](#snapstart-supported-regions) + [ ## Considerações sobre compatibilidade ](#snapstart-compatibility) + [ ## Preços do SnapStart ](#snapstart-pricing) + [ # Ativação e gerenciamento do Lambda SnapStart ](snapstart-activate.md) + [ # Tratamento da exclusividade com o Lambda SnapStart ](snapstart-uniqueness.md) + [ # Implementar código antes ou depois dos snapshots da função do Lambda ](snapstart-runtime-hooks.md) + [ # Monitoramento para o Lambda SnapStart ](snapstart-monitoring.md) + [ # Modelo de segurança para o Lambda SnapStart ](snapstart-security.md) + [ # Maximizar a performance do SnapStart do Lambda ](snapstart-best-practices.md) + [ # Solução de problemas de erros do SnapStart para funções do Lambda ](snapstart-troubleshooting.md) ## Quando usar o SnapStart O Lambda SnapStart foi projetado para lidar com a variabilidade de latência introduzida pelo código de inicialização único, como carregar dependências ou estruturas de módulos. Às vezes, essas operações podem levar vários segundos para serem concluídas durante a invocação inicial. Use o SnapStart para reduzir essa latência de vários segundos para menos de um segundo, em cenários ideais. O SnapStart funciona melhor quando usado com invocações de funções em escala. As funções que são invocadas com pouca frequência podem não ter as mesmas melhorias de performance. O SnapStart é particularmente vantajoso para dois tipos principais de aplicações: + **APIs e fluxos de usuário sensíveis à latência:** funções que fazem parte de endpoints essenciais de API ou fluxos voltados para usuários podem se beneficiar com a latência reduzida e os melhores tempos de resposta do SnapStart. + **Fluxos de trabalho de processamento de dados sensíveis à latência:** fluxos de trabalho de processamento de dados com limite de tempo que usam funções do Lambda podem obter um throughput melhor ao reduzir a latência de inicialização de funções discrepantes. A [simultaneidade provisionada](provisioned-concurrency.md) mantém as funções inicializadas e prontas para responder em milissegundos de dois dígitos. Use a simultaneidade provisionada se sua aplicação tiver requisitos rigorosos de latência de inicialização a frio que não podem ser tratados adequadamente pelo SnapStart. ## Recursos compatíveis e limitações O SnapStart está disponível para os seguintes [runtimes gerenciados pelo Lambda](lambda-runtimes.md): + Java 11 e versões posteriores + Python 3.12 e posterior + .NET 8 e versões posteriores. Se você estiver usando a [estrutura Lambda Annotations para .NET](csharp-handler.md#csharp-handler-annotations), atualize para [Amazon.Lambda.Annotations](https://www.nuget.org/packages/Amazon.Lambda.Annotations) versão 1.6.0 ou posterior para garantir a compatibilidade com o SnapStart. Outros runtimes gerenciados (como `nodejs24.x` e `ruby3.4`), [Runtimes somente para sistema operacional](runtimes-provided.md) e [imagens de contêiner](images-create.md) não são compatíveis. O SnapStart não é compatível com [simultaneidade provisionada](provisioned-concurrency.md), com o [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/accessing-fs.html) nem com um armazenamento temporário com mais de 512 MB. **nota** É possível usar o SnapStart somente em [versões de funções publicadas](configuration-versions.md#configuration-versions-config) e [aliases](configuration-aliases.md) que direcionam para versões. Não é possível usar o SnapStart em uma versão não publicada de uma função (\$1LATEST). ## Regiões com suporte O Lambda SnapStart está disponível em [todas as regiões comerciais](https://docs.aws.amazon.com/general/latest/gr/glos-chap.html#region), exceto Ásia-Pacífico (Nova Zelândia) e Ásia-Pacífico (Taipei). ## Considerações sobre compatibilidade Com o SnapStart, o Lambda usa um único snapshot como estado inicial para diversos ambientes de execução. Se sua função usar qualquer um dos itens a seguir durante a [fase de inicialização](lambda-runtime-environment.md#runtimes-lifecycle-ib), talvez seja necessário realizar algumas alterações antes de usar o SnapStart: **Exclusividade** Se o código de inicialização gerar conteúdo exclusivo que é incluído no snapshot, o conteúdo poderá não ser exclusivo quando for reutilizado em ambientes de execução. Para manter a exclusividade ao usar o SnapStart, você deve gerar conteúdo exclusivo após a inicialização. Isso inclui IDs exclusivos, segredos exclusivos e entropia que são usados para gerar a pseudoaleatoriedade. Para saber como restaurar a exclusividade, consulte [Tratamento da exclusividade com o Lambda SnapStart](snapstart-uniqueness.md). **Conexões de rede** O estado das conexões que a função estabelece durante a fase de inicialização não é garantido quando o Lambda retoma a função de um snapshot. Valide o estado das conexões de rede e restabeleça-as conforme necessário. Na maioria dos casos, as conexões de rede que um SDK da AWS estabelece são retomadas automaticamente. Para outras conexões, analise as [práticas recomendadas](snapstart-best-practices.md). **Dados temporários** Algumas funções realizam o download ou inicializam dados efêmeros, como credenciais temporárias ou carimbos de data e hora em cache, durante a fase de inicialização. Atualize os dados efêmeros no manipulador de função antes de usá-los, mesmo quando não estiver usando o SnapStart. ## Preços do SnapStart **nota** Para runtimes gerenciados em Java, não há custos adicionais para o SnapStart. Você será cobrado com base no número de solicitações para as funções, no tempo que o código demora para ser executado e na memória configurada para a função. O custo pelo uso do SnapStart inclui o seguinte: + **Armazenamento em cache:** para cada versão de função publicada com o SnapStart habilitado, você pagará pelo custo do armazenamento em cache e da manutenção do snapshot. O preço depende da quantidade de [memória](configuration-memory.md) que você aloca para sua função. A cobrança é feita por um mínimo de 3 horas. Você continuará recebendo cobranças enquanto sua função permanecer [ativa](snapstart-activate.md#snapstart-active). Use a ação da API [ListVersionsByFunction](https://docs.aws.amazon.com/lambda/latest/api/API_ListVersionsByFunction.html) para identificar as versões da função e, em seguida, use [DeleteFunction](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html) para excluir as versões não utilizadas. Para excluir automaticamente versões de funções não utilizadas, consulte o padrão [Lambda Version Cleanup](https://serverlessland.com/workflows/step-functions-lambda-version-cleanup) em Serverless Land. + **Restauração:** sempre que uma instância de função for restaurada de um snapshot, você pagará uma taxa de restauração. O preço depende da quantidade de memória que você aloca para sua função. Como acontece com todas as funções do Lambda, as taxas de duração se aplicam ao código executado no manipulador da função. Para funções do SnapStart, as cobranças por duração também se aplicam ao código de inicialização declarado fora do manipulador, ao tempo que demora para o runtime carregar e aos códigos executados em um [hook de runtime](snapstart-runtime-hooks.md). A duração é calculada a partir do momento em que o código começa a ser executado até que ele retorne ou seja encerrado, com arredondamento para o 1 ms mais próximo. O Lambda mantém cópias em cache do seu snapshot para maior resiliência e aplica automaticamente atualizações de software, como atualizações de runtime e patches de segurança. As cobranças são aplicadas sempre que o Lambda executa novamente o código de inicialização para aplicar atualizações de software. Para obter mais informações sobre o custo de uso do SnapStart, consulte [Preços do AWS Lambda](https://aws.amazon.com/lambda/pricing/#SnapStart_Pricing). # Ativação e gerenciamento do Lambda SnapStart Para usar o SnapStart, ative o SnapStart em uma função do Lambda nova ou existente. Em seguida, publique e invoque uma versão da função. **Topics** + [ ## Ativação do SnapStart (console) ](#snapshot-console) + [ ## Ativação do SnapStart (AWS CLI) ](#snapshot-cli) + [ ## Ativação do SnapStart (API) ](#snapshot-api) + [ ## Lambda SnapStart e estados de função ](#snapstart-function-states) + [ ## Atualização de um snapshot ](#update-snapshot) + [ ## Uso do SnapStart com AWS SDKs ](#snapstart-credentials) + [ ## Uso do SnapStart com o CloudFormation, o AWS SAM e o AWS CDK ](#snapstart-cfn-sam) + [ ## Exclusão de snapshots ](#snapshot-delete) ## Ativação do SnapStart (console) **Para ativar o SnapStart para uma função** 1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda. 1. Escolha o nome de uma função. 1. Escolha **Configuration** (Configuração) e, em seguida, selecione **General configuration** (Configuração geral). 1. No painel **General configuration** (Configuração geral), escolha **Edit** (Editar). 1. Na página **Edit basic settings** (Editar configurações básicas), para **SnapStart**, escolha **Published versions** (Versões publicadas). 1. Escolha **Salvar**. 1. [Publique uma versão da função](configuration-versions.md#configuration-versions-config). O Lambda inicializa o código, cria um snapshot do ambiente de execução inicializado e, em seguida, armazena em cache o snapshot para acesso de baixa latência. 1. [Invoque a versão da função](configuration-versions.md#versioning-versions-using). ## Ativação do SnapStart (AWS CLI) **Para ativar o SnapStart para uma função existente** 1. Atualize a configuração da função executando o comando [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html) com a opção **--snap-start**. ``` aws lambda update-function-configuration \ --function-name my-function \ --snap-start ApplyOn=PublishedVersions ``` 1. Publique uma versão de função com o comando [publish-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-version.html). ``` aws lambda publish-version \ --function-name my-function ``` 1. Confirme se o SnapStart está ativado para a versão da função ao executar o comando [get-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/get-function-configuration.html) e especificar o número da versão. O exemplo a seguir especifica a versão 1. ``` aws lambda get-function-configuration \ --function-name my-function:1 ``` Se a resposta mostrar que [OptimizationStatus](https://docs.aws.amazon.com/lambda/latest/api/API_SnapStartResponse.html) é `On` e [State](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html#lambda-GetFunctionConfiguration-response-State) é `Active`, o SnapStart será ativado e um snapshot estará disponível para a versão da função especificada. ``` "SnapStart": { "ApplyOn": "PublishedVersions", "OptimizationStatus": "On" }, "State": "Active", ``` 1. Invoque a versão da função ao executar o comando [invoke](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/invoke.html) e especificar a versão. O exemplo a seguir invoca a versão 1. ``` aws lambda invoke \ --cli-binary-format raw-in-base64-out \ --function-name my-function:1 \ --payload '{ "name": "Bob" }' \ response.json ``` A opção **cli-binary-format** será necessária se você estiver usando a AWS CLI versão 2. Para que essa seja a configuração padrão, execute `aws configure set cli-binary-format raw-in-base64-out`. Para obter mais informações, consulte [A AWS CLI comporta opções de linha de comando globais](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) no *Guia do usuário da AWS Command Line Interface versão 2*. **Para ativar o SnapStart ao criar uma nova função** 1. Crie uma função ao executar o comando [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html) com a opção **--snap-start**. Para **--role**, especifique o nome do recurso da Amazon (ARN) do [perfil de execução](lambda-intro-execution-role.md). ``` aws lambda create-function \ --function-name my-function \ --runtime "java25" \ --zip-file fileb://my-function.zip \ --handler my-function.handler \ --role arn:aws:iam::111122223333:role/lambda-ex \ --snap-start ApplyOn=PublishedVersions ``` 1. Crie uma versão com o comando [publish-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-version.html). ``` aws lambda publish-version \ --function-name my-function ``` 1. Confirme se o SnapStart está ativado para a versão da função ao executar o comando [get-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/get-function-configuration.html) e especificar o número da versão. O exemplo a seguir especifica a versão 1. ``` aws lambda get-function-configuration \ --function-name my-function:1 ``` Se a resposta mostrar que [OptimizationStatus](https://docs.aws.amazon.com/lambda/latest/api/API_SnapStartResponse.html) é `On` e [State](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html#lambda-GetFunctionConfiguration-response-State) é `Active`, o SnapStart será ativado e um snapshot estará disponível para a versão da função especificada. ``` "SnapStart": { "ApplyOn": "PublishedVersions", "OptimizationStatus": "On" }, "State": "Active", ``` 1. Invoque a versão da função ao executar o comando [invoke](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/invoke.html) e especificar a versão. O exemplo a seguir invoca a versão 1. ``` aws lambda invoke \ --cli-binary-format raw-in-base64-out \ --function-name my-function:1 \ --payload '{ "name": "Bob" }' \ response.json ``` A opção **cli-binary-format** será necessária se você estiver usando a AWS CLI versão 2. Para que essa seja a configuração padrão, execute `aws configure set cli-binary-format raw-in-base64-out`. Para obter mais informações, consulte [A AWS CLI comporta opções de linha de comando globais](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) no *Guia do usuário da AWS Command Line Interface versão 2*. ## Ativação do SnapStart (API) **Para ativar o SnapStart** 1. Execute um destes procedimentos: + Crie uma nova função com o SnapStart ativado ao usar a ação de API [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html) com o parâmetro [SnapStart](https://docs.aws.amazon.com/lambda/latest/api/API_SnapStart.html). + Ative o SnapStart para uma função existente ao usar a ação [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) com o parâmetro [SnapStart](https://docs.aws.amazon.com/lambda/latest/api/API_SnapStart.html). 1. Publique uma versão de função com a ação [PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html). O Lambda inicializa o código, cria um snapshot do ambiente de execução inicializado e, em seguida, armazena em cache o snapshot para acesso de baixa latência. 1. Confirme se o SnapStart está ativado para a versão da função ao usar a ação [GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html). Especifique um número de versão para confirmar que o SnapStart está ativado para essa versão. Se a resposta mostrar que [OptimizationStatus](https://docs.aws.amazon.com/lambda/latest/api/API_SnapStartResponse.html) é `On` e [State](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html#lambda-GetFunctionConfiguration-response-State) é `Active`, o SnapStart será ativado e um snapshot estará disponível para a versão da função especificada. ``` "SnapStart": { "ApplyOn": "PublishedVersions", "OptimizationStatus": "On" }, "State": "Active", ``` 1. Invoque a versão de função com a ação [Invoke](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html). ## Lambda SnapStart e estados de função Os estados de função a seguir podem ocorrer quando você usa o SnapStart. **Pendente** O Lambda está inicializando o código e obtendo um snapshot do ambiente de execução inicializado. Quaisquer invocações ou outras ações de API que operam na versão de função falharão. **Ativo** A criação do snapshot está concluída e é possível invocar a função. Para usar o SnapStart, é necessário invocar a versão de função publicada, não a versão não publicada (\$1LATEST). **Inactive** O estado `Inactive` pode ocorrer quando o Lambda regenera periodicamente os snapshots da função para aplicar atualizações de software. Nessa instância, se sua função não for inicializada, ela poderá entrar em um estado `Inactive`. Para funções que usam um runtime Java, o Lambda exclui snapshots após 14 dias sem uma invocação. Se você invocar a versão de função após 14 dias, o Lambda retornará uma resposta `SnapStartNotReadyException` e começará a inicializar um novo snapshot. Aguarde até que a versão de função atinja o estado `Active` e, em seguida, invoque-a novamente. **Falha** O Lambda encontrou um erro ao executar o código de inicialização ou ao criar o snapshot. ## Atualização de um snapshot O Lambda cria um snapshot para cada versão de função publicada. Para atualizar um snapshot, publique uma nova versão da função. ## Uso do SnapStart com AWS SDKs Para fazer chamadas para o SDK da AWS usando sua função, o Lambda gera um conjunto efêmero de credenciais ao assumir o perfil de execução da função. Essas credenciais estão disponíveis como variáveis ​​de ambiente durante a invocação da sua função. Não é necessário fornecer credenciais para o SDK diretamente no código. Por padrão, a cadeia de provedores de credenciais verifica sequencialmente cada local em que você pode definir credenciais e escolhe o primeiro disponível, que geralmente corresponde às variáveis de ambiente (`AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` e `AWS_SESSION_TOKEN`). **nota** Quando o SnapStart é ativado, o runtime do Lambda usa automaticamente as credenciais do contêiner (`AWS_CONTAINER_CREDENTIALS_FULL_URI` e `AWS_CONTAINER_AUTHORIZATION_TOKEN`), em vez das variáveis de ambiente de chave de acesso. Isso evita que as credenciais expirem antes que a função seja restaurada. ## Uso do SnapStart com o CloudFormation, o AWS SAM e o AWS CDK + **AWS CloudFormation:** declare a entidade [SnapStart](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-lambda-function-snapstart.html) em seu modelo. + **AWS Serverless Application Model (AWS SAM):** declare a propriedade do [SnapStart](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html#sam-function-snapstart) em seu modelo. + **AWS Cloud Development Kit (AWS CDK):** use o tipo [SnapStartProperty](https://docs.aws.amazon.com/cdk/api/v2/java/software/amazon/awscdk/services/lambda/CfnFunction.SnapStartProperty.html). ## Exclusão de snapshots O Lambda exclui snapshots quando: + Você exclui a função ou a versão de função. + **Somente runtimes Java**: você não invoca a versão de função por 14 dias. Após 14 dias sem uma invocação, a versão de função transita para o estado [Inactive](#snapstart-function-states) (Inativo). Se você invocar a versão de função após 14 dias, o Lambda retornará uma resposta `SnapStartNotReadyException` e começará a inicializar um novo snapshot. Aguarde até que a versão de função atinja o estado [Active](#snapstart-function-states) (Ativo) e, em seguida, invoque-a novamente. O Lambda remove todos os recursos associados aos snapshots excluídos em conformidade com o Regulamento Geral sobre a Proteção de Dados (GDPR). # Tratamento da exclusividade com o Lambda SnapStart Quando as invocações aumentam a escala verticalmente em uma função do SnapStart, o Lambda usa um único snapshot inicializado para retomar diversos ambientes de execução. Se o código de inicialização gerar conteúdo exclusivo que é incluído no snapshot, o conteúdo poderá não ser exclusivo quando for reutilizado em ambientes de execução. Para manter a exclusividade ao usar o SnapStart, você deve gerar conteúdo exclusivo após a inicialização. Isso inclui IDs exclusivos, segredos exclusivos e entropia que são usados para gerar a pseudoaleatoriedade. Recomendamos as práticas recomendadas a seguir para ajudar você a manter a exclusividade em seu código. Para funções do Java, o Lambda também fornece uma [ferramenta de verificação do SnapStart](#snapstart-scanning) de código aberto para ajudar a verificar o código que assume exclusividade. Se você gerar dados exclusivos durante a fase de inicialização, poderá usar um [hook de runtime](snapstart-runtime-hooks.md) para restaurar a exclusividade. Com ganchos de runtime, é possível executar um código específico imediatamente antes que o Lambda obtenha um snapshot ou imediatamente após o Lambda retornar uma função de um snapshot. ## Evite salvar um estado que depende da exclusividade durante a inicialização Durante a [fase de inicialização](lambda-runtime-environment.md#runtimes-lifecycle-ib) da função, evite armazenar em cache dados que devem ser exclusivos, como a geração de um ID exclusivo para registro em log ou a aplicação de sementes para funções aleatórias. Em vez disso, recomendamos gerar dados exclusivos ou definir sementes para funções aleatórias dentro do manipulador da função ou usar um [hook de runtime](snapstart-runtime-hooks.md). Os exemplos a seguir demonstram como gerar um UUID no manipulador de função. ------ #### [ Java ] **Example : geração de um ID exclusivo no manipulador de função** ``` import java.util.UUID; public class Handler implements RequestHandler { private static UUID uniqueSandboxId = null; @Override public String handleRequest(String event, Context context) { if (uniqueSandboxId == null) uniqueSandboxId = UUID.randomUUID(); System.out.println("Unique Sandbox Id: " + uniqueSandboxId); return "Hello, World!"; } } ``` ------ #### [ Python ] **Example : geração de um ID exclusivo no manipulador de função** ``` import json import random import time unique_number = None def lambda_handler(event, context): seed = int(time.time() * 1000) random.seed(seed) global unique_number if not unique_number: unique_number = random.randint(1, 10000) print("Unique number: ", unique_number) return "Hello, World!" ``` ------ #### [ .NET ] **Example : geração de um ID exclusivo no manipulador de função** ``` namespace Example; public class SnapstartExample { private Guid _myExecutionEnvironmentGuid; public SnapstartExample() { // This GUID is set for non-restore use cases, such as testing or if SnapStart is turned off _myExecutionEnvironmentGuid = new Guid(); // Register the method which will run after each restore. You may need to update Amazon.Lambda.Core to see this Amazon.Lambda.Core.SnapshotRestore.RegisterAfterRestore(MyAfterRestore); } private ValueTask MyAfterRestore() { // After restoring this snapshot to a new execution environment, update the GUID _myExecutionEnvironmentGuid = new Guid(); return ValueTask.CompletedTask; } public string Handler() { return $"Hello World! My Execution Environment GUID is {_myExecutionEnvironmentGuid}"; } } ``` ------ ## Use geradores de números pseudoaleatórios criptograficamente seguros (CSPRNGs) Se a aplicação depender da aleatoriedade, recomendamos usar geradores de números pseudoaleatórios criptograficamente seguros (CSPRNGs). Além do OpenSSL 1.0.2, os runtimes gerenciados do Lambda também incluem os seguintes CSPRNGs integrados: + **Java:** `java.security.SecureRandom` + **Python:** `random.SystemRandom` + **.NET:** `System.Security.Cryptography.RandomNumberGenerator` O software que sempre obtém números aleatórios `/dev/random` ou `/dev/urandom` também mantém a aleatoriedade com o SnapStart. As bibliotecas de criptografia da AWS mantêm a aleatoriedade automaticamente com o SnapStart, a partir das versões mínimas especificadas na tabela a seguir. Se você usar essas bibliotecas com as funções do Lambda, certifique-se de usar as seguintes versões mínimas ou versões posteriores: **** | Biblioteca | Versão mínima compatível (x86) | Versão mínima compatível (ARM) | | --- | --- | --- | | AWS libcrypto (AWS-LC) | 1.16.0 | 1.30.0 | | AWS libcrypto FIPS | 2.0.13 | 2.0.13 | Se você empacotar as bibliotecas criptográficas anteriores com suas funções Lambda como dependências transitivas usando as bibliotecas a seguir, certifique-se de usar as seguintes versões mínimas ou versões posteriores: **** | Biblioteca | Versão mínima compatível (x86) | Versão mínima compatível (ARM) | | --- | --- | --- | | AWS SDK for Java 2.x | 2.23.20 | 2.26.12 | | Runtime comum da AWS para Java | 0.29.8 | 0.29.25 | | Fornecedor de criptografia do Amazon Corretto | 2.4.1 | 2.4.1 | | Fornecedor de criptografia FIPS do Amazon Corretto | 2.4.1 | 2.4.1 | Os exemplos a seguir demonstram como usar CSPRNGs para garantir sequências numéricas exclusivas mesmo quando a função é restaurada de um snapshot. ------ #### [ Java ] **Example : java.security.SecureRandom** ``` import java.security.SecureRandom; public class Handler implements RequestHandler { private static SecureRandom rng = new SecureRandom(); @Override public String handleRequest(String event, Context context) { for (int i = 0; i < 10; i++) { System.out.println(rng.next()); } return "Hello, World!"; } } ``` ------ #### [ Python ] **Example : random.SystemRandom** ``` import json import random secure_rng = random.SystemRandom() def lambda_handler(event, context): random_numbers = [secure_rng.random() for _ in range(10)] for number in random_numbers: print(number) return "Hello, World!" ``` ------ #### [ .NET ] **Example : RandomNumberGenerator** ``` using Amazon.Lambda.Core; using System.Security.Cryptography; [assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))] namespace DotnetSecureRandom; public class Function { public string FunctionHandler() { using (RandomNumberGenerator rng = RandomNumberGenerator.Create()) { byte[] randomUnsignedInteger32Bytes = new byte[4]; for (int i = 0; i < 10; i++) { rng.GetBytes(randomUnsignedInteger32Bytes); int randomInt32 = BitConverter.ToInt32(randomUnsignedInteger32Bytes, 0); Console.WriteLine("{0:G}", randomInt32); } } return "Hello World!"; } } ``` ------ ## Ferramenta de verificação do SnapStart (somente para Java) O Lambda fornece uma ferramenta de verificação para Jada a fim de ajudar você a verificar o código que assume exclusividade. A ferramenta de verificação do SnapStart corresponde a um plug-in [SpotBugs](https://spotbugs.github.io/) de código aberto que executa uma análise estática de acordo com um conjunto de regras. A ferramenta de verificação ajuda a identificar possíveis implementações de código que podem quebrar suposições em relação à exclusividade. Para obter instruções de instalação e uma lista de verificações que a ferramenta de verificação executa, consulte o repositório [aws-lambda-snapstart-java-rules](https://github.com/aws/aws-lambda-snapstart-java-rules) no GitHub. Para saber mais sobre como lidar com a exclusividade com o SnapStart, consulte [Início mais rápido com o AWS Lambda SnapStart](https://aws.amazon.com/blogs/compute/starting-up-faster-with-aws-lambda-snapstart/) no AWS Compute Blog. # Implementar código antes ou depois dos snapshots da função do Lambda É possível usar hooks de runtime para implementar o código antes que o Lambda crie um snapshot ou depois que o Lambda retorna uma função de um snapshot. Os hooks de runtime são úteis para diversas finalidades, como: + **Limpeza e inicialização:** antes de criar um snapshot, você pode usar um hook de runtime para realizar operações de limpeza ou liberação de recursos. Depois que um snapshot é restaurado, você pode usar um hook de runtime para reinicializar quaisquer recursos ou estados que não foram capturados no snapshot. + **Configuração dinâmica:** você pode usar hooks de runtime para atualizar dinamicamente a configuração ou outros metadados antes que um snapshot seja criado ou depois de restaurado. Isso pode ser útil se sua função precisar se adaptar a mudanças no ambiente de runtime. + **Integrações externas:** você pode usar hooks de runtime para integrar-se a serviços ou sistemas externos, como enviar notificações ou atualizar estados externos, como parte do processo de verificação e restauração. + **Ajuste de performance:** você pode usar hooks de runtime para ajustar a sequência de startup da função, por exemplo, fazendo o carregamento de dependências previamente. Para ter mais informações, consulte [Ajuste de performance](snapstart-best-practices.md#snapstart-tuning). As páginas a seguir explicam como implementar hooks de runtime para seu runtime preferido. **Topics** + [Java](snapstart-runtime-hooks-java.md) + [Python](snapstart-runtime-hooks-python.md) + [.NET](snapstart-runtime-hooks-dotnet.md) # Hooks de runtime do Lambda SnapStart para Java É possível usar hooks de runtime para implementar o código antes que o Lambda crie um snapshot ou depois que o Lambda retorna uma função de um snapshot. Os hooks de runtime estão disponíveis como parte do projeto de código aberto Coordinated Restore at Checkpoint (CRaC). O CRaC está em desenvolvimento para o [Open Java Development Kit (OpenJDK)](https://wiki.openjdk.org/display/crac). Para obter um exemplo de como usar o CRaC com uma aplicação de referência, consulte o repositório [CRaC](https://github.com/CRaC/docs/blob/master/STEP-BY-STEP.md) no GitHub. O CRaC usa três elementos principais: + `Resource`: uma interface com dois métodos, `beforeCheckpoint()` e `afterRestore()`. Use esses métodos para implementar o código deseja executar antes de um snapshot e depois de uma restauração. + `Context `: para receber notificações de pontos de verificação e restaurações, `Resource` deve estar registrado em um `Context`. + `Core`: o serviço de coordenação, que fornece o padrão global `Context` por meio do método estático `Core.getGlobalContext()`. Para obter mais informações sobre `Context` e `Resource`, consulte [Package org.crac](https://javadoc.io/doc/io.github.crac/org-crac/latest/index.html) (Pacote org.crac) na documentação do CRaC. Use as etapas a seguir para implementar os hooks de runtime com o [pacote org.crac](https://github.com/CRaC/org.crac). O runtime do Lambda contém uma implementação de contexto CRaC personalizada que chama os hooks de runtime antes do ponto de verificação e depois da restauração. ## Registro e execução do hook de runtime A ordem em que o Lambda executa seus hooks de runtime é determinada pela ordem de registro. A ordem de registro segue a ordem de importação, definição ou execução em seu código. + `beforeCheckpoint()`: executado na ordem inversa do registro + `afterRestore()`: executado na ordem de registro Certifique-se de que todos os hooks registrados sejam importados e incluídos corretamente no código da sua função. Se você registrar hooks de runtime em um arquivo ou módulo separado, o módulo deverá ser importado, seja diretamente ou como parte de um pacote maior, no arquivo do manipulador da sua função. Se o arquivo ou módulo não for importado no manipulador da função, o Lambda vai ignorar os hooks de runtime. **nota** Quando o Lambda cria um snapshot, o 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](configuration-timeout.md) (máximo de 900 segundos), o que for maior. Seus hooks de runtime de `beforeCheckpoint()` contam até o limite de tempo do código de inicialização. Quando o Lambda restaura um snapshot, o runtime deve ser carregado e os hooks de runtime `afterRestore()` devem ser concluídos dentro do limite de tempo limite (dez segundos). Caso contrário, você obterá uma SnapStartTimeoutException. ## Etapa 1: atualizar a configuração de compilação Adicione a dependência `org.crac` à configuração de compilação. O exemplo a seguir usa o Gradle. Para obter exemplos de outros sistemas de compilação, consulte a [documentação do Apache Maven](https://search.maven.org/artifact/io.github.crac/org-crac/0.1.3/jar). ``` dependencies { compile group: 'com.amazonaws', name: 'aws-lambda-java-core', version: '1.2.1' # All other project dependecies go here: # ... # Then, add the org.crac dependency: implementation group: 'org.crac', name: 'crac', version: '1.4.0' } ``` ## Etapa 2: atualizar o manipulador do Lambda O *manipulador* da função do Lambda é o método no código da função que processa eventos. Quando sua função é invocada, o Lambda executa o método do manipulador. A função é executada até que o manipulador retorne uma resposta, seja encerrado ou atinja o tempo limite. Para obter mais informações, consulte [Definir o manipulador da função do Lambda em Java](java-handler.md). O manipulador exemplificado a seguir mostra como executar o código antes do ponto de verificação (`beforeCheckpoint()`) e depois da restauração (`afterRestore()`). Esse manipulador também registra o `Resource` no `Context` global gerenciado pelo runtime. **nota** Quando o Lambda cria um snapshot, o 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](configuration-timeout.md) (máximo de 900 segundos), o que for maior. Seus hooks de runtime de `beforeCheckpoint()` contam até o limite de tempo do código de inicialização. Quando o Lambda restaura um snapshot, o runtime (JVM) deve ser carregado e os hooks de runtime `afterRestore()` devem ser concluídos dentro do limite de tempo-limite (dez segundos). Caso contrário, você obterá uma SnapStartTimeoutException. ``` ... import org.crac.Resource; import org.crac.Core; ... public class CRaCDemo implements RequestStreamHandler, Resource { public CRaCDemo() { Core.getGlobalContext().register(this); } public String handleRequest(String name, Context context) throws IOException { System.out.println("Handler execution"); return "Hello " + name; } @Override public void beforeCheckpoint(org.crac.Context context) throws Exception { System.out.println("Before checkpoint"); } @Override public void afterRestore(org.crac.Context context) throws Exception { System.out.println("After restore"); ``` `Context` mantém somente uma [https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/WeakReference.html](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/WeakReference.html) para o objeto registrado. Se um [https://javadoc.io/static/io.github.crac/org-crac/0.1.3/org/crac/Resource.html](https://javadoc.io/static/io.github.crac/org-crac/0.1.3/org/crac/Resource.html) estiver na coleta de resíduos, os hooks de runtime não serão executados. O código deve manter uma referência forte para o `Resource` com a finalidade de garantir que o hook de runtime seja executado. Veja a seguir dois exemplos de padrões a serem evitados: **Example : objeto sem uma referência forte** ``` Core.getGlobalContext().register( new MyResource() ); ``` **Example : objetos de classes anônimas** ``` Core.getGlobalContext().register( new Resource() { @Override public void afterRestore(Context context) throws Exception { // ... } @Override public void beforeCheckpoint(Context context) throws Exception { // ... } } ); ``` Em vez disso, mantenha uma referência forte. No exemplo a seguir, o recurso registrado não está na coleta de resíduos e os hooks de runtime são executados de forma consistente. **Example : objeto com uma referência forte** ``` Resource myResource = new MyResource(); // This reference must be maintained to prevent the registered resource from being garbage collected Core.getGlobalContext().register( myResource ); ``` # Hooks de runtime do Lambda SnapStart para Python É possível usar hooks de runtime para implementar o código antes que o Lambda crie um snapshot ou depois que o Lambda retorna uma função de um snapshot. Os hooks de runtime do Python estão disponíveis como parte da biblioteca de código aberto [Snapshot Restore for Python](https://pypi.org/project/snapshot-restore-py/), que está incluída nos runtimes gerenciados do Python. Essa biblioteca fornece dois decoradores que você pode usar para definir seus hooks de runtime: + `@register_before_snapshot`: para funções que você deseja executar antes de o Lambda criar um snapshot. + `@register_after_restore`: para funções que você deseja executar quando o Lambda retoma uma função de um snapshot. Como alternativa, você pode usar os seguintes métodos para registrar objetos que podem ser chamados em hooks de runtime: + `register_before_snapshot(func, *args, **kwargs)` + `register_after_restore(func, *args, **kwargs)` ## Registro e execução do hook de runtime A ordem em que o Lambda executa seus hooks de runtime é determinada pela ordem de registro: + Antes do snapshot: executado na ordem inversa do registro + Após o snapshot: executado na ordem de registro A ordem do registro de hooks de runtime depende de como você define os hooks. Ao usar decoradores (`@register_before_snapshot` e `@register_after_restore`), a ordem de registro segue a ordem de importação, definição ou execução em seu código. Se você precisar de mais controle sobre a ordem de registro, use os métodos `register_before_snapshot()` e `register_after_restore()`, em vez de decoradores. Certifique-se de que todos os hooks registrados sejam importados e incluídos corretamente no código da sua função. Se você registrar hooks de runtime em um arquivo ou módulo separado, deverá garantir que o módulo seja importado, diretamente ou como parte de um pacote maior, no arquivo do manipulador da sua função. Se o arquivo ou módulo não for importado no manipulador da função, o Lambda vai ignorar os hooks de runtime. **nota** Quando o Lambda cria um snapshot, o 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](configuration-timeout.md) (máximo de 900 segundos), o que for maior. Seus hooks de runtime de `@register_before_snapshot` contam até o limite de tempo do código de inicialização. Quando o Lambda restaura um snapshot, o runtime deve ser carregado e os hooks de runtime `@register_after_restore` devem ser concluídos dentro do limite de tempo limite (dez segundos). Caso contrário, você obterá uma SnapStartTimeoutException. ## Exemplo O manipulador exemplificado a seguir mostra como executar o código antes do ponto de verificação (`@register_before_snapshot`) e depois da restauração (`@register_after_restore`). ``` from snapshot_restore_py import register_before_snapshot, register_after_restore def lambda_handler(event, context): # Handler code @register_before_snapshot def before_checkpoint(): # Logic to be executed before taking snapshots @register_after_restore def after_restore(): # Logic to be executed after restore ``` Para conferir mais exemplos, consulte [Snapshot Restore for Python](https://github.com/aws/snapshot-restore-py/tree/main/examples) no repositório do GitHub da AWS. # Hooks de runtime do Lambda SnapStart para .NET É possível usar hooks de runtime para implementar o código antes que o Lambda crie um snapshot ou depois que o Lambda retorna uma função de um snapshot. Os hooks de runtime do.NET estão disponíveis como parte do pacote [Amazon.Lambda.Core](https://www.nuget.org/packages/Amazon.Lambda.Core) (versão 2.5.0 ou posterior). Essa biblioteca fornece dois métodos que você pode usar para definir seus hooks de runtime: + `RegisterBeforeSnapshot()`: código a ser executado antes da criação do snapshot + `RegisterAfterSnapshot()`: código a ser executado após retomar uma função de um snapshot **nota** Se você estiver usando a [estrutura Lambda Annotations para .NET](csharp-handler.md#csharp-handler-annotations), atualize para [Amazon.Lambda.Annotations](https://www.nuget.org/packages/Amazon.Lambda.Annotations) versão 1.6.0 ou posterior para garantir a compatibilidade com o SnapStart. ## Registro e execução do hook de runtime Registre seus hooks no código de inicialização. Considere as seguintes diretrizes com base no [modelo de execução](csharp-handler.md#csharp-handler-setup) da função do Lambda: + Para a [abordagem de assembly executável](csharp-handler.md#csharp-executable-assembly-handlers), registre seus hooks antes de iniciar o bootstrap do Lambda com `RunAsync`. + Para a [abordagem de bibliotecas de classes](csharp-handler.md#csharp-class-library-handlers), registre seus hooks no construtor de classe do manipulador. + Para [aplicações ASP.NET Core](csharp-package-asp.md), registre seus hooks antes de chamar o método `WebApplications.Run`. Para registrar hooks de runtime para o SnapStart no .NET, use os seguintes métodos: ``` Amazon.Lambda.Core.SnapshotRestore.RegisterBeforeSnapshot(BeforeCheckpoint); Amazon.Lambda.Core.SnapshotRestore.RegisterAfterRestore(AfterCheckpoint); ``` Quando vários tipos de hooks são registrados, a ordem em que o Lambda executa seus hooks de runtime é definida pela ordem de registro: + `RegisterBeforeSnapshot()`: executado na ordem inversa do registro + `RegisterAfterSnapshot()`: executado na ordem de registro **nota** Quando o Lambda cria um snapshot, o 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](configuration-timeout.md) (máximo de 900 segundos), o que for maior. Seus hooks de runtime de `RegisterBeforeSnapshot()` contam até o limite de tempo do código de inicialização. Quando o Lambda restaura um snapshot, o runtime deve ser carregado e os hooks de runtime `RegisterAfterSnapshot()` devem ser concluídos dentro do limite de tempo limite (dez segundos). Caso contrário, você obterá uma SnapStartTimeoutException. ## Exemplo A função exemplificada a seguir mostra como executar o código antes do ponto de verificação (`RegisterBeforeSnapshot`) e depois da restauração (`RegisterAfterRestore`). ``` public class SampleClass { public SampleClass() { Amazon.Lambda.Core.SnapshotRestore.RegisterBeforeSnapshot(BeforeCheckpoint); Amazon.Lambda.Core.SnapshotRestore.RegisterAfterRestore(AfterCheckpoint); } private ValueTask BeforeCheckpoint() { // Add logic to be executed before taking the snapshot return ValueTask.CompletedTask; } private ValueTask AfterCheckpoint() { // Add logic to be executed after restoring the snapshot return ValueTask.CompletedTask; } public APIGatewayProxyResponse FunctionHandler(APIGatewayProxyRequest request, ILambdaContext context) { // Add business logic return new APIGatewayProxyResponse { StatusCode = 200 }; } } ``` # Monitoramento para o Lambda SnapStart Você pode monitorar as funções do Lambda SnapStart usando o Amazon CloudWatch, o AWS X-Ray e a [Acessar dados de telemetria em tempo real para extensões usando a API Telemetria](telemetry-api.md). **nota** As [variáveis de ambiente](configuration-envvars.md#configuration-envvars-runtime) `AWS_LAMBDA_LOG_GROUP_NAME` e `AWS_LAMBDA_LOG_STREAM_NAME` não estão disponíveis nas funções do Lambda SnapStart. ## Noções básicas sobre o comportamento de logs e faturas com o SnapStart Existem algumas diferenças relacionadas ao formato do [fluxo de logs do CloudWatch](monitoring-cloudwatchlogs.md) para funções do SnapStart: + **Logs de inicialização**: quando um novo ambiente de execução é criado, o `REPORT` não inclui o campo `Init Duration`. Isso ocorre porque o Lambda inicializa as funções do SnapStart quando você cria uma versão, em vez de durante a invocação da função. Para as funções do SnapStart, o campo `Init Duration` está no registro `INIT_REPORT`. Este registro mostra detalhes de duração para [Fase de inicialização](lambda-runtime-environment.md#runtimes-lifecycle-ib), incluindo a duração de quaisquer [ganchos de runtime](snapstart-runtime-hooks.md) `beforeCheckpoint`. + **Logs de invocação**: quando um novo ambiente de execução é criado, o `REPORT` inclui os campos `Restore Duration` e `Billed Restore Duration`: + `Restore Duration`: o tempo necessário para o Lambda restaurar um snapshot, carregar o runtime e executar qualquer [hook de runtime](snapstart-runtime-hooks.md) after-restore. O processo de restauração de snapshots pode incluir o tempo gasto em atividades fora da MicroVM. Esse tempo é relatado em `Restore Duration`. + `Billed Restore Duration`: o tempo necessário para o Lambda carregar o runtime e executar qualquer [hook de runtime](snapstart-runtime-hooks.md) after-restore. **nota** Como acontece com todas as funções do Lambda, as taxas de duração se aplicam ao código executado no manipulador da função. Para funções do SnapStart, as cobranças por duração também se aplicam ao código de inicialização declarado fora do manipulador, ao tempo que demora para o runtime carregar e aos códigos executados em um [hook de runtime](snapstart-runtime-hooks.md). A duração da inicialização a frio corresponde a soma de `Restore Duration` \$1 `Duration`. O exemplo a seguir é uma consulta do Lambda Insights que retorna os percentis de latência para as funções do SnapStart. Para obter mais informações sobre consultas do Lambda Insights, consulte [Exemplo de fluxo de trabalho usando consultas para solucionar problemas de uma função](monitoring-insights.md#monitoring-insights-queries). ``` filter @type = "REPORT" | parse @log /\d+:\/aws\/lambda\/(?.*)/ | parse @message /Restore Duration: (?.*?) ms/ | stats count(*) as invocations, pct(@duration+coalesce(@initDuration,0)+coalesce(restoreDuration,0), 50) as p50, pct(@duration+coalesce(@initDuration,0)+coalesce(restoreDuration,0), 90) as p90, pct(@duration+coalesce(@initDuration,0)+coalesce(restoreDuration,0), 99) as p99, pct(@duration+coalesce(@initDuration,0)+coalesce(restoreDuration,0), 99.9) as p99.9 group by function, (ispresent(@initDuration) or ispresent(restoreDuration)) as coldstart | sort by coldstart desc ``` ## Rastreamento ativo do X-Ray para SnapStart Você pode usar o [X-Ray](services-xray.md) para rastrear solicitações para as funções do Lambda SnapStart. Existem algumas diferenças relacionadas aos subsegmentos do X-Ray para funções do SnapStart: + Não há qualquer subsegmento `Initialization` para as funções do SnapStart. + O subsegmento `Restore` mostra o tempo necessário para o Lambda restaurar um snapshot, carregar o runtime e executar qualquer [hook de runtime](snapstart-runtime-hooks.md) after-restore. O processo de restauração de snapshots pode incluir o tempo gasto em atividades fora da MicroVM. Esse tempo é relatado no subsegmento `Restore`. Você não é cobrado pelo tempo gasto fora da microVM para restaurar um snapshot. ## Eventos de API de telemetria para SnapStart O Lambda envia os eventos do SnapStart a seguir para a [API de telemetria](telemetry-api.md): + [`platform.restoreStart`](telemetry-schema-reference.md#platform-restoreStart): mostra o horário em que a [Fase `Restore`](lambda-runtime-environment.md#runtimes-lifecycle-restore) foi iniciada. + [`platform.restoreRuntimeDone`](telemetry-schema-reference.md#platform-restoreRuntimeDone): mostra se a fase `Restore` ocorreu com êxito. mO Lambda envia essa mensagem quando o runtime envia uma solicitação de API de runtime `restore/next`. Existem três status possíveis: com êxito, com falha e tempo limite. + [`platform.restoreReport`](telemetry-schema-reference.md#platform-restoreReport): mostra quanto tempo durou a fase `Restore` e por quantos milissegundos você foi cobrado durante essa fase. ## Amazon API Gateway e métricas de URL da função Se você criar uma API da Web [usando o API Gateway](services-apigateway.md), poderá usar a métrica [IntegrationLatency](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-metrics-and-dimensions.html) para medir a latência de ponta a ponta (o tempo entre o momento em que o API Gateway retransmite uma solicitação para o backend e o momento em que recebe uma resposta do backend). Se você estiver usando um [URL da função do Lambda](urls-configuration.md), poderá usar a métrica [UrlRequestLatency](urls-monitoring.md) para medir a latência de ponta a ponta (o tempo entre o momento em que o URL da função recebe uma solicitação e o momento em que o URL da função retorna uma resposta). # Modelo de segurança para o Lambda SnapStart O Lambda SnapStart oferece suporte à criptografia em repouso. O Lambda criptografa snapshots com uma AWS KMS key. Por padrão, o Lambda usa um Chave gerenciada pela AWS. Se esse comportamento padrão for adequado ao seu fluxo de trabalho, você não precisará configurar mais nada. Caso contrário, é possível usar a opção `--kms-key-arn` no comando [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html) ou [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html) para fornecer uma chave gerenciada pelo cliente do AWS KMS. É possível fazer isso para controlar a alternância da chave KMS ou para atender aos requisitos da organização para gerenciamento de chaves KMS. As chaves gerenciadas pelo cliente incorrem em cobranças do AWS KMS padrão. Para obter mais informações, consulte [Preços do AWS Key Management Service](https://aws.amazon.com/kms/pricing/). Quando você exclui uma função ou uma versão de função do SnapStart, todas as solicitações `Invoke` para essa função ou versão de função apresentam falhas. O Lambda remove todos os recursos associados aos snapshots excluídos em conformidade com o Regulamento Geral sobre a Proteção de Dados (GDPR). # Maximizar a performance do SnapStart do Lambda **Topics** + [ ## Ajuste de performance ](#snapstart-tuning) + [ ## Práticas recomendadas de rede ](#snapstart-networking) ## Ajuste de performance Para maximizar os benefícios do SnapStart, considere as recomendações de otimização de código a seguir para seu runtime. **nota** O SnapStart funciona melhor quando usado com invocações de funções em escala. As funções que são invocadas com pouca frequência podem não ter as mesmas melhorias de performance. ### Java Para maximizar os benefícios do SnapStart, recomendamos carregar previamente as dependências e inicializar os recursos que contribuem para a latência de startup em seu código de inicialização, em vez de no manipulador de função. Isso remove a latência associada ao carregamento pesado de classes do caminho de invocação, otimizando a performance de startup com o SnapStart. Se não for possível carregar previamente as dependências ou os recursos durante a inicialização, recomendamos carregá-los previamente com invocações fictícias. Para fazer isso, atualize o código do manipulador de função, conforme mostrado no exemplo a seguir da [função “pet store”](https://github.com/awslabs/aws-serverless-java-container/tree/main/samples/spring/pet-store) no repositório GitHub do AWS Labs. ``` private static SpringLambdaContainerHandler handler; static { try { handler = SpringLambdaContainerHandler.getAwsProxyHandler(PetStoreSpringAppConfig.class); // Use the onStartup method of the handler to register the custom filter handler.onStartup(servletContext -> { FilterRegistration.Dynamic registration = servletContext.addFilter("CognitoIdentityFilter", CognitoIdentityFilter.class); registration.addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST), false, "/*"); }); // Send a fake Amazon API Gateway request to the handler to load classes ahead of time ApiGatewayRequestIdentity identity = new ApiGatewayRequestIdentity(); identity.setApiKey("foo"); identity.setAccountId("foo"); identity.setAccessKey("foo"); AwsProxyRequestContext reqCtx = new AwsProxyRequestContext(); reqCtx.setPath("/pets"); reqCtx.setStage("default"); reqCtx.setAuthorizer(null); reqCtx.setIdentity(identity); AwsProxyRequest req = new AwsProxyRequest(); req.setHttpMethod("GET"); req.setPath("/pets"); req.setBody(""); req.setRequestContext(reqCtx); Context ctx = new TestContext(); handler.proxy(req, ctx); } catch (ContainerInitializationException e) { // if we fail here. We re-throw the exception to force another cold start e.printStackTrace(); throw new RuntimeException("Could not initialize Spring framework", e); } } ``` ### Python Para maximizar os benefícios do SnapStart, concentre-se na organização eficiente do código e no gerenciamento de recursos em suas funções do Python. Como diretriz geral, execute tarefas computacionais pesadas durante a [fase de inicialização](lambda-runtime-environment.md#runtimes-lifecycle-ib). Essa abordagem remove as operações demoradas do caminho de invocação, melhorando a performance geral da função. Para implementar essa estratégia de forma eficaz, recomendamos as seguintes práticas recomendadas: + Importe dependências fora do manipulador de função. + Crie instâncias `boto3` fora do manipulador. + Inicialize recursos ou configurações estáticas antes que o manipulador seja invocado. + Considere usar um [hook de runtime](snapstart-runtime-hooks-python.md) antes do snapshot para tarefas que consomem muitos recursos, como baixar arquivos externos, pré-carregar estruturas como o Django ou carregar modelos de machine learning. **Example : otimizar a função Python para o SnapStart** ``` # Import all dependencies outside of Lambda handler from snapshot_restore_py import register_before_snapshot import boto3 import pandas import pydantic # Create S3 and SSM clients outside of Lambda handler s3_client = boto3.client("s3") # Register the function to be called before snapshot @register_before_snapshot def download_llm_models(): # Download an object from S3 and save to tmp # This files will persist in this snapshot with open('/tmp/FILE_NAME', 'wb') as f: s3_client.download_fileobj('amzn-s3-demo-bucket', 'OBJECT_NAME', f) ... def lambda_handler(event, context): ... ``` ### .NET Para reduzir a compilação just-in-time (JIT) e o tempo de carregamento do assembly, considere invocar seu manipulador de funções de um [hook de runtime](snapstart-runtime-hooks-dotnet.md) `RegisterBeforeCheckpoint`. Devido à forma como funciona a compilação em camadas do .NET, você terá ótimos resultados invocando o manipulador várias vezes, conforme mostrado no exemplo a seguir. **Importante** Certifique-se de que a invocação da função fictícia não produza efeitos colaterais indesejados, como iniciar transações comerciais. **Example** ``` public class Function { public Function() { Amazon.Lambda.Core.SnapshotRestore.RegisterBeforeSnapshot(FunctionWarmup); } // Warmup method that calls the function handler before snapshot to warm up the .NET code and runtime. // This speeds up future cold starts after restoring from a snapshot. private async ValueTask FunctionWarmup() { var request = new APIGatewayProxyRequest { Path = "/heathcheck", HttpMethod = "GET" }; for (var i = 0; i < 10; i++) { await FunctionHandler(request, null); } } public async Task FunctionHandler(APIGatewayProxyRequest request, ILambdaContext context) { // // Process HTTP request // var response = new APIGatewayProxyResponse { StatusCode = 200 }; return await Task.FromResult(response); } } ``` ## Práticas recomendadas de rede O estado das conexões que a função estabelece durante a fase de inicialização não é garantido quando o Lambda retoma a função de um snapshot. Na maioria dos casos, as conexões de rede que um SDK da AWS estabelece são retomadas automaticamente. Para outras conexões, recomendamos as práticas recomendadas a seguir. **Restabelecer as conexões de rede** Sempre restabeleça as conexões de rede quando a função for retomada de um snapshot. Recomendamos restabelecer as conexões de rede no manipulador de função. Como alternativa, você pode usar um [hook de runtime](snapstart-runtime-hooks.md) after-restore. **Não usar o nome do host como um identificador exclusivo do ambiente de execução** Recomendamos não usar o `hostname` para identificar o ambiente de execução como um nó ou um contêiner exclusivo em suas aplicações. Com o SnapStart, um único snapshot é usado como o estado inicial para diversos ambientes de execução. Todos os ambientes de execução retornam o mesmo valor `hostname` para `InetAddress.getLocalHost()` (Java), `socket.gethostname()` (Python) e `Dns.GetHostName()` (.NET). Para aplicações que requerem uma identidade de ambiente de execução ou um valor do `hostname` exclusivo, recomendamos gerar um ID exclusivo no manipulador de função. Como alternativa, use um [hook de runtime](snapstart-runtime-hooks.md) after-restore para gerar um ID exclusivo e, em seguida, use o ID exclusivo como identificador para o ambiente de execução. **Evitar vincular conexões a portas de origem fixas** Recomendamos evitar vincular conexões de rede a portas de origem fixas. As conexões são restabelecidas quando uma função é retomada de um snapshot, e as conexões de rede vinculadas a uma porta de origem fixa podem apresentar falhas. **Evitar usar o cache do DNS Java** As funções do Lambda já armazenam as respostas de DNS em cache. Se você usar outro cache DNS com o SnapStart, poderá experimentar tempos limite de conexão quando a função for retomada de um snapshot. A classe `java.util.logging.Logger` pode habilitar indiretamente o cache do DNS da JVM. Para substituir as configurações padrão, defina [networkaddress.cache.ttl](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/net/InetAddress.html#inetaddress-caching-heading) como 0 antes de inicializar o `logger`. Exemplo: ``` public class MyHandler { // first set TTL property static{ java.security.Security.setProperty("networkaddress.cache.ttl" , "0"); } // then instantiate logger var logger = org.apache.logging.log4j.LogManager.getLogger(MyHandler.class); } ``` Para evitar falhas `UnknownHostException` no runtime do Java 11, recomendamos definir `networkaddress.cache.negative.ttl` como 0. Em runtimes do Java 17 e versões posteriores, essa etapa não é necessária. Você pode definir essa propriedade para uma função do Lambda com a variável de ambiente `AWS_LAMBDA_JAVA_NETWORKADDRESS_CACHE_NEGATIVE_TTL=0`. Desabilitar o cache do DNS da JVM não desabilita o cache do DNS gerenciado do Lambda. # Solução de problemas de erros do SnapStart para funções do Lambda Esta página aborda problemas comuns que ocorrem ao usar o Lambda SnapStart, incluindo erros de criação de snapshots, erros de tempo limite e erros internos de serviço. ## SnapStartNotReadyException **Erro:** An error occurred (SnapStartNotReadyException) when calling the Invoke20150331 operation: Lambda is initializing your function. Ela estará pronta para ser invocada quando o estado se tornar ATIVO. ### Causas comuns Esse erro ocorre quando você tenta invocar uma versão de função que está no [estado](snapstart-activate.md#snapstart-function-states) `Inactive`. Sua versão da função torna-se `Inactive` quando ela não é invocada há 14 dias ou quando o Lambda recicla periodicamente o ambiente de execução ### Resolução Aguarde até que a versão de função atinja o estado `Active` e, em seguida, invoque-a novamente. ## SnapStartTimeoutException **Problema:** você recebe um `SnapStartTimeoutException` quando tenta invocar uma versão da função do SnapStart. ### Causa comum Durante a fase [Restauração](lambda-runtime-environment.md#runtimes-lifecycle-restore), o Lambda restaura o runtime do Java e executa todos os [hooks de runtime](snapstart-runtime-hooks.md) after-restore. Se um hook de runtime after-restore for executado por mais de dez segundos, a fase `Restore` atingirá o tempo limite e você receberá um erro ao tentar invocar a função. Problemas de credenciais e de conexão de rede também podem gerar tempos limite da fase de `Restore`. ### Resolução Verifique os logs do CloudWatch da função em busca de erros de tempo limite que ocorreram durante a fase de [restauração](lambda-runtime-environment.md#runtimes-lifecycle-restore). Certifique-se de que todos os hooks after-restore sejam concluídos em menos de dez segundos. **Example Log do CloudWatch** ``` { "cause": "Lambda couldn't restore the snapshot within the timeout limit. (Service: Lambda, Status Code: 408, Request ID: 11a222c3-410f-427c-ab22-931d6bcbf4f2)", "error": "Lambda.SnapStartTimeoutException"} ``` ## Erro 500 de serviço interno **Erro:** Lambda was unable to create a new snapshot because you have reached your concurrent snapshot creation limit. ### Causa comum Um erro 500 é um erro interno no próprio serviço do Lambda, e não um problema com a função ou o código. Esses erros geralmente são intermitentes. ### Resolução Tente publicar a versão da função novamente. ## 401 Não autorizado **Erro:** Bad session token or header key ### Causa comum Esse erro ocorre ao usar o [AWS Systems Manager Parameter Store e a extensão do AWS Secrets Manager](with-secrets-manager.md) com o Lambda SnapStart. ### Resolução O AWS Systems Manager Parameter Store e a extensão do AWS Secrets Manager não são compatíveis com o SnapStart. A extensão gera credenciais para comunicação com o AWS Secrets Manager durante a inicialização da função, o que causa erros de credenciais expiradas quando usada com o SnapStart. ## UnknownHostException (Java) **Erro:** Unable to execute HTTP request: Certificate for `abc.us-east-1.amazonaws.com` doesn't match any of the subject alternative names. ### Causa comum As funções do Lambda já armazenam as respostas de DNS em cache. Se você usar outro cache DNS com o SnapStart, poderá experimentar tempos limite de conexão quando a função for retomada de um snapshot. ### Resolução Para evitar falhas `UnknownHostException` no runtime do Java 11, recomendamos definir `networkaddress.cache.negative.ttl` como 0. Em runtimes do Java 17 e versões posteriores, essa etapa não é necessária. Você pode definir essa propriedade para uma função do Lambda com a variável de ambiente `AWS_LAMBDA_JAVA_NETWORKADDRESS_CACHE_NEGATIVE_TTL=0`. ## Falhas na criação do snapshots **Erro:** AWS Lambda could not invoke your SnapStart function. Se esse erro persistir, verifique se há erros de inicialização nos logs do CloudWatch. ### Resolução Revise os logs do Amazon CloudWatch da função para conferir os tempos limite dos [hooks de runtime](snapstart-runtime-hooks.md) before-checkpoint. Você também pode tentar publicar uma nova versão da função, o que às vezes pode resolver o problema. ## Latência da criação de snapshots **Problema:** quando você publica uma nova versão da função, a função permanece no [estado](snapstart-activate.md#snapstart-function-states) `Pending` por um longo tempo. ### Causa comum Quando o Lambda cria um snapshot, o 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](configuration-timeout.md) (máximo de 900 segundos), o que for maior. Se a função estiver [anexada a uma VPC](configuration-vpc.md#configuration-vpc-attaching), o Lambda também talvez precise criar interfaces de rede antes que a função fique `Active`. Caso tente invocar a versão da função enquanto a função estiver `Pending`, você poderá receber um erro 409 `ResourceConflictException`. Se a função for invocada usando um endpoint do Amazon API Gateway, você poderá receber um erro 500 no API Gateway. ### Resolução Aguarde pelo menos 15 minutos para que a versão da função seja inicializada antes de invocá-la.