Overview
Workers and Lambda are both serverless functions, but they are built on different execution models. Workers runs code in V8 isolates inside every Cloudflare location, so a request is handled near the user and isolates start fast enough that cold starts are rarely a design concern. Lambda runs each function in a Firecracker microVM inside one AWS region, which buys far more memory, longer execution, broad language support, and direct access to resources in a VPC. The choice follows the workload shape more than the vendor. For the wider platform decision, see aws-vs-cloudflare.
When Workers wins
Choose Workers when the function is short, runs on every request, and benefits from being close to the user.
- Latency-sensitive request handling: auth checks, redirects, header rewrites, A/B bucketing, geolocation routing, and API gateways in front of an origin.
- Global by default: one deploy runs in every Cloudflare location. Lambda runs in the regions you deploy to; Lambda@Edge replicates to CloudFront regional edge caches but supports fewer runtimes and tighter limits.
- Billing on CPU time: Workers bills requests plus CPU time, so time spent waiting on a slow upstream fetch costs little. Lambda bills wall-clock duration multiplied by configured memory.
- Edge storage bindings: KV, R2, D1, Durable Objects, and Queues attach to a Worker as bindings without network configuration. See cloudflare-kv and cloudflare-r2.
When Lambda wins
Choose Lambda when the function is heavy, long, or needs to live next to AWS resources.
- Memory and duration: Lambda allows up to 10,240 MB of memory and a 15-minute timeout. A Worker isolate has 128 MB of memory and a CPU-time limit (30 seconds by default on paid plans, configurable up to 5 minutes).
- Runtimes: Lambda supports Node.js, Python, Java, .NET, Ruby, custom runtimes, and container images. Workers is JavaScript, TypeScript, and Wasm first, with Python support still maturing.
- VPC access: Lambda functions can attach to a VPC and reach RDS, ElastiCache, or internal services directly. A Worker reaches private resources through Cloudflare Tunnel or Hyperdrive instead.
- Event sources: Lambda is the native handler for S3 events, DynamoDB streams, SQS, EventBridge, and Kinesis.
Trade-offs at a glance
| Dimension | Cloudflare Workers | AWS Lambda |
|---|---|---|
| Execution model | V8 isolates | Firecracker microVMs |
| Placement | Every Cloudflare location | Chosen AWS regions |
| Memory | 128 MB per isolate | 128 MB to 10,240 MB |
| Time limit | CPU-time limit, up to 5 min | Up to 15 min wall clock |
| Billing basis | Requests plus CPU time | Requests plus duration times memory |
| Languages | JS, TS, Wasm; Python maturing | Node, Python, Java, .NET, Ruby, containers |
| Private networks | Tunnel, Hyperdrive | Native VPC attachment |
Migration cost
Porting from Lambda to Workers is a rewrite of the handler, not a redeploy.
- Rewrite each handler to the Workers
fetchAPI. Enable thenodejs_compatflag for Node.js built-ins; dependencies with native modules must be replaced. - Split work that exceeds the CPU or memory limits into Queues or Durable Objects, or leave it on Lambda.
- Replace direct VPC access with Hyperdrive for databases or Cloudflare Tunnel for internal services.
Recommendation
- Request middleware, edge redirects, personalization, and API gateways: Workers.
- Image, video, or ML jobs that need gigabytes of memory or minutes of runtime: Lambda.
- Functions triggered by AWS events or bound to a VPC database: Lambda.
- A new app on Cloudflare’s storage primitives: Workers end to end, with Lambda only for the heavy jobs.