How do Lambda execution environments and cold starts work?

Follow the execution-environment lifecycle

During initialization, Lambda prepares extensions, the runtime, and function code. During invocation, the runtime calls the handler with the event. Lambda may freeze and later reuse the environment, and eventually shuts it down.

Code outside the handler can initialize SDK clients, configuration, and reusable connections once per environment. Keep this work purposeful because it contributes to initialization latency and can fail before the handler begins.

Understand when initialization appears

Initialization occurs when capacity needs a new environment, including scale-out and replacement. Deployment changes, configuration changes, runtime behavior, provisioned-concurrency configuration, and long idle periods can affect when new environments appear.

Cold-start impact is a distribution, not one fixed number. Runtime, package size, dependency initialization, networking, memory, extensions, and traffic shape all influence the measured result.

Optimize the work you can measure

Remove unused dependencies, import only what is needed, initialize clients efficiently, select appropriate memory, and avoid blocking network calls during startup unless they are necessary. Measure initialization separately from handler duration.

For latency-critical paths, evaluate provisioned concurrency and runtime-specific capabilities against an explicit service-level objective. Do not pay to eliminate occasional initialization that users never observe.

Design correctness without environment reuse

Store durable state outside the execution environment. Files in temporary storage, in-memory caches, and open connections may be reused, but code must tolerate an empty environment and reconnect safely.

Never put request-specific sensitive data into reusable global state. Reset mutable state, validate connection health, and make handlers idempotent so retries or replacement environments cannot corrupt an operation.