CloudFormation Can Now Drive Fleet Refreshes Directly
AWS added Instance Refresh as a native CloudFormation update policy on July 29, 2026. The new policy is called AutoScalingInstanceRefresh.
Configure it on an Auto Scaling group. Then update properties that need instance replacement. CloudFormation triggers the refresh automatically.
The feature is available in all AWS Regions at no additional cost.
What the Integration Unlocks
Instance Refresh is useful when a configuration change requires replacing instances or root volumes, and especially useful for large groups.
AWS names several capabilities now available through the integration: replace root volume for in-place updates, launch-before-terminate, alarm-based monitoring, and checkpoints with bake time for controlled rollouts. The announcement does not specify configuration requirements or behavioral details for these capabilities individually. The AWS CloudFormation Template Reference is the authoritative source for the full parameter set.
Auto Scaling features such as scaling policies and health checks remain active throughout the update, so service health is not at risk during deployments.
Deploying a new Amazon Machine Image (AMI) across an Auto Scaling group is a documented use case for Instance Refresh. So is applying security patches or software updates while preserving long-running instance state and avoiding capacity constraints with specialized instance types like GPU or Mac instances. Because both are documented Instance Refresh use cases, both can now be initiated through a CloudFormation stack update using the new policy.
Rollback Works Differently Here
One detail changes the operational picture.
Rollback is handled through CloudFormation stack rollback, which differs from the API-initiated rollback documented for standalone use outside CloudFormation.
That means rollback behavior will depend on how your CloudFormation stacks are configured—a relationship worth testing before moving to production. Stacks with complex configurations could behave differently from what your current runbook expects. Test rollback in a non-production stack before adopting the new policy in production.
Whether API-initiated rollback and CloudFormation stack rollback can coexist when Instance Refresh runs through CloudFormation is not addressed in the announcement.
What to Audit and Decide Now
Cloud platform owners should take three concrete steps.
Review existing stacks. Any CloudFormation stack managing an EC2 Auto Scaling group is a candidate. The announcement does not describe an automatic migration path for existing stacks.
Evaluate checkpoint and bake-time settings. The new policy supports checkpoints with bake time for controlled rollouts. Decide whether your rollout risk tolerance requires pause points. If left unconfigured, check the CloudFormation Template Reference for default behavior.
Update rollback runbooks. Rollback now runs through CloudFormation stack rollback. If your on-call playbook references a different recovery path, update it before moving to production.
The AWS CloudFormation Template Reference entry for AutoScalingInstanceRefresh is the authoritative source for parameter details and defaults.