Lambda Cold Start Estimator
Estimate Lambda cold-start latency from runtime, package size, VPC attachment and init code, and see which factor dominates.
About Lambda Cold Start Estimator
A cold start is the sum of downloading and unpacking the artefact, booting the runtime and running everything outside your handler. Package download scales with artefact size, VPC attachment adds a fixed network setup cost, and heavy SDK or framework imports usually dominate everything else. The coefficients here are order-of-magnitude figures — read the real numbers from the initDuration field in your CloudWatch REPORT lines. Cold starts land on real user requests at exactly the wrong moment — during a deployment or a traffic spike — so knowing which of the four contributors dominates tells you whether to shrink the package, lazy-load clients, or pay for provisioned concurrency.
Formula
Lambda Cold Start
cold start ≈ runtime bootstrap + 8 ms per MB of package + 110 ms if VPC-attached + your init code, then multiplied by about 0.25 when SnapStart restores a snapshot.
- bootstrap
- Time for the managed runtime to start before your code runs
- init code
- Module imports, SDK clients and config loads outside the handler
- VPC penalty
- One-off Hyperplane ENI attachment for a VPC-attached function
Worked example
With the default values below, Lambda Cold Start Estimator returns Estimated Cold Start of 496. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Runtimeone of Node.js 20 — about 150 ms bootstrap, Python 3.12 — about 180 ms bootstrap, Go on provided.al2 — about 110 ms bootstrap, Rust on provided.al2 — about 90 ms bootstrap, Ruby 3.3 — about 260 ms bootstrap, .NET 8 — about 700 ms bootstrap, Java 21 JVM — about 850 ms bootstrap
- Node.js 20 — about 150 ms bootstrap
- Deployment package sizeaccepts 0.1–250 MB
- 12 MB
- Initialization code outside the handleraccepts 0–20,000 ms
- 250 ms
- Function is attached to a VPC
- No
- SnapStart or a pre-warmed snapshot is enabled
- No
- Warm invocation durationaccepts 1–900,000 ms
- 180 ms
- Invocations per monthminimum 0 requests
- 5,000,000 requests
- Share of invocations that cold startaccepts 0–100 %
- 2 %
Results
- Estimated Cold Start
- 496 ms
- First-request Latency
- 676 ms
- Cold Starts per Month
- 100,000
- Latency Added per Month
- 13.8 hours
- Dominant Contributor
- Initialization code outside the handler
Step by step
- 1Values used
- 2Lambda Cold Start
- 3Estimated Cold Start= 496 ms
- 4First-request Latency= 676 ms
- 5Cold Starts per Month= 100,000
- 6Latency Added per Month= 13.8 hours
- 7Dominant Contributor= Initialization code outside the handler
Assumptions and limits
- The result is derived only from the 8 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
How is Lambda Cold Start calculated?
cold start ≈ runtime bootstrap + 8 ms per MB of package + 110 ms if VPC-attached + your init code, then multiplied by about 0.25 when SnapStart restores a snapshot. A cold start is the sum of downloading and unpacking the artefact, booting the runtime and running everything outside your handler. Package download scales with artefact size, VPC attachment adds a fixed network setup cost, and heavy SDK or framework imports usually dominate everything else. The coefficients here are order-of-magnitude figures — read the real numbers from the initDuration field in your CloudWatch REPORT lines.
Why does Lambda Cold Start matter?
Cold starts land on real user requests at exactly the wrong moment — during a deployment or a traffic spike — so knowing which of the four contributors dominates tells you whether to shrink the package, lazy-load clients, or pay for provisioned concurrency.
What values do I need to enter?
This calculator takes 8 inputs: Runtime, Deployment package size, Initialization code outside the handler, Function is attached to a VPC, SnapStart or a pre-warmed snapshot is enabled, Warm invocation duration, Invocations per month, Share of invocations that cold start. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Is init duration billed?
For a standard on-demand invocation the initialization phase is not billed, which is why cold starts hurt latency more than cost. SnapStart restore time and provisioned-concurrency initialization are billed, and both change the arithmetic.
Does VPC attachment still cost ten seconds?
No. Before the Hyperplane rework, VPC-attached functions could take ten seconds or more to attach an ENI on a cold start. Shared ENIs cut that to roughly 100 ms, so VPC attachment is now a minor factor next to a bloated package or a slow framework boot.