Undo changes with a manual or auto rollback
You can roll back an instance refresh that is still in progress. You can't roll it back after it's finished. You can, however, update your Auto Scaling group again by starting a new instance refresh.
When rolling back, Amazon EC2 Auto Scaling replaces the instances that have been deployed so far. The new instances match the configuration that you last saved on the Auto Scaling group before starting the instance refresh.
Amazon EC2 Auto Scaling provides the following ways to roll back:
-
Manual rollback: You start a rollback manually to reverse what was deployed up to the rollback point.
-
Auto rollback: Amazon EC2 Auto Scaling automatically reverses what was deployed if the instance refresh fails for some reason or if any CloudWatch alarms you specify go into the
ALARMstate.
Considerations
The following considerations apply when using a rollback:
-
The rollback option is only available if you specify a desired configuration as part of starting an instance refresh.
-
You can only roll back to a previous version of a launch template if the version is a specific numbered version. The rollback option is not available if the Auto Scaling group is configured to use the
$Latestor$Defaultlaunch template version. -
You also cannot roll back to a launch template that is configured to use an AMI alias from the AWS Systems Manager Parameter Store.
-
The configuration that you last saved on the Auto Scaling group must be in a stable state. If it's not in a stable state, the rollback workflow will still occur, but it will eventually fail. Until you resolve the issue, the Auto Scaling group might be in a failed state where it can no longer launch instances successfully. This might impact the availability of the service or application.
Manually start a rollback
Start an instance refresh with auto rollback
Using the auto rollback feature, you can automatically roll back the instance
refresh when it fails, such as when there are errors or a specified Amazon CloudWatch
alarm goes into the ALARM state.
If you enable auto rollback, and there are errors while replacing instances,
the instance refresh attempts to complete all replacements for one hour before
it fails and rolls back. These errors are usually caused by things like EC2
launch failures, misconfigured health checks, or not ignoring or allowing the
termination of instances that are in Standby state or protected
from scale in.
Specifying CloudWatch alarms is optional. To specify an alarm, you first need to
create it. You can specify metric alarms and composite alarms. For information
about creating the alarm, see the Amazon CloudWatch User Guide. Using Elastic Load Balancing metrics as an
example, if you use an Application Load Balancer, you could use the
HTTPCode_ELB_5XX_Count and HTTPCode_ELB_4XX_Count
metrics.
Considerations
-
If you specify a CloudWatch alarm but do not enable auto rollback, and the alarm state goes to
ALARM, the instance refresh fails without rolling back. -
You can choose a maximum of 10 alarms when you start an instance refresh.
-
When choosing a CloudWatch alarm, the alarm must be in a compatible state. If the alarm state is
INSUFFICIENT_DATAorALARM, you receive an error when you try to start the instance refresh. -
When creating an alarm for Amazon EC2 Auto Scaling to use, the alarm should include how to treat missing data points. If a metric is frequently missing data points by design, the state of the alarm is
INSUFFICIENT_DATAduring those periods. When this happens, Amazon EC2 Auto Scaling cannot replace instances until new data points are found. To force the alarm to maintain the previousALARMorOKstate, you could choose to ignore missing data instead. For more information, see Configuring how alarms treat missing data in the Amazon CloudWatch User Guide.
