Redshift.18: Redshift clusters should have Multi-AZ enabled

What does AWS Security Hub Redshift.18 check?

Redshift.18 evaluates the cluster resource and fails any provisioned cluster that does not have Multi-AZ enabled. Multi-AZ provisions compute in a second Availability Zone behind the same endpoint, so clients connect to one hostname regardless of which zone is serving.

Why does Redshift.18 matter?

A Single-AZ cluster runs all its compute in one zone, so a zone-level incident takes the entire warehouse offline with downtime that lasts until recovery completes. Multi-AZ removes that single point of failure, keeping compute running behind an unchanged endpoint. Treating resilience as a deliberate choice avoids discovering the gap during an actual outage.

How do I fix Redshift.18?

1. Enable Multi-AZ on eligible RA3 clusters via modify-cluster.
2. Ensure the cluster uses a subnet group spanning multiple AZs (see Redshift.16) first.
3. Budget for the second zone's compute, which roughly doubles compute cost.
4. Migrate DC2 or older node types to RA3, since Multi-AZ is an RA3-only feature.

# 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