# Control which Auto Scaling instances terminate during scale in
Amazon EC2 Auto Scaling uses termination policies to decide the order for terminating instances. You can use a predefined policy or create a custom policy to meet your specific requirements. By using a custom policy or instance scale in protection, you can also prevent your Auto Scaling group from terminating instances that aren't yet ready to terminate.
**Topics**
+ [When Amazon EC2 Auto Scaling uses termination policies](#common-scenarios-termination)
+ [Configure termination policies for Amazon EC2 Auto Scaling](ec2-auto-scaling-termination-policies.md)
+ [Create a custom termination policy with Lambda](lambda-custom-termination-policy.md)
+ [Use instance scale-in protection to control instance termination](ec2-auto-scaling-instance-protection.md)
+ [Design your applications to gracefully handle instance termination](gracefully-handle-instance-termination.md)
## When Amazon EC2 Auto Scaling uses termination policies
The following sections describe the scenarios in which Amazon EC2 Auto Scaling uses termination policies.
**Topics**
+ [Scale in events](#common-scenarios-termination-scale-in)
+ [Instance refresh](#common-scenarios-termination-instance-refreshes)
+ [Availability Zone rebalancing](#common-scenarios-termination-rebalancing)
### Scale in events
A scale in event occurs when there is a new value for the desired capacity of an Auto Scaling group that is lower than the current capacity of the group.
Scale in events occur in the following scenarios:
+ When using dynamic scaling policies and the size of the group decreases as a result of changes in a metric's value
+ When using scheduled scaling and the size of the group decreases as a result of a scheduled action
+ When you manually decrease the size of the group
The following example shows how termination policies work when there is a scale in event.
1. The Auto Scaling group in this example has one instance type, two Availability Zones, and a desired capacity of two instances. It also has a dynamic scaling policy that adds and removes instances when resource utilization increases or decreases. The two instances in this group are distributed across the two Availability Zones as shown in the following diagram.
![\[A basic Auto Scaling group with two instances.\]](http://docs.aws.amazon.com/autoscaling/ec2/userguide/images/termination-policy-default-diagram.png)
1. When the Auto Scaling group scales out, Amazon EC2 Auto Scaling launches a new instance. The Auto Scaling group now has three instances, distributed across the two Availability Zones as shown in the following diagram.
![\[An Auto Scaling group after scaling out by one instance.\]](http://docs.aws.amazon.com/autoscaling/ec2/userguide/images/termination-policy-default-2-diagram.png)
1. When the Auto Scaling group scales in, Amazon EC2 Auto Scaling terminates one of the instances.
1. If you did not assign a specific termination policy to the group, Amazon EC2 Auto Scaling uses the default termination policy. It selects the Availability Zone with two instances, and terminates the instance that was launched from a launch configuration, a different launch template, or the oldest version of the current launch template. If the instances were launched from the same launch template and version, Amazon EC2 Auto Scaling selects the instance that is closest to the next billing hour and terminates it.
![\[An Auto Scaling group after scaling in by one instance.\]](http://docs.aws.amazon.com/autoscaling/ec2/userguide/images/termination-policy-default-3-diagram.png)
### Instance refresh
You can start an instance refresh to update the instances in your Auto Scaling group. During an instance refresh, Amazon EC2 Auto Scaling terminates instances in the group and then launches replacements for the terminated instances. The termination policy for the Auto Scaling group controls which instances are replaced first.
### Availability Zone rebalancing
Amazon EC2 Auto Scaling balances your capacity evenly across the Availability Zones enabled for your Auto Scaling group. This helps reduce the impact of an Availability Zone outage. If the distribution of capacity across Availability Zones becomes out of balance, Amazon EC2 Auto Scaling rebalances the Auto Scaling group by launching instances in the enabled Availability Zones with the fewest instances and terminating instances elsewhere. The termination policy controls which instances are prioritized for termination first.
There are a number of reasons why the distribution of instances across Availability Zones can become out of balance.
Removing instances
If you detach instances from your Auto Scaling group, you put instances on standby, or you explicitly terminate instances and decrement the desired capacity, which prevents replacement instances from launching, the group can become unbalanced. If this occurs, Amazon EC2 Auto Scaling compensates by rebalancing the Availability Zones.
Using different Availability Zones than originally specified
If you expand your Auto Scaling group to include additional Availability Zones, or you change which Availability Zones are used, Amazon EC2 Auto Scaling launches instances in the new Availability Zones and terminates instances in other zones to help ensure that your Auto Scaling group spans Availability Zones evenly.
Availability outage
Availability outages are rare. However, if one Availability Zone becomes unavailable and recovers later, your Auto Scaling group can become unbalanced between Availability Zones. Amazon EC2 Auto Scaling tries to gradually rebalance the group, and rebalancing might terminate instances in other zones.
For example, imagine that you have an Auto Scaling group that has one instance type, two Availability Zones, and a desired capacity of two instances. In a situation where one Availability Zone fails, Amazon EC2 Auto Scaling automatically launches a new instance in the healthy Availability Zone to replace the one in the unhealthy Availability Zone. Then, when the unhealthy Availability Zone returns to a healthy state later on, Amazon EC2 Auto Scaling automatically launches a new instance in this zone, which in turn terminates an instance in the unaffected zone.
**Note**
When rebalancing, Amazon EC2 Auto Scaling launches new instances before terminating the old ones, so that rebalancing does not compromise the performance or availability of your application.
Because Amazon EC2 Auto Scaling attempts to launch new instances before terminating the old ones, being at or near the specified maximum capacity could impede or completely stop rebalancing activities. To avoid this problem, the system can temporarily exceed the specified maximum capacity of a group by a 10 percent margin (or by a margin of one instance, whichever is greater) during a rebalancing activity. The margin is extended only if the group is at or near maximum capacity and needs rebalancing, either because of user-requested rezoning or to compensate for zone availability issues. The extension lasts only as long as needed to rebalance the group.
# Configure termination policies for Amazon EC2 Auto Scaling
A termination policy provides the criteria that Amazon EC2 Auto Scaling follows to terminate instances in a specific order. By default, Amazon EC2 Auto Scaling uses a termination policy that's designed to terminate instances that are using outdated configurations first. You can change the termination policy to control which instances are most important to terminate first.
When Amazon EC2 Auto Scaling terminates instances, it tries to maintain balance across the Availability Zones that are enabled for your Auto Scaling group. Maintaining Zonal balance takes precedence over the termination policy. If one Availability Zone has more instances than others, Amazon EC2 Auto Scaling applies the termination policy to the imbalanced zone first. If the Availability Zones are balanced, it applies the termination policy across all Zones.
**Topics**
+ [How the default termination policy works](#default-termination-policy)
+ [Default termination policy and mixed instances groups](#default-termination-policy-mixed-instances-groups)
+ [Predefined termination policies](#predefined-termination-policies)
+ [Change the termination policy for an Auto Scaling group](custom-termination-policy.md)
**Note**
Amazon EC2 Auto Scaling applies termination policies only to instances that are not considered unhealthy by the Auto Scaling group. As a result, instances marked as unhealthy by Auto Scaling health checks will bypass termination policy evaluation.
For more information, see [Design your applications to gracefully handle instance termination](gracefully-handle-instance-termination.md).
## How the default termination policy works
When Amazon EC2 Auto Scaling needs to terminate an instance, it first identifies which Availability Zone (or Zones) has the most instances and at least one instance that is not protected from scale in. Then, it proceeds to evaluate unprotected instances within the identified Availability Zone as follows:
**Instances that use outdated configurations**
+ **For groups that use a launch template** – Determine whether any of the instances use outdated configurations, prioritizing in this order:
1. First, check for instances launched with a launch configuration.
1. Then, check for instances launched using a different launch template instead of the current launch template.
1. Finally, check for instances using the oldest version of the current launch template.
+ **For groups that use a launch configuration** – Determine whether any of the instances use the oldest launch configuration.
If no instances with outdated configurations are found, or there are multiple instances to choose from, Amazon EC2 Auto Scaling considers the next criteria of instances approaching their next billing hour.
**Instances approaching next billing hour**
Determine whether any of the instances that meet the previous criteria are closest to the next billing hour. If multiple instances are equally close, terminate one at random. This helps you maximize the use of your instances that are billed hourly. However, most EC2 usage is now billed per second, so this optimization provides less benefit. For more information, see [Amazon EC2 pricing](https://aws.amazon.com/ec2/pricing/).
The following flow diagram illustrates how the default termination policy works for groups that use a launch template.
![\[A flowchart showing how an Auto Scaling group uses the default termination policy to terminate instances.\]](http://docs.aws.amazon.com/autoscaling/ec2/userguide/images/termination-policy-default-flowchart-diagram.png)
## Default termination policy and mixed instances groups
Amazon EC2 Auto Scaling applies additional criteria when terminating instances in [mixed instances groups](ec2-auto-scaling-mixed-instances-groups.md).
When Amazon EC2 Auto Scaling needs to terminate an instance, it first identifies which purchase option (Spot or On-Demand) should be terminated based on the settings of the group. This makes sure that the group trends toward the specified ratio of Spot and On-Demand instances over time.
It then applies the termination policy independently within each Availability Zone. It determines which Spot or On-Demand Instance in which Availability Zone to terminate to keep the Availability Zones balanced. The same logic applies to a mixed instances group with weights defined for the instance types.
Within each zone, the default termination policy works as follows to determine which unprotected instance within the identified purchase option can be terminated:
1. Determine whether any of the instances can be terminated to improve alignment with the specified [allocation strategy](allocation-strategies.md) for the Auto Scaling group. If no instances are identified for optimization, or there are multiple instances to choose from, the evaluation continues.
1. Determine whether any of the instances use outdated configurations, prioritizing in this order:
1. First, check for instances launched with a launch configuration.
1. Then, check for instances launched using a different launch template instead of the current launch template.
1. Finally, check for instances using the oldest version of the current launch template.
If no instances with outdated configurations are found, or there are multiple instances to choose from, the evaluation continues.
1. Determine whether any of the instances are closest to the next billing hour. If multiple instances are equally close, choose one at random.
## Predefined termination policies
You choose from the following predefined termination policies:
+ **`Default`** – Terminate instances according to the default termination policy.
+ **`AllocationStrategy`** – Terminate instances in the Auto Scaling group to align the remaining instances to the allocation strategy for the type of instance that is terminating (either a Spot Instance or an On-Demand Instance). This policy is useful when your preferred instance types have changed. If the Spot allocation strategy is `lowest-price`, you can gradually rebalance the distribution of Spot Instances across your N lowest priced Spot pools. If the Spot allocation strategy is `capacity-optimized`, you can gradually rebalance the distribution of Spot Instances across Spot pools where there is more available Spot capacity. You can also gradually replace On-Demand Instances of a lower priority type with On-Demand Instances of a higher priority type.
+ **`OldestLaunchTemplate`** – Terminate instances that have the oldest launch template. With this policy, instances that use the noncurrent launch template are terminated first, followed by instances that use the oldest version of the current launch template. This policy is useful when you're updating a group and phasing out the instances from a previous configuration.
+ **`OldestLaunchConfiguration`** – Terminate instances that have the oldest launch configuration. This policy is useful when you're updating a group and phasing out the instances from a previous configuration. With this policy, instances that use the noncurrent launch configuration are terminated first.
+ **`ClosestToNextInstanceHour`** – Terminate instances that are closest to the next billing hour. This policy helps you maximize the use of your instances that have an hourly charge.
+ **`NewestInstance`** – Terminate the newest instance in the group. This policy is useful when you're testing a new launch configuration but don't want to keep it in production.
+ **`OldestInstance`** – Terminate the oldest instance in the group. This option is useful when you're upgrading the instances in the Auto Scaling group to a new EC2 instance type. You can gradually replace instances of the old type with instances of the new type.
**Note**
Amazon EC2 Auto Scaling always balances instances across Availability Zones first, regardless of which termination policy is used. As a result, you might encounter situations in which some newer instances are terminated before older instances. For example, when there is a more recently added Availability Zone, or when one Availability Zone has more instances than the other Availability Zones that are used by the group.
# Change the termination policy for an Auto Scaling group
To change the termination policy for your Auto Scaling group, use one of the following methods.
------
#### [ Console ]
You can't change the termination policy when you initially create an Auto Scaling group in the Amazon EC2 Auto Scaling console. The default termination policy is used automatically. After your Auto Scaling group has been created, you can replace the default policy with a different termination policy or multiple termination policies listed in the order in which they should apply.
**To change the termination policy for an Auto Scaling group**
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 page.
1. On the **Details** tab, choose **Advanced configurations**, **Edit**.
1. For **Termination policies**, choose one or more termination policies. If you choose multiple policies, put them in the order that you want them evaluated in.
You can optionally choose **Custom termination policy** and then choose a Lambda function that meets your needs. If you have created versions and aliases for your Lambda function, you can choose a version or alias from the **Version/Alias** drop-down. To use the unpublished version of your Lambda function, keep **Version/Alias** set to its default. For more information, see [Create a custom termination policy with Lambda](lambda-custom-termination-policy.md).
**Note**
When using multiple policies, their order must be set correctly:
If you use the **Default** policy, it must be the last policy in the list.
If you use a **Custom termination policy**, it must be the first policy in the list.
1. Choose **Update**.
------
#### [ AWS CLI ]
The default termination policy is used automatically unless a different policy is specified.
**To change the termination policy for an Auto Scaling group**
Use one of the following commands:
+ [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)
+ [update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html)
You can use termination policies individually, or combine them into a list of policies. For example, use the following command to update an Auto Scaling group to use the `OldestLaunchConfiguration` policy first and then use the `ClosestToNextInstanceHour` policy.
```
aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg --termination-policies "OldestLaunchConfiguration" "ClosestToNextInstanceHour"
```
If you use the `Default` termination policy, make it the last one in the list of termination policies. For example, `--termination-policies "OldestLaunchConfiguration" "Default"`.
To use a custom termination policy, you must first create your termination policy using AWS Lambda. To specify the Lambda function to use as your termination policy, make it the first one in the list of termination policies. For example, `--termination-policies "arn:aws:lambda:us-west-2:123456789012:function:HelloFunction:prod" "OldestLaunchConfiguration"`. For more information, see [Create a custom termination policy with Lambda](lambda-custom-termination-policy.md).
------
# Create a custom termination policy with Lambda
Amazon EC2 Auto Scaling uses termination policies to prioritize which instances to terminate first when decreasing the size of your Auto Scaling group (referred to as *scaling in*). Your Auto Scaling group uses a default termination policy, but you can optionally choose or create your own termination policies. For more information about choosing a predefined termination policy, see [Configure termination policies for Amazon EC2 Auto Scaling](ec2-auto-scaling-termination-policies.md).
In this topic, you learn how to create a custom termination policy using an AWS Lambda function that Amazon EC2 Auto Scaling invokes in response to certain events. The Lambda function that you create processes the information in the input data sent by Amazon EC2 Auto Scaling and returns a list of instances that are ready to terminate.
A custom termination policy provides better control over which instances are terminated, and when. For example, when your Auto Scaling group scales in, Amazon EC2 Auto Scaling cannot determine whether there are workloads running that should not be disrupted. With a Lambda function, you can validate the termination request and wait until the workload is done before returning the instance ID to Amazon EC2 Auto Scaling for termination.
**Topics**
+ [Input data](#lambda-custom-termination-policy-input-data)
+ [Response data](#lambda-custom-termination-policy-response-data)
+ [Considerations](#lambda-termination-policy-considerations)
+ [Create the Lambda function](#lambda-custom-termination-policy-create-function)
+ [Limitations](#lambda-custom-termination-policy-limitations)
## Input data
Amazon EC2 Auto Scaling generates a JSON payload for scale in events, and also does so when instances are about to be terminated as a result of the maximum instance lifetime or instance refresh features. It also generates a JSON payload for the scale in events that it can initiate when rebalancing your group across Availability Zones.
This payload contains information about the capacity Amazon EC2 Auto Scaling needs to terminate, a list of instances that it suggests for termination, and the event that initiated the termination.
The following is an example payload:
```
{
"AutoScalingGroupARN": "arn:aws:autoscaling:us-east-1::autoScalingGroup:d4738357-2d40-4038-ae7e-b00ae0227003:autoScalingGroupName/my-asg",
"AutoScalingGroupName": "my-asg",
"CapacityToTerminate": [
{
"AvailabilityZone": "us-east-1b",
"Capacity": 2,
"InstanceMarketOption": "on-demand"
},
{
"AvailabilityZone": "us-east-1b",
"Capacity": 1,
"InstanceMarketOption": "spot"
},
{
"AvailabilityZone": "us-east-1c",
"Capacity": 3,
"InstanceMarketOption": "on-demand"
}
],
"Instances": [
{
"AvailabilityZone": "us-east-1b",
"InstanceId": "i-0056faf8da3e1f75d",
"InstanceType": "t2.nano",
"InstanceMarketOption": "on-demand"
},
{
"AvailabilityZone": "us-east-1c",
"InstanceId": "i-02e1c69383a3ed501",
"InstanceType": "t2.nano",
"InstanceMarketOption": "on-demand"
},
{
"AvailabilityZone": "us-east-1c",
"InstanceId": "i-036bc44b6092c01c7",
"InstanceType": "t2.nano",
"InstanceMarketOption": "on-demand"
},
...
],
"Cause": "SCALE_IN"
}
```
The payload includes the name of the Auto Scaling group, its Amazon Resource Name (ARN), and the following elements:
+ `CapacityToTerminate` describes how much of your Spot or On-Demand capacity is set to be terminated in a given Availability Zone.
+ `Instances` represents the instances that Amazon EC2 Auto Scaling suggests for termination based on the information in `CapacityToTerminate`.
+ `Cause` describes the event that caused the termination: `SCALE_IN`, `INSTANCE_REFRESH`, `MAX_INSTANCE_LIFETIME`, or `REBALANCE`.
The following information outlines the most significant factors in how Amazon EC2 Auto Scaling generates the `Instances` in the input data:
+ Maintaining balance across Availability Zones takes precedence when an instance is terminating due to scale in events and instance refresh-based terminations. Therefore, if one Availability Zone has more instances than the other Availability Zones that are used by the group, the input data contains instances that are eligible for termination only from the imbalanced Availability Zone. If the Availability Zones used by the group are balanced, the input data contains instances from all of the Availability Zones for the group.
+ When using a [mixed instances policy](ec2-auto-scaling-mixed-instances-groups.md), maintaining your Spot and On-Demand capacities in balance based on your desired percentages for each purchase option also takes precedence. We first identify which of the two types (Spot or On-Demand) should be terminated. We then identify which instances (within the identified purchase option) in which Availability Zones we can terminate that will result in the Availability Zones being most balanced.
## Response data
The input data and response data work together to narrow down the list of instances to terminate.
With the given input, the response from your Lambda function should look like the following example:
```
{
"InstanceIDs": [
"i-02e1c69383a3ed501",
"i-036bc44b6092c01c7",
...
]
}
```
The `InstanceIDs` in the response represent the instances that are ready to terminate.
Alternatively, you can return a different set of instances that are ready to be terminated, which overrides the instances in the input data. If no instances are ready to terminate when your Lambda function is invoked, you can also choose not to return any instances.
When no instances are ready to terminate, the response from your Lambda function should look like the following example:
```
{
"InstanceIDs": [ ]
}
```
## Considerations
Note the following considerations when using a custom termination policy:
+ Returning an instance first in the response data does not guarantee its termination. If more than the required number of instances are returned when your Lambda function is invoked, Amazon EC2 Auto Scaling evaluates each instance against the other termination policies that you specified for your Auto Scaling group. When there are multiple termination policies, it tries to apply the next termination policy in the list, and if there are more instances than are required to terminate, it moves on to the next termination policy, and so on. If no other termination policies are specified, then the default termination policy is used to determine which instances to terminate.
+ If no instances are returned or your Lambda function times out, then Amazon EC2 Auto Scaling waits a short time before invoking your function again. For any scale in event, it keeps trying as long as the group's desired capacity is less than its current capacity. For instance refresh-based terminations, it keeps trying for an hour. After that, if it continues to fail to terminate any instances, the instance refresh operation fails. With maximum instance lifetime, Amazon EC2 Auto Scaling keeps trying to terminate the instance that is identified as exceeding its maximum lifetime.
+ Because your function is retried repeatedly, make sure to test and fix any permanent errors in your code before using a Lambda function as a custom termination policy.
+ If you override the input data with your own list of instances to terminate, and terminating these instances puts the Availability Zones out of balance, Amazon EC2 Auto Scaling gradually rebalances the distribution of capacity across Availability Zones. First, it invokes your Lambda function to see if there are instances that are ready to be terminated so that it can determine whether to start rebalancing. If there are instances ready to be terminated, it launches new instances first. When the instances finish launching, it then detects that your group's current capacity is higher than its desired capacity and initiates a scale in event.
+ A custom termination policy does not affect your ability to also use scale in protection to protect certain instances from being terminated. For more information, see [Use instance scale-in protection to control instance termination](ec2-auto-scaling-instance-protection.md).
+ If your Lambda function returns no instances, this does not automatically prevent all termination. Amazon EC2 Auto Scaling will still terminate instances that are considered unhealthy by the Auto Scaling health checks, regardless of termination policies.
## Create the Lambda function
Start by creating the Lambda function, so that you can specify its Amazon Resource Name (ARN) in the termination policies for your Auto Scaling group.
**To create a Lambda function (console)**
1. Open the [Functions page](https://console.aws.amazon.com/lambda/home#/functions) on the Lambda console.
1. On the navigation bar at the top of the screen, choose the same Region that you used when you created the Auto Scaling group.
1. Choose **Create function**, **Author from scratch**.
1. Under **Basic information**, for **Function name**, enter the name of your function.
1. Choose **Create function**. You are returned to the function's code and configuration.
1. With your function still open in the console, under **Function code**, paste your code into the editor.
1. Choose **Deploy**.
1. Optionally, create a published version of the Lambda function by choosing the **Versions** tab and then **Publish new version**. To learn more about versioning in Lambda, see [Lambda function versions](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html) in the *AWS Lambda Developer Guide*.
1. If you chose to publish a version, choose the **Aliases** tab if you want to associate an alias with this version of the Lambda function. To learn more about aliases in Lambda, see [Lambda function aliases](https://docs.aws.amazon.com/lambda/latest/dg/configuration-aliases.html) in the *AWS Lambda Developer Guide*
1. Next, choose the **Configuration** tab and then **Permissions**.
1. Scroll down to **Resource-based policy** and then choose **Add permissions**. A resource-based policy is used to grant permissions to invoke your function to the principal that is specified in the policy. In this case, the principal will be the [Amazon EC2 Auto Scaling service-linked role](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-service-linked-role.html) that is associated with the Auto Scaling group.
1. In the **Policy statement** section, configure your permissions:
1. Choose **AWS account**.
1. For **Principal**, enter the ARN of the calling service-linked role, for example, **arn:aws:iam:::role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling**.
1. For **Action**, choose **lambda:InvokeFunction**.
1. For **Statement ID**, enter a unique statement ID, such as **AllowInvokeByAutoScaling**.
1. Choose **Save**.
1. After you have followed these instructions, continue on to specify the ARN of your function in the termination policies for your Auto Scaling group as a next step. For more information, see [Change the termination policy for an Auto Scaling group](custom-termination-policy.md).
**Note**
For examples that you can use as a reference for developing your Lambda function, see the [GitHub repository](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples) for Amazon EC2 Auto Scaling.
## Limitations
+ You can only specify one Lambda function in the termination policies for an Auto Scaling group. If there are multiple termination policies specified, the Lambda function must be specified first.
+ You can reference your Lambda function using either an unqualified ARN (without a suffix) or a qualified ARN that has either a version or an alias as its suffix. If an unqualified ARN is used (for example, `function:my-function`), your resource-based policy must be created on the unpublished version of your function. If a qualified ARN is used (for example, `function:my-function:1` or `function:my-function:prod`), your resource-based policy must be created on that specific published version of your function.
+ You cannot use a qualified ARN with the `$LATEST` suffix. If you try to add a custom termination policy that refers to a qualified ARN with the `$LATEST` suffix, it will result in an error.
+ The number of instances provided in the input data is limited to 30,000 instances. If there are more than 30,000 instances that could be terminated, the input data includes `"HasMoreInstances": true` to indicate that the maximum number of instances are returned.
+ The maximum run time for your Lambda function is two seconds (2000 milliseconds). As a best practice, you should set the timeout value of your Lambda function based on your expected run time. Lambda functions have a default timeout of three seconds, but this can be decreased.
+ If your runtime exceeds the 2-second limit, any scale in action will be on hold until the runtime falls below this threshold. For Lambda functions with consistently longer runtimes, find a way to reduce the runtime, such as by caching the results where they can be retrieved during subsequent Lambda invocations.
+ Cross-account Lambda functions aren't supported. The Lambda function used as a custom termination policy must be in the same AWS account as the Auto Scaling group. The setup instructions on this page specifically focus on same-account configurations.
+ Custom termination policies do not apply to unhealthy instances. Unhealthy instances are always considered eligible for termination, and the Lambda function only evaluates the termination order for the remaining instances.
# Use instance scale-in protection to control instance termination
Instance scale-in protection gives you control over which instances Amazon EC2 Auto Scaling can terminate. A common use case for this feature is scaling container-based workloads. For more information, see [Design your applications to gracefully handle instance termination](gracefully-handle-instance-termination.md).
By default, instance scale-in protection is disabled when you create an Auto Scaling group. This means that Amazon EC2 Auto Scaling can terminate any instance in the group.
You can protect instances as soon as they launch by enabling the instance scale-in protection setting on your Auto Scaling group. Instance scale-in protection starts when the instance state is `InService`. Then, to control which instances can terminate, disable the scale-in protection setting on individual instances within the Auto Scaling group. By doing so, you can continue to protect certain instances from unwanted terminations.
**Topics**
+ [Considerations](#instance-protection-considerations)
+ [Change scale-in protection for an Auto Scaling group](#instance-protection-group)
+ [Change scale-in protection for an instance](#instance-protection-instance)
## Considerations
The following are considerations when using instance scale-in protection:
+ If all instances in an Auto Scaling group are protected from scale in, and a scale in event occurs, its desired capacity is decremented. However, the Auto Scaling group can't terminate the required number of instances until their instance scale in protection settings are disabled. In the AWS Management Console, the **Activity history** for the Auto Scaling group includes the following message if all instances in an Auto Scaling group are protected from scale in when a scale in event occurs: `Could not scale to desired capacity because all remaining instances are protected from scale in.`
+ If you detach an instance that is protected from scale in, its instance scale in protection setting is lost. When you attach the instance to the group again, it inherits the current instance scale in protection setting of the group. When Amazon EC2 Auto Scaling launches a new instance or moves an instance from a warm pool into the Auto Scaling group, the instance inherits the instance scale in protection setting of the Auto Scaling group.
+ Instance scale-in protection does not protect Auto Scaling instances from the following:
+ Health check replacement if the instance fails health checks. For more information, see [Health checks for instances in an Auto Scaling group](ec2-auto-scaling-health-checks.md).
+ Spot Instance interruptions. A Spot Instance is terminated when capacity is no longer available or the Spot price exceeds your maximum price.
+ A Capacity Block reservation ends. Amazon EC2 reclaims the Capacity Block instances even if they are protected from scale in.
+ Manual termination through the `terminate-instance-in-auto-scaling-group` command. For more information, see [Terminate an instance in your Auto Scaling group (AWS CLI)](ec2-auto-scaling-scaling-manually.md#terminate-an-instance-aws-cli).
+ Manual termination through the Amazon EC2 console, CLI commands, and API operations. To protect Auto Scaling instances from manual termination, enable Amazon EC2 termination protection. (This does not prevent Amazon EC2 Auto Scaling from terminating instances or manual termination through the `terminate-instance-in-auto-scaling-group` command.) For information about enabling Amazon EC2 termination protection in a launch template, see [Create a launch template using advanced settings](advanced-settings-for-your-launch-template.md).
## Change scale-in protection for an Auto Scaling group
You can enable or disable the instance scale-in protection setting for an Auto Scaling group. When you enable it, all new instances launched by the group will have instance scale-in protection enabled.
Enabling or disabling this setting for an Auto Scaling group does not affect existing instances.
------
#### [ Console ]
**To enable scale-in protection for a new Auto Scaling group**
When you create the Auto Scaling group, on the **Configure group size and scaling policies** page, under **Instance scale-in protection**, select the **Enable instance scale-in protection** check box.
**To enable or disable scale-in protection for an existing group**
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 check box next to the Auto Scaling group.
A split pane opens up in the bottom of the page.
1. On the **Details** tab, choose **Advanced configurations**, **Edit**.
1. For **Instance scale-in protection**, select or clear the **Enable instance-scale protection** check box to enable or disable this option as required.
1. Choose **Update**.
------
#### [ AWS CLI ]
**To enable scale-in protection for a new Auto Scaling group**
Use the following [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) command to enable instance scale-in protection.
```
aws autoscaling create-auto-scaling-group --auto-scaling-group-name my-asg --new-instances-protected-from-scale-in ...
```
**To enable scale-in protection for an existing group**
Use the following [update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html) command to enable instance scale-in protection for the specified Auto Scaling group.
```
aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg --new-instances-protected-from-scale-in
```
**To disable scale-in protection for an existing group**
Use the following command to disable instance scale-in protection for the specified group.
```
aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg --no-new-instances-protected-from-scale-in
```
------
## Change scale-in protection for an instance
By default, an instance gets its instance scale-in protection setting from its Auto Scaling group. However, you can enable or disable instance scale-in protection for individual instances after they launch.
------
#### [ Console ]
**To enable or disable scale-in protection for an instance**
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 your Auto Scaling group.
A split pane opens up in the bottom of the page.
1. On the **Instance management** tab, in **Instances**, select an instance.
1. To enable instance scale-in protection, choose **Actions**, **Set scale-in protection**. When prompted, choose **Set scale-in protection**.
1. To disable instance scale-in protection, choose **Actions**, **Remove scale-in protection**. When prompted, choose **Remove scale-in protection**.
------
#### [ AWS CLI ]
**To enable scale-in protection for an instance**
Use the following [set-instance-protection](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/set-instance-protection.html) command to enable instance scale-in protection for the specified instance.
```
aws autoscaling set-instance-protection --instance-ids i-5f2e8a0d --auto-scaling-group-name my-asg --protected-from-scale-in
```
**To disable scale-in protection for an instance**
Use the following command to disable instance scale-in protection for the specified instance.
```
aws autoscaling set-instance-protection --instance-ids i-5f2e8a0d --auto-scaling-group-name my-asg --no-protected-from-scale-in
```
------
**Note**
Remember, instance scale-in protection does not guarantee that instances won't be terminated in the event of a human error—for example, if someone manually terminates an instance using the Amazon EC2 console or AWS CLI. To protect your instance from accidental termination, you can use Amazon EC2 termination protection. However, even with termination protection and instance scale-in protection enabled, data saved to instance storage can be lost if a health check determines that an instance is unhealthy or if the group itself is accidentally deleted. As with any environment, a best practice is to back up your data frequently, or whenever it's appropriate for your business continuity requirements.
# Design your applications to gracefully handle instance termination
This topic describes features that you can use to prevent your Amazon EC2 Auto Scaling group from terminating Amazon EC2 instances that aren't yet ready to terminate. By default, Auto Scaling has no visibility into the applications running on your instances. It can terminate instances before your application is able to gracefully shut down or complete its assigned jobs. These features give your application time to complete in-progress work, transfer state, or perform cleanup before instance terminations. You can use them individually or in combination depending on your application's requirements.
These features are particularly useful for stateful workloads, where each instance in your fleet holds different data, jobs, or state than other instances. Terminating stateful instances without graceful shutdown could result in long-running jobs restarting from the beginning, reduced data redundancy or data loss, and interrupted in-progress transactions or computations. To gracefully shut down a stateful instance, its workload should be either drained (completing all currently assigned jobs) or transferred (moving jobs, data, or configuration to another active instance).
**Topics**
+ [Termination lifecycle hooks](#gracefully-handle-instance-termination-lifecycle-hooks)
+ [Instance scale-in protection](#gracefully-handle-instance-termination-scale-in-protection)
+ [Custom termination policy](#gracefully-handle-instance-termination-custom-termination-policy)
+ [Instance lifecycle policy](#gracefully-handle-instance-termination-instance-lifecycle-policy)
+ [Suspend terminations altogether](#gracefully-handle-instance-termination-suspend-terminate)
+ [Limitations](#gracefully-handle-instance-termination-limitations)
+ [Example scenarios](#gracefully-handle-instance-termination-examples)
## Termination lifecycle hooks
A termination lifecycle hook extends the life of your Amazon EC2 instance that's already selected for termination. It provides extra time to complete in-progress work currently assigned to the instance, or to save progress and transfer the work to another instance.
For many workloads, a termination lifecycle hook may be enough to gracefully shut down an application on an instance that's selected for termination. This is a best-effort approach and can't be used to prevent termination if a termination lifecycle action is abandoned. If your workload has a low tolerance for termination lifecycle action failures, configure [ instance lifecycle policies ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/instance-lifecycle-policy.html) in combination with your termination lifecycle hooks to retain instances.
To use a termination lifecycle hook, you need to know when an instance is selected for termination. You have two ways to know this:
| Option | Description | Best used for | Link to documentation |
| --- | --- | --- | --- |
| Inside the instance | The Instance Metadata Service (IMDS) is a secure endpoint that you can poll for the status of an instance directly from the instance. If the metadata comes back with Terminated, then your instance is scheduled to be terminated. | Applications where you must perform an action on the instance before the instance is terminated. | [ Retrieve the target lifecycle state ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/retrieving-target-lifecycle-state-through-imds.html) |
| Outside the instance | When an instance is terminating, an event notification is generated. You can create rules using Amazon EventBridge, Amazon SQS, Amazon SNS, or AWS Lambda to capture these events, and invoke a response such as with a Lambda function. | Applications that need to take action outside of the instance. | [ Configure a notification target ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/prepare-for-lifecycle-notifications.html#lifecycle-hook-notification-target) |
To use a lifecycle hook, you also need to know when your instance is ready to be fully terminated. Amazon EC2 Auto Scaling will not terminate the instance until it receives a [ CompleteLifecycleAction ](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_CompleteLifecycleAction.html) API call or the timeout elapses, whichever happens first.
By default, an instance can continue running for one hour (heartbeat timeout) due to a termination lifecycle hook. You can configure the default timeout if one hour is not enough time to complete the lifecycle action. When a lifecycle action is in progress, you can extend the timeout with [ RecordLifecycleActionHeartbeat ](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_RecordLifecycleActionHeartbeat.html) API calls.
For more information, see [Amazon EC2 Auto Scaling lifecycle hooks](lifecycle-hooks.md).
## Instance scale-in protection
You can use instance scale-in protection to control which instances are selected for termination during scale-in events, especially to prevent an instance that is actively processing a long-running job from being terminated. For example, when running containerized workloads, it's common to want to protect all instances and remove protection only for instances with no current or scheduled tasks. Instances can continue polling for new jobs and re-enable protection when there are new jobs assigned.
You can enable scale-in protection at the Auto Scaling group level and instance level. When you enable scale-in protection at the Auto Scaling group level, only new instances are protected when they're created. For existing instances, you can enable protection individually.
Applications can set protection either from the instances themselves, or from a centralized control plane that manages whether each instance is terminable. We recommend the centralized approach for large fleets or when protection needs to be toggled frequently, as it allows you to batch calls to [ SetInstanceProtection ](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_SetInstanceProtection.html) and avoid API throttling issues.
For more information, see [Use instance scale-in protection to control instance termination](ec2-auto-scaling-instance-protection.md).
## Custom termination policy
Like instance scale-in protection, a custom termination policy helps you prevent your Amazon EC2 Auto Scaling group from terminating specific EC2 instances. Unhealthy instances can still be terminated regardless of your custom termination policy.
Your Auto Scaling group uses a default termination policy to determine which Amazon EC2 instances it terminates first. If you want more control over which instances terminate first, you can implement a custom termination policy using a Lambda function. Auto Scaling calls this function whenever it needs to select an instance for termination, and will only terminate instances that the function returns. If the function errors, times out, or returns an empty list, Auto Scaling doesn't terminate any instances unless the instance is unhealthy.
A custom termination policy is useful when your application can identify which instances are idle or safe to terminate. This typically requires a control plane that tracks workload across the group.
For more information, see [Create a custom termination policy with Lambda](lambda-custom-termination-policy.md).
## Instance lifecycle policy
Instance lifecycle policies provide protection against Amazon EC2 Auto Scaling terminations when a termination lifecycle action is abandoned. Unlike lifecycle hooks alone, instance lifecycle policies are designed to ensure that instances move to a retained state when graceful shutdown procedures don't complete successfully.
When Auto Scaling selects an instance for termination, your configured termination lifecycle hooks are invoked and your application begins graceful shutdown procedures. If the termination lifecycle actions complete successfully with `CONTINUE`, the instance terminates normally. However, if a termination lifecycle action is abandoned for any reason, the instance lifecycle policy moves the instance to a retained state rather than terminating it. Retained instances don't count toward your Auto Scaling group's desired capacity, so replacement instances are launched automatically. You will incur standard Amazon EC2 charges for both the retained instance and its replacement until you manually terminate the retained instance using the [ TerminateInstanceInAutoScalingGroup ](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_TerminateInstanceInAutoScalingGroup.html) API.
To use this feature, you must configure both an instance lifecycle policy with the `TerminateHookAbandon` retention trigger set to `retain`, as well as at least one termination lifecycle hook. Because retained instances incur ongoing Amazon EC2 costs and require manual action, monitoring is critical. You should enable CloudWatch metrics like `GroupTerminatingRetainedInstances` and create CloudWatch alarms to alert you when instances enter retained states.
For more information, see [Control instance retention with instance lifecycle policies](instance-lifecycle-policy.md).
## Suspend terminations altogether
If you require complete control over all EC2 instance terminations within your Amazon EC2 Auto Scaling group, suspend the `Terminate` process. We only recommend using this option if the above options do not offer you the control you need for your service. By calling [ SuspendProcesses ](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_SuspendProcesses.html) to suspend the `Terminate` process, you prevent Auto Scaling from attempting terminations for any reason, except those initiated by a user request to the [ TerminateInstanceInAutoScalingGroup ](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_TerminateInstanceInAutoScalingGroup.html) API.
For more information, see [Suspend and resume Amazon EC2 Auto Scaling processes](as-suspend-resume-processes.md).
## Limitations
**Important**
When designing your application on Amazon EC2 Auto Scaling to gracefully handle instance terminations, keep the following limitations in mind.
### Unhealthy instances bypass some protections
If an instance is unhealthy, Amazon EC2 Auto Scaling will start terminating it even if you have custom termination policies or scale-in protection in place. The only way to prevent replacement of unhealthy instances by Auto Scaling is to suspend the `HealthCheck`, `ReplaceUnhealthy`, or `Terminate` process. You can use lifecycle hooks and an instance lifecycle policy to allow the application to shut down gracefully or copy any data that you need to recover before the unhealthy instance is terminated.
| Feature | Controls healthy instances | Controls unhealthy instances |
| --- | --- | --- |
| Custom termination policies | ![\[alt text not found\]](http://docs.aws.amazon.com/autoscaling/ec2/userguide/images/success_icon.png) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/autoscaling/ec2/userguide/images/negative_icon.png) No |
| Scale-in protection | ![\[alt text not found\]](http://docs.aws.amazon.com/autoscaling/ec2/userguide/images/success_icon.png) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/autoscaling/ec2/userguide/images/negative_icon.png) No |
| Suspend HealthCheck, ReplaceUnhealthy, or Terminate process | ![\[alt text not found\]](http://docs.aws.amazon.com/autoscaling/ec2/userguide/images/success_icon.png) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/autoscaling/ec2/userguide/images/success_icon.png) Yes |
| Lifecycle hooks | ![\[alt text not found\]](http://docs.aws.amazon.com/autoscaling/ec2/userguide/images/success_icon.png) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/autoscaling/ec2/userguide/images/success_icon.png) Yes |
| Instance lifecycle policy | ![\[alt text not found\]](http://docs.aws.amazon.com/autoscaling/ec2/userguide/images/success_icon.png) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/autoscaling/ec2/userguide/images/success_icon.png) Yes |
### Lifecycle hooks alone do not guarantee graceful shutdown
By default, termination lifecycle hooks operate on a best-effort basis. If a termination lifecycle action is abandoned, Amazon EC2 Auto Scaling proceeds with terminating the instance immediately. You can combine termination lifecycle hooks with an instance lifecycle policy to retain instances when termination lifecycle actions are abandoned. With this combination:
+ Your termination lifecycle hooks attempt to gracefully shut down your application after Auto Scaling triggers an instance termination and the draining from any configured Elastic Load Balancing load balancers complete.
+ If a termination lifecycle action is abandoned for any reason, the instance moves to a retained state instead of being terminated.
+ The retained instance stays in its current Amazon EC2 state, allowing you to manually complete your shutdown procedures or investigate the failure.
+ You can manually terminate retained instances by calling the [ TerminateInstanceInAutoScalingGroup ](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_TerminateInstanceInAutoScalingGroup.html) API after completing the necessary actions.
For more information, see [Control instance retention with instance lifecycle policies](instance-lifecycle-policy.md).
### Certain instance market options can be interrupted with limited notice
If you use instance market options such as Spot Instances and interruptible capacity reservations in your Auto Scaling group, Amazon EC2 can interrupt and reclaim your instances at any time. These interruptions bypass all Amazon EC2 Auto Scaling protection mechanisms, including:
+ Termination lifecycle hooks
+ Instance scale-in protection
+ Custom termination policies
+ Instance lifecycle policies
+ Suspended processes
When a Spot Instance receives an interruption notice, you have approximately two minutes to perform graceful shutdown tasks. While you can use termination lifecycle hooks to respond to Spot Instance interruptions, the instance will be forcibly terminated at the end of the two-minute window, even if the lifecycle hook is still in progress. Instance lifecycle policies also can't prevent Spot Instance interruptions.
For more information about handling Spot Instance interruptions, see [ Spot Instance interruptions ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html) and [ Best practices for Amazon EC2 Spot ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html) in the *Amazon EC2 User Guide*.
### Direct Amazon EC2 terminations bypass all protections
If you terminate an instance in your Auto Scaling group with the Amazon EC2 [ TerminateInstances ](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_TerminateInstances.html) API directly, the termination bypasses all Amazon EC2 Auto Scaling protection mechanisms.
To terminate instances in your Auto Scaling group while respecting your configured protections, use the [ TerminateInstanceInAutoScalingGroup ](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_TerminateInstanceInAutoScalingGroup.html) API instead.
## Example scenarios
When you use Amazon EC2 Auto Scaling, you can choose how much fleet management Auto Scaling handles on your behalf versus how much direct control you retain over EC2 instance termination decisions. The more sensitive your workload is to instance terminations, the more control you may want to retain. The following examples describe workloads with different tolerance levels and the recommended configurations:
### Example 1: Distributed database nodes (Low tolerance)
You run a distributed database where each EC2 instance holds a partition of your data with a replication factor of 3. Losing multiple instances that hold replicas of the same partition could cause data loss or make that partition unavailable.
**Challenge:** Auto Scaling might terminate instances faster than data can be re-replicated to other nodes, and terminations might reduce your capacity below what's needed to maintain your replication factor.
Consider the following configurations:
+ Enable [ instance scale-in protection ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html) on all database instances; remove it programmatically only after confirming data is safely replicated elsewhere.
+ Configure [ termination lifecycle hooks ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) with extended timeouts in combination with an instance lifecycle policy to allow data transfer to complete.
+ Set an [ instance maintenance policy ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-maintenance-policy.html) with a minimum healthy percentage of 100% to maintain your required capacity.
### Example 2: Long-running job processing (Medium tolerance)
You have an Amazon SQS queue that collects incoming messages for long-running jobs. When a new message arrives, an EC2 instance retrieves the message and starts a job that takes 3 hours to process. As the queue grows, Auto Scaling adds instances based on your scaling policies. As the queue shrinks, Auto Scaling terminates instances.
**Challenge:** Auto Scaling might terminate an instance that is 3 hours into processing a job rather than an idle instance. The job can be restarted on another instance, but you lose significant progress.
Consider the following configurations:
+ Configure a [ custom termination policy ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lambda-custom-termination-policy.html) that prioritizes terminating idle instances first.
+ Use [ termination lifecycle hooks ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) to allow in-progress jobs to complete.
+ Enable [ instance scale-in protection ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html) programmatically when an instance starts a job, and remove it when the job completes.
### Example 3: Worker fleet for test environments (High tolerance)
You run a fleet of EC2 instances that execute automated tests, CI/CD pipeline jobs, or development workloads. These worker instances pull tasks from a queue, and test results can be regenerated if a job fails.
**Challenge:** Test jobs may be interrupted during scale-in events, but since tests can be retried without impact, you want to optimize for cost and simplicity rather than zero-interruption availability.
Consider the following configurations:
+ Use [ termination lifecycle hooks ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) to allow in-flight requests to complete.
+ Consider using [ Spot Instances ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) with capacity-optimized allocation strategy to further reduce costs.