FSx.5: FSx for Windows File Server should be Multi-AZ

What does AWS Security Hub FSx.5 check?

FSx.5 checks whether an FSx for Windows File Server file system uses the Multi-AZ deployment type and fails any configured Single-AZ. FSx for Windows provides a managed SMB share integrated with Active Directory.

Why does FSx.5 matter?

A Single-AZ file system has no automatic failover — if its Availability Zone or the underlying file-server instance fails, the share goes unreachable and stays that way until recovery, taking every Windows workload that mounts it with it. Multi-AZ runs a synchronous standby in a second zone behind the same DNS name and fails over in seconds.

How do I fix FSx.5?

1. Choose Multi-AZ when creating new FSx for Windows file systems.
2. For an existing Single-AZ share, migrate data into a new Multi-AZ system (DataSync, robocopy, or backup/restore) and cut over.
3. Plan for the additional cost of the standby file server and cross-AZ replication.
4. Set Multi-AZ as the default for business-critical Windows shares.

# 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