An AWS team needs managed shared file systems for two workloads that EFS does not fit: a Windows application requiring SMB shares with Active Directory permissions, and a training job that must stream terabytes out of S3 at very high throughput. Which AWS file services fit each, and what distinguishes the FSx family members?

## The shape of the AWS file-storage menu AWS offers exactly one general-purpose elastic file service — EFS — and then a family of managed file systems, FSx, each of which is a *specific* file system product operated for you. The interview question is almost never "what is FSx"; it is "here is a workload, which one". So work from the constraint backwards. ## FSx for Windows File Server The deciding constraint is the protocol and the identity model. EFS speaks NFS and POSIX user/group ownership; Windows applications expect **SMB** shares and **NTFS ACLs** resolved against Active Directory identities. FSx for Windows File Server provides exactly that: it joins either AWS Managed Microsoft AD or your self-managed AD, so existing group-based permissions carry over, and it supports Windows-native features such as DFS Namespaces for a unified share namespace and shadow copies for user-recoverable previous versions. It can be deployed Single-AZ or Multi-AZ, the latter keeping a standby in a second Availability Zone with automatic failover. Reach for it for: Windows user home directories, file shares for line-of-business Windows apps, SQL Server shared storage, and lift-and-shift of an on-premises Windows file server. ## FSx for Lustre The deciding constraint is throughput at scale against data that lives in S3. Lustre is a **parallel** file system: metadata and data are distributed so that many clients read and write concurrently at aggregate rates a conventional shared NFS mount cannot approach. Its distinguishing AWS feature is the S3 integration — a data repository association makes objects in a bucket visible as files in the file system, loading their contents on first access, and results written to the file system can be exported back to S3. That combination is why it is the standard answer for ML training over a large dataset, genomics and seismic processing, and rendering. Deployment types matter: **scratch** file systems are cheap, fast and not replicated (data is lost on a failure — fine for reproducible intermediate work), while **persistent** file systems replicate within an AZ and are appropriate for longer-lived data. ## FSx for NetApp ONTAP The deciding constraint is either multi-protocol access or a dependency on ONTAP features. ONTAP serves the *same* data over NFS and SMB (and iSCSI block), which is what you want when Linux and Windows clients must share a dataset. It brings the NetApp feature set — efficient snapshots, cloning, replication with SnapMirror, storage efficiency, and automatic tiering of cold data to a lower-cost capacity pool. Teams already running ONTAP on-premises pick it because their tooling and processes transfer directly. ## FSx for OpenZFS The deciding constraint is low-latency NFS with ZFS semantics. It serves NFS, offers ZFS snapshots and near-instant clones, and targets workloads migrating from on-premises ZFS or general NAS appliances where consistent low latency matters more than elastic capacity. ## How to compare against EFS EFS remains the default for Linux/NFS workloads that want elasticity and zero capacity planning: you provision no size and pay for what you store. Every FSx file system is provisioned — you choose capacity and throughput up front and can adjust it, which means capacity planning comes back but so does predictability. Choose FSx when a hard requirement rules EFS out: | Requirement | Service | |---|---| | SMB shares with Active Directory identities | FSx for Windows File Server | | HPC/ML throughput, data staged from S3 | FSx for Lustre | | Same data over both NFS and SMB, ONTAP features | FSx for NetApp ONTAP | | Low-latency NFS with ZFS snapshots and clones | FSx for OpenZFS | | Elastic NFS, no capacity planning, many Linux clients | EFS | ## What not to do in the interview Do not recite the four FSx variants as a list. Name the constraint that selects each one — protocol, identity model, throughput profile, feature dependency — and say plainly when EFS is still the better answer, because reaching for a specialised, provisioned file system where an elastic NFS share would do is a real cost and operations mistake.