ElastiCache.3: Replication groups should have auto-failover

What does AWS Security Hub ElastiCache.3 check?

ElastiCache.3 fails when a Redis replication group has `AutomaticFailoverEnabled` set to false. This is the setting that turns read replicas into genuine high availability rather than just extra read capacity.

Why does ElastiCache.3 matter?

Without automatic failover, a primary node failure during a routine maintenance event does not promote a replica — writes simply fail until someone notices and runs a manual promotion. A textbook-looking setup with a primary and replicas across AZs can silently lack HA for months, paying for redundancy it never actually turns on.

How do I fix ElastiCache.3?

1. List replication groups and check `AutomaticFailoverEnabled` for those set to false.
2. Ensure each group has at least one read replica, then enable automatic failover with a single modify call on the live group.
3. Pair it with Multi-AZ so the promoted replica sits in a different zone from the failed primary.
4. Default new replication groups to failover enabled in your IaC so the standard sticks.

# 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