Warm Pool
Pre-initialised instances held in a stopped or standby state so that scaling out skips boot and application warm-up.
Autoscaling reacts in minutes: detection interval, instance launch, operating system boot, container pull, application start, JIT warm-up, cache fill, connection pool establishment. A traffic spike arrives in seconds.
A warm pool holds instances that have already completed most of that work. Bringing one into service is a resume rather than a launch, cutting time-to-useful from minutes to tens of seconds or less.
The trade is cost against readiness, and providers offer several points on it: instances stopped (cheapest, storage only, still needs a boot), hibernated (memory preserved, resumes fast, more expensive), or running but out of rotation (instant, full cost).
Related mechanisms with the same purpose: provisioned concurrency for serverless functions, pre-pulled images on nodes, and simply keeping a higher baseline before a known event.
The design point worth stating: warm pools treat cold start as a capacity planning problem rather than a tuning problem. Before paying for one, check whether application start-up can be shortened instead — lazy initialisation, smaller images, deferred cache warming — because that reduces the cost permanently rather than paying to hide it.