What is a cold start in AWS Lambda, and why does the same function usually respond faster on the next invocation a moment later?

## The unit Lambda actually manages Lambda does not run "a function"; it runs your code inside an **execution environment** — an isolated sandbox (a Firecracker microVM) with your deployment package, the language runtime, a slice of memory, and its own writable `/tmp`. One environment handles **exactly one invocation at a time**. That single sentence explains nearly everything about Lambda scaling and cold starts: to serve two simultaneous requests, Lambda needs two environments; if it doesn't have a spare one, it has to build it, and building it takes time. ## The lifecycle: Init, Invoke, Shutdown An environment moves through three phases. **Init** happens once per environment. Lambda downloads and unpacks your code, starts any extensions, starts the language runtime, and then executes your function's *initialization code* — everything at module/static scope, outside the handler. In Node.js that is the top level of your module; in Python the module body; in Java static initializers and the constructor of your handler class. **Invoke** is the part you normally think of as "the function running": Lambda passes the event to your handler and waits for the response. This repeats for every request the environment serves. **Shutdown** happens when Lambda decides to reclaim the environment; the runtime and extensions get a chance to stop. A **cold start** is an invocation that had to pay for an Init phase first. A **warm start** is one routed to an environment that already exists. ## Freeze and thaw Between invocations Lambda **freezes** the environment rather than destroying it. Execution is suspended: background threads, timers, and pending I/O stop making progress, and they resume (thaw) only when the next event arrives. Two consequences follow. First, work you kicked off but did not await before returning may simply not finish — and may resume, confusingly, during a *later* invocation. Second, everything you built during Init is still in memory when the environment thaws, which is exactly why the second call is fast. ```javascript // runs once per environment (Init) — reused by every later invocation const client = new SomeClient(); export const handler = async (event) => { // runs once per request (Invoke) return client.doWork(event); }; ``` ## When cold starts actually happen - **First request after a deploy.** Publishing new code or changing configuration invalidates existing environments; the next requests all initialize fresh. - **Scale-out.** Traffic rising from 10 to 60 simultaneous in-flight requests means Lambda must stand up roughly 50 more environments, and each of those requests eats an Init. - **After idleness.** Lambda eventually reclaims unused environments. AWS does not publish the idle timeout, so never design as if a warm environment is guaranteed. - **Periodic recycling.** Environments are replaced over time even under steady traffic, for patching and health reasons. Steady, high-volume traffic therefore has a *low percentage* of cold starts, but a spiky or low-volume function can see them constantly. ## How you observe it Every invocation writes a `REPORT` line to CloudWatch Logs. On a cold start that line carries an extra `Init Duration` field: ``` REPORT RequestId: ... Duration: 12.34 ms Billed Duration: 13 ms Memory Size: 512 MB Max Memory Used: 90 MB Init Duration: 430.12 ms ``` Because only a subset of requests are cold, cold starts are a **tail-latency** problem: they barely move your p50 and can dominate p99. Judge them there, not on averages. ## What influences init time, and what to do Init time is dominated by how much work happens before your handler is reachable: runtime startup plus loading dependencies and constructing clients. Runtimes differ substantially — an interpreted or ahead-of-time-compiled runtime typically initializes faster than a JVM that must load and JIT a large classpath. Doing less at Init (lazy-loading rarely used dependencies, importing narrowly rather than pulling in an entire SDK) is the cheapest lever. When a workload cannot tolerate the tail, AWS sells two answers: **provisioned concurrency**, which keeps a pool of environments already initialized and waiting, and **SnapStart**, which restores an environment from a snapshot taken after Init instead of re-running it. Both remove the Init phase from the request path rather than making Init faster. What does **not** work is the folklore fix: a scheduled "ping" that invokes the function every few minutes keeps *one* environment warm and does nothing for the scale-out case, which is where cold starts actually hurt.