Cloudflare Workers ou AWS Lambda: custo, latência e cold start

Para uma API leve voltada a usuários distribuídos, Cloudflare Workers pode reduzir o caminho até a execução do código. AWS Lambda regional ganha força quando a função precisa de mais memória, depende de serviços da AWS ou ocupa a CPU por mais tempo. A escolha exige comparar a latência da requisição inteira e o custo da arquitetura: uma inicialização rápida, sozinha, não resolve nenhuma das duas contas.

A diferença central de cobrança depende do produto escolhido. No recorte desta comparação, Workers cobra requisições e tempo de CPU, enquanto Lambda Event Functions regional cobra requisições e duração ponderada pela memória configurada. Assim, uma função que passa parte da execução esperando uma API externa e outra que processa dados continuamente podem trocar de posição na fatura. Os três cenários abaixo são hipóteses reproduzíveis, não medições do mesmo código nas duas plataformas.

Premissas: produtos, franquias e custos fora da função

Na tabela de preços do Workers, o plano pago tem cobrança mínima de US$ 5 por mês e inclui 10 milhões de requisições e 30 milhões de milissegundos de CPU mensais. O excedente custa US$ 0,30 por milhão de requisições e US$ 0,02 por milhão de milissegundos de CPU. O tempo de espera por operações de rede não é cobrado como CPU, e não há tarifa adicional de transferência de dados do Workers; armazenamento e outros produtos usados pela aplicação têm preços próprios.

Nos preços do AWS Lambda, os exemplos de Event Functions em US East (N. Virginia) usam US$ 0,20 por milhão de requisições e US$ 0,0000166667 por GB-segundo, com franquia mensal de 1 milhão de requisições e 400 mil GB-segundos. A página distingue esse modelo de Lambda Web Functions e de Lambda@Edge: o exemplo de US$ 6,63 para 10 milhões de execuções de 10 ms é de Lambda@Edge e não serve como preço regional para as contas abaixo. Para Event Functions, transferências para fora da região podem gerar cobrança, assim como serviços adicionais.

Em cada cenário, suponha que as franquias mensais estejam integralmente disponíveis e que não haja concorrência provisionada. Os totais incluem apenas a execução das funções: uma API exposta por outro serviço, banco de dados, fila, armazenamento e tráfego tarifado precisam ser somados à parte. No Lambda, a duração hipotética abrange o tempo transcorrido da invocação; no Workers, o valor proposto representa CPU ativa. Essa diferença de unidade é essencial para reproduzir os cálculos.

Três cargas e suas contas mensais

API leve: Lambda custa menos na parcela da função

Considere, como hipótese, 10 milhões de chamadas mensais e 2 ms de CPU por chamada no Workers. O consumo soma 20 milhões de milissegundos de CPU; requisições e CPU ficam dentro das franquias do plano pago, resultando em US$ 5. Para Lambda Event Functions, suponha 128 MB de memória e 50 ms de duração por chamada. São 62.500 GB-segundos, cobertos pela franquia de computação, e 9 milhões de requisições cobradas após a franquia: US$ 1,80.

Mesmo se a conta AWS já tiver consumido suas franquias com outras funções, essa carga hipotética custaria cerca de US$ 3,04 em requisições e computação. O valor menor da função não determina a latência: a distância entre cliente e região, o serviço que entrega a API e o acesso aos dados também entram no tempo percebido pelo usuário. Executar código perto dele ajuda menos quando a resposta depende de um banco distante.

Função com dependências: a duração amplia a diferença

Mantenha as 10 milhões de chamadas, mas suponha autenticação, validação e dependências que resultem em 12 ms de CPU por chamada no Workers. O total de 120 milhões de milissegundos deixa 90 milhões acima da franquia: US$ 1,80 de excedente, somados aos US$ 5 do plano, ou US$ 6,80. No Lambda, a hipótese separada é de 512 MB e 200 ms por execução. O consumo chega a 1 milhão de GB-segundos; descontada a franquia, são US$ 10 de computação e US$ 1,80 de requisições, totalizando US$ 11,80.

Workers sai mais barato sob essas premissas, mas os tempos foram escolhidos para mostrar o efeito das fórmulas, não para atribuir o resultado a uma migração real. Uma dependência pode alterar a inicialização, o consumo de memória e até a possibilidade de executar a função no ambiente escolhido. Se ela consulta serviços da AWS, a latência de ida e volta e os custos desses serviços também pertencem à comparação da arquitetura.

Processamento prolongado: a ordem se inverte

Suponha 10 mil execuções mensais de uma tarefa que consuma 180 segundos de CPU em cada Worker e, em uma hipótese distinta, dure 180 segundos em uma Event Function Lambda configurada com 1 GB. Workers acumularia 1,8 bilhão de milissegundos de CPU: US$ 35,40 acima da franquia, mais US$ 5 de plano, ou US$ 40,40. Lambda acumularia 1,8 milhão de GB-segundos; descontada sua franquia, a computação custaria cerca de US$ 23,33, sem cobrança de requisições nesse volume.

O resultado depende de a tarefa caber nos limites de cada ambiente. Igualar os segundos na fórmula não significa que o mesmo trabalho terminará no mesmo tempo: memória disponível, CPU efetiva e implementação podem mudar a duração. Com a franquia de computação do Lambda já consumida, a parcela de execução desse cenário subiria para aproximadamente US$ 30.

Cold start e latência de ponta a ponta

AWS Lambda retém o ambiente por cerca de 300 a 360 segundos no estudo, enquanto Cloudflare Workers usa cache de código.

Uma medição acadêmica de ambientes serverless encontrou retenção do ambiente AWS Lambda por cerca de 300 a 360 segundos nas condições do experimento e descreveu mecanismos diferentes: congelamento do ambiente no Lambda e cache de código no Cloudflare Workers. A observação ajuda a explicar por que chamadas após inatividade podem encontrar inicialização; não prevê o atraso de uma aplicação específica nem fornece uma comparação direta de latência final entre as duas cargas aqui calculadas.

Para uma API, o tempo relevante começa na requisição do cliente e termina na resposta. Inicialização, execução, rede e acesso a dependências podem dominar etapas diferentes; a mediana pode ainda esconder atrasos nas chamadas após inatividade ou durante picos de concorrência. Uma função pequena próxima dos usuários tende a aproveitar melhor a distribuição do Workers. Quando os dados permanecem numa região da AWS, o trajeto até eles pode reduzir essa vantagem, mesmo que o código comece a executar rapidamente.

Limites, memória e integração mudam a escolha

Limites de memória e execução diferem entre Cloudflare Workers e AWS Lambda.

Os limites do Workers fixam 128 MB de memória por isolate e, no plano pago, até 5 minutos de CPU por requisição HTTP, com limite padrão de 30 segundos que pode ser aumentado. A espera por rede não consome esse orçamento de CPU. Uma requisição HTTP pode continuar enquanto o cliente permanecer conectado, mas a tarefa hipotética de 180 segundos de CPU exigiria elevar o limite padrão e permanecer dentro da memória disponível.

As cotas do Lambda permitem configurar de 128 MB a 10.240 MB de memória e estabelecem 15 minutos como duração máxima de uma invocação comum; a CPU alocada cresce com a memória configurada. Isso amplia o espaço para funções que mantêm mais dados em memória ou executam bibliotecas pesadas. Em fluxos ligados a eventos de S3 ou filas SQS, a integração pode simplificar o desenho, embora as operações desses serviços continuem fora dos totais calculados.

Para APIs leves e cargas que passam boa parte do tempo aguardando I/O, Workers merece avaliação especial pela execução distribuída e pela cobrança de CPU. Para tarefas com maior exigência de memória, processamento prolongado ou dependência estreita de serviços da AWS, Lambda Event Functions regional pode ser mais adequado. Os três exemplos mostram a consequência prática: com as mesmas regras de franquia, o menor custo da função passa de Lambda para Workers e volta a Lambda conforme a carga muda. A decisão de produção exige acrescentar rede, dados e serviços auxiliares à fatura e observar a latência da operação completa.