The first request after idle pays a tax the second request never sees. On AWS Lambda that tax is the initialization of a fresh execution environment: the runtime boots, the code loads, the static initializers run, and only then does the handler see the request. On Cloudflare Workers the tax barely exists, because the platform runs V8 isolates instead of virtual machines. On Vercel, Fluid compute pre-warms production functions so most requests never meet a cold environment at all. Three platforms, three answers to the same problem — and the only way to choose between them is to price the latency in dollars, from the vendors' own rate cards.
Anatomy of a cold start
A cold start has three phases, and each one belongs to a different owner. First, the platform provisions the sandbox: a micro-virtual machine or container on Lambda, an isolate on Workers, a function instance on Vercel. Second, the runtime boots — the language interpreter or JavaScript engine starts and the platform wires the handler. Third, the function initializes: dependency imports, client construction, and module-level code. The first two phases are the platform's cost and largely fixed; the third is the author's cost, and it is where most cold-start latency lives.
Lambda makes the split visible. Every invocation logs a REPORT line, and on a cold invocation that line carries an Init Duration field alongside Duration and Billed Duration. That one field is the entire measurement program: if Init Duration is a small share of total latency, the problem is the handler, not the cold start; if it dominates, the initialization is the target. The other platforms expose the same split differently, but the principle is identical: measure initialization separately from execution before spending anything on warmth.
Measure the tax before you pay to remove it
Cold-start latency only matters in proportion to how often it is paid. A function invoked a million times a day has almost no cold invocations, because environments stay warm between requests; a function invoked a hundred times a day in bursts has a cold start on nearly every burst. The cold-start rate is the share of invocations that initialize:
And the latency tax on the average request is the rate times the initialization time:
A function with a 400 ms Init Duration and a 5% cold-start rate adds 20 ms to the average request — below the threshold most users notice. The same 400 ms at a 90% cold-start rate adds 360 ms, which is the entire latency budget of many APIs. The first measurement is the cold-start rate from the platform's logs: Lambda's REPORT lines, Workers' analytics, Vercel's function logs. If the rate is under 10% and the Init Duration under 200 ms, stop.
Three platforms, three cold-start models
| Platform | Cold-start model | What you pay to remove it | Billing meter | Free tier | Authority |
|---|---|---|---|---|---|
| AWS Lambda | MicroVM per environment; Init Duration on cold invocations | Provisioned concurrency or SnapStart | GB-seconds + $0.20 per million requests | 1M requests + 400,000 GB-s per month | AWS Lambda Pricing |
| Cloudflare Workers | V8 isolates; around 100x faster than a Node process, no VM cold starts | Nothing — no warming product exists | CPU milliseconds + requests | 100,000 requests per day, 10 ms CPU per invocation | Cloudflare Workers docs |
| Vercel Functions | Fluid compute; bytecode optimization and pre-warming on production | Nothing extra — pre-warming is included | Active CPU + provisioned memory | Hobby: 360 GB-hours provisioned memory included; Pro: monthly usage credit, then on-demand | Vercel Fluid compute docs; Vercel pricing docs |
The table makes the strategic point before any math: Lambda sells warmth as a priced add-on, Workers and Vercel bundle it into the platform. On Lambda the question is how much warmth to buy; on Workers the question is whether the workload fits the isolate model's constraints, chiefly the CPU-time limits and the rule against mutable global state; on Vercel the question is whether the automatic pre-warming covers the traffic pattern, since the operator cannot buy more of it directly.
Provisioned concurrency: the price of always warm
Provisioned concurrency keeps a set number of execution environments initialized and ready, so requests skip the Init Duration entirely; AWS describes it as keeping response times in the double-digit milliseconds. The price is explicit: $0.0000041667 per GB-second on x86, billed from enablement until disabled, rounded up to the nearest five minutes, with no free tier. Invocations on provisioned environments are billed separately at $0.0000097222 per GB-second, plus $0.20 per million requests. Provisioned concurrency can only be configured on a published version or an alias, never on $LATEST, and it is charged whether the environments serve traffic or sit idle.
The monthly cost of one warm environment follows directly from the rate:
A 1 GB environment held warm for a 30-day month costs $10.80. AWS's own worked example prices an 8-hour product launch: 100 provisioned environments at 1,536 MB for 8 hours cost $18.00 in provisioned concurrency, plus $0.73 of provisioned duration for 500,000 requests at 100 ms, $0.83 for 2.5 million further requests at 120 ms outside the window, and $0.40 of request charges — $19.96 in total. The Cyber Monday example is larger: 7 environments at 4,096 MB for 24 hours cost $10.08, and 2 million requests at 280 ms add $21.78 of provisioned duration, plus $0.40 of request charges, for a $32.26 total. Both show the same shape: the warmth is a small share of the bill when traffic is heavy, and the dominant share when it is not.
The 60% break-even
Provisioned concurrency is cheaper than on-demand only when the environments are busy enough, because the warmth is paid for whether it is used or not. The cost per GB-second of executed work is the warmth charge divided by utilization, plus the provisioned execution rate:
where $u$ is the utilization fraction. Setting that equal to the on-demand rate of $0.0000166667 per GB-second and solving:
At 60% utilization the two models cost the same. Below 60%, on-demand is cheaper even after accounting for cold starts; above it, provisioned concurrency is cheaper and the latency improvement is free.
The break-even does not move with scale — it is a property of the two rates, not of the deployment size. The discipline that follows is to size provisioned concurrency to the steady baseline, not the peak: keep the baseline warm, let bursts spill onto on-demand capacity, and accept cold starts on the spillover where the latency budget allows.
SnapStart: the cheaper warm start
SnapStart snapshots an initialized function — memory and disk state after initialization — and restores that snapshot when a new environment is needed. AWS states that SnapStart improves startup performance from several seconds to as low as sub-second. The pricing has two parts: cache storage at $0.0000015046 per GB-second, with a three-hour minimum per snapshot, and a restore charge of $0.0001397998 per GB for each cold start that restores a snapshot.
AWS's worked example prices a natural-language-processing workload at 7.44 million messages a month, 1% cold, 1 GB of memory and 2 seconds average duration: cache storage $4.03 plus restore charges $10.40, or $14.43 a month. Against ten 1 GB provisioned environments at $108 a month, SnapStart is roughly seven times cheaper for that workload. The trade is that SnapStart shortens initialization rather than eliminating it: a sub-second restore is not a zero-millisecond warm invocation. For workloads whose initialization is dominated by loading large modules or models, SnapStart is usually the right first buy, and provisioned concurrency is the second buy where sub-second is still too slow.
Warming with scheduled pings
The oldest cold-start trick costs almost nothing and works exactly once. A scheduled event invokes the function every minute, keeping a single execution environment warm between pings. The cost is trivial: at 512 MB and 100 ms per ping, one ping costs 0.05 GB-seconds — about four cents a month for 43,200 pings. The problem is concurrency. Each concurrent request needs its own warm environment, and a ping warms one environment, not ten. A function that serves three concurrent requests needs three warm environments, and a ping schedule cannot produce them. Warming by schedule is a reasonable stopgap for a single-instance API with predictable, low-concurrency traffic, and a false economy for anything with bursts.
Shrink the INIT instead of buying warmth
Every millisecond removed from Init Duration is a millisecond removed from every cold start, and it costs nothing per invocation. Import only what the handler needs at module scope, and move heavy clients and SDKs behind lazy initialization so they load on first use rather than at import. Keep the deployment package small — Lambda accepts up to 250 MB unzipped, but a package that large has a long load phase; tree-shake, drop dev dependencies, and prefer the AWS SDK's modular clients over the monolith. Allocate memory deliberately: Lambda scales CPU with memory, so raising memory from 128 MB to 512 MB shortens both initialization and execution, and the GB-second math often makes the larger allocation cheaper per request.
The platform-specific levers stack on top. On Vercel, Fluid compute is enabled by default for new projects as of April 23, 2025, and its automatic cold-start optimizations combine bytecode caching on Node.js 20 and above — production deployments only — with function pre-warming and optimized concurrency, where multiple invocations share one instance on Node.js and Python runtimes. On Workers, the isolate model removes the problem rather than mitigating it, but the eviction caveat applies: Cloudflare states that isolates may be spun down when they hit resource limits or are flagged, and that mutable state must not be stored in global scope. The right mental model is that Workers gives the latency for free and takes the persistent-connection convenience away.
Who should not optimize
Three operators should stop before the checklist. The first is the low-traffic hobby project on the free tier: Lambda's free tier covers 1 million requests and 400,000 GB-seconds a month, Workers' free tier covers 100,000 requests a day, and a cold start on a personal project is a rounding error. The second is the workload whose Init Duration is already under 100 ms with a cold-start rate under 10%. The third is the operator whose latency problem is the handler, not the initialization: if the REPORT line shows 2,000 ms of Duration and 150 ms of Init Duration, the cold start is 7% of the problem and the database query is the other 93%.
Execution checklist
- [x] Measure the cold-start rate: pull Init Duration from Lambda REPORT lines, or the equivalent from Workers and Vercel logs, and compute the rate and the average added latency with the two formulas above.
- [x] Shrink the INIT first: lazy imports, modular SDK clients, tree-shaken package, and a memory allocation tested against execution time — before buying any warmth.
- [x] Price the options: provisioned concurrency at $10.80 per 1 GB environment per month, SnapStart at the cache-plus-restore rates, ping warming at about $0.04 a month per environment.
- [x] Compute utilization: if it is above 60%, provisioned concurrency is cheaper than on-demand; if below, buy SnapStart or accept the cold starts.
- [x] Configure on a version or alias: never on $LATEST; verify the alias after every deployment.
- [x] Consider the isolate escape hatch: if the latency budget is sub-100 ms and the workload fits Workers' CPU limits, the platform removes the problem instead of pricing it.
- [x] Re-measure after 30 days: cold-start rate, Init Duration, and provisioned utilization — and decommission warmth that sits below 60%.
- [x] Alert on utilization below 60%: a monthly check that decommissions provisioned capacity that has drifted under the break-even.
- [x] Load-test the cold path: measure Init Duration under a burst before launch, not under steady traffic.
Founder & CEO Insight — Enow A. Jovial
Related reading on this site: the Cloudflare Workers versus Vercel edge functions comparison covers the two isolate-based platforms in depth; the CDN stale-while-revalidate and edge purge architecture guide covers the caching layer that keeps warm content close to the user; the high-traffic infrastructure comparison of Vercel, Dokku and Hetzner prices the platforms that host these functions; and the Lambda at the edge versus Cloudflare Workers playbook compares the two edge compute models directly. To price any of these options at the workload's own volume, run the numbers through the pricing calculator.