Cold Start
The latency penalty when a serverless function runs after being idle — the defining performance tax of [serverless](/glossary/serverless/), and the thing every FaaS optimization targets.
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
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.