AutoScaling.6: ASGs should use multiple instance types/AZs

What does AWS Security Hub AutoScaling.6 check?

AutoScaling.6 fails when an Auto Scaling group does not use multiple instance types across multiple Availability Zones. The control expects a mixed instances policy that diversifies the group beyond a single type in a single or narrow set of zones.

Why does AutoScaling.6 matter?

A group pinned to one instance type is a capacity risk: when AWS runs short of that type in your AZs, scale-out events fail with InsufficientInstanceCapacity and the application limps along under-provisioned. A mixed instances policy lets the group fall back across types and zones, and the same diversification opens the door to safe Spot adoption.

How do I fix AutoScaling.6?

1. Inspect each group's configuration for instance-type and AZ diversity.
2. Define a mixed instances policy on a launch template listing several compatible instance types.
3. Spread the group across multiple Availability Zones.
4. Tune the diversification and on-demand/Spot split, then roll the fleet via instance refresh.

# 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