Cloudflare Workers vs AWS Lambda: How We Decide

“Cloudflare Workers vs AWS Lambda” gets searched constantly, usually by someone hoping for a clear winner. There isn’t one. Both are serverless compute; both bill by usage; both remove the “who’s patching the OS” question. Where they diverge is the shape of workload each one was actually built to run.

We run our own products — the eSIM brand described on the work page, the sites this studio ships — entirely on Cloudflare Workers. We also build on AWS for clients whose workload doesn’t fit that shape. Neither choice is the “better” platform in the abstract. Here’s the test we actually use.

What Workers is genuinely built for

Workers runs at the edge — your code executes in the data centre closest to the person making the request, not in one region you picked at setup. For anything read-heavy and latency-sensitive — a marketing site, an API that mostly serves cached or lightly computed responses, a redirect or auth-check layer in front of something else — that’s a real, measurable win, and it comes without picking a region or configuring a CDN in front of a Lambda-backed API to get the same effect.

Cold starts are close to a non-issue on Workers, because the isolate model is lighter than a container spin-up. For a function that fires occasionally and needs to answer fast every time, that matters more than most pricing comparisons capture.

What Lambda is genuinely built for

Lambda sits inside the wider AWS ecosystem, and that’s the actual point of it — not raw compute, but proximity to RDS, S3, SQS, Step Functions, and everything else AWS offers. A workload that’s fundamentally “one big relational database with heavy reporting and long-running batch jobs” wants to live next to that database, with a mature ecosystem of tools built for exactly that shape of problem.

Long-running jobs are the clearer split. Workers has execution-time constraints that make sense for request/response work and are the wrong fit for a job that needs to run for minutes, chew through a large batch, or hold a persistent connection open. Lambda handles that more comfortably, and if the job genuinely needs more than Lambda’s own limits allow, that’s a sign the workload wants a different AWS service entirely, not a different serverless platform.

The actual test

Workload shape	Fits
Pages, forms, small APIs, queues	Cloudflare Workers
One big relational database with heavy reporting	AWS (Lambda + RDS or similar)
Latency-sensitive, globally distributed reads	Cloudflare Workers
Long-running batch jobs, persistent connections	AWS
Needs deep integration with existing AWS infrastructure	AWS
Mostly static + small dynamic surface	Cloudflare Workers

This is the same rule we apply to our own infrastructure decisions, not a sales framework built for client conversations: if the product can be described as pages, forms, small APIs and queues, it goes on the edge; if it’s one big database and many joins, it doesn’t.

Cost follows shape, not platform

Pricing comparisons between the two rarely account for what actually drives a bill: request volume and duration matter on both platforms, but Workers’ pricing model rewards short, frequent invocations, while Lambda’s makes more sense once a workload is already paying for other AWS services and benefits from being billed alongside them. Neither is “cheaper” as a blanket rule — the workload shape decides which pricing model works in your favour, which is exactly why the “vs” framing of the question undersells the real decision.

Migration is a rewrite, not a lift-and-shift

One thing worth saying plainly: moving a workload from Lambda to Workers, or the reverse, is rarely a clean port. The two platforms have different runtime models, different limits on execution time and available APIs, and different assumptions about state and connections. Treating a migration as “redeploy the same code somewhere cheaper” tends to surface exactly the constraints this article describes, just later and under more pressure. If a migration is on the table, it deserves the same scoping a new build would get, not less.

What doesn’t change either way

Whichever platform a workload lands on, the same things matter: infrastructure as code so environments are reproducible, preview environments so a change is tested somewhere other than production, monitoring and alerting so a failure is noticed before a customer reports it, and backup verification — not just backups, but a tested restore, because an untested backup is a belief, not a plan. GDPR-relevant workloads add EU-hosting and data-localisation questions that apply regardless of which serverless platform is underneath, and that’s a decision made at the infrastructure layer, not bolted on afterward.

Where we’d actually land your project

We’d ask what the workload looks like before we’d tell you which platform to use — the honest version of the “vs” question isn’t which platform wins, it’s which shape your project actually is. Our own cloud and DevOps work spans both, because the workloads we run and the workloads clients bring us aren’t the same shape, and pretending they are is how migrations turn into rewrites.

The platform doesn’t decide the architecture. The workload does, and the platform just has to fit it.

If you’re mid-decision on this for a real project, a contact conversation about the actual workload will get further than another comparison table — including this one.