Dois mundos de "serverless"
AWS Lambda inventou o conceito moderno de função serverless em 2014. Cloudflare Workers chegou em 2017 com uma abordagem radicalmente diferente: rodar JavaScript em edge usando V8 isolates em vez de containers. Em 2026, ambos amadureceram e cobrem casos de uso parecidos — mas as diferenças técnicas e de custo continuam grandes. Vamos comparar onde importa.
Modelo de execução
AWS Lambda
- Cada função roda num micro-VM (Firecracker).
- Cold start de 100ms a 2s dependendo do runtime, do tamanho do bundle e da VPC.
- Suporta runtimes: Node.js, Python, Java, Go, Ruby, .NET, custom (qualquer container).
- Memória configurável de 128 MB a 10 GB. CPU escala junto com memória.
- Timeout máximo: 15 minutos.
Cloudflare Workers
- Cada função roda num V8 isolate dentro do mesmo processo do Worker runtime.
- Cold start: < 5 ms (literalmente imperceptível).
- Suporta JavaScript, TypeScript, e qualquer coisa que compile pra WebAssembly (Rust, Go, C++).
- Memória: 128 MB fixo. CPU time: 50ms (free) ou até 5 minutos (paid Workers Unbound em 2026).
- Sem suporte a runtimes nativos como Java/JVM ou Python interpretado (existe Pyodide via WASM, mas é pesado).
A diferença fundamental: Lambda é um container que sobe e desce. Worker é um isolate que existe sempre, em todas as 300+ POPs da Cloudflare globalmente.
Latência geográfica
Esse é o maior diferencial dos Workers. Em vez de rodar numa região (us-east-1), eles rodam em todos os data centers da Cloudflare. Um usuário em Curitiba acessa o Worker que tá rodando em Curitiba — não em Virginia.
| Localização do usuário | Lambda (us-east-1) | Workers | |---|---|---| | São Paulo | ~150ms RTT | ~5ms RTT | | Lisboa | ~120ms RTT | ~10ms RTT | | Tokyo | ~180ms RTT | ~10ms RTT |
Pra APIs que respondem em < 50ms, isso é a diferença entre "rápido" e "instantâneo".
Lambda também tem Lambda@Edge e CloudFront Functions, mas as limitações são severas (sem chamadas externas em CloudFront Functions, deploy lento em Lambda@Edge).
Preço
AWS Lambda
- $0.20 por 1M requests
- $0.0000166667 por GB-segundo de execução
- Free tier: 1M requests + 400k GB-segundos por mês
Cloudflare Workers
- Free: 100k requests/dia
- Paid (Workers Standard): $5/mês inclui 10M requests + 30M CPU ms. Acima: $0.30 por 1M requests, $0.02 por 1M CPU ms
Pra workloads pequenos a médios, Workers tende a ser 3-10x mais barato. Pra workloads que usam muita CPU ou memória, Lambda pode ser mais previsível.
Limites práticos
| Limite | Lambda | Workers | |---|---|---| | Tamanho do código | 250 MB (zipped) | 10 MB (free) / 15 MB (paid) | | Memória | 128 MB - 10 GB | 128 MB | | CPU time | 15 min wall clock | 50ms - 5min CPU time | | Subrequests por invocation | ilimitado | 50 (free) / 1000 (paid) | | Variáveis de ambiente | 4 KB total | sem limite prático | | Cold start | 100ms-2s | < 5ms |
O limite de 10 MB de bundle dos Workers dói. Você não roda Puppeteer, Sharp, ou qualquer SDK pesado. Tem que usar alternativas WASM ou serviços externos.
Stack de dados
Lambda + ecosistema AWS
- DynamoDB, RDS, Aurora Serverless, S3, SQS, EventBridge, Step Functions...
- Integração profunda, mas latência de chamada de DynamoDB de Lambda em VPC pode ser 20-50ms.
- IAM e VPC adicionam complexidade.
Workers + ecosistema Cloudflare
- Workers KV (key-value eventually consistent, leitura sub-ms)
- D1 (SQLite serverless distribuído, ainda em GA recente)
- R2 (S3-compatible, sem egress fees)
- Durable Objects (estado consistente por chave)
- Queues, Pub/Sub, Vectorize (DB vetorial pra IA)
- Hyperdrive (pool de conexões pra Postgres externo)
Pra apps que vivem 100% na Cloudflare, a latência interna é absurdamente baixa. Workers + D1 + R2 atende SaaS de pequeno e médio porte com performance que Lambda + RDS jamais alcança.
Developer experience
Lambda: SAM, Serverless Framework, AWS CDK, Terraform. Deploy demora 30s a vários minutos. Logs no CloudWatch (pago, lento). Debug local complicado.
Workers: Wrangler CLI. Deploy em 2-5 segundos. Logs em tempo real no terminal. wrangler dev roda localmente com feature parity quase total. Ambiente mais simples e rápido pra iterar.
Quando escolher cada um
Vá de Lambda se...
- Você já está no ecosistema AWS e tem RDS, S3, IAM configurados.
- Precisa rodar runtimes que Workers não suporta (Java, .NET, Python interpretado pesado).
- Bundle > 10 MB inevitável (FFmpeg, Puppeteer, modelos ML grandes).
- Workload com muito processamento de longa duração (15 min wall clock).
- Compliance exige tudo numa região específica (ex: dados em São Paulo apenas).
Vá de Workers se...
- Latência de borda importa (chat, APIs públicas globais, jogos, finanças).
- Quer pagar centavos pra workloads pequenos.
- Stack frontend Cloudflare (Pages, R2, KV, D1).
- Time pequeno que valoriza DX e iteração rápida.
- Cold start de 1s é inaceitável (apps mobile, APIs críticas).
A real
Pra novos projetos web em 2026, Cloudflare Workers é a escolha padrão se o seu stack couber nos limites. É mais barato, mais rápido, mais simples. Lambda continua imbatível pra workloads dentro do ecosistema AWS estabelecido, ML inference pesado, ou casos onde os limites de Workers são um bloqueio real.
Não é uma escolha religiosa. Use os dois se fizer sentido. O importante é entender as trade-offs e não cair no marketing de nenhum dos dois.
