Skip to content
Ask AI about this
Help improve this page

FSx for Windows File Server file systems should be configured for Multi-AZ deployment

A single-AZ FSx for Windows File Server deployment goes completely unavailable during an AZ outage. Multi-AZ keeps a standby file server in a second AZ with synchronous replication, and failover typically completes in under 30 seconds. For workloads like user home directories, application shares, or SQL Server storage that depend on continuous SMB access, an AZ failure without Multi-AZ halts operations entirely.

Multi-AZ costs roughly double the storage and throughput charges of single-AZ. That's a real cost, but for any file system backing production workloads it's the right call. Single-AZ is fine for dev/test where downtime has no business impact.

Retrofit consideration

Changing deployment_type from SINGLE_AZ_1 or SINGLE_AZ_2 to MULTI_AZ_1 or MULTI_AZ_2 forces replacement of the file system, full data migration, DNS endpoint changes, and downtime. Plan a migration window with FSx native backups, AWS Backup, or DataSync before making this change.

Implementation

Choose the approach that matches how you manage Terraform.

If you use terraform-aws-modules/fsx/aws//modules/windows, set the right module inputs for this control. You can later migrate to the compliance.tf module with minimal changes because it is compatible by design.

module "fsx" {
  source  = "terraform-aws-modules/fsx/aws//modules/windows"
  version = "~>1.3"

  active_directory_id = "d-1234567890"
  name                = "abc123"
  preferred_subnet_id = "subnet-abc123"
  storage_capacity    = 32
  subnet_ids          = ["subnet-abc123", "subnet-def456"]
  throughput_capacity = 32

  deployment_type = "MULTI_AZ_1"
}

Use AWS provider resources directly. See docs for the resources involved: aws_fsx_windows_file_system.

resource "aws_fsx_windows_file_system" "this" {
  storage_capacity    = 32
  subnet_ids          = ["subnet-abc123", "subnet-def456"]
  throughput_capacity = 8

  deployment_type = "MULTI_AZ_1"
}

What this control checks

The control checks that aws_fsx_windows_file_system has deployment_type set to MULTI_AZ_1 or MULTI_AZ_2. It fails when deployment_type is omitted (defaulting to SINGLE_AZ_1), set to SINGLE_AZ_1, or set to SINGLE_AZ_2. Multi-AZ deployments also require subnet_ids to contain exactly two subnet IDs in different Availability Zones, and preferred_subnet_id must be set to indicate which AZ hosts the active file server. MULTI_AZ_2 supports both SSD and HDD storage and is the recommended choice for new deployments.

Common pitfalls

  • Deployment type change forces replacement

    deployment_type is a ForceNew attribute, so changing from SINGLE_AZ_1 to MULTI_AZ_1 destroys and recreates the file system. All data is gone unless you have a backup. Use FSx native backups, AWS Backup, or DataSync before making this change in Terraform.

  • Subnet configuration requirements differ

    Multi-AZ requires exactly two entries in subnet_ids spanning different AZs, plus preferred_subnet_id. Single-AZ needs only one. Switch to Multi-AZ without adding the second subnet and Terraform throws a validation error at apply time.

  • Security group and route table considerations

    FSx creates ENIs in both subnets for Multi-AZ deployments. Security groups in security_group_ids need to allow SMB (TCP 445) and DNS (TCP/UDP 53) from clients in both AZs. Missing rules in the second AZ cause failover connectivity failures that only surface during an actual AZ event.

  • MULTI_AZ_2 vs MULTI_AZ_1 feature differences

    MULTI_AZ_1 does not support HDD storage. MULTI_AZ_2 supports both. If you set deployment_type to MULTI_AZ_1 with storage_type = "HDD", the API rejects the request. Prefer MULTI_AZ_2 for new file systems.

Audit evidence

AWS Config evaluation results for AWS::FSx::FileSystem resources of type WINDOWS should show DeploymentType as MULTI_AZ_1 or MULTI_AZ_2 and flag any single-AZ deployments as non-compliant. The FSx console shows deployment type on the file system details page. aws fsx describe-file-systems filtered on WindowsConfiguration.DeploymentType gives the same data programmatically, and each compliant file system should show two subnet IDs confirming cross-AZ placement.

CloudTrail logs for CreateFileSystem calls confirm whether new file systems were provisioned with the correct deployment type from the start rather than migrated after the fact.

Framework-specific interpretation

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

  • Compliance.tf Control: fsx_windows_file_system_multi_az_deployment_enabled

  • Powerpipe Control: aws_compliance.control.fsx_windows_file_system_multi_az_deployment_enabled

  • Prowler Check: fsx_windows_file_system_multi_az_enabled

  • AWS Security Hub Control: FSx.5

Last reviewed: 2026-03-09