AWS Lambda Web Functions deixa rodar app Express ou Next.js sem adaptador

A AWS anunciou o AWS Lambda Web Functions, um novo form factor do Lambda que roda aplicação web HTTP padrão sem exigir que o código vire um handler de evento. Quem já tentou colocar um servidor Express no Lambda conhece o ritual: instalar serverless-http ou algo parecido, embrulhar o app.listen() num adaptador, e torcer para que o comportamento em produção seja igual ao que rodava localmente. O anúncio, publicado no AWS News Blog, elimina essa etapa.

O pulo do gato é que o código que roda no Lambda agora pode ser literalmente o mesmo que roda com node index.js na sua máquina. Não há handler, não há evento APIGatewayProxyEvent para desestruturar. O processo sobe, escuta numa porta e responde requisição HTTP como qualquer servidor.

Três form factors, três modelos de programação

Com este lançamento, o Lambda passa a oferecer três formas distintas de execução, todas construídas sobre a mesma tecnologia de isolamento Firecracker, mas com modelos de programação e cobrança diferentes.

O nome "Event Functions" é a forma que a AWS encontrou para batizar o que já existia: a função que recebe um evento, processa e devolve resposta, o modelo que todo mundo que usa Lambda hoje já conhece. Web Functions é o item novo desta leva, e MicroVMs cobre um nicho mais específico de sandboxing.

A ideia declarada pela AWS é que os três convivam na mesma conta e na mesma aplicação: Event Functions cuidando do processamento assíncrono de fundo, Web Functions servindo a API e o SSR, MicroVMs rodando a execução de código interativo, tudo sob o mesmo modelo operacional.

Por que o billing por CPU ativa importa

O ponto comercial do anúncio é a cobrança por tempo de CPU em uso, e não por tempo de parede. Em Event Functions, o relógio corre do início ao fim da invocação, inclusive enquanto a função espera resposta de um banco ou de uma API externa. Em Web Functions, segundo a AWS, o tempo gasto esperando I/O consome pouca CPU faturável, e a memória é cobrada pelo tempo em que o ambiente de execução existe, não por invocação.

Para workload I/O-bound, como endpoint de API que passa a maior parte do tempo aguardando uma query, ou endpoint de inferência de IA fazendo streaming de tokens, isso muda a conta. É exatamente o tipo de cenário em que o modelo tradicional de Lambda historicamente saía caro: você paga pelo tempo de espera, não só pelo trabalho de CPU.

Dito isso, a AWS não publicou no anúncio o preço por milissegundo de CPU nem um comparativo numérico contra o billing de Event Functions. Quem decide migrar uma API para Web Functions precisa ir até a página de preços do Lambda e rodar a conta com o próprio padrão de tráfego antes de prometer economia ao time.

Deploy de um comando, sem provisionamento prévio

O exemplo do anúncio usa um servidor Express comum:

import express from 'express';

const app = express();
const [host, port] = process.env.AWS_LAMBDA_HTTP_ENDPOINT.split(':');

app.get('/', (req, res) => {
 res.json({ message: 'Hello from Lambda Web Functions!' });
});

app.listen(port, host, () => {
 console.log(`Server running on port ${port}`);
});

A única diferença em relação a rodar localmente é a variável de ambiente AWS_LAMBDA_HTTP_ENDPOINT, que o Lambda injeta com o host e a porta que o servidor deve escutar. Para testar localmente, basta definir a mesma variável manualmente, com algo como AWS_LAMBDA_HTTP_ENDPOINT=127.0.0.1:3000 node index.js.

O deploy acontece pela AWS CLI, com um único comando:

aws lambda-web deploy --name my-web-app --code ./my-app

Esse comando empacota o código-fonte, cria a Web Function, publica a primeira revisão, anexa um endpoint e devolve uma URL HTTPS funcional em menos de um minuto, sem necessidade de provisionar recursos antes. No vocabulário do produto, revisão é um snapshot imutável do código enviado, e endpoint é a URL HTTPS que roteia tráfego para uma revisão (ou divide tráfego entre revisões).

Multi-região automática e canary sem tooling extra

Para servir usuários em regiões diferentes com baixa latência, o mesmo comando de deploy aceita múltiplas regiões:

aws lambda-web deploy --name my-web-app --code ./my-app \
 --regions us-east-1,eu-west-1,ap-northeast-1

O Lambda replica o código para as regiões informadas e configura roteamento por latência automaticamente, com cada requisição indo para a região de menor latência em relação a quem chama, por uma URL global única (<domain-id>.lambda-web.global.on.aws). É roteamento best-effort, não uma garantia de SLA por região.

Para rollout gradual em produção, existe deslocamento de tráfego entre revisões via API, sem precisar de uma ferramenta externa de feature flag ou deployment:

aws lambda-web update-web-function-endpoint \
 --function-name my-web-app \
 --endpoint-name dev \
 --auto-deployment-mode Disabled \
 --revision-weights '[{"revisionId": "<current-revision-id>", "weight": 90}, {"revisionId": "<new-revision-id>", "weight": 10}]'

Esse comando manda 90% do tráfego do endpoint para a revisão atual e 10% para a nova, o que dá um canary deployment nativo. Quem hoje monta esse tipo de rollout gradual com alias e weighted routing manual no Lambda tradicional, ou recorre a uma camada de API Gateway para isso, ganha a função embutida no próprio serviço.

CloudFront como origem privada, sem autorização customizada

Para aplicações que misturam conteúdo estático e dinâmico, a AWS recomenda usar um endpoint de Web Function como origem de uma distribuição do CloudFront: os assets estáticos saem do cache, e as requisições dinâmicas vão para a Web Function.

A novidade aqui é que o endpoint de Web Function aceita origin access control (OAC) do CloudFront diretamente, do mesmo jeito que já existe para Amazon S3. O CloudFront assina as requisições para a origem, e o endpoint só aceita chamadas vindas da sua distribuição, sem expor a URL publicamente nem exigir que você implemente autorização customizada na aplicação para bloquear acesso direto.

O que falta: São Paulo não está na lista

AWS Lambda Web Functions está disponível, segundo o anúncio, em US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo) e Europe (Ireland). A região São Paulo (sa-east-1) não aparece na lista de lançamento, o que significa que quem opera no Brasil e quer latência baixa para usuário local ainda não tem Web Function disponível na região mais próxima.

O runtime suportado no lançamento é Node.js 24 (nodejs24.x), em arquitetura Arm64, com suporte a conectividade VPC para acessar recursos dentro de uma rede privada. A AWS não detalhou no anúncio a data de fim de suporte do nodejs24.x, nem publicou número de cold start, limite de memória por ambiente de execução além do limite de 128 requisições concorrentes, ou custo por milhão de requisições comparado ao modelo de Event Functions. Quem for avaliar a migração de uma API real precisa rodar o próprio teste de carga antes de confiar na promessa de redução de custo.

Quando faz sentido migrar, e quando não

Web Functions resolve um problema real para quem hoje mantém um backend HTTP rodando atrás de adaptador no Lambda tradicional: elimina a camada de tradução entre evento e requisição HTTP, e reduz o custo de workload que passa muito tempo esperando I/O. Para API backend, servidor de SSR e endpoint de streaming de inferência de IA, o modelo de cobrança por CPU ativa tende a favorecer quem hoje paga caro pelo tempo de espera em wall-clock.

Para consumidor de fila, processador de evento do EventBridge ou trigger disparado por outro serviço AWS, o modelo de Event Functions continua sendo a opção certa: é exatamente o cenário single-concurrent, invocação por evento, para o qual ele foi desenhado. Trocar um consumer de SQS por uma Web Function não traz benefício, porque não há conceito de "requisição HTTP concorrente" nesse padrão de consumo.

Quem decide testar deve começar pelo comando mais simples do anúncio, que sobe um exemplo pronto sem nem precisar escrever código:

aws lambda-web deploy --name hello-world --hello-world

Daí, a recomendação é medir CPU ativa real do próprio workload antes de prometer economia para o time, e ficar de olho em quando sa-east-1 entra na lista de regiões suportadas.

Fonte: AWS News Blog