Lambda vs Workers: When Cold Starts Change the Cost

For a bursty API, conventional AWS Lambda functions can have the lower compute bill when occasional cold starts are acceptable. If the latency target requires provisioned Lambda capacity, Cloudflare Workers can become cheaper. Workers also suits globally distributed requests that spend much of their time waiting on I/O; Lambda may suit sustained computation or an application already tied to AWS services.

The comparison turns on more than a startup figure. Lambda Event Functions bill for requests and memory-weighted execution time, while Workers Standard bills for requests and CPU time. Where data lives, how much memory the code needs, and whether ready capacity is necessary can change both the response time and the price.

What the two bills measure

AWS’s Lambda pricing gives Event Functions one million requests and 400,000 GB-seconds each month at no charge. Its US East x86 examples use $0.20 per million requests beyond the allowance and $0.0000166667 per GB-second in the first duration tier. A GB-second multiplies configured memory by billed time, so waiting on a database can contribute to the function’s duration charge. Initialization also contributes to billed duration.

The same schedule prices provisioned concurrency separately: $0.0000041667 per provisioned GB-second, plus $0.0000097222 per execution GB-second and request charges in its US East example. The Lambda free allowance does not apply to functions using provisioned concurrency. This calculation covers Event Functions; Lambda Web Functions have a separate billing model based on requests, active CPU time, and memory.

Cloudflare’s Workers Standard pricing sets a $5 monthly paid-plan minimum, including 10 million requests and 30 million CPU milliseconds. Additional requests cost $0.30 per million and additional CPU time costs $0.02 per million milliseconds; elapsed duration has no separate charge. Network waits therefore affect a Worker’s response time without adding CPU time, although storage, databases, and other services can add costs of their own.

What startup evidence means for latency

AWS Lambda and Cloudflare Workers compared on reported execution overhead for a minimal function, distinct from cold-start time.

In a EuroSys measurement of a minimal function, the researchers found about 1.17 milliseconds of average provider-reported execution overhead for Lambda’s polling architecture, while the Workers result fell below Cloudflare’s 0.01-millisecond reporting precision. These are measurements of execution overhead for an empty response, not full cold-start times or end-to-end API latency. The study also found that longer idle intervals increased Lambda cold-start probability in its tests and described different mechanisms for retaining or resuming execution environments.

A cold Lambda invocation may need runtime and application initialization before it serves a request. Provisioned concurrency keeps environments initialized, but charges for the capacity while it is enabled. A Worker’s lighter execution path can help an intermittent endpoint, yet the user still waits for network travel and any remote data fetch. A nearby Worker that must call a distant database may offer less latency benefit than its startup behavior suggests.

Bursty API: when ready capacity changes the winner

Consider a conditional month with two million API requests, a 256 MB Lambda Event Function, and 100 milliseconds of normal billed execution per request. Assume 5% of invocations add 300 milliseconds of billed initialization. The total is 57,500 GB-seconds: two million × 0.25 GB × (0.10 seconds + 0.05 × 0.30 seconds). If this account has its free allowances available, Lambda’s modeled charge is $0.20 for requests and nothing for duration.

Assume equivalent Worker logic consumes three milliseconds of CPU per request and that daily traffic bursts beyond the Workers Free plan’s request limit, requiring the paid plan. Six million CPU milliseconds and two million requests fit within its included monthly units, leaving a $5 bill. On these assumptions, on-demand Lambda costs less despite the modeled cold starts.

Now assume the API’s latency target requires five provisioned Lambda environments for an entire 30-day month. Capacity costs about $13.50; 50,000 execution GB-seconds cost about $0.49; and two million requests cost $0.40 because this function cannot use the Lambda free allowance. The total is about $14.39 versus $5 for the assumed Worker. The reversal comes chiefly from keeping capacity ready, not from a large charge for each cold invocation. Five environments are an illustrative capacity requirement: a sharper traffic peak could need more, while provisioning only during predictable busy periods would cost less.

Global personalization: CPU time and data placement

For a second conditional workload, assume 100 million dynamic personalization requests per month. Give Lambda 512 MB of memory and 100 milliseconds of normal billed time, with another 200 milliseconds of initialization on 1% of requests. Assume the equivalent Worker uses five milliseconds of CPU per request. These are inputs to a price model, not measured timings for either implementation.

Lambda consumes 5.1 million GB-seconds. After its unused free allowances, the modeled Event Function bill is about $78.33 for duration plus $19.80 for requests, or $98.13. Workers consumes 500 million CPU milliseconds: the $5 plan, $27 in excess requests, and $9.40 in excess CPU produce $41.40. The gap follows from billing the assumed Lambda elapsed time while billing the Worker’s smaller assumed CPU time.

Cost does not establish the faster user experience. If every personalization request fetches uncached data from one distant origin, that round trip remains in the response even though Workers does not bill it as CPU time. If the required data is available near requesters, distributed execution has a stronger latency case. The location and price of the data service belong alongside either compute estimate.

Long-running integration: price meets runtime limits

A conditional integration task compared with the documented memory limits of AWS Lambda and Cloudflare Workers.

A third conditional workload reverses the compute result again. Assume 100,000 integration jobs each take 60 seconds elapsed, including 20 seconds of CPU work. At 256 MB, Lambda uses 1.5 million GB-seconds and costs about $18.33 after an otherwise unused free allowance. Workers uses two billion CPU milliseconds and costs about $44.40 on the paid plan. At this level of sustained CPU use, avoiding a charge for I/O waits does not give Workers the lower bill.

Feasibility can settle the choice before price does. AWS’s Lambda quotas allow up to 10,240 MB of memory and a 15-minute timeout for a standard invocation; specified Lambda Managed Instances invocation paths have a longer limit. Cloudflare’s Worker limits set 128 MB per isolate and a default 30-second CPU limit on the paid plan, configurable up to five minutes for an HTTP request. An HTTP Worker has no fixed elapsed-time limit while its client stays connected, but that is different from a durable background job. A task needing a larger in-memory working set cannot move into a standard Worker unchanged; an integration already driven by AWS event sources may also be simpler to keep in Lambda.

A reproducible comparison for a specific workload

For an Event Function, multiply monthly requests by configured memory in GB and average billed seconds, including the observed share and duration of initialization. Subtract any free GB-seconds available to the account, apply the regional duration and request rates, and add provisioned capacity and its distinct execution rate only for the periods when the latency target requires it. Provisioned capacity must cover the relevant concurrency: requests beyond it can still use on-demand execution.

For Workers Standard, multiply invocations by measured CPU milliseconds, subtract the plan’s included units, and add excess request and CPU charges to the paid-plan minimum. Measure comparable application logic and examine slow responses after idle periods or traffic spikes before choosing a latency target. Keep API front ends, data services, and network charges as separate lines: they can outweigh the function bill and may differ substantially between the two architectures.