Amazon FSx: Purpose-Built File Systems
The four FSx variants in depth — Windows File Server, NetApp ONTAP, OpenZFS, and Lustre — and how to choose between them based on protocol compatibility and workload shape.
Want a visual for this topic?
Generate a diagram tailored to Amazon FSx: Purpose-Built File Systems — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Match each FSx variant to the specific protocol or workload it's built for
- •Explain why FSx for Lustre is the standard choice for ML training and HPC workloads
- •Explain what FSx for Windows File Server needs Active Directory for
- •Compare FSx for NetApp ONTAP against FSx for OpenZFS for a given migration scenario
What is it?
Amazon FSx is a family of four fully managed, purpose-built file systems, each replicating the exact protocol and feature set of a specific popular file system technology, so existing applications, tooling, and expertise built around that technology work on AWS without re-architecting: FSx for Windows File Server (native SMB, Active Directory integration), FSx for NetApp ONTAP (ONTAP's data management features — snapshots, cloning, replication), FSx for OpenZFS (ZFS's snapshot and cloning model on Linux), and FSx for Lustre (a parallel file system built for high-throughput, low-latency HPC and machine learning workloads).
Why it exists
EFS is a great general-purpose managed NFS file system, but it doesn't speak SMB (the protocol Windows applications expect), doesn't offer ONTAP's specific data management APIs many enterprises have built tooling around, and isn't optimized for the extreme parallel-read throughput HPC and ML training jobs need. Rather than forcing every workload to adapt to one storage model, AWS built FSx as a family of managed services, each one a genuine, protocol-compatible implementation of an existing well-known file system technology, so migrating an existing workload doesn't require rewriting how it talks to storage.
Problem it solves
FSx for Windows File Server solves running Windows applications that expect real SMB shares and Active Directory-integrated permissions, without operating a Windows file server yourself. FSx for NetApp ONTAP and OpenZFS solve migrating existing on-premises NetApp or ZFS-based storage workflows (including their snapshot/clone/replication tooling) to AWS with minimal workflow disruption. FSx for Lustre solves the throughput ceiling that general-purpose file systems hit under massively parallel read access from hundreds of compute nodes simultaneously, which is exactly the access pattern of distributed ML training and traditional HPC simulations.
Intuition
Think of EFS as a well-stocked general hardware store — good for most jobs. FSx is like calling in four different specialist contractors, each bringing the exact specialized equipment a specific job requires: an electrician trained specifically on your building's existing wiring standard (Windows/SMB), a plumber who already knows your exact pipe fittings from a previous system (ONTAP/OpenZFS), and a high-speed logistics team built specifically to move an enormous volume of material to many locations at once, fast (Lustre for parallel HPC workloads).
Analogy
FSx for Lustre is like a stadium with hundreds of entrance gates all opening simultaneously for kickoff, built specifically so tens of thousands of people (parallel compute nodes) can stream in at once without a bottleneck at a single gate — a regular building's one or two doors (a general-purpose file system) would create a crushing queue under that same load.
Technical explanation
FSx for Windows File Server requires (or can create) an Active Directory to manage user/group permissions on files and folders using standard Windows ACLs, exactly matching how enterprise Windows file shares have always worked, and supports Windows-specific features like DFS Namespaces and shadow copies. FSx for NetApp ONTAP exposes ONTAP's own management API and CLI, supporting features like instantaneous, storage-efficient snapshots, thin cloning of entire volumes, and SnapMirror-based replication, aimed squarely at enterprises already standardized on NetApp tooling. FSx for OpenZFS offers similar snapshot/clone efficiency using ZFS's copy-on-write architecture, targeted at Linux workloads already built around ZFS semantics. FSx for Lustre is deployed either as scratch storage (no replication, lowest cost, for transient/reproducible workloads) or persistent storage (replicated within an AZ), and can link directly to an S3 bucket, lazily loading objects as files are first accessed and optionally writing results back to S3 — letting a training job treat an S3 data lake as if it were a local, extremely fast parallel file system.
Architecture
A financial services company running legacy Windows-based analytics tools migrates its file shares to FSx for Windows File Server, joined to their existing AWS Managed Microsoft AD, preserving all existing NTFS permissions with zero application changes. Separately, an ML platform team runs distributed model training across dozens of GPU EC2 instances, all reading training data through FSx for Lustre linked to an S3 data lake bucket — achieving far higher aggregate read throughput during training than reading directly from S3 or EFS would provide at that scale.
Workflow
- Identify the specific protocol/technology compatibility requirement driving the FSx choice — Windows SMB and AD-integrated permissions point to FSx for Windows File Server; existing NetApp tooling points to ONTAP; existing ZFS workflows point to OpenZFS; massively parallel HPC/ML read throughput points to Lustre. 2) For Lustre specifically, decide between scratch (cheaper, no replication, for reproducible/transient data) and persistent (replicated, for data that must survive a failure) deployment types. 3) For Windows File Server, ensure an Active Directory (self-managed or AWS Managed Microsoft AD) is available for domain-joining the file system.
Example
A genomics research team runs sequence-alignment jobs across a 200-node HPC cluster, all reading reference genome data in parallel through an FSx for Lustre scratch file system backed by an S3 bucket — the scratch deployment type is chosen deliberately since the reference data is reproducible from S3 and doesn't need FSx-level replication, keeping cost down for what is inherently transient, high-throughput compute storage.
Real-world usage
FSx for Windows File Server is the default choice whenever a genuine Windows/SMB/Active Directory requirement exists and self-managing a Windows file server is undesirable. FSx for Lustre is AWS's documented standard recommendation for large-scale machine learning training and traditional HPC simulation workloads specifically because of its parallel-read throughput characteristics, often cited directly in AWS's own ML reference architectures.
Trade-offs
The core tradeoff across all four FSx variants is the same: pay more than EFS/S3 in exchange for genuine, drop-in compatibility with a specific existing technology or a specific extreme-throughput access pattern. That tradeoff is clearly worth it when the compatibility requirement is real (a legacy Windows app that only speaks SMB) or the throughput need is real (distributed ML training bottlenecked on data loading) — and clearly not worth it when a team could have used EFS or S3 directly with a bit of adaptation.
Visual explanation
Picture FSx for Windows File Server as a managed Windows file share, joined to an Active Directory domain, serving SMB clients (Windows EC2 instances, Windows-based applications) exactly as an on-premises Windows file server would. Picture FSx for Lustre differently: many compute nodes (an ML training cluster) all connect in parallel to a Lustre file system that's often linked directly to an S3 bucket as its backing data repository, reading massive training datasets with very high aggregate throughput that scales with the number of nodes reading simultaneously.
Advantages
- —
Genuine protocol/API compatibility with existing Windows, NetApp, or ZFS tooling — not an approximation, letting existing scripts and workflows run unmodified
- —
FSx for Lustre delivers far higher aggregate parallel-read throughput than general-purpose file systems, directly benefiting large-scale ML and HPC workloads
- —
Direct S3 integration for Lustre lets a data lake in S3 be consumed as fast local-feeling storage without a separate copy step
- —
Fully managed — no self-hosted Windows file server, NetApp appliance, or Lustre cluster to operate
Disadvantages
- —
Each FSx variant is genuinely more expensive than EFS or S3 for workloads that don't actually need the specific protocol compatibility or throughput profile
- —
FSx for Windows File Server requires Active Directory, adding setup complexity if one doesn't already exist
- —
FSx for Lustre's scratch deployment type has no built-in replication — a node failure can lose data that isn't yet reflected back in S3
- —
Choosing the wrong FSx variant (e.g. ONTAP when the team has no existing NetApp dependency) adds cost and complexity with no corresponding benefit
Common mistakes
- —
Choosing FSx for Windows File Server for a workload that doesn't actually need SMB or AD-integrated permissions, when EFS would have sufficed at lower cost
- —
Using FSx for Lustre's scratch deployment type for data that isn't safely reproducible from S3, risking permanent data loss on a node failure
- —
Not accounting for FSx for Windows File Server's Active Directory dependency during planning, causing setup delays
- —
Assuming all four FSx variants are interchangeable 'managed file storage' rather than recognizing each is a distinct protocol/technology with a specific fit
In the AWS Console
- 1
AWS Console → FSx → Create file system
Choose the FSx variant matching your requirement — Windows File Server, NetApp ONTAP, OpenZFS, or Lustre.
This choice is essentially permanent for a given file system — migrating between FSx variants means creating a new file system and moving data, not an in-place conversion.
- 2
FSx → Windows File Server → Create → Directory service
Select or create an Active Directory (self-managed or AWS Managed Microsoft AD) to join the file system to.
Without a domain, Windows-native ACL-based permissions cannot be applied the way an on-premises Windows file share would expect.
- 3
FSx → Lustre → Create → Data repository association
Link the Lustre file system to an S3 bucket, choosing whether to lazily load existing objects and whether to export new/changed files back to S3.
Choose the deployment type (scratch vs persistent) based on whether the data must survive a node failure without a full S3 reload.
🎤 Interview questions
When would you choose FSx for Windows File Server over EFS? (Listen for: application specifically requires SMB protocol and/or Active Directory-integrated NTFS permissions, which EFS's NFS model doesn't provide.)
Why is FSx for Lustre the standard recommendation for ML training workloads? (Listen for: purpose-built for massively parallel read throughput across many compute nodes simultaneously, plus direct S3 data-repository integration for treating a data lake as fast local storage.)
What's the difference between FSx for Lustre's scratch and persistent deployment types? (Listen for: scratch = no replication, lower cost, for reproducible/transient data; persistent = replicated within an AZ, for data that must survive a failure.)
Why would an enterprise choose FSx for NetApp ONTAP specifically, instead of FSx for OpenZFS or EFS? (Listen for: existing investment in ONTAP-specific tooling, snapshot/clone/replication workflows like SnapMirror, migrating from on-premises NetApp infrastructure.)
What does FSx for Windows File Server need Active Directory for? (Listen for: applying standard Windows NTFS ACL-based file/folder permissions the same way an on-premises Windows file server would, requiring domain membership.)