Amazon FSx Family

By the end of this lesson you will be able to

• Explain why AWS offers Amazon FSx next to EFS, and name the four FSx file systems and the one job each is built for.
• Describe FSx for Windows File Server: SMB, NTFS permissions, Active Directory, DFS Namespaces, SSD or HDD, Single-AZ or Multi-AZ, access from Linux and from on premises, and daily backups to S3.
• Explain SMB, NFS and Active Directory in plain words, and what happens to a file share when the directory cannot be reached.
• Describe FSx for Lustre: a parallel file system for HPC and machine learning, scratch vs persistent deployments, throughput per TiB, and how an S3 data repository lazy-loads inputs and exports results.
• Describe FSx for NetApp ONTAP (NFS, SMB and iSCSI from one system, deduplication, compression, tiering, snapshots, clones, SnapMirror) and FSx for OpenZFS (NFS, very low latency, snapshots and clones).
• Choose between EFS, the four FSx file systems and S3 File Gateway for any exam scenario, and justify the choice with the keyword that decides it.

#Why FSx exists

#EFS covers one case

In lesson 5.4 you met EFS, the managed shared file system that many EC2 instances in several AZs mount at once. It is excellent at one thing: shared files for Linux over NFS. The notes put the limit plainly: EFS supports only Linux. It does not run on Windows, it knows nothing about Active Directory users or Windows permissions, it is not a parallel file system for a supercomputer, and it has no NetApp or ZFS features that companies have built their workflows on.

Companies, though, already run many other file systems in their data centres: Windows file servers, Lustre clusters for HPC, NetApp storage arrays, ZFS servers. When they move to AWS, they do not want to rewrite every application to use EFS or S3. They want the same file system they know, without the servers, disks, patches and failovers to look after.

#Four managed file systems

That is what Amazon FSx is: AWS launches well-known third-party, high-performance file systems for you as a fully managed service. You choose a file system, a size and a throughput; AWS provides the servers and disks, replicates the data, replaces failed hardware, patches the software and takes the backups. There are four members of the family:

All four live inside your VPC: each file system gets one or more elastic network interfaces in your subnets, and clients reach it on its private address. None of them can be exposed to the public internet. From on premises you reach them over Site-to-Site VPN or Direct Connect (lesson 10.10).

#FSx for Windows File Server

#A Windows file server without the server

FSx for Windows File Server is a fully managed Windows file share drive, built on Windows Server. To Windows users and applications it is exactly the file server they already know:

• SMB protocol (versions 2.0 to 3.1.1) for file sharing, and the NTFS file system underneath.
• Microsoft Active Directory integration: users log in with their usual domain accounts.
• Windows access control lists (ACLs) on files and folders, user quotas, shadow copies (the “Previous Versions” tab users restore from), Windows data deduplication, and file access auditing.
• DFS Namespaces to group many shares and file systems under one path (below).
• Clients: Windows from Windows Server 2008 and Windows 7 on, Linux EC2 instances (they mount it over SMB with cifs-utils), Amazon virtual desktops, and VMware Cloud on AWS.
• Reachable from your on-premises network over VPN or Direct Connect, and from other VPCs, accounts or Regions through VPC peering or a transit gateway.

Windows applications that fit it well: department and user shares, home directories, IIS web content, content management systems, business applications, media processing, and SQL Server, which can keep its database files on a continuously available SMB share.

#SMB, NFS and Active Directory in plain words

These three terms come up in every FSx and Storage Gateway question, so here they are without jargon.

• NFS (Network File System) is the file sharing language of Linux and Unix. Five Linux computers in an office: a folder on computer 1 is used by the other four as if it were on their own disk. That is NFS. EFS, FSx for OpenZFS and FSx for ONTAP speak it.
• SMB (Server Message Block) is the file and printer sharing language of Windows. If you have ever right-clicked a folder in Windows and chosen Properties → Sharing → Share, you have used SMB. A central Windows server sharing folders to everyone’s PC in an office uses SMB. FSx for Windows and FSx for ONTAP speak it.
• Active Directory (AD) is the central identity system of a Windows network: who the users are, their passwords, their groups, and what they may use.

FSx for Windows joins a directory when you create it. Two choices:

• AWS Managed Microsoft AD (AWS Directory Service): AWS runs the domain controllers for you in your VPC. It can trust your on-premises domain.
• Your own self-managed AD: the domain controllers you already run on premises or on EC2.

Without Active Directory, the file system cannot check who is logging in. If FSx loses contact with every domain controller, new sessions fail, and the file system can be marked Misconfigured until the directory is reachable again. Keep domain controllers in AWS, close to the file system (in the same VPC or reachable over a reliable link), not only at the end of an office VPN. Directory Service is covered in depth in chapter 20 (Identity Center and Directory Service).

#DFS Namespaces: many shares, one path

DFS (Microsoft Distributed File System) Namespaces show folders from many file servers under one tidy path, for example \\corp.example.com\files\finance and \\corp.example.com\files\design. Users never need to know which server holds which folder, and an administrator can move a folder to another file system without changing anyone’s mapped drive. FSx for Windows supports DFS Namespaces on every deployment type.

This is how FSx for Windows reaches the slides’ “hundreds of PB”. One file system holds at most 64 TiB; DFS Namespaces group many file systems so they look like one huge share. (DFS Replication, which copies folders between servers, is supported only on the older Single-AZ 1 type; Multi-AZ replicates on its own.)

#Size, speed and storage type

You choose three numbers when you create a file system, and can raise them later:

• Storage capacity: SSD from 32 GiB, HDD from 2,000 GiB, both up to 64 TiB.
• Throughput capacity: from 8 MB/s up to 12,288 MB/s (about 12 GB/s) per file system. It also sets the file server’s memory and network, so it decides most of the performance.
• SSD IOPS: by default 3 per GiB of SSD, and you can provision up to 400,000.

Two storage types:

#Single-AZ or Multi-AZ

Windows clients follow a Multi-AZ failover by themselves, because the DNS name stays the same. Linux clients do not: they resume only after the file system fails back to the preferred server. Remember it for the “what goes wrong” section.

#Backups

FSx for Windows takes an automatic daily backup, stored durably in S3 (managed by FSx, not a bucket you see). Backups are incremental and file-system-consistent (Windows Volume Shadow Copy Service). Retention is 0 to 90 days (30 by default in the console; 0 turns daily backups off). You can also take user-initiated backups that never expire, copy backups to another Region, and manage everything centrally with AWS Backup (hourly schedules, long retention, cross-account copies). A restore always creates a new file system.

#FSx for Lustre

#What Lustre is

The name Lustre comes from “Linux” + “cluster”. It is a parallel distributed file system built for large-scale computing: supercomputers, render farms, model training. A normal file server sends every file through one server. Lustre splits each file into stripes across many storage servers, and every client talks to all of them at once. Add more storage servers and the total speed grows with them.

That is why FSx for Lustre is used for machine learning, high performance computing (HPC), video processing, financial modelling and electronic design automation: work where thousands of cores read and write millions of files, often the same files, as fast as possible.

• Speed: up to hundreds of GB/s (more with EFA networking), millions of IOPS, sub-millisecond latency. Throughput is sized per TiB of storage (below).
• Clients: Linux only, with the open-source Lustre client. EC2 instances, containers on EKS, and on-premises Linux servers over VPN or Direct Connect (useful for “cloud bursting” from an on-premises cluster).
• Storage classes: SSD for low-latency, IOPS-heavy work with small, random file operations; HDD for throughput-heavy work with large, sequential file operations (with an optional SSD read cache); and, since late 2024, Intelligent-Tiering, which is elastic and moves cold data to cheaper tiers by itself.
• One AZ. A Lustre file system lives in one Availability Zone. Clients in other AZs can mount it, but pay cross-AZ traffic and latency.

#Scratch or persistent

The most important choice when you create a Lustre file system is its deployment type:

A worked example: a Persistent 2 SSD file system of 24 TiB at 250 MB/s per TiB gives 24 × 250 = 6,000 MB/s, about 6 GB/s, of baseline throughput. Reading a 36 TB dataset once at that speed takes about 36,000,000 MB ÷ 6,000 MB/s = 6,000 seconds, about 1 hour 40 minutes.

#Seamless integration with S3

The feature that makes Lustre an exam favourite is its link to S3. The notes say it simply: bring S3 data into the file system, process it, and save it back to S3.

1. You create a data repository association: a directory such as /fsx/scenes is linked to an S3 prefix such as s3://scenes-example/. (A file system can have several.)
2. Lustre imports only the metadata (names, sizes, permissions). The objects appear as files in minutes, however large the bucket.
3. Lazy loading: the first time a client reads a file, Lustre fetches its content from S3 and keeps it. That first read is slower; every later read, by any client, comes from Lustre at full speed. (You can also preload files before a job starts.)
4. With automatic import, new, changed or deleted objects in the bucket show up in the file system by themselves.
5. With automatic export (or an export data repository task at the end of a job), new and changed files are written back to S3 as objects.
6. Lustre can release files that are already safe in S3 to free space; they are lazy-loaded again if read.

So S3 stays the durable, cheap data lake and Lustre is the fast workbench in front of it. The slides call it “read S3 as a file system” and “write the output of the computations back to S3”.

#FSx for NetApp ONTAP

#NetApp storage, managed by AWS

NetApp makes storage arrays that run in many company data centres, and ONTAP is their storage operating system. FSx for NetApp ONTAP gives you the same ONTAP, with AWS running it. The notes put the use case first: your data centre has NetApp storage and you want to bring it to AWS. More broadly, it fits any NAS workload you want to move without changing applications.

Its biggest feature is that it is multi-protocol: one file system serves

• NFS to Linux and macOS,
• SMB to Windows (with Active Directory),
• iSCSI block volumes (and, newer, NVMe over TCP) to databases and other servers that want a raw disk, like a SAN.

The same volume can even be shared over NFS and SMB at once. It works with Linux, Windows and macOS clients, VMware Cloud on AWS, Amazon virtual desktops, and EC2, ECS and EKS, in AWS or on premises.

#Saving space and money

• Deduplication, compression and compaction: identical blocks are stored once, the rest is compressed, small blocks are packed together. The notes call this the big advantage: it saves storage cost.
• Two tiers: a provisioned SSD tier for hot data, and an elastic capacity pool for cold data. With a tiering policy (for example Auto, with a cooling period of 31 days by default), blocks nobody uses move to the cheaper pool by themselves, and come back when read. You pay SSD prices only for the hot part. This is what the slides mean by “storage shrinks or grows automatically”: the capacity pool grows and shrinks with your data, while the SSD tier is a size you choose.
• Snapshots that cost almost nothing until data changes, and point-in-time instantaneous clones (FlexClone): a writable copy of a volume in seconds, sharing all unchanged blocks. Perfect for testing a new release against real data.
• SnapMirror replication: NetApp’s own replication, used to migrate from an on-premises NetApp (copy once, then only the changes, then switch over) and for disaster recovery to another Region.
• Also: Single-AZ or Multi-AZ high availability, automatic daily backups, write-once (WORM) volumes for compliance, and antivirus scanning.

#FSx for OpenZFS

#ZFS, managed by AWS

ZFS is a file system first built by Sun Microsystems and loved by storage administrators for its checksums on every block, cheap snapshots, clones and compression. OpenZFS is its open-source continuation. The notes describe the audience: companies whose local servers already run ZFS. FSx for OpenZFS lets them move those workloads, or any Linux file server, to AWS without changing applications or habits.

• NFS only: versions v3, v4.0, v4.1 and v4.2. No SMB, no iSCSI. Clients: Linux, Windows and macOS NFS clients, VMware Cloud on AWS, Amazon virtual desktops, EC2, ECS and EKS.
• Very fast: the slides say up to 1,000,000 IOPS with under 0.5 ms latency; the current AWS documentation says up to 2 million IOPS with latencies of a few hundred microseconds (from its memory and NVMe caches), and up to about 21 GB/s for cached data.
• Snapshots: near-instant, point-in-time, kept on the file system. Users can even open them themselves under .zfs/snapshot, and a whole volume can be rolled back to one.
• Clones: a new volume created from a snapshot is ready at once and shares unchanged blocks, ideal for test environments.
• Compression (Zstandard or a faster, lighter algorithm) reduces storage cost and often speeds things up. Unlike ONTAP, FSx for OpenZFS does not deduplicate.
• Availability: Multi-AZ (HA across two AZs) or Single-AZ (HA), both failing over in about 60 seconds, or Single-AZ (non-HA), which self-heals in about 30 minutes. Automatic daily backups go to S3.
• Side notes (2024–2025): an Intelligent-Tiering storage class that is elastic and tiers cold data automatically, and S3 Access Points that let S3-based tools read OpenZFS volumes as objects. The exam does not expect either.

#Choosing between EFS and the FSx family

The notes’ comparison rows, made precise:

• FSx for Windows: file storage; reached from Windows EC2 (and Linux over SMB) and on-premises servers; for Windows environments, SMB, Active Directory, IIS servers.
• FSx for Lustre: file storage; reached from Linux EC2 at high speed (and on-premises Linux over VPN or Direct Connect); for HPC, big data, machine learning, processing data in S3.

Two neighbours to keep apart:

• S3 File Gateway (lesson 12.3) gives on-premises servers an NFS or SMB share whose files become objects in S3. FSx keeps files in a file system. If the data must end up in S3, think gateway; if users just need a managed file server, think FSx.
• Amazon FSx File Gateway was a local cache in front of FSx for Windows for branch offices. It has been closed to new customers since 28 October 2024 (lesson 10.11); for new designs, offices reach FSx for Windows directly over VPN or Direct Connect, or use DFS and a local server.

Try each scenario before reading the reason:

#What every FSx file system shares

• Inside your VPC, never public. Each file system has elastic network interfaces in your subnets (two for Multi-AZ). Security groups decide who can reach the ports (SMB TCP 445, NFS TCP 2049, Lustre TCP 988, iSCSI TCP 3260). Do not modify or delete those network interfaces.
• Encryption. Data at rest is always encrypted with KMS keys (an AWS managed key or your own). In transit: SMB Kerberos encryption for Windows, and automatic encryption on supported EC2 instances (Nitro) for Lustre persistent, ONTAP and OpenZFS.
• IAM controls the API (who may create, change, back up or delete file systems), not who may read a file; that is NTFS ACLs, POSIX permissions or ONTAP’s own rules.
• Backups are incremental and stored in S3 for Windows, ONTAP, OpenZFS and Lustre persistent; AWS Backup can manage all of them, with cross-Region and cross-account copies.
• Getting data in: DataSync copies from on-premises NFS or SMB servers (or from S3 and EFS) into any FSx file system and keeps permissions (lesson 10.11); ONTAP also has SnapMirror, and Lustre has its S3 repository. The full storage comparison across every service is in lesson 12.4.
• Pricing. Unlike EFS, you mostly pay for what you provision: storage (GB-month), throughput capacity (MB/s-month), sometimes extra SSD IOPS, plus backup storage. The exceptions are ONTAP’s capacity pool and the Intelligent-Tiering classes, which charge for what you store.

#What goes wrong

#FSx in system design

• Lift and shift Windows applications. IIS web farms, Windows apps and SQL Server on EC2 keep using SMB shares and Active Directory, with Multi-AZ FSx for Windows instead of a fragile file server.
• Hybrid offices. Staff in Dhaka and Chattogram map the same FSx for Windows share over Site-to-Site VPN or Direct Connect, with DFS Namespaces hiding which file system holds which department.
• HPC on demand. Data lives in S3; for each job, a scratch Lustre file system is created, linked to the bucket, used by a fleet of Spot instances, exported and deleted. You pay for the fast tier only while you compute (Spot Instances and EFA from chapter 4 fit here).
• Whole data-centre migration. A NetApp estate moves with SnapMirror to FSx for ONTAP, keeping NFS, SMB and iSCSI clients, storage efficiency and the team’s tools; disaster recovery replicates to a second Region.
• Dev and test at speed. ONTAP or OpenZFS clones give every developer or tester a full, writable copy of production data in seconds, using almost no extra space.
• Keep EFS for simple Linux sharing. For a WordPress farm across three AZs, EFS is simpler and elastic; FSx is the answer when a specific protocol, feature or performance level is required.

#Try it yourself

The commands create real, billable file systems; use a test VPC and delete them afterwards. IDs below are examples.

# 1. FSx for Windows File Server: Multi-AZ, SSD, joined to AWS Managed Microsoft AD
aws fsx create-file-system --file-system-type WINDOWS \
  --storage-capacity 32 --storage-type SSD \
  --subnet-ids subnet-0aaa1111example subnet-0bbb2222example \
  --security-group-ids sg-0123abcdexample \
  --windows-configuration "ActiveDirectoryId=d-1234567890,DeploymentType=MULTI_AZ_1,PreferredSubnetId=subnet-0aaa1111example,ThroughputCapacity=32,AutomaticBackupRetentionDays=30"
#   "FileSystemId": "fs-0123456789abcdef0",
#   "Lifecycle": "CREATING",
#   "DNSName": "amznfsxabcd1234.corp.example.com"

# 2. FSx for Lustre: scratch, linked to an S3 bucket through a data repository association
aws fsx create-file-system --file-system-type LUSTRE \
  --storage-capacity 1200 --subnet-ids subnet-0aaa1111example \
  --lustre-configuration DeploymentType=SCRATCH_2
aws fsx create-data-repository-association --file-system-id fs-0fedcba9876543210 \
  --file-system-path /scenes --data-repository-path s3://scenes-example/ \
  --s3 "AutoImportPolicy={Events=[NEW,CHANGED,DELETED]},AutoExportPolicy={Events=[NEW,CHANGED,DELETED]}"

# 3. See what you have: type, state, deployment type and DNS name
aws fsx describe-file-systems \
  --query 'FileSystems[].{Id:FileSystemId,Type:FileSystemType,State:Lifecycle,DNS:DNSName}' --output table
#   |  DNS                                       |  Id                    | State     | Type     |
#   |  amznfsxabcd1234.corp.example.com          |  fs-0123456789abcdef0  | AVAILABLE | WINDOWS  |
#   |  fs-0fedcba9876543210.fsx.ap-south-1.amazonaws.com | fs-0fedcba9876543210 | AVAILABLE | LUSTRE |

# 4. Mount them
#    Windows (PowerShell / cmd):
#      net use Z: \\amznfsxabcd1234.corp.example.com\share
#    Linux, the same Windows share over SMB:
sudo mount -t cifs //amznfsxabcd1234.corp.example.com/share /mnt/share \
  -o vers=3.0,sec=krb5,cruid=$(id -u)
#    Linux, the Lustre file system (needs the Lustre client; the mount name comes from describe-file-systems):
sudo mount -t lustre -o relatime,flock \
  fs-0fedcba9876543210.fsx.ap-south-1.amazonaws.com@tcp:/abcdefgh /fsx

# 5. Lustre: export results to S3 at the end of a job, if automatic export is off
aws fsx create-data-repository-task --file-system-id fs-0fedcba9876543210 \
  --type EXPORT_TO_REPOSITORY --paths renders/ep01 --report Enabled=false

# 6. OpenZFS: snapshot a volume, then create a clone from it
aws fsx create-snapshot --volume-id fsvol-0123456789example --name pre-upgrade
aws fsx create-volume --volume-type OPENZFS --name test-clone-1 \
  --open-zfs-configuration "ParentVolumeId=fsvol-0aaaaaaaaaexample,OriginSnapshot={SnapshotARN=arn:aws:fsx:ap-south-1:111122223333:snapshot/fsvol-0123456789example/fsvolsnap-0abc1234example,CopyStrategy=CLONE}"

# 7. A user-initiated backup (never expires), then clean up
aws fsx create-backup --file-system-id fs-0123456789abcdef0
aws fsx delete-file-system --file-system-id fs-0fedcba9876543210

On a Windows instance joined to the domain, \\amznfsxabcd1234.corp.example.com\share opens in Explorer like any file server; right-click a folder → Properties → Security shows the NTFS permissions, and the Previous Versions tab shows shadow copies if you enabled them. On the Lustre mount, lfs df -h /fsx shows the storage servers the file system is striped across.

#Summary

Key takeaways

• EFS is shared Linux storage over NFS. For anything else, Amazon FSx launches well-known third-party file systems as a fully managed service: Windows File Server, Lustre, NetApp ONTAP, OpenZFS. All live in your VPC, are encrypted at rest, and are reached from on premises over VPN or Direct Connect.
• FSx for Windows File Server: SMB, NTFS, Active Directory (AWS Managed or self-managed), ACLs, user quotas, shadow copies, DFS Namespaces; mountable from Linux too. SSD (latency-sensitive) or HDD (general shares). Up to 64 TiB and about 12 GB/s per file system; DFS groups many. Multi-AZ fails over in under 30 seconds; Single-AZ recovers in about 30 minutes. Daily backups to S3, 0–90 days.
• SMB = Windows file sharing, NFS = Linux file sharing, AD = one central place for users, passwords and permissions. Without AD reachable, a Windows share cannot authenticate new users.
• FSx for Lustre (“Linux + cluster”): parallel file system for HPC, ML, video, finance, chip design, hundreds of GB/s, sub-ms latency, Linux only, one AZ. Scratch: temporary, not replicated, 200 MB/s per TiB with about 6× burst, cheapest. Persistent: replicated in the AZ, servers replaced in minutes, 125–1,000 MB/s per TiB. S3 data repository: metadata first, lazy-load content on first read, auto import and export results back to S3.
• FSx for NetApp ONTAP: multi-protocol NFS + SMB + iSCSI, dedup, compression, SSD tier + elastic capacity pool, snapshots, instant clones, SnapMirror migration and DR, Multi-AZ.
• FSx for OpenZFS: NFS v3–v4.2 only, up to 2 million IOPS at hundreds of microseconds, snapshots, clones, compression (no dedup), Multi-AZ or Single-AZ.
• Keywords: SMB / Windows / AD / DFS → Windows; HPC / ML / S3 → Lustre; dedup / compression / multi-protocol / NetApp → ONTAP; ZFS / snapshots / clones → OpenZFS; Linux across AZs → EFS; S3 + NFS/SMB on premises → S3 File Gateway.

Self-check: Amazon FSx family30 questions