Skip to main content
In this walkthrough you’ll learn how to use CloudFormation rollback triggers to prevent stack creates or updates when one or more CloudWatch alarms are in the ALARM state. Rollback triggers allow CloudFormation to monitor specified CloudWatch alarms for a configured monitoring window after a stack operation begins. If any monitored alarm enters ALARM during that window, CloudFormation marks the operation as failed and rolls back the change. Key benefits:
  • Prevents deploying changes when monitored metrics indicate an unhealthy state.
  • Adds an automated safety net to stack updates and creates.
  • Useful for production and critical systems where metric-driven protection is required.
Demo workflow
  1. Create a stack from an EC2 instance template.
  2. Confirm the EC2 instance is running and tagged for metric lookup.
  3. Create a CloudWatch alarm that monitors the EC2 instance CPUUtilization.
  4. Attach that alarm as a rollback trigger when updating the stack.
  5. Observe the update failing when the alarm is in ALARM.
  6. Clean up resources.
Create the stack from a template. Upload the EC2 instance template and pick the template that provisions a simple EC2 instance.
A dark-themed Windows file-open dialog showing a "cf-project" folder listing YAML files (e.g., simple-s3, s3-bucket, ec2-instance). The dialog is over an AWS web console page with a "Sync from Git" option visible.
Enter a stack name and choose instance parameters. For this demo we use a t3.micro instance in the default VPC and leave other settings at their defaults. Proper tagging helps CloudWatch locate instance metrics and makes selecting the right instance easier when creating alarms.
A screenshot of the AWS CloudFormation "Create stack" console showing the Parameters panel with an EC2 instance type dropdown open (options like t3.micro and t3.small) and navigation buttons (Cancel, Previous, Next). The browser window and Windows taskbar are also visible.
Create a CloudWatch alarm to use as the rollback trigger:
  • In the CloudWatch console go to Alarms → Create alarm.
  • Select metric → EC2 → Per-Instance Metrics → CPUUtilization. If the list is long, type “CPU” to filter.
  • Metric options: for example, Statistic = Average, Period = 5 minutes.
  • Condition: choose a threshold that will trigger ALARM for demonstration (e.g., GreaterThanThreshold = 0.2).
  • Skip SNS notification for the demo and set the alarm name to CloudWatchAlarm1.
A screenshot of the AWS CloudWatch "Create alarm" page showing a CPUUtilization metric for an EC2 instance (InstanceId i-07733807276ccf726, name SimpleWebServer) with the statistic set to Average and a 5-minute period, and a small chart showing near-zero CPU usage.
Rollback trigger configuration requires two values: the monitoring time (minutes) and the alarm ARN. Add the RollbackConfiguration to your CloudFormation template or include it as part of the stack update parameters. Example snippet:
Now update the CloudFormation stack and attach the CloudWatch alarm as a rollback trigger:
  1. In the CloudFormation console select the stack → Update stack.
  2. Choose “Use existing template” (or the appropriate template option) → Next.
  3. Use the default parameter values (or modify if needed) and continue to Configure stack options.
  4. In the Configure stack options page, scroll to Rollback configuration and add the rollback trigger: set the monitoring time (minutes) and paste the alarm ARN (copy the ARN from the CloudWatch alarm details).
  5. Review the changes and submit the update.
A screenshot of the AWS CloudFormation console on the "Update stack" page showing the "Prerequisite - Prepare template" step with three template options (the "Use existing template" option selected). The left sidebar shows the update workflow steps (Update stack, Specify stack details, Configure stack options, Review DemoStack).
Important behavior and troubleshooting
If any specified CloudWatch alarm is in ALARM during the configured MonitoringTimeInMinutes window, CloudFormation treats the operation as failed and rolls back. If an alarm is already in ALARM when you start the update, the update may fail immediately depending on the monitoring window. Choose monitoring windows carefully to allow resources to stabilize and metrics to be collected.
In this demo the alarm was already in ALARM when the update began, so the stack update failed and CloudFormation reported “Update rollback complete (failed)”. Always verify alarm states (OK) before initiating critical updates if you want the rollout to proceed. Clean up resources when finished:
  • Delete the CloudFormation stack (CloudFormation console → select stack → Delete).
  • Delete the CloudWatch alarm: in CloudWatch go to Alarms, select the alarm, open Actions → Delete, and confirm.
A screenshot of the AWS CloudWatch Alarms console showing one alarm (CWAlarm1) selected and in state "In alarm," with the Actions menu open and the "Delete" option highlighted. The sidebar navigation and top controls like "Create alarm" and "Create composite alarm" are also visible.
Best practices and quick reference
  • Ensure alarms used as rollback triggers are in an OK state before starting critical stack operations.
  • Use tags to help find per-instance metrics quickly when creating alarms.
  • Set the monitoring time long enough for resources and metrics to stabilize, but short enough to avoid excessive delays.
Links and references This workflow helps you protect deployments by tying CloudFormation operations to CloudWatch alarm states so that metric-driven failures automatically prevent or roll back unsafe changes.

Watch Video