One Brand, Four Engines

Amazon FSx is not a single file system — it is a managed-service umbrella over four independently engineered file system technologies, each licensed or built to replicate a specific existing file system’s behavior exactly. AWS didn’t build one generic “cloud file system” because file systems aren’t interchangeable: an application built against Windows’ NTFS semantics and Active Directory ACLs behaves very differently from a high-performance computing job expecting POSIX semantics and parallel I/O. FSx exists so you can lift an application that already depends on a specific file system’s exact behavior into AWS without rewriting it.

Deployment Types: The Availability Dial

Every FSx engine offers a choice between Single-AZ and Multi-AZ deployment types (naming varies slightly per engine). Single-AZ is cheaper and simpler but represents a single point of failure at the Availability Zone level; Multi-AZ maintains a standby file server in a second AZ with synchronous replication, enabling automatic failover. This dial — cost versus resilience — is the first decision you make for any FSx deployment, and it should be driven by the actual RTO/RPO requirements of the application, not by default habit.

flowchart TB
    subgraph VPC["Customer VPC"]
        subgraph AZ_A["Availability Zone A"]
            APP1[Application / EC2 Instance]
            FS1[FSx Primary File Server]
        end
        subgraph AZ_B["Availability Zone B"]
            FS2[FSx Standby File Server]
        end
        ENI1[ENI - Primary Mount Target]
        ENI2[ENI - Standby Mount Target]
    end
    AD[AWS Managed Microsoft AD]
    S3REPO[(S3 Data Repository)]
    BKP[Automated Backups / Snapshots]
    CW[CloudWatch Metrics]

    APP1 -->|SMB/NFS/Lustre mount| ENI1 --> FS1
    FS1 |synchronous replication| FS2
    ENI2 -.failover target.-> FS2
    FS1 -->|Kerberos auth| AD
    FS1 |lazy load / export| S3REPO
    FS1 --> BKP
    FS1 --> CW
    

Two details matter for interviews and real designs: the failover ENI keeps the same DNS name across a failover, so applications don’t need reconfiguration when standby becomes primary; and the S3 data repository link (Lustre-specific) means FSx can present petabytes of existing S3 data as a POSIX file system without a bulk copy, loading objects into the file system layer on first access.

Anatomy of a Multi-AZ Failover

How Lustre Achieves Massive Parallel Throughput

FSx for Lustre distributes file data across many storage servers in stripes, so a single large file read or write is serviced by dozens of storage targets simultaneously rather than one disk. This is fundamentally different from Windows File Server or NFS, which typically serve a file from a single storage path. This striping is why Lustre can sustain hundreds of GB/s of aggregate throughput for HPC and machine learning training workloads that read enormous datasets in parallel across thousands of compute nodes.

flowchart LR
    A[Application Writes File] --> B[Primary File Server]
    B -->|sync replication| C[Standby File Server]
    B -->|scheduled| D[Daily Automatic Backup]
    B -->|on-demand| E[User-Initiated Snapshot]
    D --> F[Backup Retention Window]
    E --> F
    F -->|restore request| G[New or Existing File System]
    B -.lazy export/import.-> H[(S3 Data Repository)]
    

Backups are incremental after the first full backup, meaning only changed blocks are captured on each subsequent run — keeping both backup duration and storage cost proportional to the rate of change rather than total file system size. Restoring a backup creates a brand-new file system by default, which matters operationally: you can’t restore “in place” onto the same file system, and any application referencing the original file system’s DNS name or IP will need to be repointed after a restore.

Throughput on FSx is generally provisioned, not automatically inferred from usage — you select a throughput capacity tier (Windows File Server, ONTAP), a deployment type with fixed IOPS/throughput per TB (OpenZFS), or a storage/throughput pairing (Lustre) at creation time, and scaling up typically means modifying the file system’s provisioned throughput or storage capacity, sometimes with a brief performance-impacting operation during the resize.

Formula 1 and High-Frequency Simulation

Formula 1 teams have used FSx for Lustre to accelerate aerodynamic simulation workloads, where thousands of compute cores need simultaneous, low-latency access to shared simulation datasets — a workload pattern where Lustre’s parallel striping directly translates into faster simulation turnaround time compared to a traditional NFS file server.

Multi-AZ deployment types synchronously replicate every write to a standby file server in a different Availability Zone before acknowledging the write to the client — meaning a successful write is guaranteed durable across two AZs, not just one, at the moment the application receives confirmation.