Skip to main content
emnode
Sign up
Compliance Medium severity

AWS Security Hub · AutoScaling

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

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub AutoScaling.6 check?

AutoScaling.6 checks whether an Auto Scaling group uses multiple instance types. The control fails when the group has only one instance type defined: it evaluates instance-type diversity only, not Availability Zone coverage (that's AutoScaling.2's job). The backing Config rule, autoscaling-multiple-instance-types, does not evaluate attribute-based instance type selection, so a group sized by compute requirements rather than named types isn't assessed.

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 the number of instance types defined.
  2. Define a mixed instances policy on a launch template listing several compatible instance types.
  3. Tune the diversification and on-demand/Spot split, then roll the fleet via instance refresh.

Remediation script · bash

# 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

Full walkthrough (console steps, edge cases and verification) in the lesson Deploy across multiple Availability Zones.

Is AutoScaling.6 a false positive?

The rule, autoscaling-multiple-instance-types, fails the moment a group defines only one instance type, but some workloads genuinely can't be diversified. A GPU or accelerator job tied to a specific chip, an application licensed per a particular instance family, software that only runs on Graviton (or only on x86), or a fleet validated and benchmarked against exactly one type all legitimately pin to a single instance type, and a forced second type would either not run the workload or quietly change its performance profile. Note too that the rule doesn't evaluate attribute-based instance type selection: a group that diversifies by compute requirements rather than naming types may still be reported even though it can launch many types. Where the single type is a real requirement, disable this control for those groups or suppress the findings with a note recording the constraint, rather than adding a type the application can't actually use.

Full lesson Deploy across multiple Availability Zones Step-by-step remediation with CLI, code and persona-specific context.
AWS documentation for AutoScaling controls ↗ Check your own account for AutoScaling.6 →
Part of the learning path Tighten your databases

More AutoScaling controls