We Replaced AWS Lambda with Cloudflare Workers 3.0: Postmortem of 50% Lower Latency for Global Users

Last quarter, our engineering team completed a full migration of our serverless compute workload from AWS Lambda to Cloudflare Workers 3.0. The primary driver was inconsistent latency for our global user base: 60% of our users are outside the US East region where our Lambda functions were deployed, leading to p90 latency spikes over 300ms. After a 3-month migration and 6 weeks of stable production traffic, we’ve recorded a 50% reduction in median latency globally, with even steeper improvements for users in APAC and EMEA regions.

Background: Our Lambda Pain Points

We’re a B2B SaaS platform serving 120k+ active users across 62 countries, with core workloads including user authentication, dynamic API responses, and on-the-fly image resizing. For 3 years, AWS Lambda handled these workloads reliably, but we hit three critical limitations:

• Regional latency: Lambda functions run in a single AWS region. Users in Singapore, London, or São Paulo routed requests to our us-east-1 deployment, adding 150-400ms of network latency before function execution even started.
• Cold start overhead: Sporadic cold starts added 500-1200ms of latency for infrequently used endpoints, even with provisioned concurrency enabled (which increased our monthly bill by 40%).
• Vendor lock-in: Tight coupling with Lambda-specific event formats and AWS SDK integrations made multi-cloud exploration impossible.

Why Cloudflare Workers 3.0?

We evaluated multiple serverless options, including Lambda@Edge, Google Cloud Functions, and Cloudflare Workers. Workers 3.0 stood out for three key reasons:

• Edge-native execution: Workers run on Cloudflare’s 300+ global PoPs, meaning 95% of our users are within 50ms of a PoP. Workers 3.0’s V8 isolate-based runtime delivers near-zero cold starts (we measured 99.9% of requests starting execution in <10ms).
• Runtime compatibility: Workers 3.0 added support for Node.js 18+ API surface, including fetch, Web Streams, and Buffer, which let us reuse 85% of our existing Lambda codebase with minimal refactoring.
• Integrated ecosystem: We already used Cloudflare R2 for object storage and KV for edge caching, so Workers’ native integration with these tools eliminated cross-vendor API calls.

Migration Process

We followed a phased rollout to minimize risk:

1. Proof of Concept: Ported 3 low-traffic endpoints to Workers, tested latency and correctness for 2 weeks. Identified that Lambda’s aws-sdk dependencies needed to be replaced with Cloudflare’s equivalent APIs or lightweight alternatives (e.g., swapping AWS.S3 for Cloudflare R2’s S3-compatible API).
2. Canary Deployment: Routed 5% of traffic to Workers via Cloudflare Load Balancing, gradually increasing to 50% over 4 weeks. Monitored error rates, latency, and cost daily.
3. Full Cutover: Migrated remaining workloads, decommissioned Lambda functions, and updated our CI/CD pipeline to deploy directly to Workers.

Results: Latency and Beyond

The most impactful result was latency improvement. Below is a comparison of our p50, p90, and p99 latency metrics across key regions, measured over 30 days of production traffic:

Region

Lambda p50 (ms)

Workers 3.0 p50 (ms)

Lambda p90 (ms)

Workers 3.0 p90 (ms)

Lambda p99 (ms)

Workers 3.0 p99 (ms)

US East

120

58

280

140

750

380

EU West

210

92

420

190

1100

520

APAC Southeast

380

175

650

310

1800

890

Global Average

220

108

450

210

1200

590

Median global latency dropped from 220ms to 108ms – a 51% reduction, exceeding our 50% target. p90 latency improved by 53%, and p99 by 51%. We also saw a 28% reduction in monthly compute costs, as Workers’ pay-per-request pricing with no idle charges replaced Lambda’s provisioned concurrency fees.

Challenges and Lessons Learned

No migration is without friction. Key issues we encountered:

• Runtime differences: Workers use V8 isolates, not a full Node.js runtime. We had to remove dependencies that relied on Node’s fs or child_process modules, and refactor code that used Lambda-specific context objects.
• Debugging edge functions: Initial debugging was slower than Lambda, as Cloudflare’s logging pipeline has a 1-2 minute delay compared to CloudWatch’s near-real-time logs. We integrated Workers with our Datadog instance to reduce this gap.
• Request limits: Workers have a 100MB request/response payload limit, which required us to adjust our image resizing endpoint to stream large payloads instead of buffering them in memory.

Conclusion

For globally distributed workloads, Cloudflare Workers 3.0 outperformed AWS Lambda in latency, cost, and user experience. We recommend this migration for teams with users across multiple regions, especially those already using Cloudflare’s edge ecosystem. The 50% latency reduction translated to a 12% increase in user retention for our APAC user base, proving the business value of edge-native serverless compute.

All code samples and migration scripts are available in our public GitHub repository (link omitted for privacy).