Cloudflare Workers vs Lambda@Edge

Two edge compute platforms. The decision criteria for picking one.

Cloudflare Workers

Cloudflare Workers run on a V8-based runtime. JavaScript and TypeScript are native, WebAssembly handles other languages, and isolates spin up in milliseconds rather than the seconds typical of container cold starts. Code runs at every Cloudflare PoP by default, so distribution is one deploy.

• V8-based runtime. JavaScript and TypeScript native; WebAssembly for other languages.
• Isolate cold starts. Milliseconds, not seconds; the perceived latency is dominated by network, not platform startup.
• Global by default. Code runs at every Cloudflare PoP; the platform handles distribution from one deploy.
• Pricing model. Per-request plus CPU time; basic tier generous, paid tier predictable; easier to model than Lambda@Edge.

AWS Lambda@Edge

Lambda@Edge runs Node.js and Python on familiar AWS tooling. Cold starts are tens to hundreds of milliseconds (slower than Workers); distribution is via CloudFront edge locations; the differentiator is the tight CloudFront integration that Workers cannot match without leaving the platform.

• Node.js and Python. Familiar tooling for AWS-native teams; the runtime familiarity is a real onboarding savings.
• Cold starts 50-200ms. Slower than Workers; depends on runtime and package size.
• CloudFront integration. Cache key manipulation, origin selection, signed URLs; the differentiator.
• Pricing model. Per-request plus duration; higher per-request than Workers; CloudFront integration is the trade-off.

Performance comparison

Performance differs across three axes: cold start, memory ceiling, and execution time. Workers wins cold-start latency; Lambda@Edge wins memory ceiling and longer execution windows; the right choice depends on whether the workload is latency-bound or compute-bound.

• Cold start. Workers under 5ms typical; Lambda@Edge 50-200ms depending on runtime and package size.
• Memory limits. Workers 128MB; Lambda@Edge 128MB-10GB depending on event type; heavier compute fits Lambda@Edge.
• Execution time. Workers 50ms CPU per request (paid tier 30s wall-clock); Lambda@Edge 5-30 seconds depending on event type.
• Per-workload benchmark. Run the actual workload on both before committing; the synthetic numbers don’t always match the real shape.

Integration considerations

Integration is often the deciding factor. AWS-native stacks pair Lambda@Edge with IAM, CloudFront, S3, and the rest of AWS so permissions and observability work out of the box; Cloudflare-native or multi-cloud stacks pair Workers with KV, R2, Durable Objects, D1.

• AWS-native integration. Lambda@Edge with IAM, CloudFront, S3; permissions and observability work out of the box.
• Cloudflare-native integration. Workers with KV, R2, Durable Objects, D1; the Cloudflare platform is the home.
• VPC reach. Lambda@Edge runs in a VPC less seamlessly than typical Lambda; plan cross-cloud egress if going Workers.
• Per-stack lock-in awareness. The integration depth becomes lock-in; document the assumptions.

Pick by stack and use case

The right pick is stack-driven. AWS-heavy with CloudFront: Lambda@Edge, where integration savings outweigh the cold-start cost. Multi-cloud, JavaScript-first, latency-sensitive: Workers, where the cold-start advantage matters for user-facing edge logic. Migration only pays when the lock-in cost is genuinely worth it.

• AWS-heavy with CloudFront. Lambda@Edge; integration savings outweigh the cold-start cost for most use cases.
• Multi-cloud, JS-first, latency-sensitive. Workers; the cold-start advantage matters for user-facing edge logic.
• Migration discipline. Don’t switch existing systems just because the other side advertises a feature; migration rarely pays.
• Per-use-case benchmark. The actual workload latency and cost dominate the decision; the platform marketing does not.