Warm Pools
A warm pool is server capacity started in advance and held ready, so a match doesn't wait for a cold start. It trades money for time: the pool costs the same whether matches use it or not. How much it's worth depends on cold start: when new servers start in seconds, a pool becomes a cost decision rather than a requirement.
Also called
reserved capacity, warm pool, server warm pool, prewarming
,
What Does a Warm Pool Actually Hold?
A warm pool is server capacity held ready before matches ask for it. The alternative is on-demand: starting a server when a match requests one. What the pool holds decides how much waiting it removes:
Stopped machines. Set up, then stopped. AWS's EC2 Auto Scaling warm pools often work this way: the machine boots, then the game server starts.
Machines ready to accept game server instances. Running hosts with the server image already on them, so a new instance starts without provisioning a machine first.
Running instances. The game server is already up, sometimes with its map loaded, and a match is allocated to it rather than waiting for a cold start.
Each step removes more waiting, and costs more for every minute it sits unused. Multi-room servers have a version of their own: the free rooms in a running server are capacity the process already pays for.
In Practices - Insights from Edgegap's Blog
Article's key insights
Estimate cloud costs for hosting game server is a complex task for multiplayer games developers. Public cloud use this complexity to hide their true costs.
Amazon provides a tool to build an estimate, based on a few inputs. However, it hides, by design, the inefficiency of traditional orchestration when compared to the next-generation of just-in-time, container-based orchestration using co-tenancy.
Is a Warm Pool Still a Requirement?
It depends on how long new capacity takes to arrive. When adding a server means provisioning machines, the wait runs to minutes. KRAFTON reported up to 15 minutes to bring new servers online on its Agones setup for PUBG: Battlegrounds, and 3 to 4 minutes after adopting Karpenter and a container registry proxy (AWS re:Invent 2024). At that speed, the only way to answer a match at once is capacity already held. The pool is a provisioning requirement, often held in every location the game serves.
When a new server starts in seconds, the question changes. A match can get a server when it asks for one, and the pool becomes reserved capacity: a cost decision, worth holding where it stays busy enough to cost less than on-demand.
One case remains either way. Starting a server faster doesn't shorten the game's own load, which Part 4 comes back to.
How Big Should a Warm Pool Be?
Big enough to cover the time it takes to add more. A pool only has to answer the matches that arrive while new capacity is starting. Roughly: match requests per minute, multiplied by the minutes it takes to bring a new server online. Minutes of refill time need minutes of demand held in reserve, and a spike larger than the forecast can still empty it.
On Edgegap's Edge Cloud, the refill time is the cold start: 2 seconds, median, measured to container ready (platform data, 18 September 2026). A pool sized to cover it is close to zero.
Two things multiply whatever pool you hold:
Locations. A pool sits in one location or region. A game held warm in five regions holds five pools, each sized for its own peak and partly idle through its own night.
Builds. A pool holds one server version. A patch drains the old pool and fills a new one, and the two can overlap while players move across.
Where Does Reserved Capacity Cost the Least?
Where it stays busy. Reserved capacity is paid for whether it runs matches or not, so it costs less than on-demand only in the hours it is used. Size it to the load your concurrency curve says will keep it busy, and start everything above it on demand. That is hybrid orchestration.
On Edgegap, Private Fleet hosts already host the server image, so a match starts on them without a separate pool, and overflows to Edge Cloud when the fleet is full. Keeping instances running in advance, through Server Browser scaling policies, is worth it in the cases our documentation names: a server that takes more than 30 seconds to initialize, a global launch expecting a rapid influx of players, and complex network topology.
A word from our sponsor (ourselves!)
Warm pools make allocation fast because you pay for servers that sit idle. Edgegap provisions a fresh game server in a median of 2 seconds from cold start, measured to container ready before your engine starts, so a server exists only once a match needs one.
Edgegap's Take (just our opinion, take it with a grain of salt!)
A Warm Pool Is a Bet on Demand
A warm pool was how fleet-based orchestration hid slow provisioning: hold servers in every location, in case a match arrives. When a new server starts in seconds, that reason is gone. What's left is a cost decision.
So size reserved capacity to the load that will keep it busy, and start everything above it on demand. Hold less, and the cloud covers the difference. Hold more, and you pay for servers waiting on a forecast. If you are sizing a pool to hide start-up time, measure the start-up time first.
Hybrid orchestration answers both sides at once. Reserved hosts take persistent worlds and the steady load that keeps them busy, at their lower cost. On-demand deployments take everything above it, started near players in more locations than a fixed fleet reaches, so matches play better online.
,
