Runtime Node.js 24 agora disponível no AWS Lambda

Por Andrea Amorosi, Senior AI Engineer e Jonathan Tuliani, Principal, PMT na AWS.

Agora você pode desenvolver funções AWS Lambda usando Node.js 24, tanto como um runtime gerenciado ou usando a imagem base de container. O Node.js 24 está em status LTS ativo e pronto para uso em produção. Deve ser suportado com patches de segurança e correções de bugs até abril de 2028.

O runtime Lambda para Node.js 24 inclui uma nova implementação do Runtime Interface Client (RIC), que integra o código de suas funções com o serviço Lambda. Escrito em TypeScript, o novo RIC simplifica e otimiza o suporte ao Node.js no Lambda, removendo vários recursos legados. Em particular, handlers de função baseados em callback não são mais suportados.

O Node.js 24 inclui várias adições à linguagem, como Explicit Resource Management, bem como mudanças na implementação do runtime e na biblioteca padrão. Com este lançamento, desenvolvedores Node.js podem aproveitar esses novos recursos e melhorias ao criar aplicações Serverless no Lambda.

Você pode desenvolver funções Lambda Node.js 24 usando o AWS Management Console, AWS Command Line Interface (AWS CLI), AWS SDK for JavaScript, AWS Serverless Application Model (AWS SAM), AWS Cloud Development Kit (AWS CDK), e outras ferramentas de infraestrutura como código. Você pode usar o Node.js 24 com Powertools for AWS Lambda (TypeScript), um kit de ferramentas para desenvolvedores para implementar melhores práticas Serverless e aumentar a velocidade de desenvolvimento. O Powertools inclui bibliotecas para suportar tarefas comuns como observabilidade, integração com AWS Systems Manager Parameter Store, idempotência, processamento em lote, e muito mais. Você também pode usar o Node.js 24 com Lambda@Edge para personalizar conteúdo de baixa latência entregue através do Amazon CloudFront.

Esta publicação destaca mudanças importantes no runtime Node.js, atualizações notáveis da linguagem Node.js e como você pode usar o novo runtime Node.js 24 em suas aplicações Serverless.

Mudanças no runtime Node.js 24

O Lambda Runtime para Node.js 24 inclui as seguintes mudanças em relação aos runtimes Node.js 22 e anteriores.

Removendo suporte para handlers de função baseados em callback

A partir do runtime Node.js 24, o Lambda não suporta mais a assinatura de handler baseada em callback para operações assíncronas. Handlers baseados em callback recebem três parâmetros, sendo o terceiro parâmetro um callback. Por exemplo:

export const handler = (event, context, callback) => {
    try {
        // Some processing...
        
        // Success case
        // First parameter (error) is null, second is the result
        callback(null, {
            statusCode: 200,
            body: JSON.stringify({
                message: "Operation completed successfully"
            })
        });
        
    } catch (error) {
        // Error case
        // First parameter contains the error
        callback(error);
    }
};

A abordagem moderna para programação assíncrona no Node.js é usar o padrão async/await. O Lambda introduziu suporte para handlers async com o runtime Node.js 8, lançado em 2018. Veja como a função acima fica ao usar um handler async:

export const handler = async (event, context) => {
    try {
	  // Some processing
        
        return {
            statusCode: 200,
            body: JSON.stringify({
                message: "Operation completed successfully"
            })
        };
        
    } catch (error) {
        throw error;
    }
};

O runtime Node.js 24 ainda suporta handlers de função síncronos que não usam callbacks:

export const handler = (event, context) => {
    // Perform some synchronous data processing
    // Return response
    return {
        statusCode: 200,
        body: JSON.stringify(response)
    };
};

E o Node.js 24 ainda suporta streaming de resposta, permitindo aplicações mais responsivas ao acelerar o tempo até o primeiro byte:

export const handler = awslambda.streamifyResponse(async (event, responseStream, context) => {
    // Convert event to a readable stream
    const requestStream = Readable.from(Buffer.from(JSON.stringify(event)));
    // Stream the response using pipeline
    await pipeline(requestStream, responseStream);
});

Esta mudança para remover o suporte a handlers de função baseados em callback afeta apenas os runtimes Node.js 24 (e posteriores). Os runtimes existentes para Node.js 22 e anteriores continuam a suportar handlers de função baseados em callback. Ao migrar funções que usam handlers baseados em callback para o Node.js 24, você precisa modificar seu código para usar uma das assinaturas de handler de função suportadas

Como parte desta mudança, context.callbackWaitsForEmptyEventLoop foi removido. Além disso, os métodos anteriormente descontinuados context.succeed, context.fail e context.done também foram removidos. Isso alinha o runtime com padrões modernos do Node.js para um tratamento de erros e resultados mais claro e consistente.

Harmonizando comportamento de streaming e não-streaming para promessas não resolvidas

O runtime Node.js 24 também resolve uma inconsistência anterior em como promessas não resolvidas eram tratadas. Anteriormente, o Lambda não aguardava promessas não resolvidas uma vez que o handler retornasse exceto ao usar streaming de resposta. A partir do Node.js 24, o comportamento de streaming de resposta agora é consistente com o comportamento não-streaming, e o Lambda não aguarda mais promessas não resolvidas uma vez que seu handler retorne ou o fluxo de resposta termine. Qualquer trabalho em segundo plano (por exemplo, temporizadores pendentes, fetches ou callbacks enfileirados) não é aguardado implicitamente. Se sua resposta depende de operações assíncronas adicionais, certifique-se de aguardá-las em seu handler ou integrá-las ao pipeline de streaming antes de fechar o fluxo ou retornar, para que a resposta só seja concluída após todo o trabalho necessário ter sido finalizado.

Recursos experimentais do Node.js

O Node.js ativa certos recursos experimentais por padrão nos lançamentos upstream da linguagem. Tais recursos incluem suporte para importar módulos usando require() em módulos ECMAScript (módulos ES) e detectar automaticamente módulos ES vs CommonJS. Como são experimentais, esses recursos podem ser instáveis ou sofrer mudanças incompatíveis em futuras atualizações do Node.js. Para fornecer uma experiência estável, o Lambda desativa esses recursos por padrão nos runtimes Lambda correspondentes.

O Lambda permite que você reative esses recursos adicionando a flag --experimental-require-module ou a flag --experimental-detect-module à variável de ambiente NODE_OPTIONS. Ativar recursos experimentais do Node.js pode afetar o desempenho e a estabilidade, e esses recursos podem mudar ou ser removidos em futuros lançamentos do Node.js; tais problemas não são cobertos pelo AWS Support ou pelo SLA do Lambda.

Módulos ES em funções inline do CloudFormation

Com funções inline do AWS CloudFormation, você fornece o código da sua função diretamente no template do CloudFormation. Elas são particularmente úteis ao implantar recursos personalizados. Com funções inline, o nome do arquivo de código é sempre index.js, que por padrão o Node.js interpreta como um módulo CommonJS. Com o runtime Node.js 24, você pode usar módulos ES ao criar funções inline passando a flag --experimental-detect-module através da variável de ambiente NODE_OPTIONS. Anteriormente, você precisava de um pacote zip ou container para usar módulos ES. Com o Node.js 24, você pode escrever funções inline usando sintaxe ESM padrão (import/export) e top-level await), o que simplifica pequenos utilitários e lógica de inicialização sem exigir uma etapa de empacotamento.

Recursos de linguagem do Node.js 24

O Node.js 24 introduz várias atualizações de linguagem e recursos que melhoram a produtividade do desenvolvedor e o desempenho da aplicação.

O Node.js 24 inclui Undici 7, uma versão mais recente do cliente HTTP que impulsiona o ⁠fetch global. Esta versão traz melhorias de desempenho e capacidades de protocolo mais amplas. Funções Lambda que fazem uso intensivo de rede que chamam serviços AWS ou APIs externas podem se beneficiar de melhor gerenciamento de conexão e throughput, especialmente quando reutilizam clientes ou usar HTTP/2 onde suportado. A maioria das aplicações deve funcionar sem alterações, mas é recomendável validar o comportamento para cenários avançados, como cabeçalhos personalizados ou corpos de streaming, e manter a definição de clientes HTTP fora do handler para maximizar a reutilização de conexão entre invocações.

A sintaxe JavaScript Explicit Resource Management (⁠using e ⁠await using) permite limpeza determinística de recursos quando um bloco é concluído. Para handlers Lambda, isso facilita garantir que objetos de curta duração, como streams, buffers temporários ou handles de arquivo, sejam descartados prontamente, o que reduz o risco de vazamentos de recursos entre invocações warm. É recomendável manter clientes de longa duração, por exemplo, clientes SDK ou pools de banco de dados, fora do handler para aproveitar a reutilização de conexão, e aplicar descarte explícito apenas a recursos que você deseja desmontar no final de cada invocação.

Finalmente, a API ⁠AsyncLocalStorage agora usa ⁠AsyncContextFrame por padrão, melhorando o desempenho e a confiabilidade da propagação de contexto assíncrono. Isso beneficia padrões Serverless comuns, como temporizadores, correlação de logs, gerenciamento de IDs de rastreamento e metadados com escopo de solicitação através de limites async e await, e streams sem threading manual de parâmetros. Se você já usa bibliotecas baseadas em ⁠AsyncLocalStorage para logging ou observabilidade, podem observar menor sobrecarga e propagação de contexto mais consistente no Node.js 24.

Para uma visão geral detalhada dos recursos de linguagem do Node.js 24, consulte o post do blog de lançamento do Node.js 24 e o changelog do Node.js 24.

Considerações de desempenho

No lançamento, novos runtimes Lambda recebem menos uso do que runtimes estabelecidos existentes. Isso pode resultar em tempos de cold start mais longos devido à residência de cache reduzida dentro dos subsistemas internos do Lambda. Os tempos de cold start normalmente melhoram nas semanas seguintes ao lançamento à medida que o uso aumenta. Como resultado, a AWS recomenda não tirar conclusões de comparações de desempenho lado a lado com outros runtimes Lambda até que o desempenho tenha se estabilizado. Como o desempenho é altamente dependente da carga de trabalho, clientes com cargas de trabalho sensíveis ao desempenho devem conduzir seus próprios testes, em vez de confiar em benchmarks de teste genéricos.

Os desenvolvedores devem continuar a medir e testar o desempenho da função e otimizar o código e a configuração da função para qualquer impacto. Para saber mais sobre como otimizar o desempenho do Node.js no Lambda, consulte nosso post do blog Otimizando dependências Node.js no AWS Lambda.

Migração de runtimes Node.js anteriores

Já discutimos mudanças que são novas no runtime Node.js 24, como a remoção do suporte para handlers de função baseados em callback. Como lembrete, recapitularemos algumas mudanças anteriores para clientes atualizando de funções Node.js mais antigas.

AWS SDK for JavaScript

Até o Node.js 16, os runtimes Node.js do Lambda incluíam o AWS SDK for JavaScript versão 2. Isso foi substituído pelo AWS SDK for JavaScript versão 3, que foi lançado em dezembro de 2024. A partir do Node.js 18, e continuando com o Node.js 24, os runtimes Node.js do Lambda incluem a versão 3. Ao atualizar dos runtimes Node.js 16 ou anteriores e usar a versão 2 incluída, você deve atualizar seu código para usar o SDK v3.

Para desempenho ideal, e para ter controle total sobre as dependências do seu código, recomendamos empacotar e minificar o AWS SDK em seu pacote de implantação, em vez de usar o SDK incluído no runtime. Para mais informações, consulte Otimizando dependências Node.js no AWS Lambda.

Amazon Linux 2023

O runtime Node.js 24 é baseado no runtime provided.al2023, que é baseado na imagem de container mínima do Amazon Linux 2023. A imagem mínima do Amazon Linux 2023 usa microdnf como gerenciador de pacotes, com link simbólico como dnf. Isso substitui o gerenciador de pacotes yum usado nas imagens baseadas em AL2 do Node.js 18 e anteriores. Se você implantar sua função Lambda como uma imagem de container, é recomendável atualizar seu Dockerfile para usar dnf em vez de yum ao atualizar para a imagem base Node.js 24 do Node.js 18 ou anterior.

Saiba mais sobre o runtime provided.al2023 no post do blog Apresentando o runtime Amazon Linux 2023 para AWS Lambda e o post do blog de lançamento do Amazon Linux 2023.

Usando o runtime Node.js 24 no AWS Lambda

Por fim, revisaremos como configurar suas funções para usar o Node.js 24, usando uma variedade de ferramentas de implantação.

AWS Management Console

Ao usar o AWS Lambda Console, você pode escolher Node.js 24.x no menu suspenso Runtime ao criar uma função:

Criando função Node.js no AWS Management Console

Para atualizar uma função Lambda existente para Node.js 24, navegue até a função no console Lambda, clique em Edit no painel Runtime settings, depois escolha Node.js 24.x no menu suspenso Runtime:

Editando runtime da função Node.js

Imagem de container do AWS Lambda

Altere a versão da imagem base Node.js modificando a instrução FROM no seu Dockerfile.

FROM public.ecr.aws/lambda/nodejs:24
# Copy function code
COPY lambda_handler.mjs ${LAMBDA_TASK_ROOT}

AWS Serverless Application Model

No AWS SAM, defina o atributo Runtime como node24.x para usar esta versão:

AWSTemplateFormatVersion: "2010-09-09"
Transform: AWS::Serverless-2016-10-31
Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: lambda_function.lambda_handler
      Runtime: nodejs24.x
      CodeUri: my_function/.
      Description: My Node.js Lambda Function

O AWS SAM suporta a geração deste template com Node.js 24 para novas aplicações serverless usando o comando sam init. Para mais informações, consulte a documentação do AWS SAM.

AWS Cloud Development Kit (AWS CDK)

No AWS CDK, defina o atributo runtime como Runtime.NODEJS_24_X para usar esta versão.

import * as cdk from "aws-cdk-lib";
import * as lambda from "aws-cdk-lib/aws-lambda";
import * as path from "path";
import { Construct } from "constructs";
export class CdkStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);
    // The code that defines your stack goes here
    // The Node.js 24 enabled Lambda Function
    const lambdaFunction = new lambda.Function(this, "node24LambdaFunction", {
      runtime: lambda.Runtime.NODEJS_24_X,
      code: lambda.Code.fromAsset(path.join(__dirname, "/../lambda")),
      handler: "index.handler",
    });
  }
}

Conclusão

O AWS Lambda agora suporta Node.js 24 como runtime gerenciado e imagem base de container. Este lançamento usa um novo cliente de interface de runtime, remove o suporte para handlers de função baseados em callback e inclui várias outras mudanças para simplificar e otimizar o suporte ao Node.js no Lambda.

Você pode construir e implantar funções usando Node.js 24 usando o AWS Management Console, AWS CLI, AWS SDK, AWS SAM, AWS CDK, ou sua ferramenta de infraestrutura como código preferida. Você também pode usar a imagem base de container Node.js 24 se preferir construir e implantar suas funções usando imagens de container.

Para encontrar mais exemplos Node.js, use a Coleção de Padrões Serverless. Para mais recursos de aprendizado serverless, visite Serverless Land

Este conteúdo foi traduzido do post original do blog, que pode ser encontrado aqui.

Autores

	Andrea Amorosi, Senior AI Engineer
	Jonathan Tuliani, Principal, PMT

Tradutores

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.

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/

O blog da AWS