The Edge Compute Showdown: What the Numbers Say
Edge computing is no longer a niche concern. As of 2025, serverless functions handle the majority of edge API traffic for web applications that need global reach. Two platforms dominate this space: Cloudflare Workers and AWS Lambda@Edge.
Both promise to run your code close to users. Both eliminate server management. But they differ significantly in architecture, performance characteristics, and how they charge you. This comparison breaks down the real numbers so you can make an informed decision for your workloads.
Architecture: V8 Isolates vs. Container MicroVMs
The fundamental architectural difference explains almost every performance and pricing distinction between these two platforms.
Cloudflare Workers run inside V8 isolates, the same JavaScript engine that powers Chrome. When a request arrives, Cloudflare spins up a new isolate within an already-running V8 process. There is no operating system to boot, no container to provision. This process takes under 5 milliseconds.
AWS Lambda@Edge runs inside container-based microVMs on CloudFront edge locations. Each function invocation requires either a warm container (fast) or provisioning a new one from scratch (cold start). Cold starts on Lambda@Edge range from 100ms to over 1 second, depending on runtime and package size.
Deployment Footprint
Cloudflare Workers deploy automatically to 310+ edge locations worldwide. There is no region selection, no manual configuration. Your code runs everywhere by default.
Lambda@Edge functions deploy through CloudFront, which operates across 200+ edge locations. However, the function must first be created in us-east-1 before CloudFront replicates it globally. This adds deployment complexity and introduces propagation delays of several seconds to minutes.
Cold Start Performance: The Defining Difference
Cold starts are the single biggest performance differentiator between these platforms. For latency-sensitive applications, this metric alone may determine your choice.
Cloudflare Workers report a P50 latency of approximately 18ms and a P99 of around 120ms for global HTTP workloads, according to independent benchmarks. In October 2025, Cloudflare announced its “Shard and Conquer” technique, which reduced cold start rates by 90% and achieved a 99.99% warm start rate across the platform.
Lambda@Edge cold starts vary by runtime. Node.js functions typically cold-start in 200-500ms. Python functions land in a similar range. Java functions can exceed 1 second. Once warm, Lambda@Edge response times drop to 5-50ms, but the warm state is not guaranteed, especially for low-traffic functions or during traffic spikes that trigger new container provisioning.
Real-World Impact
Consider an API that handles 200 requests per user session. If 5% of those requests hit a cold start averaging 500ms on Lambda@Edge, that adds 5 seconds of cumulative latency per session. On Workers, the same scenario adds roughly zero perceptible delay because isolate startup is sub-5ms.
For high-traffic applications that keep containers warm, the gap narrows. But for applications with variable traffic patterns, geographic diversity, or many distinct function endpoints, Workers maintains a consistent latency profile that Lambda@Edge cannot match without provisioned concurrency (which Lambda@Edge does not support).
Pricing Breakdown: CPU Time vs. Wall-Clock Time
The billing model is where these platforms diverge most dramatically for I/O-heavy workloads. Understanding this distinction can save you thousands of dollars per month at scale.
Cloudflare Workers Pricing
Workers offers a free tier of 100,000 requests per day with 10ms of CPU time per invocation. The paid plan starts at $5/month and includes 10 million requests. Beyond that, additional requests cost $0.30 per million. Compute is billed at $0.02 per million milliseconds of CPU time.
The critical detail: Workers bills only for CPU time. When your function is waiting on a fetch() call, a database query, or any external I/O, the meter stops. You pay only for the milliseconds your code is actively using the CPU.
AWS Lambda@Edge Pricing
Lambda@Edge charges $0.60 per million requests, double the rate of standard Lambda ($0.20 per million). Duration is billed at $0.00005001 per 128MB-second. Unlike standard Lambda, Lambda@Edge does not include a free tier for requests or compute.
Lambda@Edge bills for wall-clock duration. If your function makes an HTTP call that takes 200ms to respond, you pay for those 200ms even though your CPU was idle. For functions that spend most of their time waiting on I/O, this billing model is significantly more expensive.
Cost Comparison: 10 Million Requests/Month
| Cost Component | Cloudflare Workers | AWS Lambda@Edge |
|---|---|---|
| Base plan | $5/month (includes 10M requests) | $0 (pay-as-you-go) |
| Request charges | $0 (included) | $6.00 (10M x $0.60/M) |
| Compute (5ms avg CPU per request) | $1.00 | $6.25 (at 50ms avg wall-clock, 128MB) |
| Data transfer (10GB out) | $0 (with R2) | $0.90 |
| Total | $6.00 | $13.15 |
This example assumes an I/O-heavy function where CPU time is 5ms but wall-clock time is 50ms due to external API calls. The 10x multiplier between CPU and wall-clock time is common for functions that aggregate data from multiple sources or proxy requests to origin servers.
At 100 million requests/month, the gap widens further. Workers would cost approximately $32 while Lambda@Edge would run approximately $131. The savings compound with scale.
Language Support and Runtime Constraints
Lambda@Edge supports Node.js and Python. That is it. No Go, no Java, no Rust at the edge. Standard Lambda supports seven runtimes plus custom runtimes, but Lambda@Edge is limited to these two languages with specific version constraints.
Cloudflare Workers natively supports JavaScript, TypeScript, and WebAssembly. The WebAssembly support is significant because it allows you to compile Rust, C, C++, and Go to Wasm and run them on Workers. This gives Workers broader effective language support despite its V8-only runtime.
Resource Limits
| Limit | Cloudflare Workers | AWS Lambda@Edge |
|---|---|---|
| Max memory | 128MB | 128MB (viewer) / 10GB (origin) |
| Max execution time | 30s (HTTP) / 15min (Cron) | 5s (viewer) / 30s (origin) |
| Max package size | 10MB (compressed) | 1MB (viewer) / 50MB (origin) |
| Environment variables | Yes (via wrangler.toml) | Not supported |
| Layers | N/A | Not supported |
| VPC access | N/A | Not supported |
| Ephemeral storage | N/A | 512MB max |
Lambda@Edge viewer-triggered functions are heavily constrained: 5-second timeout, 1MB package size, 128MB memory. Origin-triggered functions get more room (30 seconds, 50MB, up to 10GB memory) but only fire on cache misses, not every request.
Ecosystem and Storage Options
Cloudflare has built a tightly integrated ecosystem around Workers. KV provides a global key-value store. R2 offers S3-compatible object storage with zero egress fees. D1 is a SQLite-based edge database. Durable Objects enable strongly consistent, stateful compute at the edge. All of these are first-party services that require no additional configuration beyond your Workers account.
Lambda@Edge inherits the AWS ecosystem, but with significant restrictions. You cannot access VPC resources, which means no direct connections to RDS, ElastiCache, or other VPC-bound services. You can call DynamoDB and S3 via their public APIs, but each call adds latency and cost. The tight integration that makes standard Lambda powerful within AWS is largely absent at the edge.
Developer Experience
Workers ships with Wrangler, a CLI that handles local development, testing, and deployment in a single tool. You can run Workers locally with full API compatibility using wrangler dev. Deployment takes seconds and propagates globally within 30 seconds.
Lambda@Edge requires the AWS Console or SAM/CDK for deployment. Functions must be authored in us-east-1, then associated with a CloudFront distribution. Propagation takes minutes. Local testing requires SAM Local or third-party tools, and the local environment does not perfectly replicate the edge runtime constraints.
When to Choose Cloudflare Workers
Workers is the stronger choice for globally distributed, I/O-heavy workloads where consistent latency matters more than raw compute power. Specific use cases where Workers excels:
API gateways and request routing. Sub-5ms startup means every request gets handled quickly regardless of traffic patterns. The 310+ location deployment ensures users worldwide get similar response times.
A/B testing and personalization. Modifying responses at the edge based on cookies, headers, or geolocation is a natural fit. Workers can read from KV to fetch experiment configurations without origin round-trips.
Image optimization and transformation. Workers paired with Cloudflare Images can resize, reformat, and cache images at the edge. The CPU time billing model means you only pay for the actual transformation work, not the time spent fetching the source image.
Full-stack applications. With D1, KV, R2, and Durable Objects, you can build complete applications that run entirely at the edge. Frameworks like Hono and Remix support Workers as a deployment target.
When to Choose AWS Lambda@Edge
Lambda@Edge makes sense when you are already deeply invested in AWS and need edge compute as an extension of your existing CloudFront distribution. Specific scenarios:
CloudFront request/response manipulation. If you already use CloudFront and need to modify headers, implement authentication checks, or rewrite URLs before they hit your origin, Lambda@Edge integrates directly with your existing CDN configuration.
Origin-side compute with high memory needs. Origin-triggered Lambda@Edge functions support up to 10GB of memory and 30-second timeouts. For compute-heavy transformations on cache misses, this provides more headroom than Workers 128MB limit.
Compliance requirements tied to AWS. Organizations with AWS Enterprise Agreements, specific compliance certifications tied to AWS, or governance requirements that mandate staying within the AWS ecosystem may need Lambda@Edge regardless of performance or cost differences.
The Verdict
For most edge computing workloads in 2026, Cloudflare Workers offers better performance, lower costs, and a more cohesive developer experience. The zero cold start architecture, CPU-only billing, and integrated storage ecosystem give it clear advantages for web-facing applications.
Lambda@Edge remains relevant for teams locked into AWS infrastructure or those needing origin-triggered functions with high memory allocations. But its pricing premium (3x the request cost of standard Lambda), limited language support, and cold start behavior make it harder to recommend as a standalone edge compute platform.
The market is moving toward Workers-style isolate architectures. Deno Deploy, Vercel Edge Functions, and Netlify Edge Functions all use V8 isolates. AWS itself introduced CloudFront Functions (a lighter, faster alternative to Lambda@Edge) in recognition that container-based edge compute has inherent latency limitations.
If you are starting a new project that needs global edge compute, Workers is the default choice. If you are extending an existing AWS/CloudFront setup with light request manipulation, Lambda@Edge or CloudFront Functions will integrate more smoothly with what you already have.