Skip to content
Ask AI about this
Help improve this page

FSx for OpenZFS file systems should be configured for Multi-AZ deployment

A Single-AZ FSx for OpenZFS file system goes completely offline if its Availability Zone has an outage. Multi-AZ keeps a standby file server in a separate AZ with automatic failover, so NFS workloads stay online during zone-level failures. The RPO is effectively zero because data is synchronously replicated before a write is acknowledged.

Multi-AZ costs more (roughly double the file server and throughput charges), but for production workloads where downtime directly affects revenue or data integrity, the tradeoff is straightforward.

Retrofit consideration

Changing deployment_type from SINGLE_AZ to MULTI_AZ requires replacing the file system. Terraform treats this argument as ForceNew, so terraform plan will show a destroy-then-create. Back up all data before applying, update mount targets and DNS configurations, and budget for client reconnection downtime.

Implementation

Choose the approach that matches how you manage Terraform.

If you use terraform-aws-modules/fsx/aws//modules/openzfs, 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/openzfs"
  version = "~>1.3"

  deployment_type     = "MULTI_AZ_1"
  name                = "abc123"
  preferred_subnet_id = "subnet-abc123"
  storage_capacity    = 64
  subnet_ids          = ["subnet-abc123", "subnet-def456"]
  throughput_capacity = 160
}

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

resource "aws_fsx_openzfs_file_system" "this" {
  copy_tags_to_backups = true
  copy_tags_to_volumes = true
  deployment_type      = "MULTI_AZ_1"
  storage_capacity     = 64
  subnet_ids           = ["subnet-abc123", "subnet-def456"]
  throughput_capacity  = 160
}

What this control checks

The aws_fsx_openzfs_file_system resource passes when deployment_type is "MULTI_AZ_1" or "MULTI_AZ_2". It fails for "SINGLE_AZ_1" or "SINGLE_AZ_2", and also when deployment_type is omitted, since Terraform defaults to "SINGLE_AZ_1". Multi-AZ configurations also require preferred_subnet_id for the primary AZ and at least two entries in subnet_ids, one per AZ.

Common pitfalls

  • Deployment type change forces replacement

    Terraform will destroy and recreate the file system when deployment_type changes, because the argument is ForceNew. If you haven't taken a backup first, the data is gone. Snapshot the file system before running terraform apply, then restore after the new Multi-AZ file system is up.

  • Insufficient subnet_ids for Multi-AZ

    Multi-AZ requires at least two entries in subnet_ids, each in a different AZ. Providing a single subnet or two subnets in the same AZ causes the CreateFileSystem API call to fail with a validation error.

  • MULTI_AZ_2 availability

    MULTI_AZ_2 offers improved failover performance over the first generation, but isn't available in all regions. If terraform apply fails with an unsupported deployment type error, check region availability and fall back to MULTI_AZ_1 if needed.

  • Security group rules for cross-AZ replication

    Security groups attached via security_group_ids need to allow NFS client traffic on TCP 2049. Gaps here won't prevent the file system from creating, but clients will lose connectivity during failover when the standby takes over on a different network interface.

Audit evidence

AWS Config rule evaluations against AWS::FSx::FileSystem resources show the deployment type for each OpenZFS file system and flag any Single-AZ instance. The FSx console displays deployment type on the file system summary page. Running describe-file-systems filtered for OpenZFS returns the DeploymentType field for each file system; compliant systems show MULTI_AZ_1 or MULTI_AZ_2.

CloudTrail CreateFileSystem events carry the DeploymentType parameter used at provisioning time, giving auditors a historical record of how each file system was originally configured.

Tool mappings

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

  • Compliance.tf Control: fsx_openzfs_file_system_multi_az_deployment_enabled

  • AWS Config Managed Rule: FSX_OPENZFS_DEPLOYMENT_TYPE_CHECK

  • Powerpipe Control: aws_compliance.control.fsx_openzfs_file_system_multi_az_deployment_enabled

  • AWS Security Hub Control: FSx.3

Last reviewed: 2026-03-09