O blog da AWS

Explore o AWS Lambda Web Functions para criar aplicações web

Por Julian Wood, Kim Wendt e Samrat Karak, na Amazon Web Services.

Agora você pode executar um servidor web Node.js padrão no AWS Lambda com o Lambda Web Functions, um novo tipo de função do Lambda. Faça a implantação com um único comando ou com o AWS CloudFormation e obtenha um endpoint HTTPS público, sem camada de adaptação e sem servidores ou load balancers para gerenciar.

O Lambda Web Functions é adequado para aplicações web com renderização no lado do servidor, APIs REST e GraphQL, endpoints de streaming e microsserviços. Com base no anúncio de lançamento, esta publicação usa uma aplicação de exemplo para mostrar como um único ambiente de execução lida com muitas solicitações ao mesmo tempo e como a mesma aplicação atende a um público global. Você também verá como a cobrança por CPU ativa mantém o custo baixo enquanto seu código aguarda, com memória e solicitações cobradas separadamente.

Visão geral

O Lambda foi lançado em 2014 com um modelo mínimo: você envia seu código e o serviço gerencia todo o resto. Por mais de uma década, esse código foi executado como um event handler, invocado uma vez por evento, como um lote de mensagens de uma fila ou um objeto que chega ao Amazon Simple Storage Service (Amazon S3). Agora chamamos isso de Event Function, que continua sendo a escolha certa para cargas de trabalho orientadas a eventos.

As Web Functions são um segundo tipo de função do Lambda, executadas no mesmo isolamento baseado em Firecracker das Event Functions. Em vez de um handler que recebe um evento, seu código é executado como um servidor HTTP padrão que escuta em uma porta, o que permite que um framework web, ou, neste caso, um servidor Node.js simples, seja executado sem modificações.

Uma Web Function é composta por três recursos:

  • Web Function é o recurso de nível superior, com um nome e uma configuração.
  • Revisão é um snapshot imutável do seu código e da sua configuração, que o Lambda cria sempre que você implanta código ou altera a configuração da revisão, para que você possa fazer rollback direcionando o tráfego para uma revisão anterior.
  • Endpoint é um ponto de entrada de rede com um domínio HTTPS exclusivo, um tipo de autenticação e as regras que direcionam o tráfego para suas revisões.

No momento do lançamento, as Web Functions executam Node.js 24 em Arm64, com 2 vCPUs e 2 GB de memória por ambiente de execução. As Web Functions oferecem suporte à conectividade com a Amazon Virtual Private Cloud (VPC), permitindo que sua função acesse recursos existentes dentro de uma VPC.

Passo a passo

Frameworks Node.js que iniciam um servidor HTTP, como Express, Fastify e Hono, são executados sem adaptadores. O Next.js no modo standalone precisa de um pequeno index.js que defina seu host e sua porta. Esta publicação usa um servidor Node.js simples para evitar dependências.

O código-fonte completo está disponível na coleção Serverless Patterns, juntamente com outros padrões de Web Functions.

Pré-requisitos

Você precisa de uma conta da AWS com a AWS Command Line Interface (AWS CLI) instalada e configurada e o Node.js instalado localmente.

As instruções do padrão mostram como clonar o repositório e acessar o diretório do padrão, ou baixar o arquivo .zip do padrão para executar o exemplo.

A aplicação

O dashboard é um único servidor HTTP Node.js que transmite métricas do servidor em tempo real para o navegador por meio de server-sent events (SSE).

O runtime fornece o endereço em que o servidor deve escutar na variável de ambiente AWS_LAMBDA_HTTP_ENDPOINT, no formato host:port. O servidor lê esse valor e começa a escutar, exatamente como faria em qualquer outro lugar:

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

O runtime é nodejs24.x e, por padrão, carrega o index.js na raiz do pacote. Para usar um arquivo de entrada diferente, defina AWS_LAMBDA_NODEJS_ENTRYPOINT com o caminho dele.

Execução local

Você pode executar o servidor localmente com npm start.

Acesse http://localhost:3000/ para ver o dashboard transmitindo dados do servidor local.

Implantação

  1. Faça a implantação usando um único comando: 
    aws lambda-web deploy --name lambda-web-sse-dashboard --code .

    Neste exemplo, você também pode usar npm run deploy, definido no arquivo package.json.

A AWS CLI empacota seu código e cria a função e um endpoint chamado dev com uma URL HTTPS ativa. Ela também cria um perfil de execução e um bucket do S3 com versionamento, caso ainda não exista, que é compartilhado por todas as Web Functions implantadas pela CLI na Região.

  1. Pressione Enter para criar os recursos.

A saída da AWS CLI mostra a URL no formato: https://<id>.<shard>.lambda-web.<region>.on.aws

Saída do terminal da AWS CLI para o comando aws lambda-web deploy, mostrando a função criada e a URL do endpoint HTTPS ativo

Figura 1: AWS CLI mostrando o comando aws lambda-web deploy.

Acesse a URL e o dashboard será carregado, já transmitindo dados. Esse endpoint é público e o exemplo não tem autenticação, portanto use-o apenas para avaliação e exclua-o quando terminar.

Dashboard de streaming no navegador mostrando informações da função em tempo real, incluindo o tempo de atividade do ambiente e a contagem de conexões abertas

Figura 2: O dashboard de streaming da aplicação mostrando informações da função.

O dashboard mostra há quanto tempo o ambiente de execução está ativo e quantas conexões de streaming ele mantém abertas. Ele mostra quanta CPU foi usada, com um botão para gerar carga real de CPU sob demanda. A função é executada na Região Leste dos EUA (Norte da Virgínia) (us-east-1). Do meu laptop no Reino Unido, a latência é de 90 ms.

O dashboard é atualizado a cada dois segundos por meio de uma única resposta HTTP de streaming. O ambiente de uma Web Function é um processo de longa duração, portanto ele mantém a conexão aberta e continua enviando dados ao navegador. O processo de longa duração também pode executar tarefas em segundo plano fora do caminho principal da solicitação, como emitir eventos de telemetria.

O ambiente de uma Event Function atende a uma solicitação por vez. Ele pode transmitir uma resposta durante uma invocação, mas cada stream aberto ocupa um ambiente inteiro. O Lambda congela o ambiente entre as invocações, então o trabalho em segundo plano é interrompido.

Cobrança por CPU ativa

Se o ambiente permanece ativo por minutos seguidos, pelo que você está pagando? Você paga por solicitações, pela memória consumida e pelo tempo de CPU que o ambiente consome. Neste exemplo, compare o tempo de atividade da conexão com o tempo de CPU. O ambiente continua em execução, mas usa apenas uma fração de segundo de CPU.

Escolha Generate CPU load e a aplicação executa um loop de hash criptográfico por cerca de 1,5 segundo. O tempo de CPU sobe no gráfico e depois cai para perto de zero quando o trabalho termina. Quando uma solicitação espera por um banco de dados, uma API downstream ou uma inferência de IA, seu código usa pouca CPU, então a espera custa menos do que custaria com a cobrança por tempo real (wall-clock).

Gráfico de CPU do dashboard mostrando um pico no tempo de CPU após escolher Generate CPU load, voltando depois para perto de zero

Figura 3: Gráfico de CPU no meio do pico após escolher Generate CPU load.

Para obter detalhes sobre preços, leia a página de preços do AWS Lambda.

Simultaneidade e escalabilidade horizontal

Com as Web Functions, cada ambiente de execução lida com muitas solicitações ao mesmo tempo, e não uma por vez. À medida que os ambientes se aproximam do limite de simultaneidade, o Lambda adiciona mais ambientes e os remove novamente quando o tráfego diminui.

Você pode controlar como uma Web Function escala. maxConcurrencyPerEnvironment define o número máximo de solicitações que cada ambiente de execução processa ao mesmo tempo, até 128, com padrão de 64. No endpoint, maxEnvironments limita o número de ambientes de execução e rateLimit limita as solicitações por segundo. Você pode usar essas duas configurações para proteger dependências downstream, como bancos de dados e APIs externas. Ambas se aplicam em cada Região atendida pelo endpoint, e maxEnvironments se aplica a cada revisão. As solicitações acima de um limite recebem HTTP 429 e não são colocadas em fila.

Gere carga na aplicação. Envie 300 solicitações de streaming ao endpoint /api/events, com até 200 abertas ao mesmo tempo, em vez de uma rajada de respostas rápidas.

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

Dashboard mostrando muitas conexões SSE simultâneas mantidas abertas por um único ambiente de execução durante o teste de carga

Figura 4: Simultaneidade mostrando o aumento de conexões em um único ambiente de execução.

O dashboard é atualizado para refletir as conexões SSE ativas e o pico do ambiente de execução atualmente conectado.

O runtime também grava um registro de resumo por ambiente no Amazon CloudWatch Logs a cada minuto, com o ID da instância, a contagem de solicitações, o pico de simultaneidade e o tempo de CPU. Uma consulta do CloudWatch Logs Insights agrega esses registros em toda a frota:

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"

Em uma execução de exemplo com 300 solicitações de streaming e até 200 abertas ao mesmo tempo, os logs mostraram o seguinte:

  • Ambientes de execução usados: 5.
  • Total de solicitações processadas: 484.
  • Pico de simultaneidade em um único ambiente: 59.
  • Total de CPU consumida em toda a frota: 4,75 segundos.

Um ambiente atingiu o pico de 59 conexões, próximo ao limite padrão de 64. O Lambda adiciona ambientes antes que os existentes atinjam o limite, então essa carga usou cinco. As Event Functions atendem a uma solicitação por ambiente, portanto 200 streams abertos exigiriam até 200 ambientes. Em 484 solicitações, toda a frota usou cerca de 4,8 segundos de CPU.

Cada ambiente informa apenas suas próprias conexões, porque o Lambda roteia cada solicitação de forma independente, sem afinidade de sessão.

Expansão para várias Regiões

A mesma aplicação pode atender cada usuário a partir da Região com a menor latência. Como o tipo e as Regiões de um endpoint são fixados quando ele é criado, ir para o modo global significa adicionar um novo endpoint:

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

Saída do terminal da AWS CLI criando um endpoint global multi-Região e confirmando a replicação para uma segunda Região

Figura 5: AWS CLI criando um endpoint global.

O Lambda replica seu código e a configuração da revisão, incluindo variáveis de ambiente, para cada Região e centraliza os logs na Região de origem. Neste caso, o Lambda replica para a Região Europa (Londres) (eu-west-2). Ele fornece uma única URL de domínio global e usa o roteamento baseado em latência do Amazon Route 53 para enviar cada solicitação à Região com a menor latência.

Acesse a nova URL global, que agora está no formato: https://<domain>.lambda-web.global.on.aws

Dashboard da aplicação servido pela Região mais próxima por meio do endpoint global, mostrando menor latência para o usuário local

Figura 6: O dashboard da aplicação mostrando o roteamento para a Região local.

Do meu laptop no Reino Unido, a solicitação é roteada para eu-west-2 (Londres) em 16 ms, enquanto o endpoint de Região única em us-east-1 respondeu em 90 ms. Essas são medições isoladas feitas em um único local, não um benchmark. Cada solicitação vai para a Região com a menor latência para o usuário por meio da mesma URL. O Lambda gerencia o roteamento de DNS, portanto não há load balancers nem registros do Route 53 para configurar.

Autenticação e execução atrás do Amazon CloudFront

Cada endpoint tem um tipo de autenticação que você pode alterar sem reimplantar o código.

Com ApplicationManaged, o endpoint é público e seu código gerencia a autenticação (OAuth, JWT, um cookie de sessão ou o Amazon Cognito). Os administradores podem impedir endpoints públicos em toda a organização com uma política de controle de serviço que use a chave de condição lambda:Request/WebFunctionAuthType.

Com IamAuth, o Lambda valida cada solicitação com o AWS Signature Version 4 (SigV4) para endpoints de Região única e com o SigV4a para endpoints multi-Região. Somente chamadores com a permissão lambda:InvokeWebFunctionEndpoint chegam à sua aplicação, o que é adequado para APIs de serviço para serviço. Os endpoints são sempre acessíveis pela internet pública, e o IamAuth controla quem pode invocá-los.

Os endpoints usam um domínio fornecido pelo Lambda. Para um domínio personalizado, cache de borda e o AWS WAF, coloque o Amazon CloudFront na frente do endpoint. Use o IamAuth com controle de acesso à origem para que o domínio do Lambda não possa contornar o CloudFront, que ainda repassa ao seu código o cabeçalho Authorization da própria aplicação.

Crie com um agente

Como a implantação é um único comando aws lambda-web deploy e o código é um servidor HTTP comum, você pode criar a estrutura, desenvolver e implantar uma aplicação a partir de um prompt usando os skills da AWS para agentes de codificação. O Agent Toolkit for AWS inclui o Web Functions.

Limpeza

Para remover os recursos padrão criados pelo comando aws lambda-web deploy, consulte as instruções de limpeza no repositório.

Conclusão

O AWS Lambda Web Functions leva o modelo operacional Serverless para aplicações web sem camadas de adaptação. Você escreve um servidor HTTP Node.js padrão, o implanta com um único comando ou com o CloudFormation e obtém um endpoint HTTPS escalável, com pagamento por uso e roteamento global integrado. Implante a aplicação de exemplo da coleção Serverless Patterns, juntamente com outros padrões de Web Functions. Leia a documentação do Lambda Web Functions para se aprofundar e consulte o roadmap do Lambda.

Para mais recursos de aprendizado sobre Serverless, visite o Serverless Land.

Este conteúdo foi traduzido da publicação original do blog, que pode ser encontrada aqui.

Autores

Julian Wood é Principal Developer Advocate na Amazon Web Services.
Kim Wendt é Arquiteta de Soluções Sênior na Amazon Web Services.
Samrat Karak é Principal Product Manager, Técnico na Amazon Web Services.

Tradutores

Daniel Abib é Arquiteto de Soluções Sênior e Especialista em Amazon Bedrock na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e especialização em Machine Learning. Ele trabalha apoiando Startups, ajudando-os em sua jornada para a nuvem.
https://www.linkedin.com/in/danielabib/
Rodrigo Peres é Arquiteto de Soluções na AWS, com mais de 20 anos de experiência trabalhando com arquitetura de soluções, desenvolvimento de sistemas e modernização de sistemas legados.