Master Amazon FSx for SAA-C03

Build a decision framework for all four FSx types using console exploration.

Introduction

30 Second Summary

Imagine you're asked to pick the best container for shipping a package. A padded envelope, a cardboard box, a crate, and a pallet are all valid options. The right choice depends on what's inside, where it's going, and how much you want to spend. That's the same decision you face when an exam scenario describes a file storage workload on AWS.

In this project, you will build a systematic decision framework for Amazon FSx by exploring all four file system types in the AWS Console and solving 12+ scenario-based questions mapped to the SAA-C03 exam.

What You'll Build

Picture yourself reading an exam question about a company migrating Windows file shares, a genomics lab needing extreme throughput, or an enterprise with mixed Linux and Windows clients. You immediately know which FSx type fits, why the others fail, and which deployment option saves money.

By the end of this project, you'll have:

A hands-on familiarity with all four FSx creation wizards in the AWS Management Console, knowing what each configuration option means for real workloads.
A 5-step decision framework that lets you match any workload description to the correct FSx type in under 30 seconds by eliminating on protocol, OS, performance, and cost.
Confident elimination skills for distinguishing scenarios that need FSx from those that need EFS, EBS, or S3.
Secret Mission: Tackle ambiguous multi-requirement scenarios where two or more FSx types appear viable, and use cost-optimization reasoning to pick the winner.

Are there any prerequisites?

You need an AWS account with console access and basic familiarity with core services like VPC, EC2, and S3. This project costs $0 because you explore the FSx creation wizards without provisioning any resources.

Before We Start

Before diving into the AWS Console, let's lock in what you're about to build and why it matters for your exam preparation.

Navigate the FSx Console

Before you can explore each FSx file system type in depth, you need to orient yourself in the Amazon FSx console.

The FSx service offers four distinct managed file systems, each built on a different underlying technology. In this step, you will navigate to the FSx dashboard and confirm all four options are available in the creation wizard.

In this step, get ready to:

Navigate to the Amazon FSx service in the AWS Console.
Open the Create file system wizard and confirm all four file system types are listed.
Review the one-line descriptions for each type to identify their primary use cases.

Sign in and navigate to Amazon FSx

Sign in to the AWS Management Console.
In the search bar at the top of the console, type FSx.
Select FSx from the search results to open the Amazon FSx dashboard.

You should now see the FSx dashboard with a Create file system button visible.

Don't see the FSx dashboard?

Make sure you typed FSx in the services search bar (the one with the magnifying glass icon at the very top), not the documentation search. You can also navigate directly to https://console.aws.amazon.com/fsx/ in your browser.

Help me find the Amazon FSx service in my AWS Console.

Open the file system type selection page

The creation wizard is where you will spend most of your time in this project. Each file system type has its own configuration wizard with options that map directly to exam scenarios.

Click Create file system on the FSx dashboard.
Confirm you see the file system type selection page listing all four options: FSx for NetApp ONTAP, FSx for OpenZFS, FSx for Windows File Server, and FSx for Lustre.
Do NOT click Next yet. Stay on this selection page.

Why four separate file system types?

AWS does not offer a single "universal" managed file system. Each FSx type is a fully managed service built on a different underlying storage technology (Windows Server, Lustre, NetApp ONTAP, or OpenZFS).

On the SAA-C03 exam, scenario questions test whether you can pick the right type based on protocol needs, OS compatibility, and cost constraints. That selection logic is exactly what you will build in this project.

Review the one-line descriptions for each type

AWS gives you a brief description next to each file system type on this page. These one-liners are your first decision signal for the exam.

Read the short description next to each of the four file system types.
Note the mapping: Windows File Server targets SMB workloads, Lustre targets high-performance compute, NetApp ONTAP is feature-rich multi-protocol, and OpenZFS serves Linux-based file server workloads.

What are these descriptions telling me?

Each one-liner maps to a specific workload category. When you see an exam question, the protocol or workload type mentioned in the scenario is your fastest elimination signal.

Windows File Server = SMB protocol, Active Directory, Windows lift-and-shift.
Lustre = POSIX-compliant, Linux-only, extreme throughput (HPC, ML).
NetApp ONTAP = Multi-protocol (NFS + SMB + iSCSI), data tiering, enterprise features.
OpenZFS = NFS protocol, snapshots and clones, Linux file server replacement.

Before you move on, think about this: if a scenario mentions Windows users with Active Directory, which file system type would you eliminate first? What if it mentions Linux HPC nodes?

You should still be on the file system type selection page with all four options visible and no file system created. This is your home base for the next several steps.

You are oriented in the FSx console and can see all four file system types at a glance. Next up, you will dive into the Windows File Server creation wizard and explore the configuration options that map directly to SAA-C03 exam scenarios.

Explore FSx for Windows File Server

You've oriented yourself to the FSx console and confirmed all four file system types. Now it's time to explore the first one in depth.

FSx for Windows File Server is the most commonly tested FSx type on the SAA-C03 exam because it maps directly to enterprise Windows migration scenarios. Understanding its configuration options is essential for recognizing when exam questions point to this service.

In this step, get ready to:

Walk through the entire FSx for Windows File Server creation wizard without provisioning any resources.
Solve a scenario exercise matching a workload to the correct configuration.
Internalize the key exam facts that distinguish this FSx type from the others.

Walk through the Windows File Server creation wizard

The creation wizard exposes every configuration option you would choose when provisioning this file system for a real workload. You will review each option to understand what it controls and how it maps to exam scenarios.

On the file system type selection page, select FSx for Windows File Server and click Next.
On the Create file system page, set Creation method to Standard create.

You now see the full configuration form. Walk through each section below and note what each option means for real workloads and exam scenarios.

Review deployment type and storage options

Find the Deployment type section. Note the two choices:
Multi-AZ deploys a file system that is tolerant to Availability Zone unavailability. It supports both SSD and HDD storage.
Single-AZ deploys in a single Availability Zone. Single-AZ 2 is the latest generation and also supports SSD and HDD storage.
Scroll down to Storage type. Note the two choices:
SSD is designed for the highest-performance and most latency-sensitive workloads, including databases, media processing, and data analytics applications. Minimum capacity: 32 GiB.
HDD is designed for a broad spectrum of workloads, including home directories, user and departmental file shares, and content management systems. Minimum capacity: 2,000 GiB.

What do these deployment types mean for the exam?

When an exam question mentions "highly available file shares" or "tolerant to AZ failure," the answer is Multi-AZ. Multi-AZ provides 99.99% availability.

Single-AZ is cheaper but only provides 99.5-99.9% availability. Use it when cost matters more than cross-AZ resilience.

Scroll down to the Windows authentication section. Notice that you must choose either AWS Managed Microsoft AD or a self-managed Active Directory. There is no option to skip this.
Note the Encryption section showing the default aws/fsx KMS key.
Note the Throughput capacity and backup settings available at the bottom of the form.

Why is Active Directory mandatory?

FSx for Windows File Server uses SMB protocol for file access. SMB relies on Active Directory for authentication and Windows ACLs for authorization. Without AD, Windows-style identity-based access control is impossible.

This is a hard requirement. If an exam question mentions Active Directory integration with file shares, it is pointing directly at FSx for Windows File Server.

Click Cancel to exit the wizard without creating any resources.

You should be back on the FSx dashboard. No file system was created, and no charges were incurred.

Solve the scenario exercise

Exam questions test your ability to match a workload description to the correct configuration. Practice this now with a realistic scenario.

Scenario: Windows home directories for 500 users

A company is migrating its on-premises Windows file server that serves 500 users' home directories. The file server uses SMB shares with NTFS permissions managed through Active Directory. The data is mostly documents and spreadsheets with infrequent large reads. The company needs high availability across AZs.

Which FSx configuration is most appropriate?

Before you read the answer, work through this yourself. Consider: what protocol does the workload need? What storage access pattern fits? What availability requirement is stated?

✔️ I'll give it a go!

Write down your answer including: the FSx type, deployment type, storage type, and AD configuration. When you are ready, switch to the other tab to check your reasoning.

ⓧ Let me check my work

The correct answer is: FSx for Windows File Server, Multi-AZ deployment, HDD storage, integrated with AWS Managed Microsoft AD.

FSx for Windows File Server because the workload uses SMB shares with NTFS permissions and Active Directory. No other FSx type provides native SMB with AD.
Multi-AZ because the scenario explicitly requires high availability across AZs.
HDD because home directories are broad workloads with infrequent large reads. HDD is cost-optimized for this access pattern (SAA-C03 Task 4.1).
AWS Managed Microsoft AD because it integrates the existing Active Directory structure with minimal operational overhead.

Lock in your key exam facts

These are the facts the exam tests most frequently for FSx for Windows File Server. Commit them to memory.

Protocol: SMB 2.0, 2.1, 3.0, 3.1.1 only. No NFS support.
Authentication: Requires Active Directory (AWS Managed Microsoft AD or self-managed AD). This is mandatory, not optional.
Client compatibility: Windows, Linux, and macOS (all via SMB).
Data deduplication: Supported. Saves 30-80% depending on content type (Office docs 30-50%, software binaries 70-80%).
Maximum file system size: 64 TiB.
Multi-AZ availability: 99.99%.
DFS Replication: Only supported on Single-AZ deployments.
Use cases: Windows lift-and-shift, SQL Server storage, home directories, Windows application data.

Exam signal shortcuts

When you see these keywords in a scenario, they point directly to FSx for Windows File Server: "SMB", "Windows ACLs", "Active Directory integration", "NTFS permissions", "Windows lift-and-shift", "home directories with AD."

If a scenario mentions both NFS and SMB access on the same file system, that eliminates Windows File Server entirely. Only NetApp ONTAP supports both protocols natively.

You have now explored every section of the FSx for Windows File Server creation wizard, solved a scenario using cost-optimization reasoning, and internalized the key differentiators the exam tests.

Next up, you will explore FSx for Lustre and discover how it solves a performance problem that no other storage service can match.

Explore FSx for Lustre

Imagine you need to run a machine learning training job on a massive dataset stored in S3. Your Linux cluster needs 10+ GB/s sustained throughput through a file-system interface. S3 alone cannot deliver that. EFS maxes out far below that threshold for this access pattern.

FSx for Lustre exists precisely to close this performance gap. It is a fully managed file system built on the open-source Lustre parallel file system, designed for workloads that demand extreme throughput on Linux-based compute clusters.

In this step, get ready to:

Walk through the FSx for Lustre creation wizard and identify deployment and storage options.
Solve a designed-obstacle scenario where your first instinct falls short.
Internalize key exam facts that differentiate Lustre from other FSx types.

Walk through the Lustre creation wizard

The Lustre creation wizard reveals the deployment and storage choices that drive exam questions about high-performance computing and cost optimization.

Return to the FSx dashboard and click Create file system.
Select Amazon FSx for Lustre and click Next.
On the creation page, look at the Deployment and storage class section.

You should see three choices in the console. Each maps to a different workload pattern and cost profile.

What do these deployment options mean?

Persistent, SSD is for longer-term storage and latency-sensitive workloads. It provides the highest IOPS and throughput. Persistent 2 supports 250, 500, or 1000 MBps per TiB.
Persistent, Intelligent-Tiering is fully elastic storage. You do not need to specify a file system size. It automatically tiers cold data to lower-cost storage for the best price/performance balance.
Scratch, SSD is for temporary, shorter-term processing. Data is NOT replicated. If a file server fails, data is lost. It provides burst throughput up to 6x the baseline of 200 MBps per TiB.

HDD storage is also available for Persistent 1 deployments at 12 or 40 MBps per TiB.

Scroll down to the Data Repository Import/Export section.

This is the S3 integration. When linked to an S3 bucket, Lustre transparently presents S3 objects as files. It supports automatic import and export of changes.

Which deployment types support S3 data repository associations?

Not all Lustre deployment types can link to S3. Scratch 1 file systems and Intelligent-Tiering file systems do NOT support data repository associations with S3. This is a nuance that could appear on the exam.

If a scenario requires both extreme throughput AND deep S3 integration, your options are Scratch 2 or Persistent SSD deployments.

Click Cancel when you have finished reviewing the wizard. Do NOT create the file system.

Don't see the Data Repository section?

Make sure you have scrolled past the networking and encryption sections. The data repository options appear toward the bottom of the creation page.

If you selected Intelligent-Tiering as the deployment type, the S3 data repository section will not appear. Switch to Persistent SSD or Scratch SSD to see it.

Why can't I see the S3 data repository section in the Lustre wizard?

Solve the genomics scenario

Now test your understanding with a scenario that exposes a common wrong instinct. Read the scenario below and decide your answer before scrolling to the solution.

Scenario: Genomics data processing

A genomics research team needs to process 50 TB of sequencing data stored in S3. Their analysis pipeline runs on a Linux HPC cluster and requires 10+ GB/s sustained throughput for 4 hours. After processing, results must be written back to S3.

Which storage service handles this?

What is your first instinct? Think about which service you would pick and why before continuing.

✔️ I've thought about it

Let's see where the common wrong instinct leads.

The wrong instinct: "S3 is already storing the data, just read from S3 directly."

The problem: S3 cannot deliver 10+ GB/s sustained throughput to a file-system-compatible interface. EFS maxes out at much lower throughput for this access pattern. Neither service can serve a Linux HPC cluster that expects POSIX file semantics at this scale.

The correct answer: FSx for Lustre with a Scratch deployment, linked to S3 as a data repository.

Scratch because this is a temporary 4-hour workload. Data does not need to persist on the file system itself.
S3 data repository because Lustre transparently presents S3 objects as files. After processing, results are exported back to S3.
Lustre can deliver up to 1000 GB/s throughput per file system, far exceeding the 10+ GB/s requirement.
Scratch is cost-optimized because data durability is handled by S3, not Lustre. This maps to SAA-C03 Task 4.1.

ⓧ I'm not sure where to start

Use this reasoning process. Ask yourself:

What protocol does the client need? The scenario says "Linux HPC cluster" with sustained throughput. That points to POSIX/Lustre.
Is the data temporary or long-lived? The workload runs for 4 hours. The source data lives in S3 permanently. The file system itself is temporary.
Where does the data come from and go? It starts in S3 and results go back to S3. You need S3 integration.

The answer is FSx for Lustre with a Scratch deployment linked to S3 as a data repository. Scratch is cheapest for temporary workloads because data durability is handled by S3, not the file system. Lustre delivers up to 1000 GB/s throughput per file system.

Why not EFS here?

EFS is a valid choice for many NFS workloads on Linux. But it is not designed for the extreme throughput (10+ GB/s sustained) that HPC and ML training demand. When you see "Linux" plus "hundreds of GB/s" or "HPC" in a scenario, that is your signal for FSx for Lustre, not EFS.

Internalize key exam facts for FSx for Lustre

These facts appear repeatedly in SAA-C03 questions. Review them now and note the exam signals at the bottom.

Protocol: Custom POSIX-compliant protocol. Linux-only clients.
NOT accessible from Windows or macOS directly.
Scratch: Temporary, no replication, cost-optimized for short jobs.
Persistent: Durable, replicated, for long-running workloads.
Deep S3 integration: can present S3 objects as files with automatic import/export.
Maximum throughput: up to 1000 GB/s per file system.
Storage classes: SSD, Intelligent-Tiering, HDD (Persistent 1 only).
Use cases: HPC, ML training, video processing, financial modeling, genomics.

Exam signals that point to Lustre

When you see any of these keywords in a scenario, think FSx for Lustre: "Linux", "HPC", "machine learning training", "high throughput", "process S3 data", "genomics", "financial modeling."

The strongest elimination signal is OS. If the scenario mentions Windows clients at all, Lustre is immediately ruled out.

Before continuing, confirm that you can answer this: if a scenario mentions "Windows clients needing high throughput from S3 data," is Lustre the answer?

No. Lustre is Linux-only. For Windows clients needing high-throughput access to S3 data, you would look at FSx for NetApp ONTAP or a different architecture entirely.

You now have two FSx types locked in. Windows File Server owns the SMB and Active Directory space. Lustre owns extreme-throughput Linux HPC. Next up, you will explore the two remaining types that fill the gaps between them.

Explore FSx for NetApp ONTAP and OpenZFS

You've explored the two most clear-cut FSx types: Windows File Server for SMB workloads and Lustre for Linux HPC. But many real-world scenarios land in murkier territory.

What if a workload needs both NFS and SMB simultaneously? What if a team is migrating an on-premises Linux file server and wants the same snapshot workflow they already rely on? FSx for NetApp ONTAP and FSx for OpenZFS fill exactly these gaps. In this step, you'll walk through both creation wizards to understand their differentiators for exam scenarios where the answer is not obviously Windows or Lustre.

In this step, get ready to:

Walk through the FSx for NetApp ONTAP creation wizard and identify its multi-protocol and data tiering features.
Walk through the FSx for OpenZFS creation wizard and identify its NFS, snapshot, and deployment options.
Match two exam-style scenarios to the correct FSx type using protocol and feature reasoning.

Explore the FSx for NetApp ONTAP creation wizard

NetApp ONTAP is the Swiss Army knife of the FSx family. It is the only FSx type that supports three protocols simultaneously, making it the go-to choice for multi-protocol enterprise workloads.

On the FSx dashboard, click Create file system.
Select Amazon FSx for NetApp ONTAP and click Next.
On the Create file system page, examine the Deployment type section. Note the two options: Single-AZ and Multi-AZ.
Look at the effective storage pricing displayed (US East N. Virginia region): $0.022/GB-month for Single-AZ, $0.042/GB-month for Multi-AZ (with compression and deduplication factored in).
Scroll down and note the SSD storage capacity field. The minimum is 1024 GB. Compare this to Windows File Server's 32 GiB minimum for SSD.
Review the remaining configuration sections: throughput capacity, encryption, and backup settings.
Click Cancel when done. Do NOT create the file system.

What makes ONTAP unique among FSx types?

FSx for NetApp ONTAP is the only FSx type that supports all three storage protocols: NFS (v3, 4.0, 4.1, 4.2), SMB (2.0-3.1.1), and iSCSI (block storage). All three work on the same file system.

It also features automatic data tiering: hot data stays on the SSD tier for high performance, while cold data moves automatically to the Capacity Pool tier for cost optimization. Storage efficiency features like compression, deduplication, and compaction reduce the bytes you actually store.

Scale is virtually unlimited (tens of PBs). SnapMirror supports cross-region disaster recovery directly from on-premises NetApp systems to AWS.

ONTAP exam signals

When you see these keywords in an exam question, think FSx for NetApp ONTAP: "multi-protocol", "iSCSI", "NetApp on-premises migration", "SnapMirror", "cross-region replication", "data tiering", or any scenario needing more than 64 TiB in a single namespace.

Explore the FSx for OpenZFS creation wizard

OpenZFS is the simplest of the four FSx types in terms of protocol support. It speaks NFS only. Its strength is being a managed drop-in replacement for on-premises ZFS or general Linux file servers.

Return to the FSx dashboard and click Create file system.
Select Amazon FSx for OpenZFS and click Next.
Examine the Deployment type section. Note three choices: Multi-AZ (HA), Single-AZ (HA), and Single-AZ (non-HA for dev/test). This is unique among FSx types, which typically offer only two deployment options.
Look at the Storage type options: SSD and Intelligent-Tiering (elastic, auto-tiers data by access frequency with optional SSD read cache).
Review the throughput capacity and data management settings. Note that OpenZFS supports instant snapshots and space-efficient cloning.
Click Cancel when done. Do NOT create the file system.

What makes OpenZFS stand out?

OpenZFS supports NFS only (v3, 4.0, 4.1, 4.2). No native SMB. However, all client operating systems (Linux, Windows, macOS) can connect via NFS.

Its performance profile is the strongest differentiator: sub-0.5 ms latency, which is the lowest of any FSx type. Maximum file system size is 512 TiB.

Failover for Multi-AZ and Single-AZ HA deployments is approximately 60 seconds. The Single-AZ non-HA option recovers in approximately 30 minutes, making it suitable for dev/test environments only.

OpenZFS exam signals

When you see these keywords in an exam question, think FSx for OpenZFS: "on-premises ZFS migration", "Linux file server replacement", "NFS workloads needing snapshots/clones", or "lowest latency".

Test your knowledge with two quick-fire scenarios

Now that you've seen all four FSx wizards, it's time to practice matching real-world scenarios to the right type. Read each scenario below and decide on your answer before revealing the solution.

Scenario A

A company has an on-premises NetApp FAS system. They want to migrate workloads accessed by both Linux (NFS) and Windows (SMB) clients to AWS, maintaining their existing SnapMirror replication and data tiering policies.

Before you reveal the answer: which FSx type fits this scenario, and what are the key signals that led you there?

✔️ I'll give it a go!

Write down your answer and reasoning, then switch to the other tab to check.

ⓧ Maybe a little help...

Answer: FSx for NetApp ONTAP.

The key signals are multi-protocol (NFS + SMB simultaneously), SnapMirror for cross-region DR, and automatic data tiering. This matches their existing NetApp environment exactly. No other FSx type supports all three protocols plus SnapMirror.

Scenario B

A development team runs an on-premises Linux file server using ZFS for their code repositories. They need to migrate to AWS with minimal application changes, requiring NFS access and the ability to take instant snapshots for testing.

Which FSx type fits this scenario? What requirement eliminates ONTAP as the better choice here?

✔️ I'll give it a go!

Write down your answer and reasoning, then switch to the other tab to check.

ⓧ Maybe a little help...

Answer: FSx for OpenZFS.

The key signals are "on-premises ZFS", "minimal application changes", NFS access, and instant snapshots. OpenZFS directly replaces on-premises ZFS with native snapshot and cloning support. ONTAP could handle NFS and snapshots too, but OpenZFS is purpose-built for this exact migration path with lower complexity and sub-0.5 ms latency.

How to distinguish ONTAP from OpenZFS on the exam

Both support NFS and snapshots, which can make them look interchangeable. The tie-breakers are: ONTAP wins when the scenario needs multi-protocol (SMB + NFS), iSCSI, cross-region replication, or massive scale beyond 512 TiB. OpenZFS wins when the scenario is NFS-only, mentions ZFS migration, or emphasizes lowest possible latency.

You've now explored all four FSx creation wizards and can articulate each type's unique value proposition. Next up, you'll combine everything into a rapid-fire decision framework gauntlet that simulates real exam pressure.

Decision Framework Gauntlet

You now know each Amazon FSx type individually. On the exam, that is not enough.

The SAA-C03 tests your ability to rapidly eliminate wrong answers across all four FSx types, EFS, EBS, and S3 simultaneously. This step builds the systematic decision muscle you need under time pressure by giving you a structured framework and then throwing 8 scenario questions at you.

In this step, get ready to:

Internalize a 5-step decision framework for selecting the correct FSx type.
Work through 8 exam-style scenario questions mapped to SAA-C03 Task 3.1 and Task 4.1.
Identify the most common exam traps that cause learners to pick the wrong FSx type.

Internalize the 5-step decision framework

When you see an exam scenario about file storage, you need a repeatable elimination process. The following 5-step framework narrows from the broadest question (is this even file storage?) down to the specific FSx type and configuration.

Write this framework down on paper, a sticky note, or a text file you can reference during the scenarios below.

Here is the framework:

Step A: Does the workload need file storage? If it needs block storage, the answer is EBS. If it needs object storage, the answer is S3. If file storage, continue.
Step B: What protocol does the client need? SMB-only = FSx for Windows File Server. NFS-only with ZFS features = FSx for OpenZFS. NFS + SMB + iSCSI = FSx for NetApp ONTAP. POSIX high-performance Linux = FSx for Lustre.
Step C: What OS are the clients? Windows-only with Active Directory = FSx for Windows File Server. Linux-only HPC = FSx for Lustre. Mixed OS = NetApp ONTAP or OpenZFS.
Step D: What is the performance requirement? Extreme throughput (hundreds of GB/s) = FSx for Lustre. Sub-millisecond NFS latency = FSx for OpenZFS. General enterprise = FSx for Windows or NetApp ONTAP.
Step E: What is the cost optimization angle? Temporary data = Lustre Scratch. Cold data tiering = NetApp ONTAP (automatic) or Lustre Intelligent-Tiering. HDD for broad workloads = FSx for Windows File Server HDD.

How to use this framework under exam pressure

You rarely need all 5 steps. Most exam questions give you a strong signal at Step B (protocol) or Step C (OS) that immediately eliminates 2-3 options. Step D and Step E are tie-breakers when two types survive the first cuts.

The key is elimination, not selection. Cross out what does NOT fit, and the answer reveals itself.

Solve the scenario gauntlet (questions 1-4)

For each scenario below, apply your 5-step framework. Write your answer and reasoning BEFORE checking the solution. Speed matters on the exam, so aim to identify the answer within 30 seconds per question.

Q1: A media company needs to provide 2000 Windows users with personal file storage integrated with their existing Active Directory. Cost must be minimized. Files are mostly documents and media files accessed infrequently.
Q2: A financial services firm runs Monte Carlo simulations on a 500-node Linux cluster. The simulation reads 100 TB of market data from S3, processes it for 2 hours, then writes results back to S3.
Q3: An enterprise is migrating from on-premises NetApp storage. Their workload requires simultaneous NFS and SMB access. They need cross-region disaster recovery using their existing SnapMirror workflows.
Q4: A SaaS company needs highly available file storage for their Linux application servers. They require NFS access, instant snapshots for daily backups, and the lowest possible latency.

Once you have written your answers for all four, check your work below.

✔️ I'll try it first

Work through each scenario using your decision framework. Write your FSx type, deployment type, and storage class for each. Then switch to the other tab to check.

ⓧ Let me check my work

A1: FSx for Windows File Server, Multi-AZ deployment, HDD storage, with data deduplication enabled. Reasoning: SMB + Active Directory = Windows File Server (Step B). 2000 users needing HA = Multi-AZ. Infrequent access to documents = HDD (cost-optimized). Deduplication gives 30-50% savings on media content. Exam domain: Task 4.1.

A2: FSx for Lustre, Scratch deployment, linked to S3 as a data repository. Reasoning: 500-node Linux cluster = Lustre (Step C). 2-hour temporary workload = Scratch (cheapest, data persists in S3 anyway). S3 integration handles the read/write-back. Exam domain: Task 3.1 + 4.1.

A3: FSx for NetApp ONTAP. Reasoning: NFS + SMB simultaneously = ONTAP (Step B, only FSx type with multi-protocol). SnapMirror = ONTAP-specific feature. NetApp migration = direct signal. Exam domain: Task 3.1.

A4: FSx for OpenZFS, Multi-AZ deployment. Reasoning: NFS + instant snapshots = OpenZFS (Step B). Lowest possible latency = OpenZFS at sub-0.5ms (Step D). Highly available = Multi-AZ. Exam domain: Task 3.1.

Solve the scenario gauntlet (questions 5-8)

Q5: A SQL Server Always On Failover Cluster Instance needs shared block storage accessible via iSCSI from multiple Windows EC2 instances.
Q6: A machine learning team iterates on training jobs daily using the same 20 TB dataset in S3. Each training run lasts 8 hours on GPU instances. They want to avoid re-downloading from S3 each time.
Q7: A company wants Windows file shares with DFS Replication support for a single-AZ deployment to replicate data between file servers.
Q8: An enterprise needs a managed file system that can scale beyond 64 TiB and support both NFS and SMB while automatically moving infrequently accessed data to cheaper storage.

Write your answers, then check the solutions below.

✔️ I'll try it first

Apply your decision framework to each scenario. Pay special attention to Steps B and D for these questions. Switch to the other tab when ready.

ⓧ Let me check my work

A5: FSx for NetApp ONTAP. Reasoning: iSCSI = ONTAP (Step B). This is the ONLY FSx type supporting iSCSI for shared block storage. No other option is viable. Exam domain: Task 3.1.

A6: FSx for Lustre, Persistent deployment, linked to S3. Reasoning: ML training on Linux GPUs = Lustre (Step C). Daily reuse of the same dataset = Persistent (the file system caches the data, eliminating repeated S3 downloads). Scratch would require re-downloading every day. Exam domain: Task 4.1.

A7: FSx for Windows File Server, Single-AZ deployment. Reasoning: Windows file shares = Windows File Server (Step B). DFS Replication is ONLY supported on Single-AZ deployments. This is a key nuance. Exam domain: Task 3.1.

A8: FSx for NetApp ONTAP. Reasoning: Beyond 64 TiB = eliminates Windows File Server (max 64 TiB). NFS + SMB = ONTAP (Step B). Automatic data tiering from SSD to Capacity Pool = ONTAP's unique feature for cost optimization. Exam domain: Task 4.1.

Count your correct answers. Before continuing, predict: do you think you scored 6 out of 8 or higher?

What is a passing score here?

If you got 6 or more correct, your framework is solid. If you scored below 6, revisit your wrong answers and trace through the framework to find where your reasoning diverged.

Common exam traps to watch for

These are the mistakes that catch most exam takers:

Confusing FSx for Windows File Server (SMB-only) with NetApp ONTAP (multi-protocol including SMB). If the scenario needs BOTH NFS and SMB, Windows File Server cannot do it.
Selecting EFS when the scenario specifies Windows clients or extreme throughput. EFS is NFS-only and cannot match Lustre's throughput.
Missing that Lustre is Linux-only. It is NOT accessible from Windows or macOS clients directly.
Forgetting that ONTAP is the ONLY FSx type with iSCSI support. Any scenario mentioning iSCSI has exactly one answer.
Not recognizing "ZFS migration" or "Linux file server replacement" as OpenZFS signals.

Scored below 6?

Go back to each wrong answer. Identify which step in the framework (A through E) would have led you to the correct answer. The most common failure point is skipping Step B (protocol) and jumping to Step D (performance). Protocol is the strongest eliminator.

Help me understand where my reasoning is breaking down.

You now have a systematic way to eliminate wrong answers under time pressure. Next up, put your framework to the ultimate test with ambiguous scenarios where two FSx types both look viable.

Secret mission

The Ambiguous Scenarios

Ready for the real exam challenge? These scenarios deliberately make two or more FSx types look viable. Your job is to find the specific requirement that breaks the tie using cost-optimization reasoning or performance nuance.

Clean Up Your Resources

This project runs entirely in the AWS Console with no resources provisioned. There are no ongoing costs because you cancelled every creation wizard before clicking the final create button.

Resources you used:

AWS Management Console (FSx service page). No file systems were created.

Keep everything running

No action needed. Nothing is running and nothing is costing you money.

Your AWS account remains active with no FSx resources.
You can return to the FSx console at any time to re-explore the creation wizards.
Your decision framework notes (if you wrote them down) are yours to keep and review before exam day.

Pause - I'll come back to this later

There is nothing to pause. No resources were provisioned during this project.

No file systems, volumes, or backups exist in your FSx console.
You can sign out of the AWS Console and return whenever you want.

Delete - I don't want to use this again

There is nothing to delete. All four FSx creation wizards were cancelled without provisioning any resources.

Confirm no file systems exist by opening the FSx console and checking the file systems list. It should show zero items.
If you saved decision framework notes locally, delete them if you no longer need them.

Nice Work!

Nice work! You now have a battle-tested decision framework for Amazon FSx that lets you confidently answer any SAA-C03 question about file storage selection, deployment architecture, and cost optimization across all four FSx types.

You've learned how to:

Explore all four FSx creation wizards in the AWS Console and identify the configuration options that map to real workload requirements for FSx for Windows File Server, FSx for Lustre, FSx for NetApp ONTAP, and FSx for OpenZFS.
Build a 5-step decision framework that eliminates wrong answers by protocol, OS compatibility, performance requirement, and cost optimization angle under exam time pressure.
Practice 12+ scenario-based questions mapped to SAA-C03 Task 3.1 (high-performing storage) and Task 4.1 (cost-optimized storage).
Secret Mission: Tackle 4 ambiguous multi-requirement scenarios where two or more FSx types appear viable, using cost-optimization reasoning to break ties between candidates.

Ready to quiz yourself?