A “cold start” is the latency added when Lambda has to initialize a new execution environment before it can run a function — as opposed to a “warm” invocation, which reuses an environment already sitting around from a previous call. For a user-facing API, that difference can be the gap between a 50ms response and a multi-second one.
What actually happens during a cold start
The typical work involved — not a rigid sequence guaranteed to happen identically on every cold start — covers:
- Environment provisioning — setting up the execution environment (and, for a container image, pulling it).
- Runtime initialization (Node, Python, Java, etc.) — this varies a lot by language; Java and .NET typically take noticeably longer than Node or Python.
- Function-code loading and dependency/init-time work — module-level imports, SDK client construction, database connection setup.
- Invoke the handler with the actual event.
Steps 1–3 are the cold start. Step 4 happens on every invocation, warm or cold, and is usually fast by comparison.
What makes it worse
- Package/dependency size. A deployment package bundling an entire unused SDK, or node_modules with every dependency rather than just the ones used, adds directly to initialization time.
- VPC configuration can affect initialization latency. The historical ENI (elastic network interface) attachment penalty for VPC-attached functions has been substantially reduced by AWS’s Hyperplane-based networking — it’s a factor worth checking, not a given that every VPC-attached function is slower than a non-VPC one.
- Heavy init-time work. Constructing multiple SDK clients, loading a large config file, or running a synchronous network call at module load time all happen on every cold start, not just once.
- Runtime choice. Interpreted/JIT-warm languages (Node, Python, Go) generally cold-start faster than JVM-based or .NET runtimes, which pay a startup cost for the runtime itself — though the actual difference depends heavily on init code, dependency size, and memory configuration, not the runtime alone.
Reducing it
- Provisioned concurrency pre-initializes a specified number of execution environments, avoiding cold starts for invocations served by that pre-initialized pool — provided capacity is sufficient; traffic exceeding it can still spill over into on-demand (cold-starting) environments, and invocations must go through the correctly configured version or alias to hit the pool at all. This runs continuously at a cost whether invoked or not.
- Trim the package. Bundle only what’s imported; for Node, a bundler (esbuild) that tree-shakes unused code measurably helps.
- Move work out of module scope only if it’s not needed on every invocation — but keep genuinely reusable things (a database connection, an SDK client) at module scope so they’re built once per environment, not once per invocation.
- Consider a lighter runtime for the latency budget — a lean Node.js or Go function is a reasonable starting point for reducing startup overhead, but benchmark the actual workload rather than assuming a runtime choice alone settles it; initialization code and dependency footprint usually matter more.
- SnapStart snapshots an initialized execution environment and resumes from it, cutting cold-start time without the continuous cost of provisioned concurrency. As of AWS’s current documentation, it supports Java 11+, Python 3.12+, and .NET 8+ — not Node.js, Ruby, or OS-only runtimes — and it’s incompatible with provisioned concurrency, so check current runtime support and restrictions before relying on it.
When cold starts don’t actually matter
A function triggered by an async event (an S3 upload, an SQS message, a scheduled job) rarely needs cold-start optimization — nothing is waiting on a synchronous response. The cost/effort of provisioned concurrency is best reserved for functions sitting directly behind a user-facing API Gateway or ALB request.
See also: Cloud Service Status Pages: AWS, Google, Apple & Azure for checking whether a latency spike is actually a provider-side incident before chasing a cold-start fix, and S3 Bucket Policies vs IAM Policies: What’s the Difference? for the permissions layer Lambda functions typically sit behind.