AWS recently released Warm Pools for EC2 Auto Scaling, which reduces the time and cost to scale out (horizontally scale) applications by maintaining a pool of pre-initialized instances.
Warm Pools launch a configured number of instances in the background, allowing any lengthy application initialization or bootstrapping to take place, and then stopping those instances until they are needed. Also, users can opt to configure a warm pool not to be stopped to further reduce any latency caused by going from a stopped state to a running state.
Warm pools are customizable, enabling users to configure the size of the pool, change the state of the instances, or enable lifecycle hooks.
Since 2009, AWS customers have been using EC2 Auto Scaling to build and scale applications on AWS. While EC2 provides a way to respond to real-time application demand using auto-scaling groups, it takes a long period of time to bootstrap instances.
Pre-initialized instances in a Warm Pool can be launched to serve traffic in as low as 30 seconds. This might not be optimal for regular scale-out tasks that are up and running in a few seconds, but it reduces the startup time dramatically especially for applications with high startup time (i.e: databases, application servers, etc.).
To avoid the latency issue, some users had to increase the minimum size in an auto-scaling group to guarantee they have readily available instances once an increase in application demand occurs. Over-provisioning led to other issues including increased cost, wasted compute, and skewed metrics.
There are a few limitations to keep in mind when using Warm Pools for EC2.
A warm pool cannot be added to an auto-scaling group that has a mixed instances policy or that is using spot instances. The support for CloudFormation or CodeDeploy is not available as of this writing and might be coming soon.
For those using Warm Pools with Elastic Container Services (ECS) or Elastic Kubernetes Service (EKS), these services may schedule jobs on an instance before it reaches the warm pool.
An EC2 instance can be put in a stopped state only if it is using an Amazon Elastic Block Store (EBS) volume attached to it as its only root device. Instances using an instance store as its root device cannot be stopped.
If the warm pool uses up all the instances available when there’s a scale-out event, instances will launch directly into the auto-scaling group (aka cold starts). Also, this could happen if an availability zone is out of capacity.
Warm Pools made it possible to quicken scaling out applications using auto-scaling groups by pre-initializing instances, making them readily available to be placed into service.
Mixed with life cycle hooks, Warm Pools enable developers and operators to manage the operation of applications as instances enter and exit a warm pool. Users can get started with Warm Pools using the most recent AWS Command Line Interface (CLI) or any AWS SDK.