# Decrease latency for applications with long boot times using warm pools
A warm pool gives you the ability to decrease latency for your applications that have exceptionally long boot times, for example, because instances need to write massive amounts of data to disk. With warm pools, you no longer have to over-provision your Auto Scaling groups to manage latency in order to improve application performance. For more information, see the following blog post [Scaling your applications faster with EC2 Auto Scaling Warm Pools](https://aws.amazon.com/blogs/compute/scaling-your-applications-faster-with-ec2-auto-scaling-warm-pools/).
**Important**
Creating a warm pool when it's not required can lead to unnecessary costs. If your first boot time does not cause noticeable latency issues for your application, there probably isn't a need for you to use a warm pool.
**Topics**
+ [Core concepts](#warm-pool-core-concepts)
+ [Prerequisites](#warm-pool-prerequisites)
+ [Update the instances in a warm pool](#update-warm-pool)
+ [Related resources](#warm-pools-related-resources)
+ [Limitations](#warm-pools-limitations)
+ [Use lifecycle hooks](warm-pool-instance-lifecycle.md)
+ [Create a warm pool for an Auto Scaling group](create-warm-pool.md)
+ [View health check status](warm-pools-health-checks-monitor-view-status.md)
+ [AWS CLI examples for working with warm pools](examples-warm-pools-aws-cli.md)
## Core concepts
Before you get started, familiarize yourself with the following core concepts:
**Warm pool**
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. As instances leave the warm pool, they count toward the desired capacity of the group. This is known as a *warm start*.
While instances are in the warm pool, your scaling policies only scale out if the metric value from instances that are in the `InService` state is greater than the scaling policy's alarm high threshold (which is the same as the target utilization of a target tracking scaling policy).
**Warm pool size**
By default, the size of the warm pool is calculated as the difference between the Auto Scaling group's maximum capacity and its desired capacity. For example, if the desired capacity of your Auto Scaling group is 6 and the maximum capacity is 10, the size of your warm pool will be 4 when you first set up the warm pool and the pool is initializing.
To specify the warm pool's maximum capacity separately, use the custom specification (`MaxGroupPreparedCapacity`) option and set a custom value for it that is greater than the current capacity of the group. If you provide a custom value, the size of the warm pool is calculated as the difference between the custom value and the current desired capacity of the group. For example, if the desired capacity of your Auto Scaling group is 6, if the maximum capacity is 20, and if the custom value is 8, the size of your warm pool will be 2 when you first set up the warm pool and the pool is initializing.
You might only need to use the custom specification (`MaxGroupPreparedCapacity`) option when working with large Auto Scaling groups to manage the cost benefits of having a warm pool. For example, an Auto Scaling group with 1,000 instances, a maximum capacity of 1,500 (to provide extra capacity for emergency traffic spikes), and a warm pool of 100 instances might help you achieve your goals better than keeping 500 instances reserved for future use inside the warm pool.
**Minimum warm pool size**
Consider using the minimum size setting (`MinSize`) to statically set the minimum number of instances to maintain in the warm pool. There is no minimum size set by default. The `MinSize` setting is useful when you specify `MaxGroupPreparedCapacity` to ensure that a minimum number of instances are maintained in the warm pool even when the desired capacity of the Auto Scaling group is higher than the `MaxGroupPreparedCapacity`.
**Warm pool instance state**
You can keep instances in the warm pool in one of three states: `Stopped`, `Running`, or `Hibernated`. Keeping instances in a `Stopped` state is an effective way to minimize costs. With stopped instances, you pay only for the volumes that you use and the Elastic IP addresses attached to the instances.
Alternatively, you can keep instances in a `Hibernated` state to stop instances without deleting their memory contents (RAM). When an instance is hibernated, this signals the operating system to save the contents of your RAM to your Amazon EBS root volume. When the instance is started again, the root volume is restored to its previous state and the RAM contents are reloaded. While the instances are in hibernation, you pay only for the EBS volumes, including storage for the RAM contents, and the Elastic IP addresses attached to the instances.
Keeping instances in a `Running` state inside the warm pool is also possible, but is highly discouraged to avoid incurring unnecessary charges. When instances are stopped or hibernated, you are saving the cost of the instances themselves. You pay for the instances only when they are running.
**Lifecycle hooks**
You use [lifecycle hooks](warm-pool-instance-lifecycle.md) to put instances into a wait state so that you can perform custom actions on the instances. Custom actions are performed as the instances launch or before they terminate.
In a warm pool configuration, lifecycle hooks delay instances from being stopped or hibernated and from being put in service during a scale-out event until they have finished initializing. If you add a warm pool to your Auto Scaling group without a lifecycle hook, instances that take a long time to finish initializing could be stopped or hibernated and then put in service during a scale-out event before they are ready.
**Instance reuse policy**
By default, Amazon EC2 Auto Scaling terminates your instances when your Auto Scaling group scales in. Then, it launches new instances into the warm pool to replace the instances that were terminated.
If you want to return instances to the warm pool instead, you can specify an instance reuse policy. This lets you reuse instances that are already configured to serve application traffic. To make sure that your warm pool is not over-provisioned, Amazon EC2 Auto Scaling can terminate instances in the warm pool to reduce its size when it is larger than necessary based on its settings. When terminating instances in the warm pool, it uses the [default termination policy](ec2-auto-scaling-termination-policies.md#default-termination-policy) to choose which instances to terminate first.
If you want to hibernate instances on scale in and there are existing instances in the Auto Scaling group, they must meet the requirements for instance hibernation. If they don't, when instances return to the warm pool, they will fallback to being stopped instead of being hibernated.
Currently, you can only specify an instance reuse policy by using the AWS CLI or an SDK. This feature is not available from the console.
## Prerequisites
Before you create a warm pool for your Auto Scaling group, decide how you will use lifecycle hooks to initialize new instances with an appropriate initial state.
To perform custom actions on instances while they are in a wait state due to a lifecycle hook, you have two options:
+ For simple scenarios where you want to run commands on your instances at launch, you can include a user data script when you create a launch template or launch configuration for your Auto Scaling group. User data scripts are just normal shell scripts or cloud-init directives that are run by cloud-init when your instances start. The script can also control when your instances transition to the next state by using the ID of the instance on which it runs. If you are not doing so already, update your script to retrieve the instance ID of the instance from the instance metadata. For more information, see [Access instance metadata](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html) in the *Amazon EC2 User Guide*.
**Tip**
To run user data scripts when an instance restarts, the user data must be in the MIME multi-part format and specify the following in the `#cloud-config` section of the user data:
```
#cloud-config
cloud_final_modules:
- [scripts-user, always]
```
+ For advanced scenarios where you need a service such as AWS Lambda to do something as instances are entering or leaving the warm pool, you can create a lifecycle hook for your Auto Scaling group and configure the target service to perform custom actions based on lifecycle notifications. For more information, see [Supported notification targets](warm-pool-instance-lifecycle.md#warm-pools-supported-notification-targets).
**Prepare instances for hibernation**
To prepare Auto Scaling instances to use the `Hibernated` pool state, create a new launch template or launch configuration that is set up correctly to support instance hibernation, as described in the [Hibernation prerequisites](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/hibernating-prerequisites.html) topic in the *Amazon EC2 User Guide*. Then, associate the new launch template or launch configuration with the Auto Scaling group and start an instance refresh to replace the instances associated with a previous launch template or launch configuration. For more information, see [Use an instance refresh to update instances in an Auto Scaling group](asg-instance-refresh.md).
## Update the instances in a warm pool
To update the instances in a warm pool, you create a new launch template or launch configuration and associate it with the Auto Scaling group. Any new instances are launched using the new AMI and other updates that are specified in the launch template or launch configuration, but existing instances are not affected.
To force replacement warm pool instances to launch that use the new launch template or launch configuration, you can start an instance refresh to do a rolling update of your group. An instance refresh first replaces `InService` instances. Then it replaces instances in the warm pool. For more information, see [Use an instance refresh to update instances in an Auto Scaling group](asg-instance-refresh.md).
## Related resources
You can visit our [GitHub repository](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples) for examples of lifecycle hooks for warm pools.
## Limitations
+ Warm pool limitations for an Auto Scaling group with mixed instances types:
+ Warm pools aren’t supported with weighted mixed instance groups. If your Auto Scaling group uses instance weighting, you can’t add a warm pool.
+ Warm pools don’t support Spot Instances within mixed instance groups. Your mixed instances policy must be configured for On-Demand instances only when using warm pools.
+ When using warm pools with mixed instance groups in hibernated state, you must configure `HibernationOptions` in your launch template.
+ Amazon EC2 Auto Scaling can put an instance in a `Stopped` or `Hibernated` state only if it has an Amazon EBS volume as its root device. Instances that use instance stores for the root device cannot be stopped or hibernated.
+ Amazon EC2 Auto Scaling can put an instance in a `Hibernated` state only if meets all of the requirements listed in the [Hibernation prerequisites](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/hibernating-prerequisites.html) topic in the *Amazon EC2 User Guide*.
+ If your warm pool is depleted when there is a scale-out event, instances will launch directly into the Auto Scaling group (a *cold start*). You could also experience cold starts if an Availability Zone is out of capacity.
+ If an instance within the warm pool encounters an issue during the launch process, preventing it from reaching the `InService` state, the instance will be considered a failed launch and terminated. This applies regardless of the underlying cause, such as an insufficient capacity error or any other factor.
+ If you try using a warm pool with an Amazon Elastic Kubernetes Service (Amazon EKS) managed node group, instances that are still initializing might register with your Amazon EKS cluster. As a result, the cluster might schedule jobs on an instance as it is preparing to be stopped or hibernated.
+ Likewise, if you try using a warm pool with an Amazon ECS cluster, instances might register with the cluster before they finish initializing. To solve this problem, you must configure a launch template or launch configuration that includes a special agent configuration variable in the user data. For more information, see [Using a warm pool for your Auto Scaling group](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/asg-capacity-providers.html#using-warm-pool) in the *Amazon Elastic Container Service Developer Guide*.
# Use lifecycle hooks with a warm pool in Auto Scaling group
Instances in a warm pool maintain their own independent lifecycle to help you create the appropriate custom action for each transition. This lifecycle is designed to help you to invoke actions in a target service (for example, a Lambda function) while an instance is still initializing and before it is put in service.
**Note**
The API operations that you use to add and manage lifecycle hooks and complete lifecycle actions are not changed. Only the instance lifecycle is changed.
For more information about adding a lifecycle hook, see [Add lifecycle hooks to your Auto Scaling group](adding-lifecycle-hooks.md). For more information about completing a lifecycle action, see [Complete a lifecycle action in an Auto Scaling group](completing-lifecycle-hooks.md).
For instances entering the warm pool, you might need a lifecycle hook for one of the following reasons:
+ You want to launch EC2 instances from an AMI that takes a long time to finish initializing.
+ You want to run user data scripts to bootstrap the EC2 instances.
For instances leaving the warm pool, you might need a lifecycle hook for one of the following reasons:
+ You can use some extra time to prepare EC2 instances for use. For example, you might have services that must start when an instance restarts before your application can work correctly.
+ You want to pre-populate cache data so that a new server doesn't launch with an empty cache.
+ You want to register new instances as managed instances with your configuration management service.
## Lifecycle state transitions for instances in a warm pool
An Auto Scaling instance can transition through many states as part of its lifecycle.
The following diagram shows the transition between Auto Scaling states when you use a warm pool:
![\[The lifecycle state transitions for instances in a warm pool.\]](http://docs.aws.amazon.com/autoscaling/ec2/userguide/images/warm-pools-lifecycle-diagram.png)
¹ This state varies based on the warm pool's pool state setting. If the pool state is set to `Running`, then this state is `Warmed:Running` instead. If the pool state is set to `Hibernated`, then this state is `Warmed:Hibernated` instead.
When you add lifecycle hooks, consider the following:
+ When a lifecycle hook is configured for the `autoscaling:EC2_INSTANCE_LAUNCHING` lifecycle action, a newly launched instance first pauses to perform a custom action when it reaches the `Warmed:Pending:Wait` state, and then again when the instance restarts and reaches the `Pending:Wait` state.
+ When a lifecycle hook is configured for the `EC2_INSTANCE_TERMINATING` lifecycle action, a terminating instance pauses to perform a custom action when it reaches the `Terminating:Wait` state. However, if you specify an instance reuse policy to return instances to the warm pool on scale in instead of terminating them, then an instance that is returning to the warm pool pauses to perform a custom action at the `Warmed:Pending:Wait` state for the `EC2_INSTANCE_TERMINATING` lifecycle action.
+ If the demand on your application depletes the warm pool, Amazon EC2 Auto Scaling can launch instances directly into the Auto Scaling group as long as the group isn't at its maximum capacity yet. If the instances launch directly into the group, they are only paused to perform a custom action at the `Pending:Wait` state.
+ To control how long an instance stays in a wait state before it transitions to the next state, configure your custom action to use the **complete-lifecycle-action** command. With lifecycle hooks, instances remain in a wait state either until you notify Amazon EC2 Auto Scaling that the specified lifecycle action is complete, or until the timeout period ends (one hour by default).
The following summarizes the flow for a scale-out event.
![\[A flow diagram of a scale-out event.\]](http://docs.aws.amazon.com/autoscaling/ec2/userguide/images/warm-pools-scale-out-event-diagram.png)
When instances reach a wait state, Amazon EC2 Auto Scaling sends a notification. Examples of these notifications are available in the EventBridge section of this guide. For more information, see [Warm pool example events and patterns](warm-pools-eventbridge-events.md).
## Supported notification targets
Amazon EC2 Auto Scaling provides support for defining any of the following as notification targets for lifecycle notifications:
+ EventBridge rules
+ Amazon SNS topics
+ Amazon SQS queues
+ AWS Lambda functions
**Important**
If you have a user data (cloud-init) script in your launch template or launch configuration that configures your instances when they launch, you do not need to receive notifications to perform custom actions on instances that are starting or restarting.
The following sections contain links to documentation that describes how to configure notification targets:
**EventBridge rules** — To run code when Amazon EC2 Auto Scaling puts an instance into a wait state, you can create an EventBridge rule and specify a Lambda function as its target. To invoke different Lambda functions based on different lifecycle notifications, you can create multiple rules and associate each rule with a specific event pattern and Lambda function. For more information, see [Create EventBridge rules for warm pool events](warm-pool-events-eventbridge-rules.md).
**Amazon SNS topics** — To receive a notification when an instance is put into a wait state, you create an Amazon SNS topic and then set up Amazon SNS message filtering to deliver lifecycle notifications differently based on a message attribute. For more information, see [Receive notifications using Amazon SNS](prepare-for-lifecycle-notifications.md#sns-notifications).
**Amazon SQS queues** — To set up a delivery point for lifecycle notifications where a relevant consumer can pick them up and process them, you can create an Amazon SQS queue and a queue consumer that processes messages from the SQS queue. If you want the queue consumer to process lifecycle notifications differently based on a message attribute, you must also set up the queue consumer to parse the message and then act on the message when a specific attribute matches the desired value. For more information, see [Receive notifications using Amazon SQS](prepare-for-lifecycle-notifications.md#sqs-notifications).
**AWS Lambda functions** — To run custom code when Amazon EC2 Auto Scaling puts an instance into a wait state, you can specify a Lambda function as the notification target. The Lambda function is invoked with lifecycle notification data, allowing you to perform custom actions such as instance configuration, application setup, or integration with other AWS services. You must configure the Lambda function's resource-based policy to allow the Auto Scaling service-linked role to invoke the function. For more information, see [Route notifications to AWS Lambda directly](prepare-for-lifecycle-notifications.md#lambda-notification).
# Create a warm pool for an Auto Scaling group
This topic describes how to create a warm pool for your Auto Scaling group.
**Important**
Before you continue, complete the [prerequisites](ec2-auto-scaling-warm-pools.md#warm-pool-prerequisites) for creating a warm pool and confirm that you have created a lifecycle hook for your Auto Scaling group.
## Create a warm pool
Use the following procedure to create a warm pool for your Auto Scaling group.
**To create a warm pool (console)**
1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), and choose **Auto Scaling Groups** from the navigation pane.
1. Select the check box next to an existing group.
A split pane opens up at the bottom of the page.
1. Choose the **Instance management** tab.
1. Under **Warm pool**, choose **Create warm pool**.
1. To configure a warm pool, do the following:
1. For **Warm pool instance state**, choose which state you want to transition your instances to when they enter the warm pool. The default is `Stopped`.
1. For **Minimum warm pool size**, enter the minimum number of instances to maintain in the warm pool.
1. For **Instance reuse**, select the **Reuse on scale in** check box to allow instances in the Auto Scaling group to return to the warm pool on scale in.
1. For **Warm pool size**, choose one of the available options:
+ **Default specification**: The size of the warm pool is determined by the difference between the maximum and desired capacity of the Auto Scaling group. This option streamlines warm pool management. After you create the warm pool, its size can be easily updated just by adjusting the maximum capacity of the group.
+ **Custom specification**: The size of the warm pool is determined by the difference between a custom value and the desired capacity of the Auto Scaling group. This option gives you flexibility to manage the size of your warm pool independently from the maximum capacity of the group.
1. View the **Estimated warm pool size based on current settings** section to confirm how the default or custom specification applies to the size of the warm pool. Remember, the warm pool size depends on the desired capacity of the Auto Scaling group, which will change if the group scales.
1. Choose **Create**.
## Instance type selection with mixed instance groups
Auto Scaling prioritizes instance types that are already in the warm pool during scaling events when your group is configured with a mixed instances policy. Launch behavior:
1. Auto Scaling attempts to launch instances using instance types available in the warm pool.
1. If warm launch fails, Auto Scaling attempts cold launch using all remaining instance types in your mixed instances policy.
**Example**
**Example**
If you configure your Auto Scaling group with 10 instance types and your warm pool contains 6 of those instance types. During scale-out, Auto Scaling first tries the 6 instance types from the warm pool. If unsuccessful, Auto Scaling tries all configured instance types through cold launch.
This gives you warm pool performance benefits when possible while maintaining the flexibility of your full mixed instances configuration.
## Delete a warm pool
When you no longer need the warm pool, use the following procedure to delete it.
**To delete your warm pool (console)**
1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), and choose **Auto Scaling Groups** from the navigation pane.
1. Select the check box next to an existing group.
A split pane opens up at the bottom of the page.
1. Choose the **Instance management** tab.
1. For **Warm pool**, choose **Actions**, **Delete**.
1. When prompted for confirmation, choose **Delete**.
# View health check status and the reason for health check failures
Health checks allow Amazon EC2 Auto Scaling to determine when an instance is unhealthy and should be terminated. For warm pool instances kept in a `Stopped` state, it employs the knowledge that Amazon EBS has of a `Stopped` instance's availability to identify unhealthy instances. It does this by calling the `DescribeVolumeStatus` API to determine the status of the EBS volume that's attached to the instance. For warm pool instances kept in a `Running` state, it relies on EC2 status checks to determine instance health. While there is no health check grace period for warm pool instances, Amazon EC2 Auto Scaling doesn't start checking instance health until the lifecycle hook finishes.
When an instance is found to be unhealthy, Amazon EC2 Auto Scaling automatically deletes the unhealthy instance and creates a new one to replace it. Instances are usually terminated within a few minutes after failing their health check. For more information, see [View the reason for health check failures](replace-unhealthy-instance.md).
Custom health checks are also supported. This can be helpful if you have your own health check system that can detect an instance's health and send this information to Amazon EC2 Auto Scaling. For more information, see [Set up a custom health check for your Auto Scaling group](set-up-a-custom-health-check.md).
On the Amazon EC2 Auto Scaling console, you can view the status (healthy or unhealthy) of your warm pool instances. You can also view their health status using the AWS CLI or one of the SDKs.
**To view the status of your warm pool instances (console)**
1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), and choose **Auto Scaling Groups** from the navigation pane.
1. Select the check box next to the Auto Scaling group.
A split pane opens up in the bottom of the **Auto Scaling groups** page.
1. On the **Instance management** tab, under **Warm pool instances**, the **Lifecycle** column contains the state of your instances.
The **Health status** column shows the assessment that Amazon EC2 Auto Scaling has made of instance health.
**Note**
New instances start healthy. Until the lifecycle hook is finished, an instance's health is not checked.
**To view the reason for health check failures (console)**
1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), and choose **Auto Scaling Groups** from the navigation pane.
1. Select the check box next to the Auto Scaling group.
A split pane opens up in the bottom of the **Auto Scaling groups** page.
1. On the **Activity** tab, under **Activity history**, the **Status** column shows whether your Auto Scaling group has successfully launched or terminated instances.
If it terminated any unhealthy instances, the **Cause** column shows the date and time of the termination and the reason for the health check failure. For example, "At 2021-04-01T21:48:35Z an instance was taken out of service in response to EBS volume health check failure".
**To view the status of your warm pool instances (AWS CLI)**
View the warm pool for an Auto Scaling group by using the following [describe-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-warm-pool.html) command.
```
aws autoscaling describe-warm-pool --auto-scaling-group-name my-asg
```
Example output.
```
{
"WarmPoolConfiguration": {
"MinSize": 0,
"PoolState": "Stopped"
},
"Instances": [
{
"InstanceId": "i-0b5e5e7521cfaa46c",
"InstanceType": "t2.micro",
"AvailabilityZone": "us-west-2a",
"LifecycleState": "Warmed:Stopped",
"HealthStatus": "Healthy",
"LaunchTemplate": {
"LaunchTemplateId": "lt-08c4cd42f320d5dcd",
"LaunchTemplateName": "my-template-for-auto-scaling",
"Version": "1"
}
},
{
"InstanceId": "i-0e21af9dcfb7aa6bf",
"InstanceType": "t2.micro",
"AvailabilityZone": "us-west-2a",
"LifecycleState": "Warmed:Stopped",
"HealthStatus": "Healthy",
"LaunchTemplate": {
"LaunchTemplateId": "lt-08c4cd42f320d5dcd",
"LaunchTemplateName": "my-template-for-auto-scaling",
"Version": "1"
}
}
]
}
```
**To view the reason for health check failures (AWS CLI)**
Use the following [describe-scaling-activities](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-scaling-activities.html) command.
```
aws autoscaling describe-scaling-activities --auto-scaling-group-name my-asg
```
The following is an example response, where `Description` indicates that your Auto Scaling group has terminated an instance and `Cause` indicates the reason for the health check failure.
Scaling activities are ordered by start time. Activities still in progress are described first.
```
{
"Activities": [
{
"ActivityId": "4c65e23d-a35a-4e7d-b6e4-2eaa8753dc12",
"AutoScalingGroupName": "my-asg",
"Description": "Terminating EC2 instance: i-04925c838b6438f14",
"Cause": "At 2021-04-01T21:48:35Z an instance was taken out of service in response to EBS volume health check failure.",
"StartTime": "2021-04-01T21:48:35.859Z",
"EndTime": "2021-04-01T21:49:18Z",
"StatusCode": "Successful",
"Progress": 100,
"Details": "{\"Subnet ID\":\"subnet-5ea0c127\",\"Availability Zone\":\"us-west-2a\"...}",
"AutoScalingGroupARN": "arn:aws:autoscaling:us-west-2:123456789012:autoScalingGroup:283179a2-f3ce-423d-93f6-66bb518232f7:autoScalingGroupName/my-asg"
},
...
]
}
```
# Examples for creating and managing warm pools with the AWS CLI
You can create and manage warm pools using the AWS Management Console, AWS Command Line Interface (AWS CLI), or SDKs.
The following examples show you how to create and manage warm pools using the AWS CLI.
**Topics**
+ [Example 1: Keep instances in the `Stopped` state](#warm-pool-configuration-ex1)
+ [Example 2: Keep instances in the `Running` state](#warm-pool-configuration-ex2)
+ [Example 3: Keep instances in the `Hibernated` state](#warm-pool-configuration-ex3)
+ [Example 4: Return instances to the warm pool when scaling in](#warm-pool-configuration-ex4)
+ [Example 5: Specify the minimum number of instances in the warm pool](#warm-pool-configuration-ex5)
+ [Example 6: Define the warm pool size using a custom specification](#warm-pool-configuration-ex6)
+ [Example 7: Define an absolute warm pool size](#warm-pool-configuration-ex7)
+ [Example 8: Delete a warm pool](#delete-warm-pool-cli)
## Example 1: Keep instances in the `Stopped` state
The following [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html) example creates a warm pool that keeps instances in a `Stopped` state.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped
```
## Example 2: Keep instances in the `Running` state
The following [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html) example creates a warm pool that keeps instances in a `Running` state instead of a `Stopped` state.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Running
```
## Example 3: Keep instances in the `Hibernated` state
The following [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html) example creates a warm pool that keeps instances in a `Hibernated` state instead of a `Stopped` state. This lets you stop instances without deleting their memory contents (RAM).
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Hibernated
```
## Example 4: Return instances to the warm pool when scaling in
The following [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html) example creates a warm pool that keeps instances in a `Stopped` state and includes the `--instance-reuse-policy` option. The instance reuse policy value `'{"ReuseOnScaleIn": true}'` tells Amazon EC2 Auto Scaling to return instances to the warm pool when your Auto Scaling group scales in.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --instance-reuse-policy '{"ReuseOnScaleIn": true}'
```
## Example 5: Specify the minimum number of instances in the warm pool
The following [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html) example creates a warm pool that maintains a minimum of 4 instances, so that there are at least 4 instances available to handle traffic spikes.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --min-size 4
```
## Example 6: Define the warm pool size using a custom specification
By default, Amazon EC2 Auto Scaling manages the size of your warm pool as the difference between the maximum and desired capacity of the Auto Scaling group. However, you can manage the size of the warm pool independently from the group's maximum capacity by using the `--max-group-prepared-capacity` option.
The following [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html) example creates a warm pool and sets the maximum number of instances that can exist concurrently in both the warm pool and Auto Scaling group. If the group has a desired capacity of 800, the warm pool will initially have a size of 100 as it initializes after running this command.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --max-group-prepared-capacity 900
```
To maintain a minimum number of instances in the warm pool, include the `--min-size` option with the command, as follows.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --max-group-prepared-capacity 900 --min-size 25
```
## Example 7: Define an absolute warm pool size
If you set the same values for the `--max-group-prepared-capacity` and `--min-size` options, the warm pool has an absolute size. The following [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html) example creates a warm pool that maintains a constant warm pool size of 10 instances.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --min-size 10 --max-group-prepared-capacity 10
```
## Example 8: Delete a warm pool
Use the following [delete-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-warm-pool.html) command to delete a warm pool.
```
aws autoscaling delete-warm-pool --auto-scaling-group-name my-asg
```
If there are instances in the warm pool, or if scaling activities are in progress, use the [delete-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-warm-pool.html) command with the `--force-delete` option. This option also terminates the Amazon EC2 instances and any outstanding lifecycle actions.
```
aws autoscaling delete-warm-pool --auto-scaling-group-name my-asg --force-delete
```