Lambda Cold Start Optimization

Prerequisites: completion of Lambda Fundamentals; a function you can attach to API Gateway or invoke synchronously to measure latency.

Version note: verified against docs.aws.amazon.com/lambda/latest/dg/snapstart.html, July 2026. SnapStart currently supports Java 11/17/21+, Python 3.12 and later, and .NET 8 and later — it does NOT support Node.js, Ruby, Go, container-image functions, or provided.al2/provided.al2023 custom runtimes. It's also incompatible with Provisioned Concurrency (pick one per function version), Amazon EFS, and ephemeral storage over 512 MB, and only applies to published versions/aliases, never $LATEST. Because of the Node.js gap, this project uses Python 3.13 to demonstrate SnapStart and a Node.js 22.x function to demonstrate Provisioned Concurrency, so you see both tools on the runtime each is actually built for.

A cold start happens whenever Lambda has to build a fresh execution environment before it can run your handler: download the code, start the runtime, and execute everything at module scope before your handler is even called. A warm invocation skips straight to the handler. The gap between the two is entirely a function of how much work your initialization code does and which runtime you're on — interpreted languages like Python and Node.js typically cold-start in the 100-500ms range, while a JVM function initializing a full framework can run 2-8 seconds without mitigation.

This matters disproportionately for synchronous, user-facing paths (an API behind API Gateway, or — increasingly — an AI agent chaining multiple tool calls where every cold start in the chain adds directly to what the end user waits for) and barely matters at all for a background SQS consumer with no one watching a spinner. Optimize where it's actually felt; don't reflexively apply Provisioned Concurrency to every function in an account.