Amazon FSx

Amazon FSx is a family of fully managed file storage services. “Fully managed” means AWS runs the file servers, patches them, replaces failed hardware, and handles backups for you — you just create a file system and mount it. FSx exists because not every workload fits Amazon EFS (Elastic File System), which only speaks NFS (Network File System, the Linux/Unix file-sharing protocol). When you need native Windows file shares, an ultra-fast scratch drive for machine learning, or the exact features of an on-premises NetApp appliance, FSx gives you a managed version of the real thing.

The four FSx families

FSx is not one product — it is four different file systems under one name. Each wraps a well-known storage technology so you do not have to install and operate it yourself.

FSx flavor	Protocol	Runs on	Best for
FSx for Windows File Server	SMB	Windows / Linux	Windows apps, .NET, SQL Server, home directories with Active Directory
FSx for Lustre	Lustre (POSIX)	Linux	HPC, machine learning training, media rendering — very high throughput
FSx for NetApp ONTAP	NFS, SMB, iSCSI	Windows / Linux	Migrating existing NetApp workloads; multi-protocol access; snapshots
FSx for OpenZFS	NFS	Linux	Latency-sensitive Linux workloads wanting ZFS snapshots and clones

“SMB” is Server Message Block, the file-sharing protocol Windows uses for \\server\share network drives. “POSIX” means standard Unix file semantics. “iSCSI” presents storage as a raw block device (like a virtual disk) over the network.

FSx for Windows File Server

This is a managed Windows file share. It speaks SMB and integrates with Active Directory (AD), Microsoft’s directory service that controls user logins and permissions across a Windows network. That means you can keep your existing NTFS permissions, file ownership, and AD groups exactly as they are on-premises.

When to use this: any Windows workload that expects a UNC path (\\fileserver\data), shared home directories, SQL Server data files, or .NET applications. When NOT to: pure Linux NFS workloads (use EFS) or HPC scratch space (use Lustre).

FSx for Lustre

Lustre is the parallel file system that powers many of the world’s fastest supercomputers. FSx for Lustre delivers hundreds of GB/s of throughput and millions of IOPS (input/output operations per second). It can transparently link to an S3 bucket: your training data lives cheaply in S3, and Lustre lazy-loads it into a high-speed file system for compute.

When to use this: machine learning training, genomics, financial modeling, video rendering — anything that reads huge datasets fast. When NOT to: general-purpose shared storage that must survive for years (Lustre “scratch” deployments are temporary by design; use “persistent” deployment type for durability).

FSx for NetApp ONTAP and OpenZFS

ONTAP is the operating system of NetApp’s enterprise storage arrays. FSx for ONTAP gives you that exact feature set — multi-protocol (NFS, SMB, and iSCSI at once), instant snapshots, cloning, and storage-efficient compression/dedup — as a managed service. It is the natural landing zone when you “lift and shift” an existing NetApp estate to AWS.

FSx for OpenZFS is for Linux teams that want the well-known ZFS file system: cheap snapshots, instant copy-on-write clones, and low sub-millisecond latency, served over NFS.

FSx vs EFS — the key decision

This is the gotcha that trips up most engineers. EFS is Linux/NFS only. If a Windows machine needs a native file share, or you need Active Directory integration, EFS cannot do it — you must use FSx for Windows. Likewise, EFS cannot deliver Lustre-class HPC throughput.

Need	Choose
Linux NFS shared storage, simple and elastic	Amazon EFS
Windows / SMB share + Active Directory	FSx for Windows File Server
Highest-performance HPC / ML scratch	FSx for Lustre
Existing NetApp features, multi-protocol	FSx for NetApp ONTAP
ZFS snapshots/clones on Linux	FSx for OpenZFS

Tip: If you are unsure between EFS and FSx, ask one question first — “Is any client a Windows machine using SMB?” If yes, the answer is almost always FSx for Windows. EFS has no SMB endpoint at all.

Create an FSx for Windows file system

Using the AWS Management Console

Open the FSx console and choose Create file system.
Select Amazon FSx for Windows File Server and click Next.
Choose Standard create, give it a name, and pick a deployment type: Multi-AZ (survives an Availability Zone failure) or Single-AZ.
Set storage capacity (minimum 32 GiB) and throughput capacity (e.g., 32 MB/s).
Choose your VPC (Virtual Private Cloud, your isolated network) and subnets.
Connect to your AWS Managed Microsoft AD or a self-managed Active Directory.
Review and choose Create file system. It is ready in 20-40 minutes.

Using the AWS CLI (v2)

aws fsx create-file-system \
  --file-system-type WINDOWS \
  --storage-capacity 32 \
  --subnet-ids subnet-0a1b2c3d \
  --security-group-ids sg-0a1b2c3d \
  --windows-configuration '{
    "ActiveDirectoryId": "d-0a1b2c3d4e",
    "ThroughputCapacity": 32,
    "DeploymentType": "MULTI_AZ_1",
    "PreferredSubnetId": "subnet-0a1b2c3d"
  }'

Output:

{
    "FileSystem": {
        "FileSystemId": "fs-0a1b2c3d4e5f6a7b8",
        "FileSystemType": "WINDOWS",
        "Lifecycle": "CREATING",
        "StorageCapacity": 32,
        "VpcId": "vpc-0a1b2c3d",
        "DNSName": "fs-0a1b2c3d4e5f6a7b8.example.com"
    }
}

Once Lifecycle becomes AVAILABLE, a Windows client maps the share using the DNS name: \\fs-0a1b2c3d4e5f6a7b8.example.com\share.

Create an FSx for Lustre file system

aws fsx create-file-system \
  --file-system-type LUSTRE \
  --storage-capacity 1200 \
  --subnet-ids subnet-0a1b2c3d \
  --lustre-configuration '{
    "DeploymentType": "SCRATCH_2",
    "ImportPath": "s3://my-training-data"
  }'

The ImportPath links the file system to an S3 bucket so your data is loaded on demand. A Linux EC2 instance then mounts it:

sudo mount -t lustre fs-0a1b2c3d4e5f6a7b8.fsx.us-east-1.amazonaws.com@tcp:/mountname /mnt/fsx

Cost gotcha: Lustre SCRATCH deployments are cheap but have no data replication — a failed disk loses data. For data you must keep, use PERSISTENT_2, which replicates within an Availability Zone and costs more per GB-month. As of 2026, FSx for Windows Single-AZ SSD starts around $0.13 per GB-month and Multi-AZ roughly double; always check current pricing for your Region.

Best practices

Match the flavor to the protocol. Windows/SMB to FSx for Windows; Linux NFS to EFS or OpenZFS; HPC to Lustre. Choosing wrong forces a costly migration later.
Use Multi-AZ for production Windows shares so an Availability Zone outage does not take your file server down.
Link Lustre to S3 instead of copying terabytes manually — let FSx lazy-load and write results back.
Right-size throughput separately from storage on FSx for Windows; you can scale throughput up without growing capacity.
Restrict access with security groups, opening only the needed ports (SMB 445, NFS 2049, Lustre 988) to your client subnets.
Enable automatic daily backups and use AWS Backup for centralized, cross-Region retention policies.
Prefer SSD storage for latency-sensitive apps and HDD only for large, infrequently accessed Windows file shares to save money.