A Amazon anunciou em 12 de outubro o AWS Lambda Web Functions, formato que executa servidores HTTP Node.js convencionais sem converter cada requisição para o modelo de eventos do Lambda. Aplicações baseadas em Express, Hono, Fastify, React Router e outros frameworks podem escutar uma porta, receber tráfego diretamente e escalar até zero quando ficam ociosas.
O serviço cria um endpoint HTTPS, administra ambientes de execução e distribui as requisições entre eles. Cada ambiente pode atender várias solicitações simultâneas. A cobrança combina quantidade de requisições, CPU usada ativamente, memória reservada durante a vida do ambiente e transferência de dados.
Servidor HTTP substitui o adaptador de eventos
No Lambda tradicional, uma Function URL, API Gateway ou outro integrador transforma a requisição HTTP em um evento. O handler recebe esse objeto, executa a lógica e devolve uma resposta no formato esperado. Frameworks web normalmente dependem de adaptadores para traduzir os dois lados.
Web Functions muda essa interface. A aplicação inicia um servidor Node.js e escuta na porta fornecida pelo ambiente. Rotas, middlewares, streaming e estrutura do projeto ficam mais próximos do desenvolvimento local. A documentação da AWS informa que o pacote é enviado como arquivo ZIP e que não são necessários wrappers específicos do Lambda.
Isso reduz uma camada de integração, mas não transforma o ambiente em uma máquina persistente. O processo ainda pode ser criado e removido conforme a demanda. Estado durável deve ficar em banco, armazenamento ou serviço externo; memória e arquivos locais não podem ser tratados como fonte permanente.
Cada ambiente atende várias requisições
Uma Web Function pode processar múltiplas requisições concorrentes no mesmo ambiente. A AWS administra um limite dinâmico e permite definir maxConcurrencyPerEnvironment entre 1 e 128. O padrão é 64.
Cargas de entrada e saída, como APIs que aguardam banco ou serviço externo, podem aproveitar melhor um processo com várias requisições em voo. Enquanto uma chamada espera, outra usa a CPU. Aplicações intensivas em CPU podem sofrer contenção quando muitas requisições disputam os mesmos recursos.
O limite configurado é um teto, não uma promessa de que o ambiente sempre chegará a essa concorrência. A plataforma pode usar um valor dinâmico menor. A documentação de escalabilidade recomenda acompanhar latência, requisições simultâneas, ambientes ativos e throttling antes de alterar o padrão.
Essa diferença exige revisar código que assumia uma única requisição por processo. Variáveis globais mutáveis, clientes não seguros para concorrência e caches sem isolamento podem misturar dados. A aplicação deve ser tratada como servidor multiusuário desde o primeiro request.
Cobrança separa CPU ativa de memória
No AWS Lambda Web Functions, CPU é cobrada quando a aplicação e o runtime estão trabalhando ativamente. Uma requisição que aguarda banco de dados ou API externa consome pouca CPU nesse intervalo. A memória, porém, continua sendo medida durante toda a vida do ambiente, inclusive em períodos ociosos entre solicitações.
O modelo difere do Lambda Event Functions, em que a duração de cada invocação é uma unidade central da cobrança. Também difere de um contêiner permanentemente ligado, porque Web Functions pode remover ambientes quando não há tráfego.
Para estimar custo, não basta multiplicar requisições por duração. É necessário medir CPU ativa, memória configurada, quantidade e vida dos ambientes, concorrência, tráfego de saída e componentes colocados à frente do endpoint. Aplicações com muita memória e pouco tráfego podem acumular custo enquanto um ambiente permanece ativo; limites e escala a zero precisam ser observados em uso real.
Endpoint oferece HTTPS, limites e autenticação
Cada endpoint recebe domínio HTTPS com TLS. A equipe escolhe autenticação IAM ou autenticação administrada pela própria aplicação. Para domínio personalizado ou AWS WAF, a AWS orienta colocar uma distribuição CloudFront à frente da Web Function.
Dois controles ajudam a conter tráfego. rateLimit limita a taxa de chegada por endpoint e região. maxEnvironments limita quantos ambientes podem ficar ativos em cada região. Em conjunto, eles podem proteger bancos e APIs externas de uma escala maior do que conseguem suportar.
O teto documentado por endpoint é 10 mil requisições por segundo em cada região, sujeito também às cotas da conta. A capacidade aproximada depende da quantidade de ambientes multiplicada pela concorrência efetiva de cada um. Esse cálculo não substitui teste de carga, porque CPU, memória e dependências podem reduzir a concorrência útil.
Revisões imutáveis permitem canário
Web Functions organiza o código em revisões imutáveis. Um endpoint pode encaminhar tráfego a uma ou duas revisões, permitindo canário com pesos diferentes. A configuração reduz o risco de substituir todo o tráfego de uma vez e facilita retornar à versão anterior.
Canário precisa de observabilidade por revisão. Taxa de erro, latência e consumo devem ser separados para que a versão nova não fique escondida na média do endpoint. O princípio é o mesmo de ambientes de staging: uma etapa intermediária só reduz risco quando mede o comportamento que motivou sua existência.
Revisão imutável não inclui automaticamente a compatibilidade de banco, fila ou API externa. Mudanças de esquema precisam continuar tolerando versões simultâneas durante a transição.
Um endpoint pode distribuir tráfego entre regiões
A AWS oferece endpoints por região e endpoints multirregionais. No segundo caso, a plataforma usa roteamento por latência para escolher entre as regiões configuradas. O endpoint único simplifica o acesso global, mas a documentação descreve o direcionamento como melhor esforço.
Aplicação e dados precisam existir nas regiões escolhidas. Um servidor próximo do usuário perde vantagem se consultar um banco distante em toda requisição. Sessões, consistência, replicação, residência de dados e recuperação continuam sob responsabilidade da arquitetura.
Na estreia, o serviço foi anunciado nas regiões Leste dos EUA 1 e 2, Oeste dos EUA 2, Ásia-Pacífico Tóquio e Europa Irlanda. A disponibilidade deve ser reconfirmada antes de planejar produção, porque o conjunto de regiões pode mudar.
Suporte inicial é Node.js 24 em Arm64
O formato começou com runtime Node.js 24 e arquitetura Arm64. Aplicações Java, Python, .NET e outras linguagens permanecem em Event Functions ou podem usar Lambda MicroVMs conforme o caso. O Ponto Nulo detalhou esse outro formato em AWS Lambda MicroVMs para código de usuário e IA.
O uso de Node.js não garante compatibilidade automática. Dependências nativas precisam ter binários Arm64 ou ser compiladas para o ambiente. Aplicações que gravam no sistema de arquivos, mantêm processos auxiliares ou dependem de extensões específicas devem ser testadas dentro dos limites documentados.
Conexão a VPC é suportada por um network connector do Lambda. Acesso privado a bancos e serviços internos pode aumentar o caminho de rede e precisa ser medido. Segredos continuam fora do pacote e devem ser fornecidos por mecanismos apropriados de configuração e identidade.
Onde Web Functions se encaixa
Web Functions atende aplicações HTTP que querem o modelo serverless sem abandonar a estrutura de um servidor Node.js. APIs pequenas, backends de aplicações, streaming de resposta e serviços com tráfego variável são candidatos naturais. A ausência de adaptador reduz diferenças entre desenvolvimento local e execução.
Event Functions continuam adequadas quando o trabalho nasce de filas, arquivos, streams ou eventos gerenciados. Contêineres permanecem úteis para runtimes diferentes, processos duradouros e controle maior do ambiente. MicroVMs atendem execução isolada e estado retomável. A escolha depende do protocolo de entrada, ciclo de vida e perfil de carga.
Contratos HTTP continuam necessários em qualquer formato. Um documento OpenAPI ou JSON Schema separa a interface pública da plataforma usada para executá-la e facilita testes de compatibilidade.
O AWS Lambda Web Functions estava disponível nas cinco regiões anunciadas, com Node.js 24 em Arm64, endpoint HTTPS e escala até zero. Antes de migrar uma API, a equipe precisa validar concorrência no processo, dependências nativas, custo de memória ociosa, limites de downstream e comportamento multirregional.
