Deploying New AMIs to Auto Scaling Groups

Security patches, application updates, base OS changes - AMI updates are constant in any production environment. Here's how I deploy them to Auto Scaling groups without taking down the application.

The Approach

1. Create a new Launch Template version with the new AMI
2. Update the ASG to use the new version
3. Run Instance Refresh to roll out the change

Step 1: New Launch Template Version

Launch Templates support versioning. Instead of creating a new template, create a new version:

aws ec2 create-launch-template-version \
  --launch-template-id lt-0123456789abcdef0 \
  --source-version 1 \
  --launch-template-data '{"ImageId":"ami-NEW123456"}'

Or in the console: Launch Templates → Select template → Actions → Modify template (create new version) → Update AMI ID.

Step 2: Update the ASG

Point your ASG to the new Launch Template version. You can specify an exact version or use $Latest to always get the newest.

I prefer explicit versions in production - $Latest can surprise you.

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name my-asg \
  --launch-template LaunchTemplateId=lt-0123456789abcdef0,Version=2

Step 3: Instance Refresh

This is the magic. Instance Refresh terminates old instances and launches replacements with the new AMI, maintaining minimum capacity throughout.

aws autoscaling start-instance-refresh \
  --auto-scaling-group-name my-asg \
  --preferences MinHealthyPercentage=90,InstanceWarmup=300

MinHealthyPercentage: Keep at least 90% of instances running. The refresh replaces instances in batches small enough to stay above this threshold.

InstanceWarmup: Time for new instances to become healthy. Set this based on your actual application startup time, not a guess.

Monitor progress:

aws autoscaling describe-instance-refreshes --auto-scaling-group-name my-asg

Configuration Tips

Warmup time matters. If your app takes 3 minutes to start, set warmup to at least 4. Too short and the refresh thinks instances are healthy before they're ready, potentially replacing too many at once.

Test in staging first. Always. An AMI that passes CI might still fail in production due to IAM permissions, networking, or dependencies.

Keep old versions around. If something breaks, you want to quickly point back to the previous Launch Template version without rebuilding.

Name your AMIs well. myapp-v2.4.1-ubuntu22-20240115 tells you what's in it. ami-0123abc tells you nothing.

Rollback

If the new AMI has problems:

1. Update ASG to previous Launch Template version
2. Run another Instance Refresh
3. Old instances get replaced with known-good AMI

This is why I keep old Launch Template versions.

Key Takeaways

• Launch Templates with versioning make AMI updates clean
• Instance Refresh handles rolling deployments automatically
• Set MinHealthyPercentage high (90%+) to maintain capacity
• Set InstanceWarmup based on actual startup time
• Always test AMIs in staging before production
• Keep previous versions for fast rollback