cold-start-budget-reference

Overview

Per aws.amazon.com/blogs/compute on cold starts (opens in new window), Lambda's cold start has three phases:

1. Init - download deployment package, unzip, bootstrap the runtime (Node/Python/Java/etc.).
2. Init code - execute module-level imports + global setup.
3. Invoke - the actual handler call.

Phases 1 + 2 are the "cold" part. Phase 3 is what runs every invocation (cold or warm).

When to use

• Designing a latency budget for a Lambda / Workers / Edge function.
• Investigating "p95 is fine but p99 is 5s."
• Choosing a runtime - Cloudflare's isolate model is qualitatively different from Lambda containers.
• Auditing provisioned-concurrency / SnapStart configurations.

How to use

1. Look up the runtime's typical range in the per-runtime budget table (e.g. Node.js 256MB is 200-700ms; Java 11 without SnapStart is 1.5-6s).
2. Set the latency budget as two lines: p50/p95 tracks warm performance, and a separate p99 line absorbs the cold-start tail.
3. Force a cold start (deploy, or wait past the idle-evict window) and record p95 first-invocation latency against the budget.
4. If cold starts breach budget, apply the matching mitigation from below: SnapStart (JVM/.NET), provisioned concurrency, package-size trimming, lazy imports, or a pre-compiled runtime (Go/Rust).
5. Add the build-step and monitoring assertions from Testable behaviours (zipped artifact < 50MB, init phase < 500ms, CloudWatch Init Duration).
6. Re-measure after each change and confirm the p99 tail moved, not just p50/p95.

Per-runtime cold-start budgets

Per AWS, Cloudflare, Vercel docs (typical ranges; bigger packages and bigger memory-class skew higher):

The "Workers / Edge" qualitative leap is the isolate model: each function is a V8 isolate, spun up in microseconds per developers.cloudflare.com (opens in new window) - no container, no OS startup.

Mitigations

Provisioned concurrency (AWS Lambda)

Per docs.aws.amazon.com/lambda (opens in new window): keeps N execution environments pre-initialised. Eliminates cold starts up to N concurrent requests; you pay for the keep-warm time.

Trade-off: cost. A constant N=10 provisioned concurrency for 30 days ≈ $30-300 depending on memory class.

Lambda SnapStart (Java / .NET)

Per docs.aws.amazon.com/lambda/latest/dg/snapstart.html (opens in new window): takes a snapshot of the initialised JVM and restores from it on each cold start. Reduces Java cold starts from 1.5-6s → 100-300ms.

Caveats:

• State snapshot includes connections, random seeds; can't have per-instance unique values frozen.
• Hooks beforeCheckpoint / afterRestore let you re-prime non-serializable state.

Package-size discipline

Lambda cold-start scales with deployment-package size. Per AWS: keep under 50MB (zipped) → cold start in the 200-800ms range. Larger packages → seconds.

Avoid heavy module-level imports

Init code runs once but on every cold start. Heavy imports (database connection pool init, large dependency trees) inflate init time.

# Bad: top-level
import heavy_lib            # 2s import time
def handler(event, ctx):
    return heavy_lib.do_thing(event)

# Better: lazy-import
def handler(event, ctx):
    import heavy_lib
    return heavy_lib.do_thing(event)

Lazy imports add per-warm-call latency but reduce cold-start spike.

Runtime choice

Pre-compiled runtimes (Go, Rust) have far lower cold starts than managed runtimes (Java, Python). For latency-critical paths, runtime choice is a primary lever.

Testable behaviours

Worked example

A Java 11 Lambda (512MB) serves a low-traffic checkout callback. Users report occasional multi-second waits, though the dashboard p95 looks healthy.

1. The per-runtime table puts Java 11 without SnapStart at 1.5-6s cold start; p95 hides it because cold starts land in the p99 tail.
2. Enable SnapStart, which snapshot-restores the initialised JVM and drops the cold start to the 100-300ms range.
3. Re-prime non-serializable state in an afterRestore hook so a stale pooled DB connection is not frozen into the snapshot.
4. Force a cold start (wait past idle-evict) and compare Init Duration before and after; confirm the p99 line, not just p95, falls.

Result: the cold-start tail drops from ~5s to the 100-300ms range with no provisioned-concurrency spend.

Anti-patterns

Limitations

• Cold-start measurement is platform-side. CloudWatch Init Duration metric is canonical for Lambda; Workers / Edge expose their own.
• SnapStart caveats are subtle. State that survives the snapshot may be wrong (random seeds, connection state).
• Provisioned-concurrency is regional. Multi-region Lambdas need PC per region.
• Workers / Edge are not free of all variance. First request per (script, region) still has 5-30ms init.
• Doesn't address steady-state throughput. Cold start is one metric; concurrency-limit + duration are separate.

References

• AWS Lambda cold-start blog: aws.amazon.com/blogs/compute (opens in new window).
• Lambda SnapStart: docs.aws.amazon.com/lambda/latest/dg/snapstart.html (opens in new window).
• Cloudflare Workers isolate model: developers.cloudflare.com/workers/reference/how-workers-works (opens in new window).
• Vercel Edge Runtime: vercel.com/docs/functions/edge-runtime (opens in new window).
• Companion catalog: lambda-timeout-budget-reference.
• Consumed by: aws-sam-local-testing, lambda-test-tools-net, cloudflare-workers-miniflare, vercel-edge-runtime-testing, netlify-functions-tests, serverless-framework-test-plugin, serverless-integration-test-builder.