Cold Start

A cold start adds latency when a serverless platform prepares an execution environment before running application code. AWS Lambda documents code download and environment setup as contributing to this delay and bills the time as part of invocation duration. The lifecycle discussion here concerns standard Lambda function execution; other modes have separate rules.

After an invocation, Lambda can freeze an environment and reuse it later. A warm start reuses that preparation. Reuse is not guaranteed, so startup latency must be assessed from the workload’s observed behavior and configuration.

Judge it by frequency, size, and who notices

AWS describes cold starts as typically occurring in fewer than 1% of invocations, with durations ranging from under 100 milliseconds to over a second. These are general observations, not a frequency or latency guarantee for your function. Measure three dimensions against the workload’s deadline.

• How often? Traffic, scale-out, configuration changes, and environment replacement affect reuse. Steady traffic can increase warm reuse but does not guarantee it. Infrequent calls may encounter more cold starts; measure the rate rather than assuming every sparse workload behaves the same way.
• How big? AWS identifies initialization code as a major contributor: imports, configuration, and connection setup can add substantial delay. Profile those steps along with platform and runtime startup instead of assuming a fixed latency.
• Who experiences it, and against what deadline? A background job usually absorbs an extra second; it does not if the queue has a completion deadline, or if a burst of cold starts slows enough concurrent workers to build a backlog. A user-facing request is the clear case, and one that fans out to several functions can meet the penalty more than once.

A percentile can miss rare slow starts. In a simplified distribution where every cold request is slower than every warm request, let q be the cold fraction and p the percentile expressed as a fraction. The percentile reaches the cold region at approximately p > 1 – q: its remaining upper tail must be narrower than the cold fraction. Exact boundaries depend on sample size and percentile convention. Using nearest-rank percentiles, 10,000 requests with 5 at 2,100 ms and 9,995 at 100 ms have a mean of 101 ms, p99 and p99.9 of 100 ms, and p99.99 of 2,100 ms.

Report cold-start counts and rates, initialization duration, latency percentiles, and the sample size and time window together. Actual warm and cold latency distributions can overlap, so latency alone does not identify a cold start. A sample of 100 requests can contain a 0.5% event, but cannot estimate that rate reliably: under independent occurrence with probability 0.005, the chance of observing none is about 60.6%. Use platform initialization signals alongside request latency.

AWS observes that cold starts are often more frequent in development and test workloads. Treat that as a reason to compare traffic and configuration with production before choosing a mitigation; a development observation does not establish the production impact.

What happens during initialization

The Init phase starts extensions, bootstraps the runtime, and executes static code such as imports and connection setup. For on-demand Lambda, the initial Init attempt has a 10-second limit. If it does not finish, Lambda retries Init at the first invocation using the configured function timeout. Ten seconds is therefore not a universal bound on initialization delay. Provisioned concurrency, SnapStart, and Lambda Managed Instances have different initialization rules; check the selected mode’s lifecycle.

Package size and static initialization work are useful optimization targets. Connection setup also depends on remote services and network conditions, which the function does not fully control. Profile the stages to distinguish code changes from dependency or configuration problems.

Objects initialized outside the handler can be reused in the same environment. Initialize common dependencies there when useful, and consider loading rarely used objects on demand. Lazy initialization moves work onto the first request using that path; test its latency and failure handling.

Four ways to reduce it, and what each costs

Approach	Effect	Cost
Trim the package and imports	Can reduce download and initialization work by removing unused dependencies	Engineering and compatibility testing; verify packaging and runtime behavior after changes
Defer rarely used initialization	Shortens Init for the common path by loading heavy objects only when a code path needs them	Slightly more code, and a slower first request on those paths
Pre-initialize environments (provisioned concurrency)	The documented purpose is that it “pre-initializes execution environments, reducing cold starts” — environments are ready before requests arrive	You pay for the reserved environments whether or not they are used, which removes scale-to-zero economics
Snapshot-based startup	Resumes new environments from a persisted snapshot of an initialized environment instead of initializing from scratch	Runtime and configuration constraints, plus care with anything captured in the snapshot that should be per-environment — a cached credential or random seed, for instance

Start with measured initialization costs and evaluate package or code changes against the engineering effort and validation they require. Lazy loading can improve the common path while delaying a less common one. Pre-initialization and snapshots have pricing or configuration tradeoffs; choose them when measurements show that they help meet the required deadline.

When to stop caring

Initialization may need little optimization when it is a small share of a long batch run, or when measured startup delays leave sufficient margin before the completion deadline. Check backlog growth and bursts as well as single-request duration. Asynchronous execution alone does not remove a deadline, and initialization is not universally bounded by a second.

How cold starts fit with the wider question of choosing between virtual machines, containers, and serverless is worked through in You Rented the Server, Not the Outcome; the statelessness the model requires is covered in stateless service.

References

• AWS Lambda Developer Guide, Understanding the Lambda execution environment lifecycle