AWS Lambda Web Functions: mão na massa com um dashboard Node.js 24 em tempo real

A AWS lançou um novo tipo de função no Lambda que roda um servidor HTTP comum, sem camada de adaptação. Reproduzi o exemplo oficial, comando por comando, para mostrar onde ele brilha e onde você ainda precisa prestar atenção.

Quem trabalha com Lambda está acostumado a escrever um handler que recebe um evento, processa e devolve. O Lambda Web Functions muda essa premissa: seu código vira um servidor HTTP comum, do jeito que você já escreve com Express, Fastify, Hono ou um http.createServer cru. Nada de adaptador traduzindo requisição em evento. Segui o exemplo oficial que a AWS publicou (um dashboard de métricas em tempo real) para entender o que muda na prática, do deploy ao comportamento sob carga.

Dois tipos de função dentro do mesmo Lambda

Até aqui, todo código no Lambda era o que a AWS agora chama de Event Function: invocado uma vez por evento (uma mensagem de fila, um objeto chegando ao S3), com o ambiente congelado entre invocações. A Web Function é um segundo tipo de função, rodando no mesmo isolamento baseado em Firecracker, mas como processo de longa duração que escuta numa porta.

Uma Web Function tem três peças:

• Web Function: o recurso de topo, com nome e configuração.
• Revision: um snapshot imutável de código e configuração, criado a cada deploy, que permite rollback apontando o tráfego para uma revisão anterior.
• Endpoint: a porta de entrada, com domínio HTTPS, tipo de autenticação e regras de roteamento para as revisões.

No lançamento, as Web Functions rodam nodejs24.x em Arm64, com 2 vCPUs e 2 GB de memória por ambiente de execução, e aceitam conectividade com VPC.

Pré-requisitos

Você precisa de uma conta AWS, da AWS CLI instalada e configurada, e do Node.js instalado localmente. O código completo do exemplo está na coleção Serverless Patterns, junto com outros padrões de Web Functions; dá para clonar o repositório ou baixar o .zip do padrão direto.

O código é só um servidor HTTP

A aplicação de exemplo é um dashboard que transmite métricas do servidor para o navegador via server-sent events. O runtime entrega o endereço de escuta na variável AWS_LAMBDA_HTTP_ENDPOINT, no formato host:port, e o servidor lê isso normalmente:

const [host, port] = (process.env.AWS_LAMBDA_HTTP_ENDPOINT || "0.0.0.0:3000").split(":");
server.listen(Number(port), host);

Por padrão, o runtime carrega index.js na raiz do pacote. Se seu entrypoint tem outro nome (caso comum em projetos Next.js em modo standalone, que precisam de um pequeno index.js definindo host e porta), defina AWS_LAMBDA_NODEJS_ENTRYPOINT com o caminho correto.

Rodando local e implantando com um comando

Localmente, npm start sobe o servidor e http://localhost:3000/ mostra o dashboard já transmitindo dados. Para implantar:

aws lambda-web deploy --name lambda-web-sse-dashboard --code .

Esse comando empacota o código, cria a função, um perfil de execução, um bucket S3 com versionamento (compartilhado entre as Web Functions da CLI na região) e um endpoint chamado dev com URL HTTPS ativa, no formato https://<id>.<shard>.lambda-web.<region>.on.aws. A CLI pede confirmação antes de criar os recursos. Atenção: esse endpoint sai público e sem autenticação; use só para avaliação e apague ao terminar.

Testando simultaneidade sem contar ambiente por ambiente

A diferença operacional mais relevante é que um único ambiente de execução atende muitas conexões ao mesmo tempo, em vez de uma por vez como numa Event Function. Isso é controlado por maxConcurrencyPerEnvironment (até 128, padrão 64) na Web Function, e por maxEnvironments e rateLimit no endpoint, que limitam quantos ambientes sobem e quantas requisições por segundo passam, protegendo dependências downstream. Solicitações acima do limite recebem HTTP 429 e não entram em fila.

Para gerar carga, dá para disparar 300 requisições de streaming contra /api/events, com até 200 abertas ao mesmo tempo:

curl -sN --parallel --parallel-immediate --parallel-max 200 --max-time 90 "https://<ENDPOINT>/api/events?[1-300]"

O runtime grava um resumo por ambiente no CloudWatch Logs a cada minuto, com ID da instância, contagem de requisições, pico de simultaneidade e tempo de CPU. Uma consulta no CloudWatch Logs Insights agrega esses dados:

QID=$(aws logs start-query \
--log-group-name /aws/lambda/web/lambda-web-sse-dashboard \
--start-time $(($(date +%s)-300)) --end-time $(date +%s) \
--query-string 'filter type="platform.invokeSummary" | stats count_distinct(record.instanceId) as environments, sum(record.metrics.requests) as totalRequests, max(record.metrics.concurrentRequests) as peakConcurrency, sum(record.metrics.cpuTimeMs)/1000 as totalCpuSeconds' \
--query queryId --output text) && sleep 6 && aws logs get-query-results --query-id "$QID"

Na execução documentada pela equipe da AWS, com as mesmas 300 requisições e até 200 simultâneas, os números foram: 5 ambientes de execução usados, 484 requisições processadas no total, pico de 59 conexões simultâneas num único ambiente (perto do limite padrão de 64) e 4,75 segundos de CPU somando toda a frota. Para comparar: uma Event Function precisaria de até 200 ambientes para os mesmos 200 streams abertos, porque cada uma atende uma requisição por vez.

Cobrança por CPU ativa, não por tempo de parede

Se o ambiente fica minutos de pé, o que você paga? Requisições, memória consumida e tempo de CPU, cobrados separadamente. No exemplo, acionar Generate CPU load roda um loop de hash criptográfico por cerca de 1,5 segundo: o gráfico de CPU sobe e volta perto de zero quando o trabalho termina, mesmo com a conexão aberta por muito mais tempo.

Na prática, isso significa que esperar por um banco de dados, uma API downstream ou uma inferência de IA custa menos CPU do que custaria numa cobrança por tempo real, porque o relógio de CPU não corre enquanto o código espera. A AWS não publicou nesse post os valores por milissegundo de CPU nem por milhão de requisições; para esses números, vale conferir a página de preços oficial do Lambda antes de projetar custo em produção.

Multirregião sem load balancer para configurar

Tipo e regiões de um endpoint ficam fixados na criação; ir para múltiplas regiões significa criar um segundo endpoint:

aws lambda-web deploy --name lambda-web-sse-dashboard --code . --endpoint-name global --endpoint-type MultiRegion --regions us-east-1,eu-west-2

O Lambda replica código e configuração da revisão (incluindo variáveis de ambiente) para cada região, centraliza logs na região de origem e expõe uma URL global no formato https://<domain>.lambda-web.global.on.aws, usando roteamento baseado em latência do Route 53 por trás dos panos. Na medição que os autores do post fizeram a partir de um laptop no Reino Unido, o endpoint single-region em us-east-1 respondeu em 90 ms, contra 16 ms no endpoint global roteado para eu-west-2 (Londres). Eles mesmos fazem a ressalva: são medições isoladas de um único ponto, não um benchmark.

Para quem lê daqui, um detalhe importante: o exemplo da AWS não cita a região São Paulo (sa-east-1) nem como origem nem como destino de replicação. Antes de desenhar uma arquitetura multirregião pensando no Brasil, vale checar na documentação oficial se sa-east-1 já está na lista de regiões suportadas para Web Functions, porque o material de lançamento não confirma isso.

Autenticação: do público ao serviço-a-serviço

Cada endpoint tem um tipo de autenticação trocável sem reimplantar código. Com ApplicationManaged, o endpoint é público e seu código cuida da autenticação (OAuth, JWT, cookie de sessão, Amazon Cognito); administradores podem bloquear endpoints públicos na organização inteira com uma política de controle de serviço usando a chave lambda:Request/WebFunctionAuthType. Com IamAuth, o Lambda valida cada requisição com SigV4 (endpoints de região única) ou SigV4a (multirregião), e só chamadores com a permissão lambda:InvokeWebFunctionEndpoint chegam à aplicação: bom para comunicação serviço a serviço, mesmo com o endpoint acessível pela internet pública.

Para domínio próprio, cache de borda e AWS WAF, o caminho é colocar o Amazon CloudFront na frente do endpoint, com IamAuth e controle de acesso à origem, garantindo que o domínio do Lambda não vire um atalho que ignora o CloudFront (o cabeçalho Authorization da sua aplicação continua chegando normalmente).

Criando com um agente de codificação

Como o deploy inteiro é um comando e o código é um servidor HTTP qualquer, o Agent Toolkit for AWS já inclui skills de Web Functions, permitindo montar estrutura, desenvolver e implantar a partir de um prompt num agente de codificação.

O que fica em aberto

O material de lançamento não traz número de cold start nem latência de inicialização do ambiente de execução, algo que todo mundo que mede Lambda vai querer ver antes de migrar carga de produção. Também não há, até aqui, suporte a outros runtimes além de nodejs24.x, nem detalhamento de como a conectividade com VPC se comporta sob a mesma lógica de ambientes compartilhados. Para limpar os recursos do exemplo, as instruções de cleanup estão no próprio repositório do padrão Serverless Patterns.

Fonte: AWS Brasil — Blog