Cold starts

A cold start is the extra latency when the platform must create a new execution environment, load your code and run your setup code before the handler can run. A warm call reuses an environment that has already finished setup. Cold starts matter for user-facing APIs. They barely matter for queue workers, where the queue's timeouts absorb the delay.

Walking through the budget

A cold start is roughly the sum of three parts:

cold ≈ platform provision + runtime boot + your init (imports, DI, DB clients)

Your code is the part you control. Rough orders of magnitude, as of 2025–2026 and highly workload-dependent:

The mitigations

1. Ship smaller artifacts. Fewer dependencies and tree-shaken bundles. Large scientific libraries start slowly everywhere.
2. Move setup out of the hot path. Do not open database pools or load large models at import time, unless every call needs them. With SnapStart or provisioned concurrency, setup runs once, so it can be front-loaded.
3. Keep warm capacity. Provisioned concurrency on Lambda, or minInstances on Cloud Run, keeps environments ready. You pay for idle time.
4. Use SnapStart for Java. Lambda snapshots an initialized microVM and restores it on scale-out. Watch for uniqueness bugs: regenerate IDs, refresh credentials, and do not assume a fresh /tmp.
5. Prefer containers that handle many requests at once. One warm Cloud Run instance can absorb a burst that would start dozens of single-request Lambda environments.
6. Measure VPC placement. Attaching a function to a VPC used to add seconds per cold start. Today it costs much less, but wrong subnet sizing or a missing NAT still hurts. Measure with the VPC on and off before you blame the runtime.

Memory is a dial

On Lambda, memory also sets the CPU share. Cost is billed in GB-seconds, which is memory in GB times duration in seconds.

512 MB, 400 ms  ->  0.5 GB x 0.4 s  = 0.20 GB-seconds
1 GB,   150 ms  ->  1.0 GB x 0.15 s = 0.15 GB-seconds   (faster and cheaper)

Doubling memory can cut the duration by more than half, which lowers the bill. Always measure. Tools such as AWS Lambda Power Tuning sweep the settings for you.

Common mistakes

• Blaming the runtime for slow init code. Heavy imports and open pools cost time in every cold start.
• Buying provisioned concurrency for nightly batch. You pay for idle capacity nobody uses.
• Measuring cold starts only on a laptop. Test in the real platform.

Check yourself

1. Name two parts of a cold start. Answer: platform provisioning, runtime boot, and your own init code such as imports and database clients.
2. When is provisioned concurrency worth paying for? Answer: on a user-facing path with spiky traffic and a tight p99 target. Skip it for asynchronous or nightly work.

Key takeaways

• A cold start is platform provisioning, runtime boot, and your init.
• Shrink your init and package before you buy warm capacity.
• Pay for warm capacity only on latency-sensitive paths.
• Next, event sources and retries covers what triggers functions, and what happens when they fail.

Further learning

The AWS blog post on SnapStart explains the restore model in detail. The Power Tuning project automates the memory sweep.

Starting up faster with AWS Lambda SnapStartThis blog written by Tarun Rai Madan, Sr. Product Manager, AWS Lambda, Mike Danilov, Sr. Principal Engineer, AWS Lambda, and Colm MacCárthaigh, VP/Distinguished Engineer, EC2. AWS Lambda SnapStart is a new performance…Amazon Web Services

AWS Lambda Power TuningAWS Lambda Power Tuning is an open-source tool that can help you visualize and fine-tune the memory/power configuration of Lambda functions. It runs in your own AWS account - powered by AWS Step Fu...GitHub