Apresentando runtimes de public preview no AWS Lambda, começando com Node.js 26 e Python 3.15

Por Jonathan Tuliani, Principal Product Manager no time AWS Lambda.

Hoje, o AWS Lambda apresenta os runtimes em visualização pública, uma nova forma de experimentar versões de linguagem futuras no Lambda antes do lançamento de disponibilidade geral (GA). A partir de hoje, você pode criar e atualizar funções Lambda usando Node.js 26 e Python 3.15, os primeiros runtimes disponíveis como visualizações públicas.

Anteriormente, o Lambda sempre lançou novos runtimes como Disponíveis para o público geral (GA), oferecendo uma experiência pronta para produção desde o primeiro dia. Mas isso significava que você não podia executar suas funções no Lambda usando uma versão pré-lançamento da linguagem, e nós não podíamos ouvir seu feedback enquanto mudanças incompatíveis ainda eram possíveis. Os runtimes em visualização pública mudam isso. Ao colocar runtimes pré-GA em suas mãos meses antes, podemos ouvir seu feedback e tratá-lo antes do GA, enquanto ainda temos a oportunidade de fazer mudanças incompatíveis para melhorar o runtime.

Os runtimes de visualização estão disponíveis em todas as Regiões comerciais da AWS, Regiões AWS GovCloud (US) e Regiões da China. Eles usam o mesmo identificador de runtime que o eventual runtime GA, então suas funções são promovidas automaticamente quando o runtime atinge o GA, sem necessidade de ação.

Por que runtimes em visualização pública

Quando o Lambda lança um novo runtime como GA, isso significa que ele está pronto para uso em cargas de trabalho de produção desde o primeiro dia. Historicamente, a equipe do Lambda validou novos runtimes por meio de testes internos e benchmarking de pré-lançamento. No entanto, sem cargas de trabalho reais de clientes executando no runtime, alguns problemas só aparecem após o lançamento GA. E uma vez que o runtime é GA, o escopo para tratar esses problemas é muito reduzido, pois não podemos arriscar quebrar cargas de trabalho de produção existentes.

Os runtimes em visualização pública abordam isso abrindo uma janela de feedback pré-GA. Durante este período, você pode implantar funções usando o runtime futuro, e a equipe do Lambda pode agir com base no que você encontrar, incluindo fazer mudanças potencialmente incompatíveis se necessário. Além disso, como a linguagem upstream ainda está em sua fase de pré-lançamento, também existe a oportunidade de que problemas descobertos durante a visualização possam ser corrigidos no próprio runtime, não apenas contornados.

Isso beneficia todos os envolvidos. Você obtém um runtime que foi testado contra uma gama mais ampla de cargas de trabalho reais antes de atingir o GA. Parceiros terceiros, incluindo provedores de observabilidade, ferramentas de infraestrutura como código e frameworks de implantação, ganham tempo para validar a compatibilidade. E as comunidades de linguagem upstream recebem um sinal de uma grande plataforma de nuvem enquanto ainda podem agir sobre ele.

Esta é a primeira vez que estamos lançando runtimes como visualizações públicas. Como tal, é um experimento. Esperamos tornar as visualizações públicas o padrão para todos os futuros lançamentos de runtime, dependendo do sucesso deste experimento e do feedback que recebermos.

O que está incluído nos runtimes de visualização

Os runtimes de visualização Node.js 26 e Python 3.15 são construídos com base no último pré-lançamento upstream de cada versão de linguagem. No lançamento, eles são uma simples atualização de versão. Não há aprimoramentos adicionais específicos do Lambda além do que a nova versão da linguagem em si fornece. Para detalhes sobre o que há de novo em cada versão de linguagem, consulte as informações de lançamento upstream:

Os runtimes de visualização estão disponíveis tanto como runtimes gerenciados quanto como imagens de container base. As imagens base são publicadas no repositório ECR de imagens base do Lambda com tags de imagem começando com 3.15-preview (para Python) e 26-preview (para Node.js).

Durante o período de visualização, podemos introduzir recursos ou aprimoramentos adicionais a esses runtimes. Quando o fizermos, anunciaremos no mesmo issue do GitHub que usamos para coletar seu feedback:

Acompanhe esses issues para se manter informado sobre quaisquer mudanças durante o período de visualização.

O que esperar durante a visualização

Os runtimes de visualização seguem a mesma cadência de patches que os runtimes GA. Quando uma atualização é lançada upstream, o Lambda a aplica ao runtime de visualização na mesma programação de qualquer outro runtime suportado. Todos os recursos do Lambda suportados pelos runtimes GA atuais estão disponíveis nos runtimes de visualização, incluindo Lambda Managed Instances e funções duráveis.

A diferença chave é que a versão da linguagem subjacente ainda não atingiu seu lançamento estável. Além disso, a equipe do Lambda ainda está trabalhando nos runtimes para adicionar recursos e otimizar o desempenho. Ou seja, mudanças incompatíveis podem ocorrer durante o período de visualização. Uma função que funciona hoje pode exigir uma correção após o Lambda lançar a próxima atualização do runtime. Isso é por design: o período de visualização existe para que esses problemas possam ser encontrados e resolvidos antes do GA, não depois.

Por causa desse potencial de mudanças incompatíveis, os runtimes de visualização não são cobertos pelo SLA do AWS Lambda ou pelos planos de suporte técnico da AWS. Recomendamos fortemente contra usá-los para cargas de trabalho de produção. O Lambda emite uma mensagem de aviso nos CloudWatch Logs a cada cold start para deixar claro quando uma função está executando em um runtime de visualização:

WARNING: This is a preview runtime version and should not be used for production workloads. For further information and to provide feedback, see https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html.

Você pode notar que, no lançamento, os runtimes de visualização têm desempenho mais lento que os runtimes GA, em particular para cold starts. Isso ocorre por causa de uma combinação de falta de otimização e menos cache em subsistemas internos do Lambda. Faremos benchmarking e otimizaremos o desempenho durante o período de visualização, antes do GA.

As funções que usam runtimes de visualização são cobradas nas taxas padrão do Lambda. Não há custo adicional ou preço separado.

Compartilhe seu feedback

Queremos ouvir de você durante o período de visualização. Criamos um issue dedicado no GitHub para cada runtime de visualização onde você pode compartilhar sua experiência:

Comente nesses issues diretamente, ou abra um issue separado no repositório se preferir.

Estamos interessados em todo feedback, não apenas relatórios de bugs. Se você vir uma oportunidade de aproveitar um novo recurso da linguagem no runtime, ou uma forma de melhorar o modelo de programação do Lambda para essa linguagem, queremos ouvir sobre isso. O período de visualização é quando ainda podemos fazer mudanças significativas, então este é o melhor momento para compartilhar suas ideias.

Note que o feedback deve ser direcionado ao runtime em si: o ambiente de execução, a integração da linguagem e o modelo de programação. Para solicitações de recursos mais amplas do Lambda, consulte o roadmap público do AWS Lambda.

Transição para GA

Tanto Node.js 26 quanto Python 3.15 devem atingir seus lançamentos estáveis upstream em outubro de 2026. O GA do Lambda para cada runtime é direcionado para dentro de dois meses após esses lançamentos. Para as datas estimadas de GA mais recentes, consulte a documentação do Lambda.

Para o Node.js, o cronograma de GA está vinculado ao lançamento “Active LTS” do Node.js, que está agendado para outubro de 2026. Somente nesse ponto o lançamento é considerado adequado para cargas de trabalho de produção pelo projeto Node.js, e somente então é suficientemente estável para a aplicação automática de patches do runtime do Lambda, na qual patches são aplicados às suas funções sem ação de sua parte. O Lambda não fará GA do runtime Node.js 26 até que atinja o Active LTS.

Quando um runtime de visualização atinge o GA, suas funções são promovidas automaticamente. O identificador de runtime não muda: nodejs26.x na visualização é o mesmo nodejs26.x no GA. Você não precisa atualizar a configuração da sua função, templates ou código. O rótulo de visualização é removido do console e da documentação, o runtime passa a ser coberto pelo SLA do Lambda e pelo AWS Support, e a barra de desempenho e qualidade do GA se aplica desse ponto em diante.

Se você fixou sua função em uma versão específica do runtime usando Runtime Management Controls durante o período de visualização, ela permanece fixada. Você pode desfixar a qualquer momento para migrar para o runtime GA. Funções fixadas em uma versão de runtime pré-GA não são cobertas pelo SLA do Lambda e pelo AWS Support.

Começando

Você pode começar a usar os runtimes de visualização Node.js 26 e Python 3.15 hoje usando o console do Lambda, a AWS Command Line Interface (AWS CLI), o AWS CloudFormation, o AWS Serverless Application Model (AWS SAM) ou o AWS Cloud Development Kit (AWS CDK).

Console

No console do Lambda, escolha “Node.js 26 (Preview)” ou “Python 3.15 (Preview)” na lista de runtimes ao criar ou atualizar uma função.

AWS CLI

Crie uma função usando o runtime de visualização com o identificador de runtime padrão:

aws lambda create-function \
  --function-name my-function \
  --runtime nodejs26.x \
  --handler index.handler \
  --role arn:aws:iam::123456789012:role/my-role \
  --zip-file fileb://function.zip

Para Python 3.15, use --runtime python3.15. Esses são os mesmos identificadores que os runtimes GA usarão, não há um valor separado específico de visualização.

AWS CloudFormation

Especifique o runtime de visualização em seu template do CloudFormation usando o mesmo identificador de runtime:

Resources:
  MyFunction:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: my-function
      Runtime: nodejs26.x
      Handler: index.handler
      Role: arn:aws:iam::123456789012:role/my-role
      Code:
        S3Bucket: amzn-s3-demo-function-code
        S3Key: function.zip

AWS SAM

O AWS SAM suporta runtimes de visualização usando o identificador de runtime padrão em seu template:

Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.15
      Handler: app.lambda_handler
      CodeUri: src/

Quando você executa sam init, os runtimes de visualização aparecem na lista de templates com um rótulo “(Preview)”, para que você possa criar um novo projeto diretamente.

AWS CDK

O AWS CDK ainda não inclui membros de enum embutidos (como Runtime.NODEJS_26_X). Durante a fase de visualização, você pode usar o construtor público Runtime para especificar o runtime diretamente, por exemplo:

import { Stack, StackProps } from "aws-cdk-lib";
import { Construct } from "constructs";
import { Function, Runtime, RuntimeFamily, Code } from "aws-cdk-lib/aws-lambda";

export class LambdaStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    new Function(this, "MyFunction", {
      runtime: new Runtime("nodejs26.x", RuntimeFamily.NODEJS),
      handler: "index.handler",
      code: Code.fromAsset("lambda"),
    });
  }
}

Ou, para Python 3.15, substitua new Runtime("nodejs26.x", RuntimeFamily.NODEJS) por new Runtime("python3.15", RuntimeFamily.PYTHON).

Isso sintetiza CloudFormation idêntico ao que um enum embutido produz. Quando o runtime atingir o GA, um membro de enum correspondente será adicionado. Não há diferença funcional enquanto isso.

Conclusão

Os runtimes em visualização pública oferecem a você um lugar na mesa enquanto os próximos runtimes do Lambda ainda estão tomando forma. Experimente usar Node.js 26 ou Python 3.15 hoje para implantar uma função, executar sua suíte de testes e nos conte o que encontrou.

Compartilhe feedback e acompanhe:

Esses issues do GitHub são onde publicaremos quaisquer aprimoramentos ou mudanças incompatíveis durante o período de visualização, então vale a pena acompanhá-los mesmo que você não tenha feedback imediato. Os runtimes de visualização estão disponíveis hoje em todas as Regiões da AWS, incluindo AWS GovCloud (US) e as Regiões AWS da China. Para saber mais, consulte a documentação de runtimes do Lambda.

Este conteúdo foi traduzido da publicação original do blog em inglês (disponível aqui).

Autores

Jonathan Tuliani é Principal Product Manager no time AWS Lambda na Amazon Web Services.

Tradutores

Nicolas Tarzia é Senior Technical Account Manager na AWS, com mais de 13 anos de experiência, com ampla experiência em arquitetura cloud, engenharia e design de software. Sua área de interesse são tecnologias serverless.
https://www.linkedin.com/in/nicolastarzia

Daniel Abib é Arquiteto de Soluções Sênior e Especialista em Amazon Bedrock 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 especialização em Machine Learning. Ele trabalha apoiando Startups, ajudando-os em sua jornada para a nuvem.
https://www.linkedin.com/in/danielabib/

O blog da AWS