.png)
Key takeaways
1
Warm pools support three instance states Stopped, Hibernated, and Running and the state you choose sets both resume time and what you pay while instances wait. Stopped is AWS's recommended default; Running is discouraged since it removes the cost advantage entirely.
2
Warm pool size is calculated automatically from your Auto Scaling group's capacity settings by default, though a custom maximum can pin it to a fixed count instead. For workloads with lengthy initialization or per-start preparation, use lifecycle hooks or correctly configured restartable user data so instances are not stopped or put InService before they are ready.
3
Stopped and Hibernated instances carry no compute charge, so Savings Plans and Reserved Instances don't apply to the pool itself. Commitment coverage should instead be sized to your InService baseline.
An EC2 warm pool is a set of pre-initialized instances that sits alongside your Auto Scaling group in a cost-reduced state. When traffic spikes, the group can draw from the pool instead of cold-launching new instances, avoiding first-boot initialization steps.
The resulting scale-out time depends on your AMI, instance type, application initialization, lifecycle hooks, and health checks. Stopped pool instances incur EBS and attached public IPv4 charges, rather than EC2 compute charges, while they wait.
Compare measured launch-to-healthy time, the number of instances needed before cold launches can finish, and the pool’s monthly holding cost before deciding.
For a 30-second initialization that is fine. For an 8-minute one it is not: a spike arriving in under 8 minutes hits your existing InService instances with 100% of the increased load while new instances are still initializing.
Pre-provisioning fixes the latency but defeats the point of scaling needing 10 instances at peak and 3 at minimum, running 10 continuously erases the cost benefit entirely.
Warm pools solve both: instances are pre-initialized so they enter service quickly, but not fully running, so you pay EBS rates while they wait.
Stopped (default and recommended). The instance is fully off. You pay only for attached EBS volumes and Elastic IPs, not compute. Initialization work from first launch is preserved on the EBS root volume, so the instance enters service without repeating the slow steps.
Hibernated. Hibernation signals the OS to save RAM contents to the EBS root volume before stopping. On restart, the root volume is restored and RAM reloaded, so the application continues from its last memory state.
The hibernation prerequisites are strict: Linux instance RAM must be under 150 GiB (Windows, 16 GiB or less), the root volume must be encrypted with encryption enforced at launch, volumes must be gp2, gp3, io1, or io2, and hibernation must be enabled when the instance launches you cannot enable it on an existing instance.
Resume time scales with RAM size, so hibernation is not automatically faster than a stop and start for large memory footprints.
Running. Instances are fully powered on and billed at the same compute rate as your InService instances. AWS highly discourages this state to avoid unnecessary charges, if resume time is the only reason to consider it, compare it against simply raising your ASG desired capacity.
The resulting scale-out time depends on your AMI, instance type, application initialization, lifecycle hooks, and health checks. Stopped pool instances incur EBS and attached public IPv4 charges, rather than EC2 compute charges, while they wait.
The short answer
Warm pools are a strong fit when your measured cold-start time would leave too little capacity to absorb your fastest expected traffic surge. A Stopped pool can avoid repeating first-boot initialization while instances wait at EBS-storage cost, but the operational overhead and holding cost must be justified by the capacity gap it closes.Compare measured launch-to-healthy time, the number of instances needed before cold launches can finish, and the pool’s monthly holding cost before deciding.
What Problem Warm Pools Actually Solve
Every instance Auto Scaling launches must boot, start its OS, install or start application software, run configuration, and pass load balancer health checks before it serves traffic.For a 30-second initialization that is fine. For an 8-minute one it is not: a spike arriving in under 8 minutes hits your existing InService instances with 100% of the increased load while new instances are still initializing.
Pre-provisioning fixes the latency but defeats the point of scaling needing 10 instances at peak and 3 at minimum, running 10 continuously erases the cost benefit entirely.
Warm pools solve both: instances are pre-initialized so they enter service quickly, but not fully running, so you pay EBS rates while they wait.
Warm Pool States: Stopped, Hibernated, Running
Per the Amazon EC2 Auto Scaling warm pools documentation, pool instances carry a Warmed: prefix in the console: Warmed:Pending, Warmed:Pending:Wait, Warmed:Stopped, Warmed:Running, Warmed:Hibernated. While instances sit in the pool, scaling policies only scale out on metrics from InService instances.Stopped (default and recommended). The instance is fully off. You pay only for attached EBS volumes and Elastic IPs, not compute. Initialization work from first launch is preserved on the EBS root volume, so the instance enters service without repeating the slow steps.
Hibernated. Hibernation signals the OS to save RAM contents to the EBS root volume before stopping. On restart, the root volume is restored and RAM reloaded, so the application continues from its last memory state.
The hibernation prerequisites are strict: Linux instance RAM must be under 150 GiB (Windows, 16 GiB or less), the root volume must be encrypted with encryption enforced at launch, volumes must be gp2, gp3, io1, or io2, and hibernation must be enabled when the instance launches you cannot enable it on an existing instance.
Resume time scales with RAM size, so hibernation is not automatically faster than a stop and start for large memory footprints.
Running. Instances are fully powered on and billed at the same compute rate as your InService instances. AWS highly discourages this state to avoid unnecessary charges, if resume time is the only reason to consider it, compare it against simply raising your ASG desired capacity.
| Stopped | Hibernated | Running | |
|---|---|---|---|
| What you pay | EBS + Elastic IP | EBS incl. RAM storage + Elastic IP | Full compute + EBS |
| Best for | Most workloads | In-memory state under the RAM limit | Avoid unless no alternative |
| All instance types | Yes, if EBS-backed root | No, prerequisites apply | Yes |
Warm Pool Pricing: The Exact Math
Warm pool cost depends on four things:- The number of instances in the pool
- The pool state
- The EBS volumes attached to those instances
- Whether Elastic IPs are associated
Warm Pool Cost Formula
Monthly Stopped-state cost
=
instances × volume size (GB) × $/GB-month
Savings %
=
Running instance cost − Stopped-state cost
Running instance cost
× 100
Use your own instance size and region rates.
The worked example below uses US East pricing.
Public IPv4 addresses, including Elastic IP addresses, incur an hourly charge whether they are in use or idle, so include any address attached to a warm-pool instance in the pool-cost calculation.
Worked on one baseline: 5 m5.large pool instances, 100 GB gp3 root volume, US East, no Elastic IPs attached.
Worked on one baseline: 5 m5.large pool instances, 100 GB gp3 root volume, US East, no Elastic IPs attached.
| Pool state | Monthly cost | Saving vs. running |
|---|---|---|
| Stopped | 5 × 100 GB × $0.08 = $40 | $345.60 (89.6%) |
| Hibernated | $40 + (5 × 8 GB RAM × $0.08) = $43.20 | $342.40 (88.8%) |
| Running | 5 × $0.096/hr × 720 hrs + $40 = $385.60 | None |
Rates are illustrative, based on US East (N. Virginia) Linux On-Demand and gp3 storage pricing, and exclude public IPv4, data transfer, and EBS provisioned-performance charges.
Compute Savings Plans apply only to running EC2 instances, so Stopped and Hibernated pool instances need no coverage at all. Once an instance moves to InService it begins consuming compute hours and any applicable discount applies immediately.
With a custom maximum, set MaxGroupPreparedCapacity and the pool becomes the difference between that value and desired capacity instead. With desired capacity 6 and MaxGroupPreparedCapacity 8, the pool is 2.
Pool size is dynamic in both cases. It has an absolute size only when MaxGroupPreparedCapacity and MinSize are set to the same value. And if desired capacity rises above MaxGroupPreparedCapacity, pool capacity drops to 0 unless you specify MinSize.
MinSize sets the minimum instances maintained in the pool and defaults to 0, per the PutWarmPool API reference. When the pool shrinks below it, Auto Scaling launches new instances to restore the count.
Compute Savings Plans apply only to running EC2 instances, so Stopped and Hibernated pool instances need no coverage at all. Once an instance moves to InService it begins consuming compute hours and any applicable discount applies immediately.
Warm Pool Sizing: How the Math Works
By default, warm pool size is the difference between the Auto Scaling group’s maximum capacity and its desired capacity. With desired capacity 6 and maximum 10, the pool is 4.With a custom maximum, set MaxGroupPreparedCapacity and the pool becomes the difference between that value and desired capacity instead. With desired capacity 6 and MaxGroupPreparedCapacity 8, the pool is 2.
Pool size is dynamic in both cases. It has an absolute size only when MaxGroupPreparedCapacity and MinSize are set to the same value. And if desired capacity rises above MaxGroupPreparedCapacity, pool capacity drops to 0 unless you specify MinSize.
MinSize sets the minimum instances maintained in the pool and defaults to 0, per the PutWarmPool API reference. When the pool shrinks below it, Auto Scaling launches new instances to restore the count.
Sizing rule of thumb.
Set MinSize to the number of instances you need immediately available during your fastest-rising traffic pattern, not the total capacity needed at peak. If load can double within 5 minutes but the doubled capacity only needs to be ready within 10 minutes, a MinSize of 2–3 covers the immediate response while standard cold launches cover the remainder. Sizing the pool to your full peak defeats much of the cost advantage over simple over-provisioning.
Set MinSize to the number of instances you need immediately available during your fastest-rising traffic pattern, not the total capacity needed at peak. If load can double within 5 minutes but the doubled capacity only needs to be ready within 10 minutes, a MinSize of 2–3 covers the immediate response while standard cold launches cover the remainder. Sizing the pool to your full peak defeats much of the cost advantage over simple over-provisioning.
Two consequences worth planning for: if the pool is depleted when a scale-out arrives, instances launch directly into the group, a cold start. And a pool instance that never reaches InService is treated as a failed launch and terminated.
Because pool size moves inversely to desired capacity, warm pool EBS cost is highest when your load is lowest.
Because pool size moves inversely to desired capacity, warm pool EBS cost is highest when your load is lowest.
Should You Use Warm Pools?
| Signal | Use warm pools | Use standard Auto Scaling |
|---|---|---|
| Initialization time | Measured cold-start time exceeds your available surge tolerance | Measured cold-start time fits within your available surge tolerance |
| Workload type | ML inference, large JVM apps, model-loading services | Stateless microservices, lightweight containers |
| Traffic pattern | Sudden spikes, predictable burst schedules | Gradual organic growth |
| Scale target | Tens of instances | 50 or more pool instances, where EBS cost adds up |
| Orchestration | On-Demand Auto Scaling groups | Weighted mixed fleets or mixed fleets that require Spot Instances |
| Team maturity | Willing to manage lifecycle hooks and instance refresh | Wants minimal operational overhead |
Strongest cases. Anything loading large models or datasets at startup, where initialization is real compute work worth paying for once rather than on every scale-out. Event-driven workloads with predictable spikes can also pre-heat the pool ahead of anticipated demand.
Hard constraints to check first. Per the documented warm pool limitations, warm pools are not supported with weighted mixed instance groups at all, and your mixed instances policy must be configured for On-Demand instance types only, Spot Instances are not supported within mixed instance groups.
Since November 2025 warm pools do work with mixed instances policies for On-Demand types, specified either as instance type lists or by attribute-based selection. A hibernated pool with mixed instances also requires HibernationOptions in your launch template.
Without a lifecycle hook, instances that take a long time to initialize could be stopped or hibernated and then put into service during a scale-out event before they are ready.
Warm pools use a two-stage hook model. The first holds the instance in Warmed:Pending:Wait until your initialization script completes and signals complete-lifecycle-action, and only then does it enter the pool. The second holds it in Pending:Wait during scale-out so final configuration runs before it reaches InService.
On Linux, user data does not automatically re-run when a stopped instance restarts which is why stopping after initialization is valuable, but also why anything that must run on every entry to service belongs in the second hook or in user data explicitly configured to run on every boot.
For timeout sizing, DefaultResult choices, and testing the failure path, see Auto Scaling Lifecycle Hooks: Graceful Startup & Shutdown Without Waste. A related hook decision is whether to return instances to the pool on scale-in instead of terminating them.
With Flex Insured Commitments, teams can get up to 57% savings of a three-year AWS commitment with none of the commitment risk, depending on the service, configuration, and payment option.
After you approve a recommendation, we purchase and manage the commitment on your behalf. We commit only to your verified InService baseline spikes ride On-Demand as designed.
If a commitment ever costs more than the equivalent on-demand usage, we calculate that loss at the end of the month and provide cashback protection for it. We charge a percentage of realized savings, so the fee only exists when the savings do.
Hard constraints to check first. Per the documented warm pool limitations, warm pools are not supported with weighted mixed instance groups at all, and your mixed instances policy must be configured for On-Demand instance types only, Spot Instances are not supported within mixed instance groups.
Since November 2025 warm pools do work with mixed instances policies for On-Demand types, specified either as instance type lists or by attribute-based selection. A hibernated pool with mixed instances also requires HibernationOptions in your launch template.
Lifecycle Hooks and Warm Pool Behavior
Auto Scaling stops or hibernates instances as they enter the warm pool and does not wait for user data to finish running. AWS covers this in using lifecycle hooks with a warm pool.Without a lifecycle hook, instances that take a long time to initialize could be stopped or hibernated and then put into service during a scale-out event before they are ready.
Warm pools use a two-stage hook model. The first holds the instance in Warmed:Pending:Wait until your initialization script completes and signals complete-lifecycle-action, and only then does it enter the pool. The second holds it in Pending:Wait during scale-out so final configuration runs before it reaches InService.
On Linux, user data does not automatically re-run when a stopped instance restarts which is why stopping after initialization is valuable, but also why anything that must run on every entry to service belongs in the second hook or in user data explicitly configured to run on every boot.
For timeout sizing, DefaultResult choices, and testing the failure path, see Auto Scaling Lifecycle Hooks: Graceful Startup & Shutdown Without Waste. A related hook decision is whether to return instances to the pool on scale-in instead of terminating them.
How Warm Pools Fit Your Cost Strategy
Everything above is a fleet-level decision. Covering the InService instances actually handling traffic is a separate one: Savings Plans don’t apply to Stopped or Hibernated pool instances, so commitment coverage belongs on the InService baseline. For the sizing method, see EC2 Auto Scaling Savings Plans: Size Commitments Without Wasting SP Hours.With Flex Insured Commitments, teams can get up to 57% savings of a three-year AWS commitment with none of the commitment risk, depending on the service, configuration, and payment option.
After you approve a recommendation, we purchase and manage the commitment on your behalf. We commit only to your verified InService baseline spikes ride On-Demand as designed.
If a commitment ever costs more than the equivalent on-demand usage, we calculate that loss at the end of the month and provide cashback protection for it. We charge a percentage of realized savings, so the fee only exists when the savings do.
Frequently asked questions
What does an EC2 warm pool cost?
It depends on the pool state. Stopped charges only attached EBS volumes and Elastic IPs, not compute, a 100 GB gp3 root volume is roughly $8/month in US East. Hibernated adds storage for the RAM contents. Running costs full on-demand compute rates, which AWS discourages.
What are the three EC2 warm pool states?
Stopped (the default) keeps the instance off, with EBS and Elastic IP charges only. Hibernated saves RAM to the EBS root volume so the instance resumes from its exact memory state. Running keeps instances powered on at full compute rates and is highly discouraged.
How is warm pool size calculated?
By default, the difference between your Auto Scaling group's maximum capacity and its desired capacity. If you set MaxGroupPreparedCapacity, it becomes the difference between that value and desired capacity instead. The pool has an absolute size only when MaxGroupPreparedCapacity and MinSize match.
Do I need lifecycle hooks for warm pools?
Not in every case, but AWS recommends them for workloads with lengthy initialization. Auto Scaling does not wait for user data to finish before stopping or hibernating an instance entering the pool, so use lifecycle hooks or user data configured to handle stops and restarts to keep an instance from being stopped mid-initialization or entering service before it is ready.
Share
Facebook
X
LinkedIn
Reddit
