In a Functions-as-a-Service (FaaS) platform like AWS Lambda, what is the difference between a 'cold start' and a 'warm start' when a function is invoked, and why does it happen?

## What the platform does when a request arrives To understand cold starts you first need to understand that a FaaS platform does not keep a server sitting around waiting for your code to run. Instead, when a request or event arrives, the platform's control plane finds (or creates) an **execution environment** - typically a lightweight, sandboxed container or a microVM such as AWS's Firecracker - and loads your function's code into it. If no existing environment is available (the very first call, or a burst of concurrent calls that exceeds the number of already-running environments), the platform must perform what's called a **cold start**: - it downloads or mounts your deployment package (zip file or container image) - it starts the language runtime process (the JVM, the Node.js V8 engine, the Python interpreter, the .NET CLR, and so on) - it then executes any code that lives outside your handler function - imports, static initializers, SDK client construction, configuration loading Only after all of that 'init phase' completes does the platform invoke your actual handler with the event payload. All of this adds latency on top of your function's own execution time, and that added latency is what people mean by 'the cold start penalty' or 'cold start tax.' ## The warm start A **warm start** is the opposite case: a later invocation is routed to an environment that is still alive from handling an earlier request. Because the runtime is already booted and your init-phase code has already run, the platform can go straight to invoking the handler, so the extra latency disappears and you're left with just your business logic's execution time, often in the single-digit-to-low-double-digit milliseconds. This is why the same function can log 20ms on one call and 900ms on another with no code difference - the difference is purely whether the platform had a warm environment sitting ready. ## Why the model exists This model exists because it is what makes serverless economically and operationally attractive: providers only want to pay for (and bill you for) compute that is actively doing work, and they want to scale environments up and down **elastically** without you provisioning capacity. If every function kept a server running permanently, you'd be back to paying for idle EC2 instances and managing autoscaling groups yourself - the whole point of FaaS is that the platform handles that elasticity for you, and the cost of that elasticity is the occasional cold start when demand grows or when an environment has been idle long enough to be reclaimed. ## The trade-off The trade-off is **latency predictability** versus **cost and operational simplicity**. Cold starts are worse the 'heavier' your runtime is: - a Go or Rust or Node.js function with a small deployment package might cold-start in tens of milliseconds - a JVM-based Java or .NET function with a large dependency tree and a big deployment artifact can take one to several seconds, because the JVM/CLR itself is slow to boot and JIT-warm Higher configured memory usually also grants more CPU, which speeds up cold starts, so bumping memory is a common cheap mitigation. VPC-attached functions historically had much worse cold starts too, because the platform had to attach an elastic network interface before the function could reach VPC resources - most providers have since optimized this away, but it's a real historical failure mode worth knowing. ## Where it shows up in production In production, cold starts show up as latency spikes concentrated in your p95/p99/p99.9 percentiles rather than your median or average - a dashboard that looks fine on p50 latency can be hiding a nasty tail. They bite hardest in three scenarios: - **(1) low-traffic or spiky functions**, where environments idle out between calls and every burst starts with a wave of cold environments (a 'cold start storm' during a traffic spike, since the platform must provision N new environments simultaneously to handle N concurrent new requests) - **(2) synchronous, latency-sensitive paths** like an API Gateway-fronted Lambda backing a user-facing web request, where a multi-second cold start can breach a client timeout or an SLA - **(3) after a deployment**, where every environment for the new code version starts cold because the platform can't reuse containers running the old code ## A concrete example A concrete real-world example: a team runs a Java Spring Boot function on AWS Lambda behind API Gateway for a checkout API. Under steady low traffic, most requests land on cold environments because idle containers get recycled between sporadic calls, and p99 latency is dominated by JVM boot plus Spring context initialization (often 2-5 seconds) rather than the actual checkout logic. The team mitigates this with AWS Lambda Provisioned Concurrency, which keeps a fixed number of environments pre-initialized and warm at all times, trading a flat hourly cost for eliminating the cold-start tail on the critical path - a decision that only makes sense once cold starts are shown to be violating a real latency SLA.