Skip to content
Amazon EC2 Auto Scaling Warm Pools help applications scale out faster and operate more efficiently. With Warm Pools, users can improve the elasticity of their applications by creating a pool of pre-initialized EC2 instances that are ready to quickly serve application traffic.
Because Warm Pools were released relatively recently, many teams are still in the process of adapting them as part of their cost optimization efforts. That’s why we wrote this article about what Warm Pools are and how to use them, with step-by-step configuration guide, example use cases, and best practices from our experience managing $1.5 billion in AWS spend.
Auto Scaling Groups And Why You Need Warm Pools
An ASG works by setting a base capacity of EC2 instances that can scale out (increase) or scale in (decrease) based on defined criteria such as CPU utilization or network requests. This ensures high availability and fault tolerance by automatically replacing unhealthy instances and adjusting the capacity to meet demand, thereby improving user experience without unnecessary cost. A typical lifecycle of an instance in an ASG involves several states: from launching (pending state) to operational (in-service), and eventually to scaling in (termination). AWS allows for custom actions at these stages using lifecycle hooks, which provide opportunities for executing scripts or initializing processes before the instance moves into the next state.
Despite their benefits, ASGs can sometimes face challenges. A common issue is the slow launch time of resources. This can be particularly problematic when applications need to scale up rapidly. For example, applications with long startup time may take a significant amount of time to initialize and become ready to serve traffic. To mitigate these challenges, it’s not uncommon to over-provision capacity within ASGs. Over-provisioning compute resources results in cost inefficiency, skewed scaling metrics and cloud waste.
That’s why Amazon EC2 Auto Scaling Warm Pools were released, to reduce scale-out latency by maintaining a pool of pre-initialized instances ready to be placed into service.
What Are Warm Pools?
A Warm Pool is a pool of pre-initialized EC2 instances that sits alongside an Auto Scaling group. Whenever your application needs to scale out, the Auto Scaling group can draw on the warm pool to meet its new desired capacity. This helps you to ensure that instances are ready to quickly start serving application traffic, accelerating the response to a scale-out event. Warm Pools can significantly improve the responsiveness of your applications by maintaining a pool of pre-initialized instances that are ready to serve traffic.
You can use Warm Pool settings to manage the state of your Warm Pool instances for testing configurations or cost management. Additionally, you can dynamically adjust the size of the Warm Pool to meet demand without impacting the performance of your running application. We’ll talk more about the advantages and use cases of Warm Pools later in the article – let’s first discuss how to configure warm pools in the AWS management console.
How to Configure a Warm Pool on an AWS Auto Scaling Group
- Open the Amazon EC2 console: Go to the Auto Scaling Groups page
- Select your Auto Scaling Group: Click on the name of the group you want to configure.
- Go to the Instance Management tab.
- Create a Warm Pool: Click “Create Warm Pool”.
- Configure the Warm Pool:
- Warm Pool instance state: Select one of the states (Stopped, Running, Hibernated). This state defines in what state the warmed instances will stay until they are attached to the ASG if needed.
Stopped: Instances kept in “Stopped” state can help you to reduce your compute costs. You won’t be charged for the EC2 usage, only for the resources attached to this EC2 instance (EBS volumes, EIP addresses, …)
Running: Use this state if you want the lowest possible latency on the ASG scale-out. You will be charged the full price of the warmed EC2 instance even if it stays in the Warm Pool and does not actually serve traffic.
Hibernated: If your EC2 instance supports hibernation, you can use this setting to meet the balance between the other two options – you won’t be charged for the EC2 instance usage, only for the resources attached to this EC2, but at the same time the scale-out speed will be faster compared to the warmed instances that are in the “Stopped” state.
- Minimum warm pool size: Define the minimum number of instances that should always be in the warm pool.
- Instance reuse: If this option is selected, EC2 instances will be returned back to the Warm Pool on scale-in events, insead of termination. This is a relatively new option that allows you to better utilize your instances by re-using them if needed.
- Warm Pool size: By default size is set to (Pool Size = “Max Capacity” – “Desired Capacity”). So if your ASG has the Maximum capacity set to 10 and the Desired capacity set to 7, your Warm Pool size will be 3. You can override this behavior to use the following formula (Pool Size = “Desired Capacity” – “Custom Value”)
Advantages & Use Cases of Warm Pools
Let’s dive into the reasons why you might want to use warm pools and some real world use cases.
Cost-Effectiveness
Faster Scaling
Lifecycle Management
Warm Pools offer comprehensive lifecycle management, allowing for the efficient reuse of instances. With features that enable running instances to return to the Warm Pool on scale-in, they enhance resource utilization by reusing instances instead of terminating them.
Warm Pool Use Cases | |
Interactive Applications | Warm Pools are ideal for applications requiring frequent, rapid scaling based on user interaction or real-time data processing. They ensure that resources are available on-demand, thereby enhancing the application’s ability to handle sudden increases in traffic or computation requests without latency. |
Event-Driven Processing | For applications that operate based on events — such as media processing after uploading content or executing batch jobs in response to specific triggers — Warm Pools provide the necessary computational resources almost instantaneously. This capability is crucial for maintaining performance standards and meeting operational deadlines. |
Predictable Load Patterns | Organizations with predictable spikes in demand, such as retail websites during sales events or media sites during major broadcasts, can benefit from Warm Pools. By maintaining pre-initialized instances, these pools allow for immediate resource availability, thus handling surges in traffic or load without affecting service delivery. |
High-Performance Computing (HPC) | In scenarios where high-performance computing resources are needed sporadically — for instance, scientific simulations or financial modeling — Warm Pools offer a way to keep compute resources at the ready. This setup avoids the setup delay and allows for immediate processing, making efficient use of the computing power when it’s needed most. |
DevOps and Testing Environments | For development and testing environments where teams frequently spin up and tear down instances, Warm Pools can significantly reduce the time spent waiting for resources to become available. This facilitates a faster iteration cycle and more efficient development processes. |
Machine Learning | Warm Pools can be vital for real-time analytics and adaptive learning systems where computational needs fluctuate quickly. For iterative experiments and script tuning, Warm Pools offer quick resets between jobs, minimizing instance spawning and configuration time.In large-scale hyperparameter optimization, Warm Pools provide immediate access to resources for evaluating multiple parameter sets concurrently, speeding up optimization and enhancing model performance.For batch model training across different datasets or locations, Warm Pools ca help manage manage hundreds or thousands of jobs efficiently, ensuring ready compute resources and accelerating extensive training tasks routinely. |
Limitations of Warm Pools
Resource and Cost Management Challenges
In some cases, Warm Pools may add costs and management overhead:
- Managing Warm Pools requires precise capacity planning and continuous monitoring to avoid over-provisioning and unnecessary costs, or under-provisioning, which fails to meet scaling demands. Inaccurate predictive scaling can result in instances spinning up too late, causing delays, or too early, leading to idle resources.
- Misconfigurations, such as setting a larger-than-necessary Warm Pool or choosing improper instance states (e.g., keeping instances running when stopping would suffice), can significantly increase unnecessary expenses.
- Managing Warm Pools adds complexity to Auto Scaling configurations, increasing the risk of misconfiguration and administrative overhead. Not all EC2 features and instance types support features like hibernation, which is essential for cost-effective scaling.
- Even if you stop EC2 instances, there are still smaller supplementary charges for EBS volumes, elastic IPs, etc.
Operational and Compatibility Limitations
In addition, warm pools can’t be used in the following scenarios:
- You cannot add a Warm Pool to an Auto Scaling group that utilizes a mixed instances policy or requests Spot Instances through its launch template or launch configuration.
- Amazon EC2 Auto Scaling can only put an instance in a Running, Stopped or Hibernated state if it has an Amazon EBS volume as its root device. Instances using instance stores for the root device cannot be stopped or hibernated. An instance can only be placed in a Hibernated state if it meets all the prerequisites outlined in the Amazon EC2 User Guide for Linux Instances.
- EBS volumes must have encryption if you want to keep them in hibernated mode.
Technical Challenges
Here are some examples of common technical challenges relating to warm pools.
- Cold Starts: If the Warm Pool is depleted during a scale-out event, or if an Availability Zone is out of capacity, instances will have to launch directly into the Auto Scaling group, resulting in a cold start.
- Failed Launches: Instances that encounter issues during the launch process and fail to reach the InService state are terminated. This includes failures due to insufficient capacity or other factors.
- Service Integration with Amazon EKS and ECS: When using a Warm Pool with Amazon EKS or ECS, instances that are still initializing might register with the cluster prematurely. This requires a specific configuration in the launch template or configuration to prevent premature job scheduling on these instances.
Security and Compliance Concerns
How nOps helps you save on ASGs with Warm Pools
At nOps, we understand that managing AWS Auto Scaling Groups (ASGs) with Warm Pools and Spot Instances presents unique challenges. With Warm Pools, you can’t use Mixed Instance Policies to take advantage of instance diversification, making it difficult and complicated to use Warm Pools and save reliably with Spot at the same time.
Our solution respects the architecture of your ASGs with Warm Pools, while adding the enhancement of Spot Instance integration. After the pre-warmed instance from the Warm Pool has accepted the traffic and stabilized the workload, we seamlessly swap it with a Spot Instance to significantly reduce costs.
We optimize your ASGs by selecting diverse Spot Instances that not only match the performance requirements but also offer the best value at the time of scaling, even they are a different family or size. This approach enhances the robustness, availability, and fault tolerance of your application.
nOps makes it possible to leverage the best of both worlds—immediate scalability with Warm Pools and cost efficiency with Spot Instances. All of these complexities are managed on your behalf to ensure your ASGs are both cost-effective and resilient.
nOps Copilot for ASGs
If you’re looking to optimizing your EC2 auto scaling groups’ performance and costs, nOps can help. Compute Copilot is an intelligent workload provisioner that continuously manages, scales, and optimizes all of your AWS compute to get you the lowest cost with maximum stability.
Compute Copilot was created to make it easy to save on ASG costs with Spot. Fully aware of the changing Spot market, your dynamic usage, and your AWS purchase commitments, Copilot automatically and continuously tunes your ASG configurations to ensure you’re (1) always using the right amount of Spot, and (2) always on the most cost-effective and reliable option available, gracefully moving your workloads onto optimal instances to drastically reduce your rates of termination.
If you’re currently using Spot to save on your ASG costs, you’re familiar with the complexity involved in choosing the best Spot instances for your workloads and cost-optimizing your commitment usage. Copilot makes all of this easy, so that your time is freed for building and innovating.
Copilot is fully compatible with all of your ASGs, even if you’re using Warm Pools or other advanced features that add complexity and management overhead. And because Copilot is built on your existing AWS-native ASGs, it’s ultra-easy to onboard. Simply plug it in to effortlessly run mission-critical workloads with peace of mind that you’re always getting the best performance and stability at the lowest costs.
nOps manages over $1.5 billion in AWS spend and was recently ranked #1 in G2’s cloud cost management category. Book a demo to find out how to save in just 10 minutes.
