Cloudflare Workers vs AWS Lambda: When Edge Beats Centralized
Edge runtimes and traditional FaaS overlap less than the marketing suggests. Workload shape, data geography, and cold starts decide for you.
The “Workers vs Lambda” framing makes them sound like substitutes. They aren’t, really. Cloudflare Workers is an edge runtime that executes JavaScript / WASM globally within milliseconds of cold start. AWS Lambda is a traditional FaaS that runs arbitrary languages in regional data centers with much more flexibility and much higher cold-start latency. Both have legitimate cases, and the choice is dominated by the shape of the workload more than by raw performance.
We’ve shipped both in production for client work — Workers for API edge routing and personalization, Lambda for batch processing and traditional API backends. Here’s how the decision actually plays out.
What they actually are#
- Cloudflare Workers runs your code on Cloudflare’s edge network (300+ cities), inside a V8 isolate (not a container). Cold starts measured in single-digit milliseconds. The runtime is JavaScript / TypeScript / WebAssembly, with some constraints (no arbitrary native code).
- AWS Lambda runs your code in regional data centers, inside an isolated execution environment (Firecracker microVM). Cold starts: 100-500ms for warm runtimes (Node, Python), seconds for cold container starts. The runtime is anything you can package (Node, Python, Go, Rust, Java, .NET, custom container).
The runtime model is the deepest difference. V8 isolates start in microseconds because they’re not full processes; they’re V8 contexts inside a long-running process. Lambda’s Firecracker microVMs give you full process isolation and arbitrary code, at the cost of cold-start latency.
What’s actually different#
| Dimension | Cloudflare Workers | AWS Lambda |
|---|---|---|
| Runtime | V8 isolates (JS/TS/WASM) | Firecracker microVM (any language) |
| Cold start | ~5 ms | 100 ms - 5 s |
| Latency from user | ~10-30 ms anywhere | 50-300 ms (region-dependent) |
| Max execution time | 30 s (CPU time) | 15 minutes |
| Memory | 128 MB | 128 MB - 10 GB |
| Native libraries | Limited (WASM only) | Anything |
| State store options | KV, R2, D1, Durable Objects, Hyperdrive | DynamoDB, S3, RDS, anything in your VPC |
| VPC integration | None (separate model) | Yes, native |
| Pricing | Per-request + CPU time | Per-request + GB-second |
| Free tier | 100k requests/day | 1M requests/month |
| Best for | Edge logic, lightweight APIs | Backends, batch, anything else |
Where Cloudflare Workers wins#
Edge latency. When the user is in Singapore and your origin is in us-east-1, every API call eats 200ms of round-trip just for the network. Workers run near the user. For latency-sensitive workloads (auth checks, redirects, A/B routing, personalization, edge caching logic), the latency win is dramatic and real.
Cold-start economics. Workers have effectively no cold-start tax. Lambda does — and at low traffic, the tax shows up on every request. For sporadically-called APIs (webhooks, scheduled triggers, low-traffic endpoints), Workers feel snappy where Lambda feels broken.
Edge data stores. KV (eventually-consistent globally distributed K/V), R2 (S3-compatible object storage), D1 (SQLite at the edge), Durable Objects (strongly-consistent stateful objects co-located with logic), Hyperdrive (connection-pooling Postgres). These let you build genuinely-at-the-edge applications without going back to origin for everything.
Cost at high request count, low CPU. For lightweight requests, Workers’ per-request pricing is meaningfully cheaper than Lambda’s GB-second model. We’ve seen 10x cost reductions on workloads that fit Workers’ shape.
Free tier is generous. 100k requests/day on the free tier is enough to host real production workloads (low-traffic SaaS, internal tools, side projects) at zero cost.
Where Cloudflare Workers loses#
Language constraints. JavaScript / TypeScript / WebAssembly only. If your team is Python-native and your shared libraries are Python, you’re either porting to TypeScript or compiling to WASM (possible, painful). For ML workloads, native Python with NumPy / Pandas / PyTorch is non-negotiable; Workers is wrong.
CPU-bound work. 30-second CPU limit. Heavy data processing, ML inference (anything beyond small models), batch transforms — wrong tool.
VPC access. Workers don’t natively live in your VPC. Talking to a Postgres in a private subnet requires Hyperdrive or a Cloudflare Tunnel. Doable; one more thing.
Mature integrations are thinner. AWS has ~250 services that Lambda integrates with. Workers has Cloudflare’s growing platform but less coverage of the broader cloud ecosystem.
Operational tooling. Wrangler is good but the broader observability / logging ecosystem is thinner than AWS’s. Logpush + Workers Analytics covers it but the third-party tooling lags AWS.
Where AWS Lambda wins#
Backends. Standard “API hits Lambda, Lambda hits RDS / DynamoDB, returns response.” Lambda is well-optimized for this. The cold-start penalty is real but acceptable for non-latency-critical workloads, and Provisioned Concurrency eliminates it.
Batch and async. Lambda + SQS + EventBridge is the canonical AWS async pattern. Long-running batch (up to 15 min), large memory (up to 10GB), VPC access — Lambda owns this space.
Language flexibility. Python ML inference, Go data processing, Java for legacy integrations, Rust for performance-critical paths. Lambda runs whatever you can package.
VPC integration. Lambda lives in your VPC. Private RDS, internal services, restricted resources — all natively accessible. For enterprise / regulated workloads, this is often the deciding factor.
Ecosystem. EventBridge, Step Functions, SQS, SNS, S3 triggers, DynamoDB streams, API Gateway, Application Load Balancer integration. Lambda is the glue of AWS-native architectures.
Provisioned Concurrency. Eliminates cold starts for predictable workloads at a price. Workers don’t need this, but Lambda’s solution exists when latency matters.
Where AWS Lambda loses#
Cold starts on low-traffic endpoints. Without Provisioned Concurrency, sporadically-called Lambdas have 200-500ms cold starts that users feel. Provisioned Concurrency works but costs money even when idle — which defeats some of the FaaS appeal.
Edge latency. Lambda runs in regions. A user in Mumbai hitting a Lambda in us-east-1 eats 250ms of round-trip every request. Lambda@Edge exists but is less powerful and less performant than Workers.
Per-GB-second pricing penalty for memory-light workloads. Lambda’s pricing scales with allocated memory. Lots of small requests with light memory needs are over-paying compared to Workers.
The pattern of patterns#
The right way to think about this: Workers for the edge slice, Lambda (or your normal backend) for the regional slice.
A typical production architecture:
[user request]
↓
[Cloudflare Workers] ── auth check, A/B routing, edge cache lookup,
↓ geo-based response, request enrichment
↓
[your origin] ──────── Lambda / ECS / EKS / wherever
↓ full business logic, DB access, heavy work
↓
[Postgres / DynamoDB / etc.]Workers handles the things that benefit from being close to the user: auth validation, simple routing logic, edge cache, lightweight personalization. Anything that’s “small and latency-critical.” The heavy lifting stays in your origin where the data lives and where the operational story is richer.
Trying to put everything at the edge is a mistake. Trying to use Lambda for what Workers does well is a different mistake. Both tools have a sweet spot.
When to pick which (in isolation, not both)#
If you’re picking only one tool for a project:
Pick Workers if:
- The workload is read-heavy, latency-sensitive, globally distributed users.
- Logic is small (under 30 sec CPU, under 128MB memory typically).
- Your data is in Cloudflare’s data services (KV, R2, D1) or fronted by a CDN.
- Your team is comfortable with TypeScript.
- You want the lowest possible cold-start and edge latency.
Pick Lambda if:
- You’re AWS-native, your data is in AWS, you want one cloud’s tooling.
- The workload is backend-shaped (API → DB → response), batch, or async.
- You need long execution, large memory, or arbitrary languages.
- You need VPC access to private resources.
- The team is Python / Go / Java native.
What we deploy by default#
For client work:
- Lambda for backend logic when the project is AWS-native (most of our enterprise work). Standard API → RDS → response, batch processors, event-driven workflows, anything that touches private VPC resources.
- Cloudflare Workers for edge functionality in front of the origin — A/B routing for marketing experiments, geo-based response variants, auth-token validation, basic personalization, edge cache logic.
- Both for projects where the architecture naturally splits: Workers for the user-facing edge, Lambda (or ECS / EKS) for the origin work.
For pure SaaS where everything happens at the edge and the data lives in Cloudflare’s stack, Workers can carry the whole load. We’ve shipped small SaaS apps on Workers + D1 + R2 with no other infrastructure. It works.
The thing both platforms get wrong#
Both Workers and Lambda are excellent at the things they’re designed for and increasingly press into each other’s territory through extensions (Lambda@Edge, Workers’ connection pooling). This pressure creates feature parity in marketing materials but leaves the real strengths fuzzy.
Don’t pick based on the feature-overlap edge cases. Pick based on the dominant pattern of your workload — edge or regional, lightweight or heavy, JavaScript or arbitrary language, global or local. The dominant pattern determines which tool is the natural fit; the edge cases get handled either way.
The pattern of patterns#
Edge computing and traditional FaaS are different shapes of the same idea. The mistake is treating them as substitutes. They’re complements. The Workers slice of your stack and the Lambda slice of your stack live at different layers and serve different needs.
Most production systems we deploy use both — Workers at the edge for the latency-critical bits, Lambda or a traditional backend for the data-heavy bits. The architectural clarity of “which layer does what” is more valuable than picking one tool to do everything.
Edge and centralized compute solve different problems. Use both where it makes sense. If you’re sizing the architecture for a new SaaS or backend, our cloud infrastructure service has shipped both Workers and Lambda in production. Tell us about the workload.