The SAA-C03 exam’s Design High-Performing Architectures (24%) and Design Resilient Architectures (26%) domains both lean on storage selection, and the file-storage questions have quietly become harder. A few years ago “Windows file share” meant FSx for Windows File Server and “HPC” meant FSx for Lustre, and that was the whole FSx story. Today the exam guide lists four FSx members, and the scenarios probe the differences within each one: scratch versus persistent Lustre, Single-AZ versus Multi-AZ Windows, which ONTAP tiering policy fits a cold archive, and when OpenZFS beats EFS for a Linux migration. If you only know the two-member version, you will lose points to distractors that are all technically “FSx.”
This guide assumes you already know the block / file / object split and the headline EBS-vs-EFS-vs-S3 trade-offs. Those are covered in the AWS storage services overview for SAA-C03, which introduces FSx in about fifteen lines. This article goes the other way: deep into the FSx family only, with the deployment types, performance knobs, data-management features and limits that scenario questions actually test.
Why Four File Systems? AWS’s Own Selection Rule
Amazon FSx is a family, not one product. Each member runs a different file system under the hood, is managed by a different team, and exists for a different population of workloads:
| FSx member | File system | Primary protocol(s) | Clients | Deployment | Max size | What it is for |
|---|---|---|---|---|---|---|
| FSx for Windows File Server | Windows Server / NTFS | SMB 2.0–3.1.1 | Windows, Linux, macOS | Single-AZ or Multi-AZ | 64 TiB | Lift-and-shift Windows shares, home directories, AD-integrated apps |
| FSx for Lustre | Lustre (parallel) | Lustre POSIX client | Linux only | Single-AZ | ~1,000 GBps throughput per FS | HPC, ML training, media rendering, data processing from S3 |
| FSx for NetApp ONTAP | NetApp ONTAP | NFS, SMB, iSCSI, NVMe/TCP | Windows, Linux, macOS | Single-AZ or Multi-AZ, scale-out | Virtually unlimited (tens of PiB with tiering) | Enterprise NAS features, multi-protocol, hybrid with on-prem ONTAP |
| FSx for OpenZFS | OpenZFS | NFS v3, v4.0, v4.1, v4.2 | Windows, Linux, macOS | Single-AZ (HA or non-HA) or Multi-AZ | 512 TiB SSD | Replacing Linux/ZFS file servers, latency-sensitive workloads, dev/test clones |
AWS’s own guidance for choosing between them is refreshingly blunt: pick the one that matches the storage technology your team already runs or the workload already expects. Windows Server shares → Windows File Server. Lustre or any parallel file system → Lustre. NetApp appliances or a need for NAS features → ONTAP. ZFS or generic Linux NFS servers → OpenZFS. The exam uses the same logic, so the first thing to extract from any FSx scenario is what the workload is migrating from or what protocol it speaks.
Everything that follows is organised by member, then pulled together into a decision table.
FSx for Windows File Server
What it is
A fully managed Windows Server file server with a native NTFS file system, exposed over SMB versions 2.0 through 3.1.1. Everything a Windows admin expects is present: NTFS ACLs, Active Directory authentication, DFS Namespaces, shadow copies (Volume Shadow Copy Service, so users can restore previous versions themselves), data deduplication, user quotas, access-based enumeration and DNS aliases. Clients can be Windows, Linux (via cifs-utils) or macOS, plus WorkSpaces, AppStream 2.0 and VMware Cloud on AWS.
Active Directory is mandatory
Users are authenticated by Microsoft Active Directory. You join the file system to either AWS Managed Microsoft AD or a self-managed AD (on-premises or on EC2) at creation time. This is a frequent exam discriminator: if the scenario says “must integrate with existing on-premises Active Directory,” FSx for Windows handles it directly through the self-managed AD option. EFS does not integrate with AD at all.
Single-AZ vs Multi-AZ
| Single-AZ | Multi-AZ | |
|---|---|---|
| File servers | One, with automatic component repair | Active in one AZ, standby in a second AZ |
| Replication | Within the AZ | Synchronous across AZs |
| Failover | Not applicable | Automatic to standby, transparent to SMB clients (same DNS name) |
| Use for | Dev/test, cost-sensitive workloads that tolerate AZ loss | Production shares that must survive an AZ outage |
The deployment type is chosen at creation and cannot be changed later. To move from Single-AZ to Multi-AZ you back up and restore into a new file system, or copy with AWS DataSync.
SSD vs HDD and the two performance knobs
You provision three things independently:
- Storage capacity in GiB. SSD or HDD. The family-wide maximum is 64 TiB per file system.
- Throughput capacity in MBps. This buys network throughput, file-server CPU and memory (for the in-memory cache, deduplication and shadow copies), and disk throughput. Standard tiers run up to 2,048 MBps; in six large Regions you can go to 12,288 MBps and 400,000 IOPS. Levels below 32 MBps are meant for test and development.
- SSD IOPS. SSD storage includes 3 IOPS per GiB by default and you can provision up to 500 IOPS per GiB, capped at 400,000 per file system.
HDD storage uses a burst-credit model: 12 MBps per TiB baseline, 80 MBps per TiB burst. SSD provides sub-millisecond latency; HDD single-digit milliseconds. You can upgrade HDD to SSD later but not the reverse. The in-memory cache on the file server means actively accessed data is served at network speed regardless of disk type, which is why “small active working set, large cold dataset” scenarios can legitimately pick HDD to save money.
Backups, encryption and hybrid access
Automatic daily backups are on by default and are file-system-consistent (VSS), incremental and stored in S3. Data at rest is encrypted with KMS; in transit with SMB Kerberos session keys. On-premises clients reach shares over Direct Connect or Site-to-Site VPN, and other VPCs, accounts or Regions can mount shares over VPC peering or Transit Gateway. For branch offices that need low-latency access to a cloud share, the answer is Amazon FSx File Gateway (part of Storage Gateway), which caches frequently used data locally. That gateway is covered in the hybrid storage and data transfer guide.
Exam keywords: “SMB,” “Windows file share,” “Active Directory,” “NTFS permissions,” “DFS Namespaces,” “shadow copies,” “home directories for Windows users,” ”.NET application needs a shared drive.”
FSx for Lustre
What it is
A managed deployment of Lustre, the parallel file system used on most of the world’s largest supercomputers. It is POSIX-compliant and Linux-only, mounted with the open-source Lustre client (built into Amazon Linux 2023 and Amazon Linux 2; packaged for RHEL, Ubuntu and SUSE). It delivers sub-millisecond latency, up to hundreds of GBps to over a TBps of aggregate throughput, and millions of IOPS by striping files across many Object Storage Servers (OSSs). EKS pods use it through the FSx for Lustre CSI driver, SageMaker can use it directly as a training input source, and AWS Batch and ParallelCluster integrate with it.
Lustre is Single-AZ. There is no Multi-AZ option, and that fact alone eliminates it in “must survive an AZ failure with no data loss” scenarios.
Scratch vs persistent: the first exam discriminator
| Scratch | Persistent | |
|---|---|---|
| Data replication | None. If a file server or disk fails, data on it is lost and clients get I/O errors | Replicated within the AZ; failed servers replaced automatically within minutes |
| Baseline throughput | 200 MBps per TiB, with burst up to 6× baseline | Chosen per TiB (see below) |
| Backups | Not supported | Supported (unless linked to an S3 data repository) |
| Encryption in transit | — | Automatic on supported EC2 instance types |
| Cost | Lowest | Higher |
| Use for | Temporary, short-term, cost-optimised processing where the data can be regenerated or lives in S3 | Longer-running, throughput-focused workloads sensitive to disruption |
The current scratch generation is Scratch 2. The two persistent generations differ in storage class and throughput:
- Persistent 1 – SSD at 50, 100 or 200 MBps per TiB, or HDD at 12 or 40 MBps per TiB (with an optional SSD read cache sized to 20% of HDD capacity). Creatable only via CLI/API today.
- Persistent 2 – SSD at 125, 250, 500 or 1,000 MBps per TiB, plus the Intelligent-Tiering storage class, an optional metadata configuration (more metadata IOPS) and Elastic Fabric Adapter (EFA) support for the highest-throughput HPC and GPU workloads.
Throughput in Lustre scales with capacity because you are buying more OSSs as you add TiB. A 10 TiB Persistent 2 file system at 250 MBps/TiB gives 2.5 GBps baseline. If a question says “the training job needs 20 GBps,” you compute the TiB × MBps/TiB product; you do not “increase throughput capacity” as you would on Windows or ONTAP.
Storage classes: SSD, HDD and Intelligent-Tiering
- SSD – provisioned capacity, sub-millisecond latency to the whole dataset. Pick for latency-sensitive small random I/O.
- HDD (Persistent 1 only) – provisioned, single-digit millisecond latency, cheapest per TiB for throughput-oriented sequential workloads.
- Intelligent-Tiering (Persistent 2 only) – fully elastic: you do not specify a size and pay only for data stored. Data moves through Frequent Access → Infrequent Access (after 30 days without access) → Archive Instant Access (after 90 days) and returns to Frequent on access, with no retrieval fees. Optional SSD read cache. Throughput is provisioned in 4,000 MBps increments. It is replicated across AZs, but note two limits that matter for exam logic: it cannot be linked to an S3 data repository, and it is a Persistent 2 feature only.
S3 integration: data repository associations
This is Lustre’s signature feature and the one the exam loves. You link a file system to an S3 bucket or prefix through a data repository association (DRA). Then:
- At creation, FSx imports the metadata (names, sizes, permissions) of existing objects so the bucket appears as a directory tree. File contents are lazily loaded from S3 on first access, or you can preload them with a data repository import task.
- An import policy of
NEW,CHANGEDand/orDELETEDkeeps the file system in sync as objects change in S3. - An export policy (or an export task) writes new and changed files, including POSIX metadata, back to S3. This is how a job’s output lands durably in S3 so the Lustre file system itself can be deleted afterwards.
lfs hsm_releasefrees local space for files already exported to S3 while keeping them visible; they reload on the next read.
Persistent 2 file systems support multiple DRAs to different buckets or prefixes. The architectural pattern this enables is the classic exam answer: “data lake in S3 + burst HPC/ML processing in Lustre, export results to S3, tear the file system down.” Two caveats are regularly tested: backups are not supported on a file system linked to S3 (S3 is the durable copy), and Intelligent-Tiering file systems do not support DRAs.
Data compression and on-premises bursting
Persistent file systems can enable LZ4 data compression, which reduces storage consumption and often increases effective throughput. For hybrid scenarios, you can mount Lustre from on-premises over Direct Connect or VPN and copy data in as needed, or burst on-prem HPC into AWS.
Exam keywords: “HPC,” “machine learning training,” “genomics,” “video rendering,” “millions of IOPS,” “hundreds of GBps,” “process data stored in S3,” “POSIX file system for Linux compute cluster,” “temporary / scratch space.”
FSx for NetApp ONTAP
What it is
A fully managed NetApp ONTAP storage array in AWS. If a company already runs NetApp on-premises, this is the lift-and-shift target that preserves their tooling, data-management features and even their management APIs (ONTAP CLI and REST API work alongside the AWS console and CLI). It is the only FSx member that is multi-protocol: the same data can be served over NFS, SMB, iSCSI and NVMe/TCP, and NFS and SMB can access the same files simultaneously. Clients: Linux, Windows and macOS, on AWS or on-premises.
Resource model: file system → SVM → volume
An ONTAP file system contains one or more storage virtual machines (SVMs), each an isolated tenant with its own network endpoints and optional Active Directory join. Volumes (FlexVol, or FlexGroup for very large single namespaces) live inside SVMs and are thin-provisioned: a volume’s configured size does not consume storage until data is written. Snapshots are enabled by default (.snapshot directory) and are space-efficient.
Deployment types and generations
| Dimension | First generation (Single-AZ 1, Multi-AZ 1) | Second generation, one HA pair (Single-AZ 2, Multi-AZ 2) | Second generation, scale-out (Single-AZ 2) |
|---|---|---|---|
| HA pairs | 1 | 1 | 1–12 |
| SSD storage | 1–192 TiB | 1–512 TiB | up to 1 PiB total |
| SSD IOPS max | 160,000 | 200,000 | 2,400,000 |
| Throughput capacity | 128–4,096 MBps | 384–6,144 MBps | up to 6,144 MBps per HA pair |
Every HA pair is an active/standby file-server pair. In Single-AZ both servers are in separate fault domains within one AZ; in Multi-AZ the standby sits in a second AZ with synchronous replication, so an AZ outage fails over automatically, typically in under 60 seconds, and fails back when the preferred server recovers. NFS and SMB failover is transparent because clients use a floating endpoint IP; iSCSI and NVMe/TCP clients need multipathing configured. Multi-AZ file systems add routes to your VPC route tables for the floating IP, which is why reaching a Multi-AZ ONTAP file system from a peered VPC or through Transit Gateway requires route entries pointing at the file system’s CIDR range. As with Windows, the deployment type cannot be changed after creation.
Two storage tiers and the tiering policies
ONTAP file systems have SSD (primary) storage, which you provision, and capacity pool storage, an elastic tier that scales to petabytes and is cost-optimised for cold data. Each volume has a tiering policy:
| Policy | What moves to capacity pool | Default cooling period | Typical use |
|---|---|---|---|
| Auto (console default) | All cold user data and snapshots | 31 days (2–183 configurable) | General-purpose, the recommended default |
| Snapshot-only (CLI/API default) | Only snapshot blocks | 2 days (2–183) | Active data that must stay on SSD, cheap snapshot retention |
| All | Everything, as soon as written (via background process) | n/a | Archives, backups, DR copies, data you rarely read |
| None | Nothing; existing tiered data is pulled back | n/a | Latency-critical volumes |
File metadata always stays on SSD regardless of policy, which is why ONTAP can present petabytes with fast directory listings. Randomly read cold blocks are promoted back to SSD under Auto; sequential reads (an antivirus scan, a backup) are not, so a nightly scan does not blow out your SSD tier. Tiering only begins once SSD utilisation exceeds 50%, cold data stops being promoted at 90%, and tiering stops entirely at 98%. AWS recommends staying under 80% SSD utilisation.
Storage efficiency is the other cost lever: deduplication, compression and compaction run automatically and commonly save around 65% on general-purpose data. Combined with tiering, this is how ONTAP earns the “SSD performance for a fraction of SSD cost” line in the docs.
Data management features the exam names
- SnapMirror – block-level replication to another ONTAP file system (another Region, or on-premises). Used for cross-Region DR and for migrating from on-premises NetApp without changing applications. When a scenario says “replicate to a second Region and fail over,” SnapMirror is the ONTAP answer.
- FlexClone – instant, writable, space-efficient clones of a volume. Dev/test copies of a production database volume in seconds.
- FlexCache – caches a cloud volume on-premises (or vice versa) so distributed teams get local read performance against one source of truth.
- SnapLock – write-once-read-many (WORM) volumes in Compliance or Enterprise retention mode for regulatory retention.
- Cloud write mode, autosizing, antivirus (Vscan) integration, file access auditing and SMB Kerberos / IPsec encryption in transit round out the enterprise feature list.
Automatic daily backups are stored across multiple AZs and can be copied cross-Region. FSx for ONTAP’s Multi-AZ SLA is 99.99%.
Exam keywords: “NetApp,” “ONTAP,” “multi-protocol,” “both NFS and SMB,” “iSCSI block storage,” “SnapMirror,” “on-premises NAS migration,” “petabyte-scale file data with automatic tiering,” “WORM / compliance retention.”
FSx for OpenZFS
What it is
A managed OpenZFS file system served over NFS v3, v4.0, v4.1 and v4.2 to Linux, Windows and macOS clients. It is purpose-built for replacing on-premises ZFS or generic Linux NFS servers without re-architecting, and for workloads that want the lowest latency in the FSx family: a few hundred microseconds and up to 2 million IOPS from the in-memory and NVMe cache, and 400,000 IOPS with 10 GBps (21 GBps for compressed data) from disk. OpenZFS does not speak SMB and has no Active Directory integration, so “Windows users with ACLs” is never an OpenZFS answer.
Deployment types
| Type | Architecture | Recovery |
|---|---|---|
| Single-AZ (non-HA) | One file server, self-healing | Typically ~30 minutes |
| Single-AZ (HA) | Primary + standby in the same AZ | Failover ~60 seconds |
| Multi-AZ (HA) | Primary + standby in different AZs, separate data copy per AZ | Failover ~60 seconds, survives AZ loss |
Storage classes and performance
- SSD – provisioned size (up to 512 TiB), full-dataset low latency.
- Intelligent-Tiering – elastic; pay for stored data, optional SSD read cache, no size to specify.
Throughput capacity is provisioned separately from storage, in the same spirit as Windows and ONTAP.
ZFS data management
OpenZFS brings the features ZFS admins migrate for: near-instant point-in-time snapshots stored locally, data cloning of volumes (writable copies that share blocks with the source, ideal for dev/test copies and CI), compression (Z-standard or LZ4), thin provisioning, multiple volumes per file system and user and group quotas. Backups go to S3 with cross-Region copy support, and on-demand data replication copies snapshots between OpenZFS file systems for migration or DR. A newer capability worth knowing: you can attach S3 Access Points to OpenZFS volumes, so S3-API-based tools can read and write file data without copying it.
Exam keywords: “ZFS,” “Linux NFS file server migration,” “lowest latency,” “sub-millisecond / hundreds of microseconds,” “snapshots and clones for dev/test,” “NFS v4,” “no Windows/AD requirement.”
The Decision Table
| Scenario signal | Choose | Why not the others |
|---|---|---|
| Windows shares, NTFS ACLs, Active Directory, SMB | FSx for Windows File Server | EFS/Lustre/OpenZFS have no SMB or AD; ONTAP works but is overkill unless NAS features are needed |
| Linux shared storage, “scale automatically,” no capacity planning, serverless/Fargate | EFS | Not FSx at all; see the storage overview |
| HPC, ML training, hundreds of GBps, process S3 data with a POSIX file system | FSx for Lustre | Only Lustre links to S3 as a data repository and scales throughput per TiB |
| Temporary processing, lowest cost, data regenerable or in S3 | Lustre Scratch | Persistent costs more for durability you do not need |
| Long-running HPC that cannot tolerate server loss, needs backups | Lustre Persistent 2 | Scratch has no replication or backups |
| Both NFS and SMB to the same data; iSCSI / NVMe block storage | FSx for ONTAP | The only multi-protocol member |
| Migrating from on-prem NetApp; SnapMirror; keep ONTAP tooling | FSx for ONTAP | Nothing else speaks ONTAP |
| Petabytes of file data, most of it cold, automatic tiering, still fast listings | FSx for ONTAP (Auto/All tiering) | Lustre Intelligent-Tiering fits HPC datasets but not general NAS; Windows caps at 64 TiB |
| Replace a Linux ZFS/NFS server; snapshots and clones; lowest latency NFS | FSx for OpenZFS | EFS lacks clones and has higher latency; ONTAP is heavier than needed |
| Must survive an AZ failure | Windows Multi-AZ, ONTAP Multi-AZ, OpenZFS Multi-AZ (HA), EFS Regional | Lustre is Single-AZ only |
| Branch office needs low-latency access to a cloud Windows share | FSx File Gateway in front of FSx for Windows | Other gateways serve S3/volumes, not SMB shares |
Features Shared Across the Family
Scenario questions often hinge on knowing what is common, so you can eliminate false discriminators:
- Encryption at rest with AWS KMS on every member, and encryption in transit (SMB Kerberos for Windows, Nitro-based or protocol-level for the others on supported instances).
- Access control by VPC security groups at the network layer, IAM for the FSx API, and the native file-system permission model (NTFS ACLs, POSIX modes, ONTAP export policies) for files.
- Backups are incremental, crash-consistent (file-system-consistent for Windows via VSS), stored in S3 and manageable centrally through AWS Backup. The one exception to remember: Lustre file systems linked to an S3 data repository and Lustre scratch file systems do not support backups.
- Hybrid access over Direct Connect or Site-to-Site VPN, and cross-VPC/account/Region access over VPC peering or Transit Gateway.
- AWS DataSync is the recommended tool to migrate data into any FSx member and to copy between them.
- FSx file systems are never exposed to the public internet; attaching an Elastic IP to a file system’s network interface is automatically undone.
- All four appear in the SAA-C03 in-scope services list, along with EFS, S3, EBS and Storage Gateway.
Worked Scenarios
1. A media company’s rendering farm of 500 Linux instances needs a shared file system with at least 10 GBps throughput for a two-week project. Source footage and finished renders live in S3. Minimise cost. Lustre, linked to the S3 bucket with a DRA and an export policy so renders land in S3. Two weeks of processing with S3 as the system of record points to Scratch 2 (or Persistent 2 if the project cannot tolerate server failure mid-render). Size: 10 GBps ÷ 200 MBps/TiB ≈ 50 TiB of scratch, or 10 TiB of Persistent 2 at 1,000 MBps/TiB. Delete the file system afterwards.
2. A company migrates 40 TB of Windows home directories. Users authenticate against on-premises Active Directory over Direct Connect. The shares must stay available if an AZ fails. FSx for Windows File Server, Multi-AZ, joined to the self-managed AD. HDD storage is reasonable for home directories; enable shadow copies so users self-restore.
3. A healthcare company runs NetApp arrays on-premises and wants a cloud DR copy of 800 TB of imaging data, most of it not accessed after 60 days, with the ability to fail over applications to AWS. FSx for ONTAP as the SnapMirror destination. Volumes use the All tiering policy (or Auto with a short cooling period) so the cold majority lives in the capacity pool at low cost; metadata stays on SSD; failover re-points applications to the ONTAP SVM endpoints with the same NFS/SMB paths.
4. A fintech’s analytics platform needs both Linux (NFS) and Windows (SMB) access to the same dataset, plus a few iSCSI LUNs for a legacy database. Only FSx for ONTAP serves NFS, SMB and iSCSI from the same file system.
5. A SaaS vendor’s CI pipeline needs dozens of writable copies of a 2 TB test dataset created and destroyed many times per day, with NFS access from Linux build agents and the lowest possible latency. FSx for OpenZFS: snapshot the dataset volume and create clones per pipeline run in seconds, paying only for changed blocks. EFS has no clone capability; Lustre is overkill and Windows is the wrong protocol.
6. An HPC team needs a POSIX file system for a six-month genomics study with sub-millisecond latency, cannot lose data if a server fails, and must take backups. Data is not in S3. Lustre Persistent 2 with SSD. Persistent gives replication and server replacement; because it is not linked to S3, backups are supported. Scratch fails both requirements.
7. A startup running Linux containers on Fargate needs a shared file system that grows automatically with no provisioning. EFS, not FSx. Fargate mounts EFS natively; none of the FSx members integrate with Fargate, and all of them (except Intelligent-Tiering classes) require you to choose a size or throughput.
Exam Traps Cheat Sheet
- Lustre is Linux-only and Single-AZ only. Windows clients or “survive an AZ failure” eliminate it.
- Scratch = no replication, no backups, bursts to 6×; Persistent = replicated, replaceable servers, backups (unless S3-linked).
- Linked-to-S3 Lustre file systems do not support backups; S3 is the durable copy. Intelligent-Tiering Lustre cannot link to S3 at all.
- Lustre throughput is per TiB of capacity (50–1,000 MBps/TiB); Windows, ONTAP and OpenZFS have a separately provisioned throughput capacity.
- FSx for Windows requires Active Directory (AWS Managed or self-managed). EFS has no AD integration.
- Windows caps at 64 TiB; ONTAP scales to a PiB of SSD plus petabytes of capacity pool; OpenZFS SSD caps at 512 TiB.
- ONTAP is the only multi-protocol member (NFS + SMB + iSCSI + NVMe/TCP) and the only one with SnapMirror, FlexClone, FlexCache and SnapLock.
- ONTAP tiering: Auto moves cold data and snapshots after 31 days by default; Snapshot-only moves only snapshots after 2 days; All moves everything; None keeps everything on SSD. Metadata never tiers.
- OpenZFS is NFS-only (v3–v4.2), no SMB/AD, lowest latency, snapshots and clones; Single-AZ non-HA, Single-AZ HA and Multi-AZ HA options.
- Deployment type (Single-AZ/Multi-AZ) cannot be changed after creation on Windows or ONTAP; back up and restore or use DataSync.
- HDD → SSD upgrade is possible on Windows; SSD → HDD is not.
- FSx File Gateway caches an FSx for Windows share on-premises; it is not a generic FSx feature.
Practice the Discrimination, Not the Definitions
Storage questions on SAA-C03 rarely ask “what is FSx for Lustre.” They describe a workload with three or four constraints and list two FSx members plus EFS and S3 as options, and the correct answer turns on one detail: the protocol, the AZ requirement, whether the data lives in S3, or whether the workload is temporary. The fastest way to internalise that discrimination is to work through a large set of such scenarios under time pressure and read the explanations for the ones you miss.
Sailor.sh’s AWS Certified Solutions Architect - Associate (SAA-C03) Mock Exam Bundle includes storage-selection scenarios across all four FSx members, EFS, EBS and S3, written at exam difficulty with explanations that call out why each distractor is wrong. Pair it with the SAA-C03 study guide for the overall plan, the high-performing architectures guide for the compute and database half of Domain 3, and the resilient architectures guide for the Multi-AZ and DR patterns that FSx deployment types plug into.
Frequently Asked Questions
What is the difference between FSx for Lustre scratch and persistent file systems?
Scratch file systems do not replicate data and do not replace failed file servers; if a server or disk fails, data on it is lost and clients get I/O errors. They offer 200 MBps per TiB baseline with burst up to six times that, and the lowest price, so they suit temporary processing where the durable copy is in S3. Persistent file systems replicate data within the AZ, automatically replace failed servers, support backups when not linked to S3, and let you choose throughput per TiB (Persistent 2: 125, 250, 500 or 1,000 MBps per TiB).
Can FSx for Lustre span multiple Availability Zones?
No. Every FSx for Lustre file system lives in a single AZ (the Intelligent-Tiering storage class replicates its data across AZs for durability, but the file system is still accessed in one AZ). If the requirement is to keep serving files through an AZ outage, use FSx for Windows Multi-AZ, FSx for ONTAP Multi-AZ, FSx for OpenZFS Multi-AZ, or EFS.
How does FSx for Lustre integrate with S3?
Through a data repository association that links the file system to a bucket or prefix. Object metadata is imported so the bucket appears as directories; file contents load lazily on first read or via an import task. Import policies (NEW, CHANGED, DELETED) keep the file system in sync with S3, and export policies or tasks write changes back. Files can be released from Lustre once exported to free space. Backups are not supported on S3-linked file systems, and Intelligent-Tiering file systems cannot be linked.
When should I choose FSx for NetApp ONTAP over FSx for Windows File Server?
Choose ONTAP when you need more than SMB: simultaneous NFS and SMB access to the same files, iSCSI or NVMe/TCP block storage, SnapMirror replication for DR or migration from on-premises NetApp, FlexClone copies, SnapLock WORM retention, or petabyte-scale data with automatic SSD-to-capacity-pool tiering. Choose FSx for Windows when the requirement is a straightforward Windows file share with Active Directory and NTFS permissions and a maximum of 64 TiB.
What do the FSx for ONTAP tiering policies do?
Each volume has a policy that decides what moves from the provisioned SSD tier to the elastic capacity pool. Auto (console default) tiers cold user data and snapshots after a 31-day cooling period; Snapshot-only tiers just snapshot blocks after 2 days; All tiers everything via a background process; None keeps data on SSD. Cooling periods are configurable from 2 to 183 days, metadata always stays on SSD, and tiering only starts once the SSD tier is more than 50% full.
Is FSx for OpenZFS a replacement for EFS?
They overlap for Linux NFS workloads, but they target different needs. OpenZFS gives much lower latency, ZFS snapshots and instant writable clones, compression, and a provisioned performance model; it is Single-AZ or Multi-AZ with a chosen size or an Intelligent-Tiering class. EFS is fully elastic, Regional by default, integrates natively with Lambda and Fargate, and needs no sizing. If the scenario emphasises “no capacity planning” or serverless compute, EFS wins; if it emphasises “lowest latency,” “clones,” or “migrating a ZFS server,” OpenZFS wins.
Do FSx file systems support Active Directory?
FSx for Windows File Server requires it (AWS Managed Microsoft AD or a self-managed AD). FSx for NetApp ONTAP supports AD for SMB access and Windows ACLs. FSx for Lustre and FSx for OpenZFS use POSIX permissions and do not integrate with AD.
Can I change an FSx file system from Single-AZ to Multi-AZ after creation?
No. Deployment type is fixed at creation for FSx for Windows and FSx for ONTAP. To change it, take a backup and restore into a new file system of the desired type, or migrate with AWS DataSync (or SnapMirror for ONTAP).
Key Takeaways
- Amazon FSx is four managed file systems, and the exam tests the differences between them as much as the differences from EFS and S3.
- Match the member to the workload’s heritage and protocol: SMB and Active Directory → Windows File Server; HPC/ML and S3-resident data on Linux → Lustre; multi-protocol and NetApp features → ONTAP; Linux/ZFS NFS servers and low latency → OpenZFS.
- Within Lustre, scratch is cheap and unreplicated, persistent is replicated and backable, throughput is bought per TiB, S3 integration is via data repository associations, and everything is Single-AZ.
- Within ONTAP, know the SVM/volume model, Single-AZ versus Multi-AZ, the Auto / Snapshot-only / All / None tiering policies, and SnapMirror, FlexClone, FlexCache and SnapLock by name.
- The shared features (KMS encryption, backups, DataSync, security groups, hybrid access over DX/VPN) are rarely the discriminator; protocol, AZ resilience, S3 linkage and workload duration are.