Cold Start

What is a cold start?

A cold start is the extra latency incurred when a serverless function is invoked without a warm, ready execution environment waiting. The platform must provision a sandbox (Firecracker microVM or container), load your code and dependencies, initialize the runtime, and run any startup code — then handle the request. A warm invocation skips all of it. The gap between the two is the cold start, and it’s the single most-discussed drawback of the serverless model.

What actually drives the delay

Cold start cost is dominated by things you control. Package size: a bloated deployment with heavy dependencies takes longer to load — trimming it is the highest-leverage fix. Runtime: interpreted/JIT runtimes with large startup costs (JVM, .NET historically) cold-start slower than lean ones (Go, Rust, Node); this genuinely influences language choice for latency-critical functions. Initialization code: work done outside the handler runs on every cold start, so opening database connections, loading models, or parsing config at module scope is paid repeatedly — but code inside the handler that could be hoisted to run once (and reused across warm invocations) is the classic optimization. VPC attachment historically added ENI setup latency (much improved, still nonzero).

Managing it in production

The levers: provisioned concurrency (keep N environments warm — eliminates cold starts at the cost of paying for idle, which partly defeats scale-to-zero economics), lean packages and fast runtimes, connection reuse via pooling proxies, and honest workload triage — latency-critical user-facing paths may not belong in cold-start-prone serverless at all, while async and batch work never notices. The 2026 reality: cold starts shrank dramatically (sub-100ms for lean functions) but never vanished.

What people get wrong

• Heavy initialization inside the handler instead of hoisting one-time setup to module scope for warm reuse.
• Provisioned concurrency everywhere — it re-introduces the idle cost serverless was meant to remove; apply it surgically.
• Ignoring package bloat — the easiest cold-start win, routinely left on the table.

Primary source: AWS Lambda — cold starts and optimization

Mitigation Strategies

Common techniques for reducing cold start impact include provisioned concurrency (paying to keep a set number of execution environments warm and ready, eliminating cold starts for that reserved capacity at the cost of paying for idle capacity), minimizing function package size and dependencies (since a smaller deployment package initializes faster), and choosing runtimes with inherently faster cold start characteristics — compiled languages like Go and Rust generally cold-start faster than JVM-based languages like Java, whose runtime initialization overhead is comparatively larger. For latency-sensitive, user-facing applications where even occasional multi-second delays are unacceptable, these mitigations (particularly provisioned concurrency) are often a worthwhile tradeoff against serverless’s cost efficiency, while for background or batch processing where occasional latency spikes don’t matter, cold starts are frequently a non-issue not worth optimizing for at all.