Decide on patching first and cold start second. AWS says cold starts typically occur in under 1 percent of invocations and range from under 100 ms to over 1 second, and provisioned concurrency exists to reduce them. A packaging choice that makes patching slow rarely repays a small, unmeasured latency gain.
What AWS says about cold starts
The Lambda execution environment documentation describes a cold start as the preparation of an environment: downloading your code, starting the environment and running initialization code outside the handler. It states cold starts typically occur in under 1 percent of invocations, that the duration varies from under 100 ms to over 1 second, and that they are more common in development and test functions. For predictable start times it recommends provisioned concurrency, which pre-initializes execution environments.
So the frequency is low and a tool exists. That frames the trade honestly: cold start is real but bounded.
The packaging options and what each costs
| Option | Patching | Cold start note |
|---|---|---|
| Dependencies in the zip | Rebuild per function | Larger package to download |
| Shared layer | One layer update, then roll each function to the new version | AWS says layers for Go and Rust can increase cold start |
| Container image | Rebuild on a new base and dependency set | Keep images small, multi-stage builds help, per AWS |
| Runtime-included libraries | AWS updates them periodically | Smallest package, but less control |
Regular Lambda layers do not patch themselves. Each function must be updated to the new layer version, covered in how to roll out a patched Lambda layer.
A decision guide
- Is the function on a hot, user-facing path? If not, ignore cold start and optimize for patchability.
- If it is, measure. Record cold start and warm latency for your actual package. Do not rely on a general claim.
- Trim before you restructure. Removing unused dependencies cuts size and risk together.
- Consider provisioned concurrency for the few paths that need steady latency, and remember that it keeps environments pre-initialized with the version configured.
- Never trade away the ability to rebuild fast. If a choice means a patch takes days, it needs a strong reason.
Where startup time hides
AWS documents that static initialization code runs before the handler and that the Init phase is limited to 10 seconds for standard functions. Heavy imports, large clients and eager setup all run there. Lazy loading rarely used dependencies is a safe optimization, as long as the dependency is still declared and scanned.
Patching latency is the number to track
Cold start is easy to see on a dashboard. Patch latency is not, unless you track it: the time from a fix release to the fix running in production. Add it to your engineering metrics next to cold start. A team that watches only the first will optimize the wrong thing.
Try it yourself
The fix available now demo shows the gap between a fix being published and being applied. That gap is the metric that matters here.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard's dependency scanning and reachability analysis show which findings need a fast fix, and autonomous remediation can open fix pull requests, which are off by default with every category on Manual. Free scan: gold.safeguard.sh/scan.
Quick check
How often do Lambda cold starts happen?
AWS says they typically occur in under 1 percent of invocations, more often in development and test functions.
Is provisioned concurrency a security feature?
No. It pre-initializes execution environments to reduce cold starts. It does not patch anything.
Sources
- Understanding the Lambda execution environment lifecycle, AWS documentation
- Managing Lambda dependencies with layers, AWS documentation
- Create a Lambda function using a container image, AWS documentation
Last reviewed: 19 October 2026.
