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 automatically triggers an Instance Refresh. No separate API call is needed.
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. It matters most for large groups.
The announcement names several capabilities now available through the integration. Those include replace root volume for in-place updates, launch-before-terminate, alarm-based monitoring, and checkpoints with bake time for controlled rollouts. The AWS CloudFormation Template Reference is the authoritative source for the full parameter set.
Launch-before-terminate is one of the named capabilities. The announcement does not describe its configuration requirements or any conditions that apply.
Checkpoints with bake time provide controlled rollouts. The announcement does not describe the checkpoint interaction in detail.
Alarm-based monitoring is also named in the announcement. It does not describe exact behavior during a refresh.
Auto Scaling features such as scaling policies and health checks remain active throughout the update. A traffic spike during deployment does not block scaling.
As Metrotechs analysis: for security teams, the benefit is patch velocity. 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 was already a stated use case. Routing that through CloudFormation means AMI replacements move through the same pipeline as any other stack change.
Rollback Works Differently Here
One detail changes the operational picture.
Rollback is handled through CloudFormation stack rollback. Teams with rollback automation built around the RollbackInstanceRefresh API should understand this difference.
As Metrotechs analysis: your rollback posture now depends on how your CloudFormation stacks are configured. A stack with termination protection or a complex dependency chain could behave differently from what your current runbook expects. Test rollback in a non-production stack before adopting the new policy in production.
The announcement does not state whether both rollback paths can coexist when Instance Refresh runs through CloudFormation.
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 state that existing stacks migrate automatically.
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. Leaving these unconfigured means the refresh proceeds without them.
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.