Aprimoramento da performance de inicialização com o Lambda SnapStart - AWS Lambda
Casos de usoRecursos compatíveis e limitaçõesRegiões com suporteConsiderações sobre compatibilidadePreços

Aprimoramento da performance de inicialização com o Lambda SnapStart

O Lambda SnapStart pode oferecer 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 do estado da memória e do disco do ambiente de execução 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 ter mais informações, consulte Tratamento da exclusividade com o Lambda SnapStart.

Tópicos

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

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

Outros runtimes gerenciados (como nodejs22.x e ruby3.3), Runtimes somente para sistema operacional e imagens de contêiner não são compatíveis.

O SnapStart não é compatível com simultaneidade provisionada, com o Amazon Elastic File System (Amazon EFS) 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 e aliases que direcionam para versões. Não é possível usar o SnapStart em uma versão não publicada de uma função ($LATEST).

Regiões com suporte

Para runtimes de Java, o Lambda SnapStart está disponível em todas as regiões comerciais, exceto Ásia-Pacífico (Malásia).

Para runtimes de Python e .NET, o Lambda SnapStart está disponível nas seguintes Regiões da AWS:

  • Leste dos EUA (Norte da Virgínia)

  • Leste dos EUA (Ohio)

  • Oeste dos EUA (Oregon)

  • Ásia-Pacífico (Singapura)

  • Ásia-Pacífico (Sydney)

  • Ásia-Pacífico (Tóquio)

  • Europa (Frankfurt)

  • Europa (Irlanda)

  • Europa (Estocolmo)

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

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.

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 que você aloca para sua função. A cobrança é feita por um mínimo de 3 horas. Você continuará recebendo a cobrança até excluir a versão da função. Use a ação da API ListVersionsByFunction para identificar as versões da função e, em seguida, use DeleteFunction 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 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. 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.