O blog da AWS

O AWS Lambda padroniza cobrança para Fase de INIT

Por Shubham Gupta, Principal PMTes, Lambda e Jeff Gebhart, Sr. STAM-Srvrless.

A partir de 1º de agosto de 2025, a AWS padronizará a cobrança da fase de inicialização (INIT) em todas as configurações de funções do AWS Lambda. Essa alteração afeta especificamente as invocações sob demanda de funções do Lambda empacotadas como arquivos ZIP que usam runtime gerenciados, para os quais a duração da fase INIT não era cobrada anteriormente. Essa atualização padroniza o faturamento da fase INIT em todos os tipos de runtime, pacotes de implantação e modos de invocação. A maioria dos usuários verá um impacto mínimo em sua fatura geral do Lambda decorrente dessa mudança, já que a fase INIT normalmente ocorre para uma fração muito pequena das invocações de funções. Nesta postagem, discutimos o ciclo de vida da função Lambda e as próximas mudanças na cobrança da fase INIT. Você aprenderá o que acontece na fase INIT e quando ela ocorre, como monitorar a duração da fase INIT e estratégias para otimizar essa fase e minimizar os custos.

Entendendo o ciclo de vida de execução da função Lambda

O ciclo de vida de execução da função Lambda consiste em três fases distintas: INIT, INVOKE e SHUTDOWN. A fase INIT é acionada durante uma “inicialização a frio” quando o Lambda cria um novo ambiente de execução para uma função em resposta a uma invocação. Isso é seguido pela fase INVOKE, na qual a solicitação é processada, e, finalmente, pela fase SHUTDOWN, em que o ambiente de execução é encerrado. Para obter um resumo do ciclo de vida da execução, assista ao ciclo de vida do ambiente de execução do AWS Lambda.

Durante a fase INIT, o Lambda executa uma série de etapas preparatórias em uma duração máxima de 10 segundos. O serviço recupera o código da função de um bucket interno do Amazon S3 ou do Amazon Elastic Container Registry (Amazon ECR) para funções usando empacotamento de containers. Em seguida, ele configura um ambiente com a memória, o runtime e outras configurações especificas. Quando o ambiente de execução é preparado, o Lambda executa quatro tarefas principais em sequência:

  1. Iniciar quaisquer extensões configuradas (Extension INIT)
  2. Inicializar o runtime (Runtime INIT)
  3. Executar o código estático da função (Função INIT)
  4. Executar quaisquer  hooks de runtime antes do ponto de verificação (aplicável somente ao Lambda SnapStart)

Entendendo as mudanças na cobrança

As cobranças do Lambda são baseadas no número de solicitações e na duração da execução do código. A duração é calculada a partir do momento em que o código da função começa a ser executado até sua conclusão ou término, arredondada para o milissegundo mais próximo. O custo da duração depende da quantidade de memória que você aloca para sua função.

Anteriormente, a duração da fase de INIT não era incluída na duração cobrada para funções que utilizavam runtimes gerenciados com empacotamento em arquivo ZIP, conforme evidenciado nos logs do Amazon CloudWatch:

REPORT RequestId: xxxxx Duration: 250.06 ms Billed Duration: 251 ms Memory Size: 1024 MB
Max Memory Used: 350 MB Init Duration: 100.77 ms

No entanto, funções configuradas com runtimes personalizados, concorrência provisionada (PC) ou pacote OCI já incluíam a duração da fase INIT em sua duração cobrada. A partir de 1º de agosto de 2025, a fase INIT será cobrada em todos os tipos de configuração e a duração da fase INIT será incluída na duração cobrada para invocações de funções sob demanda usando runtime gerenciados com pacotes de arquivamento ZIP. Após essa alteração, a linha de logs do REPORT Request ID mostrará o seguinte:

REPORT RequestId: xxxxx Duration: 250.06 ms Billed Duration: 351 ms Memory Size: 1024 MB
Max Memory Used: 350 MB Init Duration: 100.77 ms

As cobranças adicionais de duração da fase INIT seguirão o preço padrão de duração sob demanda, específico para cada região da AWS, que pode ser encontrado na página de preços do Lambda. Para funções do AWS Lambda @Edge, a duração da fase INIT será cobrada de acordo com as taxas de duração do Lambda @Edge.

Encontrando a duração da fase de INIT e seu impacto na cobrança do Lambda

Você já pode monitorar o tempo gasto na fase inicial de suas invocações de função usando a métrica “init_duration” do CloudWatch. Essa métrica também é citada como “Init Duration” na linha de log “REPORT RequestID” no CloudWatch Logs. Essas ferramentas oferecem informações valiosas sobre o tempo de inicialização das funções do Lambda, que agora serão levadas em consideração nos cálculos de faturamento.

Para uma análise mais abrangente, você pode usar a seguinte consulta do CloudWatch Log Insights para gerar um relatório detalhado estimando a duração anteriormente não cobrada da fase INIT. A consulta ajuda você a entender a proporção do tempo da fase INIT não cobrada em relação ao seu uso geral do Lambda, permitindo projeções de custo mais precisas após essa alteração no cobrança.

filter @type = "REPORT" and @billedDuration < (@duration + @initDuration) 
| stats sum((@memorySize/1000000/1024) * (@billedDuration/1000)) as BilledGBs, 
sum((@memorySize/1000000/1024) * ((ceil(@duration + @initDuration) - @billedDuration)/1000)) as UnbilledInitGBs, 
(UnbilledInitGBs/ (UnbilledInitGBs+BilledGBs)) as Ratio

A consulta do CloudWatch Log Insights fornece três métricas essenciais:

  1. BilledGBS: representa o total de GB-s (gigabytes por segundo) atualmente cobrados pelos grupos de log escolhidos.
  2. UnbilledInitGBs: mostra o total de GB-s consumidos durante a fase INIT que anteriormente não estava incluído na cobrança.
  3. Ratio: indica a porcentagem do total de GB-s atribuídos à duração da fase INIT não cobrada anteriormente.

O uso desses recursos de monitoramento existentes permite que você avalie e otimize proativamente os tempos de inicialização da função Lambda, potencialmente minimizando o impacto da nova estrutura de cobrança em seus custos gerais.

 Entendendo e otimizando a fase de INIT do Lambda

A fase Lambda INIT é acionada em dois cenários específicos: durante a criação de um novo ambiente de execução e quando uma função escala para atender à demanda. Esse código INIT é executado somente durante essas “cold start” e é ignorado durante invocações subsequentes que usam ambientes quentes existentes. Após a fase de inicialização, o Lambda executa o código handler da função para processar a invocação.

Após a execução do manipulador (handler), o Lambda congela o ambiente de execução. Para melhorar o gerenciamento e o desempenho dos recursos, o serviço Lambda retém o ambiente de execução por um período de tempo não determinístico. Durante esse período, se outra solicitação chegar para a mesma função, o serviço poderá reutilizar o ambiente. Essa segunda solicitação geralmente termina mais rápido, porque o ambiente de execução já existe e não é necessário baixar o código e executar o código INIT. Isso é chamado de “warm start”.

Os desenvolvedores podem usar a fase INIT para criar, inicializar e configurar objetos que devem ser reutilizados em várias invocações durante a função INIT, em vez de fazê-lo no handler. A inicialização antecipada das dependências/objetos compartilhados reduz a latência das invocações subsequentes. Por exemplo:

  • Baixar mais bibliotecas ou dependências
  • Estabelecer conexões de clientes com outros serviços da AWS, como Amazon S3 ou Amazon DynamoDB
  • Criar conexões de banco de dados para serem compartilhadas entre invocações
  • Recuperar parâmetros ou segredos do aplicativo do Amazon Systems Manager Parameter Store ou do AWS Secrets Manager

Ao desenvolver funções do Lambda, é importante decidir estrategicamente qual código é executado durante a fase de inicialização e não na fase de manipulação, pois isso afeta tanto o desempenho quanto os custos.

Otimizando o tamanho do pacote/biblioteca

A fase INIT inclui criar um ambiente de execução, baixar o código da função e inicializá-lo. Três fatores principais influenciam seu desempenho:

  1. O tamanho do pacote da função, em termos de bibliotecas e dependências importadas, e camadas Lambda.
  2. A quantidade de código e o trabalho de INIT.
  3. O desempenho de bibliotecas e outros serviços na configuração de conexões e outros recursos.

Pacotes de funções maiores aumentam o tempo de download do código. Você pode diminuir a duração da fase INIT reduzindo o tamanho do pacote, resultando em “cold start” mais rápidas e menores custos de INIT. Além disso, otimizar o carregamento de bibliotecas também pode afetar significativamente o tamanho do pacote. Ferramentas como o esbuild podem otimizar ainda mais o desempenho reduzindo e agrupando pacotes. Para obter detalhes, leia Reduza os tempos de cold start do Lambda: migre para o AWS SDK para JavaScript v3.

Otimizando a execução da fase INIT e a eficiência de custos

A frequência das execuções da fase INIT (ou cold start) afeta diretamente o desempenho e a eficiência de custos. De acordo com uma análise das cargas de trabalho de produção do Lambda, os INITs (cold starts) normalmente ocorrem em menos de 1% das invocações, o que significa que o código na fase INIT pode ser executado apenas uma vez a cada cem invocações.

Você pode usar a fase INIT para realizar operações únicas que beneficiem as invocações subsequentes. Os padrões comuns de otimização incluem o pré-cálculo de tabelas de pesquisa ou a transformação de conjuntos de dados estáticos. Por exemplo, baixar dados estáticos do Amazon S3 ou do DynamoDB durante o INIT, disponibilizando-os para todas as invocações de funções subsequentes sem downloads repetidos.

Lambda SnapStart

O Lambda SnapStart fornece uma solução eficaz para reduzir a latência de cold start e os custos da fase de INIT. Quando ativado, o SnapStart cria um imagem durante a primeira função INIT e a reutiliza para cold starts subsequentes, eliminando a necessidade de repetidas execuções da fase INIT. Essa abordagem é particularmente valiosa para funções com tempos de inicialização mais longos devido ao carregamento de dependências/frameworks de módulos, à inicialização do runtime ou à execução de um código INIT único. O SnapStart é compatível com ambientes de execução Java, .NET e Python. Você pode implementar o SnapStart por meio do console Lambda ou da AWS Command Line Interface (AWS CLI), certificando-se de que seu código esteja de acordo com as diretrizes de serialização da AWS para compatibilidade com a restauração de snapshots. O uso do SnapStart permite que você melhore significativamente os tempos de inicialização das funções e otimize os custos em várias linguagens de programação populares.

Concorrência provisionada

A concorrência provisionada é um recurso do Lambda que pré-inicializa os ambientes de execução antes que qualquer invocação ocorra. Essa abordagem proativa elimina efetivamente o impacto no desempenho da fase INIT em chamadas de funções individuais, porque o INIT é concluído com antecedência.

Embora todas as funções que utilizam Concorrência Provisionada se beneficiem de tempos de inicialização reduzidos em comparação com a execução sob demanda, o impacto é particularmente notável em certos ambientes de runtime. Por exemplo, funções em C# e Java—que normalmente apresentam INIT mais lento mas tempos de execução mais rápidos em comparação com Node.js ou Python—podem alcançar ganhos significativos de desempenho através deste recurso. A implementação de Concorrência Provisionada permite gerenciar efetivamente tanto padrões de tráfego consistentes quanto picos de uso esperados, minimizando assim a latência de cold start em suas aplicações Serverless. Esta estratégia de otimização é particularmente valiosa para funções com requisitos complexos de INIT ou aquelas que atendem cargas de trabalho sensíveis à latência. Do ponto de vista de otimização de custos, a Concorrência Provisionada é mais adequada para cargas de trabalho com padrões de uso sustentado acima de 60% de utilização, pois isso geralmente proporciona melhor eficiência de custos em comparação com a execução sob demanda.

Conclusão

A partir de 1º de agosto de 2025, a AWS está padronizando a cobrança da fase de INIT para o AWS Lambda. A AWS oferece várias maneiras para você otimizar tanto o desempenho quanto os custos de suas funções Lambda. Seja utilizando SnapStart, implementando Concorrência Provisionada ou otimizando o código de INIT, recomendamos trabalhar em estreita colaboração com as equipes de suporte da AWS para identificar a abordagem de otimização mais adequada para os requisitos específicos da sua carga de trabalho.

Para obter mais suporte e orientação, considere participar de workshops de otimização de custos da AWS ou consultar a documentação do Lambda.

Este conteúdo foi traduzido da postagem original do blog, que pode ser encontrada aqui.

Biografia dos Autores

Shubham Gupta, Principal PMTes, Lambda
Jeff Gebhart, Sr. STAM-Srvrless

Biografia do Tradutor

Rodrigo Peres é Arquiteto de Soluções na AWS, com mais de 20 anos de experiência trabalhando com arquitetura de soluções, desenvolvimento de sistemas e modernização de sistemas legados.

Biografia do Revisor

Daniel Abib é arquiteto de soluções sênior na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e segurança. Ele trabalha apoiando clientes corporativos, ajudando-os em sua jornada para a nuvem.

https://www.linkedin.com/in/danielabib/