Lambda Cold Start

Reviewed explanation

A Lambda cold-start path includes preparation of an execution environment before the function’s handler runs. Initialization starts the runtime and performs setup, including applicable code outside the handler. A warm invocation can use an environment that is already prepared. The distinction is preparation versus handler work, not a rule that a function is cold only on its first-ever call.

We use a deliberately ordinary on-demand event-function model. The trace says exactly when a fresh environment is prepared on the request path and when a prepared one is reused. It excludes provisioned concurrency, SnapStart, Durable Functions and Managed Instances, which can change where initialization, restoration or other work happens. Even on-demand Lambda can sometimes initialize environments ahead of requests; the trace is a chosen case, not a promise about every invocation.

Code outside the handler can prepare reusable objects, while the handler processes the particular event. In the given second invocation, environment A remains available and is reused, so its setup is not repeated. The handler still runs and can have its own permissions, dependencies, input validation or errors. Warm does not mean that the entire operation takes no time or is guaranteed to succeed.

The function may have been used many times before environment A exists. Scaling, environment retirement or failures can cause a later invocation to take a different preparation path. In the third case we explicitly choose new environment B. Do not infer reuse from the function name, the closeness of two requests, or a label that happened to be fast. A runtime can also reset and initialize again after an error; the no-error example below does not model that path.

The numbers below are invented to separate two parts of time: initialization on the modeled request path plus handler execution. We omit queueing, network transport and all other delays. For A’s first modeled request, 300 milliseconds of initialization plus 40 milliseconds of handler work gives 340 milliseconds. That arithmetic is not an AWS performance target, a cold-start threshold, a billing calculation or a guarantee that all warm calls are faster than all cold calls.

Treat reuse as an optimization, not the storage of record. A prepared environment can retain suitable objects or a temporary cache, but it can be replaced or shut down. An application should not depend on the next invocation receiving that same memory. Here every given read returns Seeds under the unchanged-storage assumption; the returned label is separate from whether a fresh or reused environment handled it.

Source collection

• AWS Lambda: Understanding the Lambda programming model

  Used in: Quick notes · Worked example · Lesson text

  Configured handler, invocation event/context, ordinary event-function environment reuse, concurrency and transient state.

  Describes the configured handler entry point, invocation event/context, initialization outside the handler, returned errors and qualified environment reuse. This lesson is scoped to an ordinary event-function example, not all Durable/Web/Managed Instances behavior, default runtime limits or prices.

• AWS Lambda: Execution environment lifecycle

  Used in: Quick notes · Worked example · Lesson text

  Init/Invoke, on-demand preparation, environment reuse/reset, suppressed initialization and SnapStart timing; no prices, default limits or universal lifetime.

  Explains Init/Invoke, possible environment reuse, resets/shutdown, and different timing for provisioned concurrency, SnapStart, Durable Functions and Managed Instances. On-demand environments can sometimes initialize ahead of requests. No latency distribution, billing claim, lifetime or guaranteed reuse is taken from the page.

Notes AI source review · 2026-10-17

AI source comparison recorded 2026-10-17. Human learner validation is pending.