A cold start is the latency a serverless function incurs when the platform has to create a fresh execution environment before it can run the code. The AWS Lambda developer guide explains that when Lambda receives a request, the service “first prepares an execution environment,” during which it downloads the code, starts the environment, and runs any initialization code outside the main handler before finally running the handler itself. The AWS docs note that the first two of these steps - downloading the code and setting up the environment - “are frequently referred to as a cold start,” and that this added time both counts toward billed duration and adds latency to the invocation.
The opposite case is a warm start. After an invocation finishes, Lambda freezes and retains the execution environment for a period of time; if another request for the same function arrives, Lambda can reuse it. According to the AWS documentation, that second request “typically finishes more quickly, since the execution environment is already fully set up.”
AWS reports that cold starts typically occur in under 1% of invocations, with durations ranging from under 100 milliseconds to over a second, and notes they are more common in development and test functions, which are invoked less frequently than production workloads. The largest contributor is the developer’s own initialization code - importing libraries, loading configuration, and opening connections - which runs only when a new environment is created.
Cold starts are a defining trade-off of Function-as-a-Service: the same independent, scale-to-zero model that makes serverless efficient also means there is sometimes no warm environment ready, so the first request must wait for one to be built. The 2019 Berkeley View on serverless computing identifies this kind of startup and scheduling latency as one of the obstacles the field must address as it matures.