Amazon FSx
Amazon FSx is a family of managed file systems, each built on a real industry-standard engine and run for you. Unlike EFS — a single NFS service — FSx lets you pick the file system that matches a specific workload: Windows File Server, Lustre, NetApp ONTAP, or OpenZFS.
Each flavor is fully managed: AWS handles installation, patching, backups, and failover, and you configure capacity, performance, and access. The price premium over EFS buys a specialized engine, justified only when you actually need its features.
The Four Flavors
FSx for Windows File Server serves SMB with Active Directory integration, Windows ACLs, and DFS — the obvious choice for migrating Windows file shares and legacy Windows apps. FSx for NetApp ONTAP offers NFS, SMB, and iSCSI with snapshots, dedup, and SnapMirror replication for enterprise and hybrid-NetApp shops.
FSx for Lustre is high-throughput parallel storage for HPC and ML, and integrates with S3 as a backing store — keep raw data in S3, cache it on fast Lustre SSDs for training or analysis. FSx for OpenZFS brings ZFS snapshots, clones, and data-integrity guarantees over NFS.
Choosing and Sizing
Match the flavor to the protocol and feature set: SMB and AD for Windows; Lustre for parallel HPC/ML; ONTAP for NFS/SMB/iSCSI with enterprise features; OpenZFS for ZFS semantics on Linux. Pricing is by storage capacity, reserved throughput capacity, and backup storage, and varies by flavor.
Use multi-AZ deployments for production and single-AZ only for dev or short-lived workloads.
FSx — a specific engine — Windows SMB, Lustre, NetApp, or OpenZFS — when you need that protocol or feature.
EFS — simple shared Linux/NFS file storage. Use it whenever you do not need an FSx-specific feature.
S3 — object storage. Often the durable home of data that FSx for Lustre then caches for fast compute.
- Reaching for FSx for Windows when plain Linux NFS sharing on EFS would do — and paying for features you do not use.
- Running production FSx single-AZ — use multi-AZ for production and reserve single-AZ for dev.
- Choosing the wrong flavor for the protocol — e.g. expecting SMB from FSx for Lustre, which targets parallel HPC.
- Keeping ML training data only in Lustre instead of backing it with S3 and caching on Lustre for the run.
- Forgetting to clean up unused FSx file systems — each specialized engine is expensive to leave idle.
- Skipping the built-in FSx backups for production file systems.
- Match the flavor to the workload — Windows/SMB, Lustre/HPC, ONTAP/enterprise, OpenZFS/ZFS — rather than defaulting blindly.
- Use multi-AZ deployments for production file systems.
- Use the FSx-integrated backups; they are reliable and simple.
- Pair FSx for Lustre with S3: durable data in S3, fast cache in Lustre, for ML and HPC.
- Tag file systems so unused, costly ones are easy to find and remove.
Knowledge Check
How does FSx differ from EFS?
- FSx is a family of engines (Windows, Lustre, NetApp, OpenZFS) you pick between; EFS is one NFS service
- FSx is HTTP object storage like an S3 bucket, while EFS is raw locally-attached block storage like an EBS volume
- FSx is locked to a single AZ; EFS spans multiple Regions worldwide
- They are the same underlying service marketed under two different names
You are migrating Windows file shares that depend on SMB and Active Directory. Which FSx flavor fits?
- FSx for Windows File Server — built on real Windows Server with SMB, AD, and Windows ACLs
- FSx for Lustre — by far the fastest engine, so it wins on raw throughput
- FSx for OpenZFS — ZFS speaks SMB natively and joins an Active Directory domain directly with no extra setup
- EFS configured with the optional SMB mount and AD option
What pattern does FSx for Lustre commonly use for ML training data?
- Keep raw data durably in S3 and cache it on fast Lustre SSDs for the training run
- Store the single authoritative copy of the data in Lustre and never back it up
- Replace S3 entirely with Lustre as the durable store for all objects
- Serve the training set over SMB straight to the Windows nodes
When is FSx the wrong choice?
- When simple shared Linux NFS would do — EFS is simpler and cheaper without FSx-specific features
- When you need Windows SMB shares backed by Active Directory authentication
- When you run HPC workloads demanding very high parallel throughput
- When you have existing on-premises NetApp ONTAP file workloads that you want to lift and migrate to AWS
You got correct