ELB.13: A single-AZ load balancer is a data-plane single point of failure

What does AWS Security Hub ELB.13 check?

ELB.13 fails when an Application, Network or Gateway Load Balancer (ELBv2) is configured with subnets in fewer than two Availability Zones. Classic Load Balancers are out of scope here; they are covered by the separate ELB.10 control. The control checks the load balancer's own AZ footprint, not that of its targets.

Why does ELB.13 matter?

Multi-AZ compute is meaningless if every request first passes through a load balancer pinned to one zone. When that AZ has a network or power event, the entire data plane goes dark regardless of how healthy your targets in other zones are. The December 2021 us-east-1 single-AZ failure took down major services for exactly this reason: resilient fleets behind single-AZ hops.

How do I fix ELB.13?

1. Audit each load balancer's enabled AZs with describe-load-balancers.
2. Add subnets in additional AZs online with set-subnets (ALB/NLB/GWLB); the change adds nodes without dropping existing connections.
3. Confirm each new AZ has healthy registered targets so the added node can serve traffic.
4. Enforce a minimum of two AZs in your IaC and with a Config rule so the finding does not recur.

# 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