AWS lança Lambda Web Functions e deixa Express e Hono rodarem nativos no Lambda

A AWS↳AWS20 conteúdosE-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envioDevSecOps · out 2025Codex na AWS: chegada do agente da OpenAI à nuvem da AmazonDevSecOps · abr 2026Salesforce e AWS ampliam colaboração em IA, CRM e marketplaceDevSecOps · nov 2023Ver tudo em DevSecOps → anunciou em outubro de 2026 o Lambda Web Functions, uma nova categoria de função Lambda feita para rodar aplicações web em Node.js↳Node.js45 conteúdosComo criar aplicações console em Node.jsDev (Back & Front) · fev 2025Entendendo o ciclo de publicação do Node.jsDev (Back & Front) · fev 2020Nodejs por baixo dos panosDev (Back & Front) · jul 2019Ver tudo em Dev (Back & Front) → sem precisar de camada de adaptação. Frameworks como Express, Hono, Fastify e Next.js passam a rodar direto na plataforma, como se estivessem num servidor HTTP comum escutando uma porta.

Até aqui, quem queria rodar uma API Express no Lambda precisava envolver o app numa camada de tradução entre o evento do Lambda e o formato esperado pelo framework (bibliotecas como serverless-http existem justamente para isso). O Lambda Web Functions elimina essa etapa: o deploy é do servidor HTTP padrão, sem reescrever rotas nem trocar o roteador por um handler de evento.

O que muda no modelo de cobrança e performance

A diferença mais relevante para quem opera em produção está na cobrança. Segundo a documentação oficial do Lambda Web Functions, o novo modelo cobra por tempo de CPU ativo e memória, e não pelo tempo de CPU gasto esperando respostas de serviços externos, como bancos de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → ou outras APIs.

Isso favorece diretamente cargas de trabalho que passam boa parte do tempo de execução esperando I/O: renderização no servidor (SSR), backends de API que consultam banco e inferência de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → com resposta em streaming. Hoje, nesses casos, o modelo tradicional do Lambda cobra pelo tempo todo da invocação, incluindo a espera.

Outras mudanças técnicas relevantes:

• Um único ambiente de execução "quente" (warm) agora atende múltiplas requisições simultâneas, o que reduz significativamente a ocorrência de cold starts.
• Há suporte nativo a streaming de resposta, incluindo saída incremental de modelos de linguagem.
• O roteamento multi-região direciona cada requisição para a região mais próxima do usuário automaticamente.
• As funções existentes do Lambda passam a se chamar Lambda Event Functions; nada muda para quem já usa o modelo tradicional.

Micah Walter, arquiteto de soluções sênior na AWS, resume o apelo da mudança:

Você pode pegar um servidor padrão escutando porta, construído com Express, Hono, Fastify, Next.js ou qualquer framework Node.js, fazer o deploy com um único comando, e o Lambda cuida automaticamente de escalonamento, distribuição multi-região e cobrança por CPU ativo. Sem adaptadores, sem infraestrutura para gerenciar e sem lock-in de framework.

You can take a standard port-listening server built with Express, Hono, Fastify, or any Node.js framework, deploy it with a single command, and Lambda automatically handles scaling, multi-region distribution, and active CPU billing. No adapters, no infrastructure to manage, and no framework lock-in.Micah Walter, senior solutions architect na AWS

Atenção: o modelo de concorrência mudou de verdade

Aqui está o ponto que merece cuidado de quem for migrar código existente. No modelo tradicional do Lambda, cada invocação roda isolada, uma de cada vez por ambiente de execução. Com o Lambda Web Functions, um mesmo ambiente quente processa várias requisições concorrentes ao mesmo tempo, exatamente como um servidor Express normal rodando num contêiner faria.

Isso é bom para performance, mas quebra uma premissa que muitos times carregavam havia anos sem perceber: a de que não precisavam se preocupar com estado compartilhado entre requisições, porque cada invocação era isolada. O usuário magnetik79, numa thread no Hacker News, resumiu o problema:

Essa é grande, e é bom ver algo que não está inteiramente focado em IA. O que parece ótimo: muitas cargas de trabalho agora podem pular o API Gateway inteiramente (...) isso muda totalmente o modelo atual de programação HTTP do Lambda, agora você não trabalha mais com uma invocação por requisição, agora você pode precisar se preocupar com sincronização e mutex.

This is a big one - and nice to see something not entirely honed in AI. What looks great: Many workloads can now skip API Gateway entirely (...) this totally changes the current Lambda HTTP programming model - now you're no longer working with one invoke/one request - now you might need to be sync/mutex aware.magnetik79, usuário no Hacker News

Na prática, quem migrar um app Express existente precisa revisar variáveis globais, caches em memória e qualquer estado que assumia isolamento por invocação. Código que nunca precisou pensar em condição de corrida agora precisa.

Como fica o deploy e o domínio

Por padrão, o endpoint do Lambda Web Functions usa um domínio fornecido pela própria AWS. Para domínio customizado, cache de borda ou proteção com AWS WAF, a recomendação da AWS é colocar o Amazon CloudFront na frente, usando o Lambda Web Functions como origem.

Em artigo publicado sobre o lançamento, Julian Wood, Kim Wendt e Samrat Karak construíram uma aplicação de exemplo para mostrar como um único ambiente de execução atende muitas requisições ao mesmo tempo e como a aplicação serve usuários globalmente. Eles resumem:

O Lambda Web Functions traz o modelo operacional serverless para aplicações web sem camadas de adaptador. Você escreve um servidor HTTP Node.js padrão, faz o deploy com um comando ou CloudFormation, e recebe um endpoint HTTPS escalável, pago por uso, com roteamento global já embutido.

Lambda Web Functions bring the serverless operating model to web applications without adapter layers. You write a standard Node.js HTTP server, deploy it with one command or CloudFormation, and get a scalable, pay-per-use HTTPS endpoint with global routing built in.Julian Wood, Kim Wendt e Samrat Karak

Quem fica de fora, por enquanto

O Lambda Web Functions suporta apenas Node.js. Python, Java e .NET continuam disponíveis só pelo modelo tradicional de Lambda (agora chamado Lambda Event Functions). Não há, segundo a fonte, data anunciada para extensão a outras linguagens.

Vale lembrar que, no início de 2026, a AWS já havia lançado o Lambda MicroVMs, voltado a ambientes de sandbox isolados e com estado, para rodar código não confiável ou gerado por usuário, com ciclo de vida gerenciado pelo próprio cliente. São produtos complementares: um resolve isolamento de código arbitrário, o outro resolve servir tráfego HTTP com o modelo de programação de um framework convencional.

E para quem desenvolve no Brasil?

Aqui está o ponto mais prático para times brasileiros avaliando a migração: o Lambda Web Functions está disponível, por enquanto, em apenas cinco regiões: Norte da Virgínia, Ohio, Oregon, Tóquio e Irlanda. São Paulo não está na lista.

Isso significa que, hoje, qualquer app migrado para o novo modelo e servindo usuários no Brasil vai operar com latência extra até a AWS expandir a disponibilidade para sa-east-1, ou até o time optar por colocar CloudFront na frente para mitigar parte do impacto de rede (o CloudFront tem ponto de presença no Brasil, mas a origem continua numa das cinco regiões atuais). Para APIs internas ou workloads que já têm boa parte da infraestrutura hospedada nos EUA, o impacto é menor; para apps que servem majoritariamente usuários brasileiros com requisitos de latência apertados, vale esperar a expansão de regiões antes de migrar cargas críticas.

Não é exclusividade da AWS

O modelo que o Lambda Web Functions adota (sem camada de adaptador, com escalonamento automático e concorrência configurável) já existe em outras nuvens. Google Cloud Run e Azure Container Apps oferecem propostas parecidas: rodar aplicações web sem adaptador, com scale-to-zero e concorrência configurável, voltadas a cargas de tráfego intermitente ou em rajadas.

A diferença prática está nos detalhes de cobrança e no modelo de rede. Quem já avalia Cloud Run ou Container Apps para workloads Node.js tem agora mais uma opção concreta de comparação dentro do próprio ecossistema AWS, sem precisar sair da plataforma para ganhar esse modelo de programação mais simples.

Fonte: InfoQ