Execution Environments and Cold Starts
Execution Environments and Cold Starts
Lambda runs your function inside a sandbox it reuses across invocations. Each environment passes through two phases: init (fetch the package, start the runtime, run top-level code) and invoke (your handler). A cold start is creating a fresh environment — provisioning plus init — before the first request is served. Warm invocations freeze and resume the same environment, which is why module-scope code (SDK clients, DB pools) survives between calls.
Cold-start time grows with package size, slow init code, and heavier runtimes; VPC-attached functions long paid a networking penalty, now largely removed by Hyperplane ENI attachment. The CloudWatch REPORT line separates Init Duration from Duration, so you always know which phase you are tuning.
Layers, Provisioned Concurrency, SnapStart
Layers, Provisioned Concurrency, SnapStart
Layers share code across functions: attach up to five, contents extract under /opt (in Python, /opt/python lands on sys.path), with the combined unzipped size of function plus all layers capped at 250 MB.
Provisioned concurrency (PC) pre-runs init on N environments attached to an alias or version, so invocations skip cold starts. Application Auto Scaling can raise or lower N for load patterns; PC is billed whenever enabled, even while idle.
SnapStart snapshots an environment after init, so new environments restore the snapshot instead of replaying init — a strong fit for Java services where class loading and init dominate cold starts.
Tuning and Pitfalls
Tuning and Pitfalls
Ordering mistakes are the usual failure: publish a version, create an alias, then attach PC to the alias — PC cannot target $LATEST, and a new deployment briefly re-warms before PC catches up. PC also cannot react within milliseconds to a burst beyond its configured count, so pair it with scaling targets and reserve capacity so other workloads cannot consume it.
With SnapStart, anything opened during init (database connections) may be stale once an environment is restored or frozen — revalidate on first use. Initialize clients outside the handler but inside the environment to reuse them.
Interview: quote Init Duration vs Duration from the logs, name the fix (trim package, move code out of init, PC, SnapStart), and state what it costs.
Quiz
1. What counts as a cold start?
2. Where does layer code land for a Python function?
3. When does provisioned concurrency stop helping?
Flashcards
Question
Init vs invoke phase
Click to reveal answer
Answer
Init fetches code and runs top-level statements; invoke runs the handler. Cold start = provisioning + init.
Question
Provisioned concurrency
Click to reveal answer
Answer
Pre-initialized environments attached to an alias/version; billed while enabled, even idle.
Question
SnapStart
Click to reveal answer
Answer
Snapshots the environment after init so new instances restore instead of re-running init (strong for Java).
Question
Layers limits
Click to reveal answer
Answer
Up to 5 layers; function + layers combined ≤ 250 MB unzipped; content under /opt.
Question
Where to measure
Click to reveal answer
Answer
CloudWatch REPORT splits Init Duration from Duration — tune the phase that actually hurts.
Revision Notes
Key Takeaways
- 1. Module-scope init runs once per environment — keep it fast and side-effect safe
- 2. PC removes cold starts for a price; SnapStart attacks init cost for heavy runtimes
- 3. Read Init Duration before optimizing invoke code
Interview Tips
- • Walk the lifecycle (provision → init → invoke → freeze) and place each optimization on it
- • Justify PC with an SLA number and say how you would right-size it from concurrency metrics
Cheat Sheet
Cold start = provision+init, not slow handler. Layers ≤5, 250MB combined, under /opt. PC: version→alias→attach, billed idle. SnapStart snapshots post-init. Measure Init Duration vs Duration in REPORT.