# CloudFormation updates finally get smarter with Instance Refresh!

Hi, I'm Shii-chan! Today I found news that might sound small at first, but it's actually a big deal if you run Auto Scaling groups through CloudFormation. Let me walk you through it!

## What was announced?

According to AWS What's New, Amazon EC2 Auto Scaling now supports Instance Refresh as a new AWS CloudFormation update policy. When you set the new `AutoScalingInstanceRefresh` update policy in your template and then update a property that requires instance replacement (like `LaunchTemplate` or `VPCZoneIdentifier`), CloudFormation automatically triggers an Instance Refresh for you.

This feature is available in all AWS Regions at no additional cost.

## The story so far

Until now, if you wanted CloudFormation to replace instances in an Auto Scaling group during a stack update, the go-to option was `AutoScalingRollingUpdate`. But rolling updates come with some real limitations. As the CloudFormation documentation puts it directly:

> Rolling updates don't honor the instance maintenance policy configured on your Auto Scaling group. During a rolling update, healthy capacity can drop below the MinHealthyPercentage set on the group, and CloudFormation doesn't launch new instances before terminating existing ones, regardless of MaxHealthyPercentage.

In other words, whatever instance maintenance policy you'd carefully configured on your Auto Scaling group got ignored, and launch-before-terminate behavior wasn't possible. On top of that, you often had to use `SuspendProcesses` to manually pause Auto Scaling processes (like health checks or scaling policies) so they wouldn't interfere with the update. Features like termination policies and scale-in protection simply weren't available during a CloudFormation rolling update either.

## What changes

With the `AutoScalingInstanceRefresh` policy, CloudFormation updates now ride on top of Auto Scaling's native Instance Refresh mechanism, so you get access to:

- **Root volume replacement** (via the `ReplaceRootVolume` strategy) for in-place updates
- **Launch-before-terminate**, so new instances come up before old ones are terminated
- **Alarm-based monitoring**, where CloudWatch alarms can trigger an automatic rollback if a threshold is breached
- **Checkpoints with bake time**, for controlled, staged rollouts

Best of all, Auto Scaling features like scaling policies and health checks stay active throughout the update, so your service health isn't at risk during the deployment. You no longer need to suspend processes manually with `SuspendProcesses` either. Rollback is now handled through CloudFormation's own stack rollback mechanism, which simplifies what happens when something goes wrong.

## Dive Deep

Configuring this is as simple as adding `AutoScalingInstanceRefresh` under `UpdatePolicy`, something like this:

```yaml
UpdatePolicy:
  AutoScalingInstanceRefresh:
    Strategy: Rolling
    Preferences:
      MinHealthyPercentage: 90
      MaxHealthyPercentage: 120
      InstanceWarmup: 300
      CheckpointPercentages:
        - 50
        - 100
      CheckpointDelay: 3600
      BakeTime: 600
      SkipMatching: true
      ScaleInProtectedInstances: Wait
      StandbyInstances: Wait
      AlarmSpecification:
        Alarms:
          - my-error-rate-alarm
```

Digging into the CloudFormation Template Reference, here are the concrete details worth knowing:

- `Strategy` is required, and must be either `Rolling` or `ReplaceRootVolume`
- You can't specify both `AutoScalingInstanceRefresh` and `AutoScalingRollingUpdate` on the same Auto Scaling group — doing so fails the stack update
- CloudFormation only triggers an Instance Refresh when you change one of: `LaunchTemplate`, `MixedInstancesPolicy`, `VPCZoneIdentifier`, `AvailabilityZones`, `AvailabilityZoneIds`, or `PlacementGroup`
- The gap between `MinHealthyPercentage` and `MaxHealthyPercentage` can't exceed 100 — a wider range lets more instances be replaced at once
- Both `BakeTime` (wait time before the refresh is considered complete) and `CheckpointDelay` (wait time after a checkpoint) can go up to 172,800 seconds (48 hours)
- `CheckpointPercentages` is a list of thresholds, and the last value must be 100 if you want all instances replaced
- `ScaleInProtectedInstances` and `StandbyInstances` each accept `Refresh`, `Ignore`, or `Wait`, and both default to `Wait` (waiting one hour before failing if nothing changes)
- An Auto Scaling group can only run one Instance Refresh at a time, so starting a stack update with this policy while a manual Instance Refresh is already running can cause the update to fail
- The classic `cfn-signal` helper script isn't supported here — instead, use an `autoscaling:EC2_INSTANCE_LAUNCHING` lifecycle hook if you need to wait for instance readiness
- Both the forward update and any rollback are bounded by CloudFormation's 36-hour resource timeout, so for long-running refreshes it's recommended to configure a service role on the stack to avoid issues from expiring temporary credentials

## Wrap-up

- CloudFormation has a new update policy, `AutoScalingInstanceRefresh`, that lets stack updates use Auto Scaling's native Instance Refresh mechanism
- You get root volume replacement, launch-before-terminate, alarm-based monitoring, and checkpoints with bake time, all while scaling policies and health checks stay active
- Rollback is now unified under CloudFormation's stack rollback, and it's available in every region at no extra cost
- The older `AutoScalingRollingUpdate` policy can't be combined with it, and still carries its old constraints like `SuspendProcesses`

If you manage Auto Scaling groups through CloudFormation and have ever winced during an update, this one is worth checking out!