Cloudflare Workers vs AWS Lambda: Real Latency and Cold Start Costs Compared
Your users don't care that your function took 400ms to cold-start. They just notice the app felt slow. If you're picking between Cloudflare Workers and AWS Lambda for a latency-sensitive workload, the marketing pages won't tell you what you actually need to know.
This article cuts through the noise with a practical, side-by-side look at how these two platforms behave under real conditions: cold starts, warm latency, global distribution, pricing, and the limits that will surprise you at 2am.
What you'll learn
- How cold starts differ fundamentally between Workers and Lambda
- Where each platform's latency profile actually comes from
- The pricing models and where each one gets expensive
- Runtime and language constraints on both platforms
- How to choose based on your specific workload
Prerequisites
This article assumes you're comfortable with the concept of serverless functions and have at least deployed something to either AWS or Cloudflare. No code deployment walkthrough here β the focus is the comparison, not the tutorial.
The Cold Start Problem, Explained Once
A cold start happens when the platform needs to spin up a new execution environment from scratch because no warm instance is available. The platform has to allocate memory, load the runtime, pull your code, and initialize your application before it can process the first request.
On AWS Lambda, this means booting a microVM (via Firecracker), initializing the language runtime (Node.js, Python, Java, etc.), and running your initialization code. On Cloudflare Workers, the story is different by design β and that difference is the core of this whole debate.
How Cloudflare Workers Handles Cold Starts
Cloudflare Workers run on the V8 JavaScript engine, the same engine that powers Chrome and Node.js. Instead of spinning up a full container or microVM per request, Workers use V8 isolates: lightweight execution contexts that spin up in under a millisecond.
The result is that Workers cold starts are effectively invisible to users. Cloudflare quotes sub-millisecond isolate startup times, and in practice that holds. Your function runs at the edge β in one of Cloudflare's data centers distributed across hundreds of cities β so the network hop to reach it is also short.
There's a tradeoff, though. Because you're in a V8 isolate, you're constrained to JavaScript, TypeScript, or anything that compiles to WebAssembly. You don't get a POSIX environment. You can't shell out to a subprocess. Certain Node.js APIs simply don't exist.
What Workers can't do
- Run arbitrary binaries or native extensions
- Use full Node.js APIs (no
fs, nochild_process) - Execute for longer than 30 seconds on the free plan (50ms CPU time limit on free, up to 30 seconds of wall-clock time on paid)
- Allocate more than 128MB of memory per request
How AWS Lambda Handles Cold Starts
Lambda's cold start cost is real, and it varies significantly by runtime. Java functions with a large classpath can take several seconds on a cold start. Python and Node.js are typically in the 200ms to 800ms range. The exact number depends on your memory allocation, the size of your deployment package, and whether you have a VPC attached.
VPC-attached Lambdas used to have notoriously long cold starts because of elastic network interface provisioning. AWS has improved this substantially, but attaching a Lambda to a VPC still adds latency compared to a public-internet function.
Lambda does offer Provisioned Concurrency to eliminate cold starts: you pay to keep a number of instances pre-warmed and ready. It works, but it changes the cost model from pay-per-request to pay-per-hour, which narrows the cost advantage serverless was supposed to give you.
Factors that increase Lambda cold start time
- Heavier runtimes (Java, .NET) vs. lighter ones (Python, Node.js)
- Large deployment packages with many dependencies
- VPC attachment
- High memory allocation (counterintuitively, very low memory can also slow initialization)
- Complex initialization logic outside the handler function
Warm Latency: What Happens After the First Request
Once an instance is warm, the comparison shifts. A warm Lambda function running in the same AWS region as your other services will have very low internal latency β often single-digit milliseconds for the compute itself. The total round-trip latency your user sees depends mostly on where they are relative to that region.
Cloudflare Workers serve from the edge location closest to the user. For a globally distributed user base, this typically means lower average latency than a Lambda deployed in a single region like us-east-1. For users who happen to be sitting near your Lambda region, the difference narrows significantly.
If your workload is CPU-bound and runs for more than a few milliseconds, Lambda's higher CPU ceiling (up to 10GB RAM, 6 vCPUs) becomes relevant. Workers cap at 128MB and tight CPU time limits. A Worker is the wrong tool for image transcoding or large matrix math.
Pricing Models Side by Side
Both platforms offer a free tier, and both become meaningfully different in cost at scale. Here's how the models compare structurally.
| Dimension | Cloudflare Workers | AWS Lambda |
|---|---|---|
| Free requests/month | 100,000/day (free plan) | 1 million/month |
| Paid pricing unit | Per 10 million requests | Per 1 million requests + GB-seconds |
| Duration billing | CPU time (not wall-clock) | Wall-clock time Γ memory |
| Provisioned warm instances | Not applicable (isolates are always fast) | Provisioned Concurrency (hourly cost) |
| Egress costs | Included in most cases | Standard AWS data transfer rates |
The CPU-time billing on Workers is meaningful. If your Worker spends most of its time waiting on a fetch to an external API, you're not billed for that wait. Lambda bills for wall-clock duration regardless of whether your function is actively doing compute or blocking on I/O.
At high request volumes, Workers is often cheaper for short, I/O-bound tasks. Lambda can be cheaper for compute-heavy tasks that justify the memory allocation.
Runtime Support and Language Constraints
This is where the platforms diverge most sharply in terms of what you can build.
Lambda supports Python, Node.js, Java, Go, .NET, Ruby, and custom runtimes via the runtime API. You can run almost any Linux binary by packaging it with your function. If your stack includes libraries with native C extensions, Lambda handles it. If you need to run a compiled Rust binary, Lambda handles it.
Workers support JavaScript, TypeScript, and WebAssembly. Through WASM you can run Rust, C, and other compiled languages, but the experience is more constrained than native Lambda execution. The Workers team has been expanding compatibility with standard Web APIs and a subset of Node.js APIs over time, but gaps remain.
π€ Share this article
Sign in to save
Related Articles
Comments (0)
No comments yet. Be the first!
Leave a Comment