AutoScaling.2: A single-AZ Auto Scaling group is one outage from zero capacity

What does AWS Security Hub AutoScaling.2 check?

AutoScaling.2 fails when an Auto Scaling group is configured to use only a single Availability Zone. The control checks the group's AvailabilityZones list and expects instances spread across two or more.

Why does AutoScaling.2 matter?

A single-AZ group is one zone event away from zero capacity: if that AZ has an outage or its launch APIs stop accepting placements, the group cannot replace or add instances until the zone recovers. Regional incidents like the 2017 us-east-1 event stranded exactly these groups while multi-AZ ones shrugged it off. Spreading across AZs means a single zone failure costs you a fraction of capacity, not all of it.

How do I fix AutoScaling.2?

1. List Auto Scaling groups and find those bound to a single AZ.
2. Add subnets from additional Availability Zones to the group's VPCZoneIdentifier.
3. Let the group rebalance instances across the new zones, mindful of cross-AZ data transfer cost.
4. Set a minimum of two AZs as standard for new groups.

# Fix the highest-impact data stores first: enable Multi-AZ on production databases.
for db in $(aws rds describe-db-instances \
    --query 'DBInstances[?MultiAZ==`false` && DBClusterIdentifier==null].DBInstanceIdentifier' --output text); do
  aws rds modify-db-instance --db-instance-identifier "$db" \
    --multi-az --apply-immediately
  echo "$db: standby being provisioned in a second AZ"
done

# Span a stateless compute fleet across three AZs, then mirror the set on its load balancer.
aws autoscaling update-auto-scaling-group --auto-scaling-group-name web-tier-asg \
  --vpc-zone-identifier "subnet-0aaa1,subnet-0bbb2,subnet-0ccc3"
aws elbv2 set-subnets --load-balancer-arn "$ALB_ARN" \
  --subnets subnet-0aaa1 subnet-0bbb2 subnet-0ccc3