Back to blog
Cloud & DevOps

Cloudflare Workers vs AWS Lambda: A Practical Comparison in 2026

Bruno Bracaioli
Cloudflare Workers vs AWS Lambda: A Practical Comparison in 2026

Two worlds of "serverless"

AWS Lambda invented modern serverless functions in 2014. Cloudflare Workers arrived in 2017 with a radically different approach: running JavaScript at the edge using V8 isolates instead of containers. In 2026, both have matured and cover similar use cases — but the technical and pricing differences are still huge. Let's compare where it matters.

Execution model

AWS Lambda

  • Each function runs in a micro-VM (Firecracker).
  • Cold start of 100ms to 2s depending on runtime, bundle size and VPC.
  • Supports runtimes: Node.js, Python, Java, Go, Ruby, .NET, custom (any container).
  • Memory configurable from 128 MB to 10 GB. CPU scales with memory.
  • Max timeout: 15 minutes.

Cloudflare Workers

  • Each function runs in a V8 isolate inside the same Worker runtime process.
  • Cold start: < 5 ms (literally imperceptible).
  • Supports JavaScript, TypeScript, and anything that compiles to WebAssembly (Rust, Go, C++).
  • Memory: 128 MB fixed. CPU time: 50ms (free) or up to 5 minutes (paid Workers Unbound in 2026).
  • No support for native runtimes like Java/JVM or interpreted Python (Pyodide via WASM exists, but it's heavy).

The fundamental difference: Lambda is a container that spins up and down. A Worker is an isolate that always exists, in all 300+ Cloudflare POPs globally.

Geographic latency

This is Workers' biggest differentiator. Instead of running in one region (us-east-1), they run in every Cloudflare data center. A user in Curitiba hits the Worker running in Curitiba — not in Virginia.

| User location | Lambda (us-east-1) | Workers | |---|---|---| | São Paulo | ~150ms RTT | ~5ms RTT | | Lisbon | ~120ms RTT | ~10ms RTT | | Tokyo | ~180ms RTT | ~10ms RTT |

For APIs that respond in < 50ms, this is the difference between "fast" and "instant".

Lambda also has Lambda@Edge and CloudFront Functions, but limitations are severe (no external calls in CloudFront Functions, slow deploy in Lambda@Edge).

Pricing

AWS Lambda

  • $0.20 per 1M requests
  • $0.0000166667 per GB-second of execution
  • Free tier: 1M requests + 400k GB-seconds per month

Cloudflare Workers

  • Free: 100k requests/day
  • Paid (Workers Standard): $5/month includes 10M requests + 30M CPU ms. Above: $0.30 per 1M requests, $0.02 per 1M CPU ms

For small to medium workloads, Workers tends to be 3-10x cheaper. For workloads using lots of CPU or memory, Lambda may be more predictable.

Practical limits

| Limit | Lambda | Workers | |---|---|---| | Code size | 250 MB (zipped) | 10 MB (free) / 15 MB (paid) | | Memory | 128 MB - 10 GB | 128 MB | | CPU time | 15 min wall clock | 50ms - 5min CPU time | | Subrequests per invocation | unlimited | 50 (free) / 1000 (paid) | | Environment variables | 4 KB total | no practical limit | | Cold start | 100ms-2s | < 5ms |

Workers' 10 MB bundle limit hurts. You can't run Puppeteer, Sharp, or any heavy SDK. You have to use WASM alternatives or external services.

Data stack

Lambda + AWS ecosystem

  • DynamoDB, RDS, Aurora Serverless, S3, SQS, EventBridge, Step Functions...
  • Deep integration, but DynamoDB call latency from Lambda in VPC can be 20-50ms.
  • IAM and VPC add complexity.

Workers + Cloudflare ecosystem

  • Workers KV (eventually consistent key-value, sub-ms reads)
  • D1 (distributed serverless SQLite, recently in GA)
  • R2 (S3-compatible, no egress fees)
  • Durable Objects (consistent per-key state)
  • Queues, Pub/Sub, Vectorize (vector DB for AI)
  • Hyperdrive (connection pool for external Postgres)

For apps living 100% on Cloudflare, internal latency is absurdly low. Workers + D1 + R2 serves small to medium SaaS with performance Lambda + RDS will never reach.

Developer experience

Lambda: SAM, Serverless Framework, AWS CDK, Terraform. Deploy takes 30s to several minutes. Logs in CloudWatch (paid, slow). Local debugging is awkward.

Workers: Wrangler CLI. Deploy in 2-5 seconds. Real-time logs in the terminal. wrangler dev runs locally with near-total feature parity. Simpler, faster environment to iterate in.

When to pick each

Go with Lambda if...

  • You're already in the AWS ecosystem with RDS, S3, IAM set up.
  • You need runtimes Workers doesn't support (Java, .NET, heavy interpreted Python).
  • Bundle > 10 MB is unavoidable (FFmpeg, Puppeteer, large ML models).
  • Workload has heavy long-running processing (15 min wall clock).
  • Compliance requires everything in a specific region (e.g., data in São Paulo only).

Go with Workers if...

  • Edge latency matters (chat, global public APIs, games, finance).
  • You want to pay pennies for small workloads.
  • Cloudflare frontend stack (Pages, R2, KV, D1).
  • Small team that values DX and fast iteration.
  • 1s cold start is unacceptable (mobile apps, critical APIs).

The honest take

For new web projects in 2026, Cloudflare Workers is the default choice if your stack fits within the limits. It's cheaper, faster, simpler. Lambda remains unbeatable for workloads inside the established AWS ecosystem, heavy ML inference, or cases where Workers' limits are a real blocker.

It's not a religious choice. Use both if it makes sense. What matters is understanding the trade-offs and not falling for either side's marketing.

Compartilhar:

Fique por dentro

Receba novos artigos sobre IA, desenvolvimento e tecnologia direto no seu email.