Lambda Web Functions: concorrência HTTP muda o desenho antes de mudar a conta

A AWS anunciou Lambda Web Functions para executar aplicações HTTP sem reescrevê-las como handlers de eventos, inicialmente com Node.js 24 em Arm64.[5] Cada ambiente aceita até 128 requisições concorrentes e usa cobrança por CPU ativa, embora a memória continue sendo medida durante a existência do ambiente.[5] O anúncio merece atenção, mas eu começaria pela mudança de concorrência, não pela promessa de economia.

O que muda para quem desenvolve

Servidores com Express, Hono, Fastify e Next.js aparecem entre os exemplos; a adaptação demonstrada lê o endereço de escuta em AWS_LAMBDA_HTTP_ENDPOINT.[5] A AWS diferencia Web Functions das Event Functions, nome descritivo das funções tradicionais, que processam uma requisição por vez em cada ambiente e cobram tempo de parede.[5]

Minha leitura é que a familiaridade com um servidor HTTP reduz uma parte da adaptação, mas não encerra o trabalho de arquitetura. Eu revisaria variáveis compartilhadas, pools de conexão, limites de dependências e cancelamento. Se várias requisições convivem no mesmo processo, o aceite deve demonstrar que os dados de uma não aparecem na outra e que uma chamada lenta não monopoliza os recursos disponíveis.

O serviço publica revisões imutáveis e permite distribuir tráfego entre elas; a implantação multirregional oferece uma URL global com roteamento por menor latência em regime de melhor esforço.[5] Eu usaria essas capacidades para reduzir o risco da mudança, sem presumir que replicar código também resolve a localização dos dados.

Como aplicar

Escolha um endpoint Node.js pequeno e representativo, preferencialmente com espera por banco ou API. Defina um teste comparativo com a implantação atual: mesma resposta, mesma dependência, mesmo volume e a mesma distribuição de requisições. Não simule toda espera com um temporizador se o problema real depende de conexões e limites de um serviço externo.

Meça latência, erros, CPU, memória e conexões abertas durante diferentes níveis de concorrência. Para streaming, inclua cliente que abandona a resposta e dependência que demora além do prazo. Registre o consumo associado à execução inteira, não somente ao trecho de processamento principal.

Use uma revisão nova com tráfego limitado antes de ampliar a exposição. A demonstração da AWS apresenta distribuição 90%/10% entre revisões.[5] Estabeleça previamente qual taxa de erro ou regressão de latência interrompe o experimento.

Se houver CloudFront, o anúncio também descreve Origin Access Control para restringir o endpoint à distribuição autorizada.[5] Avalie essa configuração separadamente da autenticação dos usuários da aplicação.

Cuidados e limites

A disponibilidade inicial cobre Norte da Virgínia, Ohio, Oregon, Tóquio e Irlanda; Python e Java não aparecem como runtimes iniciais.[5] Não planeje migração direta de FastAPI ou Quarkus com base nesse lançamento.

A publicação não apresenta benchmark independente nem preço final suficiente para garantir economia em qualquer aplicação.[5] Meu critério seria custo por requisição útil dentro do objetivo de latência, incluindo memória e dependências. Um modelo de cobrança diferente é uma hipótese a medir, não uma redução já comprovada.

Fonte

[5] Fonte: AWS News Blog