Neptune.9: Neptune clusters should span multiple AZs

What does AWS Security Hub Neptune.9 check?

Neptune.9 fails when a Neptune DB cluster does not have read-replica instances spread across multiple Availability Zones. The control checks the cluster's instance topology, not just storage durability.

Why does Neptune.9 matter?

Neptune storage is replicated across AZs and so is durable, but a single-instance cluster is not highly available — if its AZ fails, Neptune must rebuild the primary from storage, which takes many minutes of downtime. With a replica in a second AZ, failover promotes the existing replica in seconds. The gap is the difference between a brief blip and a multi-minute outage.

How do I fix Neptune.9?

1. Inspect the cluster's instances and their AZs with describe-db-clusters and describe-db-instances.
2. Add a read-replica in a different AZ with create-db-instance, matching the primary's instance class.
3. Set failover priority tiers so the right replica is promoted, and point read traffic at the reader endpoint.
4. Default a multi-AZ topology in your IaC so new clusters are compliant from creation.

# 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