How does AWS Lambda's execution environment reuse actually work, and why does that make cold starts disproportionately affect low-traffic or bursty functions?

After a Lambda function finishes an invocation, AWS keeps its execution environment (the initialized runtime, loaded code, and any state outside the handler) warm for a period, and a subsequent invocation that arrives while it's still warm reuses it — skipping the expensive initialization (cold start) entirely. This only helps when invocations are frequent enough that a warm environment is still around when the next one arrives; a low-traffic function with long gaps between invocations, or a bursty function where many concurrent invocations arrive faster than warm environments can be reused one-at-a-time, ends up paying the cold-start cost far more often than a steady, high-throughput function does.

A Lambda "cold start" is the cost of provisioning a fresh execution environment: downloading the code package, starting the runtime, and running any initialization code outside the handler (imports, SDK client setup, connection pool creation) before the handler itself can run. AWS mitigates this by keeping a used execution environment around for a period after it finishes handling an invocation, so a subsequent invocation can reuse it — the code, runtime, and any initialized state (a database connection, a loaded configuration) persist across invocations of the same environment, which is why initialization code placed outside the handler function only runs once per environment, not once per invocation.

The reuse only pays off if a new invocation actually arrives while a warm environment exists and is free to take it. This creates two distinct patterns where cold starts remain common despite reuse existing at all:

Low-traffic functions: if invocations are spaced far enough apart (Lambda's warm-environment retention isn't indefinite — AWS doesn't guarantee a specific duration, and idle environments get recycled after some period of inactivity), by the time the next invocation arrives, the previous environment has already been reclaimed, forcing a fresh cold start every time. A function invoked once every 20 minutes essentially never benefits from reuse, regardless of how well reuse works in principle.

Bursty functions: if many invocations arrive concurrently or in rapid succession, each concurrent invocation needs its own execution environment — a single warm environment handles one invocation at a time, not many simultaneously. A sudden burst of 50 concurrent requests to a function that normally handles one at a time means up to 49 of those requests hit fresh, cold environments, because there simply aren't 50 warm environments sitting around for a function that rarely sees that concurrency level. Reuse helps the steady-state, one-at-a-time case; it does nothing for the sudden-fan-out case, since environments can't be pre-created faster than concurrent demand requires them.

Both patterns explain why a function that looks "generally fine" in aggregate p50 latency can still have a visibly bad p99 — the tail is disproportionately made up of exactly these cold-start-prone cases (long gaps, sudden bursts), which a low-traffic or spiky workload hits far more often than a steady high-throughput one does.

• Execution environment reuse lets a subsequent invocation skip cold-start initialization only if a warm environment is still around and free when it arrives.
• Low-traffic functions with long gaps between invocations rarely benefit from reuse, since idle environments get reclaimed before the next invocation shows up.
• Bursty/concurrent traffic needs one environment per concurrent invocation — reuse doesn't help fan-out, since environments can't be pre-provisioned faster than sudden demand.
• This is why p99 latency (dominated by cold starts) can look much worse than p50 for exactly these traffic patterns, even when the function's steady-state performance is fine.

• AWS: Lambda execution environment
• AWS: Understanding AWS Lambda cold starts
• AWS: Configuring provisioned concurrency