storageSAA-C03SAP-C02DOP-C02CLF-C02

Amazon FSx: The Managed File System Powerhouse

Fully managed, high-performance file systems for every workload — Windows, Linux, HPC, and beyond.

Updated 2026-02-21

Overview

Amazon FSx provides fully managed third-party file systems optimized for specific workloads, eliminating the undifferentiated heavy lifting of deploying and maintaining file servers. FSx offers four distinct file system types — FSx for Windows File Server, FSx for Lustre, FSx for NetApp ONTAP, and FSx for OpenZFS — each purpose-built for different performance profiles, protocols, and use cases. It integrates natively with AWS compute, storage, backup, and migration services to support enterprise, HPC, and cloud-native workloads at scale.

Provide enterprise-grade, fully managed shared file storage that replaces on-premises NAS/SAN appliances and supports industry-standard protocols (SMB, NFS, Lustre) without operational overhead.

Use When

Windows workloads requiring SMB shares, Active Directory integration, NTFS permissions, and DFS Namespaces — use FSx for Windows File Server.
High-performance computing (HPC), machine learning training, genomics, or media processing requiring sub-millisecond latency and hundreds of GB/s throughput — use FSx for Lustre.
Lift-and-shift of NetApp ONTAP environments requiring NFS, SMB, iSCSI, SnapMirror, and deduplication — use FSx for NetApp ONTAP.
Workloads needing OpenZFS-compatible NFS storage with instant point-in-time snapshots and data cloning for dev/test environments — use FSx for OpenZFS.

Avoid When

Object storage for unstructured data at massive scale — use Amazon S3 instead; FSx is block/file-level storage, not object storage.
Simple shared file storage for Linux workloads that don't require high performance or specific protocol features — Amazon EFS is simpler, serverless, and auto-scales without capacity planning.
Ephemeral scratch storage attached to a single EC2 instance — use EC2 Instance Store or EBS; FSx is designed for shared, persistent, multi-client access.
Archival or infrequent-access cold storage — use S3 Glacier or S3 Intelligent-Tiering; FSx is optimized for active workloads, not archival.

Key Features

FSx for Windows File Server

SMB protocol, Active Directory integration, NTFS, DFS Namespaces, shadow copies, Multi-AZ HA

FSx for Lustre

Sub-millisecond latency, native S3 integration, Scratch (temporary) and Persistent deployment types

FSx for NetApp ONTAP

Multi-protocol (NFS/SMB/iSCSI), SnapMirror replication, storage efficiency, FlexClone, Multi-AZ

FSx for OpenZFS

NFS v3/v4/v4.1/v4.2, instant snapshots, data cloning, up to 1 million IOPS

Automated Daily Backups

Enabled by default (7-day retention), stored in S3 (managed by AWS, not visible to you)

AWS Backup Integration

Centralized backup management, cross-Region and cross-account backup copies

Multi-AZ High Availability

Available for FSx for Windows File Server and FSx for NetApp ONTAP only

In-Transit Encryption

SMB encryption for Windows; Lustre uses in-transit encryption via VPN or Direct Connect

At-Rest Encryption

All FSx file systems encrypt data at rest using AWS KMS-managed keys

S3 Native Integration (Lustre)

FSx for Lustre can link to an S3 bucket as a data repository; lazy-loads data on first access

AWS DataSync Integration

Used for one-time or scheduled data migration to/from FSx — not a backup solution

Amazon Route 53 Integration

DNS failover for Multi-AZ FSx for Windows File Server; clients reconnect automatically after failover

VPC-only Access

FSx is not publicly accessible; accessed within VPC via ENIs, VPN, or Direct Connect

Storage Scaling (Online)

Storage capacity can be increased (not decreased) without downtime for all FSx types

Throughput Scaling (Online)

Throughput capacity can be modified for Windows and ONTAP file systems

CloudWatch Metrics

Storage capacity, throughput, IOPS, and latency metrics available natively

AWS IAM Access Control

IAM controls API access; file-level permissions use NTFS (Windows) or POSIX (Lustre/ONTAP/OpenZFS)

Integration Patterns

S3-Linked High-Performance Data Repository

high freq

Amazon FSx for LustreAmazon S3

Link FSx for Lustre to an S3 bucket as a data repository. Files are lazy-loaded on first access from S3 into Lustre's high-speed file system. After processing, results can be exported back to S3. Ideal for ML training, genomics, and media workflows where data lives in S3 but must be processed at high speed.

Centralized Backup and Cross-Region DR

high freq

Amazon FSxAWS Backup

Use AWS Backup to centrally manage FSx backup schedules, retention policies, and cross-Region/cross-account backup copies. This is the correct pattern for DR — not DataSync. AWS Backup provides a single pane of glass across all FSx types and other AWS services.

On-Premises to FSx Migration

high freq

Amazon FSx for Windows File ServerAWS DataSync

Use AWS DataSync to migrate data from on-premises Windows file servers or NAS appliances to FSx for Windows File Server. DataSync handles scheduling, bandwidth throttling, data validation, and incremental transfers. This is a migration pattern, not a backup/DR pattern.

Multi-AZ Automatic DNS Failover

high freq

Amazon FSx for Windows File ServerAmazon Route 53

In a Multi-AZ FSx for Windows File Server deployment, Route 53 DNS automatically updates to point to the standby file server's IP after failover. Clients using the DNS name reconnect transparently. This provides HA within a Region but does NOT protect against Region-level failures.

Protocol-Based File Storage Selection

high freq

Amazon FSxAmazon EFS

Choose FSx for Windows File Server when SMB, Active Directory, and NTFS are required. Choose EFS for simple, serverless NFS shared storage for Linux workloads. EFS auto-scales and requires no capacity planning; FSx requires provisioned capacity but offers richer protocol and performance options.

NetApp On-Premises to Cloud Migration with SnapMirror

medium freq

Amazon FSx for NetApp ONTAPAWS DataSync

Migrate on-premises NetApp ONTAP data to FSx for NetApp ONTAP using SnapMirror (native NetApp replication) for initial seeding, then use DataSync for final cutover or ongoing sync. This is the recommended lift-and-shift pattern for NetApp environments.

HPC Cluster Shared Scratch Storage

medium freq

Amazon FSx for LustreAmazon EC2AWS ParallelCluster

Deploy FSx for Lustre (Scratch_2) as shared high-speed storage for HPC clusters managed by AWS ParallelCluster. All compute nodes access the same Lustre file system simultaneously. After computation, export results to S3. Scratch_2 is cost-optimized for burst HPC jobs.

Service Limits & Quotas

LimitValueNote

FSx for Windows File Server — Minimum storage capacity (SSD)

32 GiB GiB

HDD minimum is 2,000 GiB — significantly higher than SSD minimum.

FSx for Windows File Server — Maximum storage capacity

65,536 GiB (64 TiB) GiB

Candidates confuse the per-file-system limit with total addressable storage when DFS is used.

FSx for Windows File Server — Minimum throughput capacity

8 MBps MBps

Throughput capacity is independently configurable from storage capacity — a key differentiator from EFS.

FSx for Windows File Server — Maximum throughput capacity

2,048 MBps MBps

For extreme throughput beyond this, consider FSx for Lustre which can reach hundreds of GB/s.

FSx for Lustre — Minimum storage capacity (Persistent SSD)

1,200 GiB GiB

Scratch file systems also start at 1,200 GiB but have no data replication within AZ — critical distinction.

FSx for Lustre — Scratch file system data persistence

Temporary; data is not replicated and does not persist if the file system fails N/A

Scratch_2 has higher burst throughput than Scratch_1 — both are non-persistent but differ in performance.

FSx for NetApp ONTAP — Minimum SSD storage capacity

1,024 GiB GiB

ONTAP supports storage efficiency features (deduplication, compression, compaction) that can dramatically reduce effective capacity consumed.

FSx for NetApp ONTAP — Supported protocols

NFS (v3, v4, v4.1), SMB, iSCSI N/A

FSx for Windows supports SMB only. FSx for Lustre supports Lustre protocol only. Only ONTAP is truly multi-protocol.

FSx for OpenZFS — Minimum storage capacity

64 GiB GiB

OpenZFS is the go-to for NFS workloads needing instant snapshots and data cloning — commonly tested in dev/test scenarios.

FSx for Windows — Automated backup retention period

0–90 days days

Candidates assume automated backups are weekly — they are DAILY. This is a top misconception on exams.

FSx Multi-AZ deployment — Availability

Single-AZ and Multi-AZ options available (Windows File Server and ONTAP) N/A

FSx for Lustre and FSx for OpenZFS are Single-AZ only. Only Windows and ONTAP support Multi-AZ.

FSx cross-Region backup copies

Supported via AWS Backup cross-Region copy N/A

DataSync is for data migration/sync, not backup replication. Cross-Region backup copies require AWS Backup.

Pricing Model

Pay for what you provision (storage capacity, throughput capacity, IOPS, backups)

Billed per GiB-month of provisioned storage — unlike EFS which bills per GiB-stored (consumed), FSx requires capacity planning and upfront provisioning.
Throughput capacity (MBps) is billed separately from storage for FSx for Windows File Server — you can tune performance independently of storage size.
FSx for Lustre Scratch file systems cost less per GiB-month than Persistent — the trade-off is no data replication and no HA.
Automated backups are stored in S3 and billed per GiB-month of backup storage — incremental after first backup, so ongoing cost is typically low.
Multi-AZ deployments cost more than Single-AZ due to the standby file server — factor this into HA design decisions.
FSx for NetApp ONTAP charges for SSD storage, SSD IOPS, throughput capacity, and capacity pool (tiered) storage separately.
Data transfer costs apply when accessing FSx from outside the VPC (e.g., via VPN or Direct Connect) or across AZs.

Exam Tips

criticalHigh Availability vs. Disaster Recovery

Multi-AZ FSx (Windows/ONTAP) provides HIGH AVAILABILITY within a single Region via automatic failover to a standby — it does NOT provide cross-Region disaster recovery. For DR, you need cross-Region backup copies via AWS Backup.

criticalRPO and Backup Frequency

FSx automated backups are DAILY (not weekly, not user-initiated) and are enabled by default with a 7-day retention period. When a question asks about the minimum RPO achievable with built-in backup features, the answer is ~24 hours (daily backup), not weekly.

criticalDataSync vs. AWS Backup

Use AWS DataSync for DATA MIGRATION to/from FSx — not for backup replication or DR. If a question asks how to replicate FSx backups to another Region for DR, the answer is AWS Backup cross-Region copy, not DataSync.

criticalFSx for Lustre Deployment Types

FSx for Lustre has TWO deployment types: Scratch (non-persistent, no replication, temporary HPC jobs) and Persistent (replicated within AZ, long-running workloads). If a question mentions 'HPC job that finishes in hours and data can be regenerated,' choose Scratch. If it mentions 'ongoing workload requiring durability,' choose Persistent.

criticalMulti-AZ Support by FSx Type

Only FSx for Windows File Server and FSx for NetApp ONTAP support Multi-AZ deployments. FSx for Lustre and FSx for OpenZFS are Single-AZ ONLY. If a question requires Multi-AZ HA for a Linux NFS workload, ONTAP is the answer, not Lustre.

critical

Multi-AZ FSx = HA within ONE Region (AZ failover). Cross-Region DR requires AWS Backup cross-Region copy. Never confuse these two — it's the #1 FSx trap.

critical

FSx automated backups are DAILY by default (not weekly, not manual). Minimum RPO with built-in backups is ~24 hours. For sub-24hr RPO, use Multi-AZ or application-level replication.

critical

DataSync = migrate/sync live file data. AWS Backup = backup replication and cross-Region DR copies. If the question is about DR backup strategy, choose AWS Backup — not DataSync.

importantMulti-Protocol Access

FSx for NetApp ONTAP is the ONLY FSx type that supports multi-protocol access (NFS + SMB + iSCSI simultaneously). If a question involves both Windows and Linux clients accessing the same file system, FSx for ONTAP is the answer.

importantFSx for Lustre S3 Integration

FSx for Lustre natively integrates with S3 as a data repository — files are lazy-loaded from S3 on first access. This is the canonical pattern for ML training data pipelines. If a question asks for the fastest way to process S3 data with HPC-level throughput, FSx for Lustre + S3 data repository is the answer.

importantEFS vs. FSx Decision Framework

EFS vs. FSx for Windows: EFS is NFS-only, Linux-only, serverless, and auto-scales. FSx for Windows is SMB-only, Windows-centric, requires capacity provisioning, and supports Active Directory. Never choose EFS for Windows workloads or SMB protocol requirements.

importantStorage Scaling Limitations

FSx storage capacity can only be INCREASED, never decreased. Plan capacity carefully — you cannot shrink a file system after creation. This is a common trap in cost-optimization questions.

Good to KnowNetwork Access Model

All FSx file systems are VPC-only — they are never publicly accessible. Access from on-premises requires AWS VPN or AWS Direct Connect. If a question asks about on-premises access to FSx, VPN or Direct Connect must be part of the architecture.

Common Misconceptions & Traps

Common Mistake

Multi-AZ FSx for Windows File Server protects against Region failures and provides disaster recovery.

Correct

Multi-AZ FSx provides HIGH AVAILABILITY within a single Region by maintaining a standby file server in a different Availability Zone with automatic failover. It does NOT protect against Region-level failures. True cross-Region DR requires cross-Region backup copies using AWS Backup.

This is the #1 FSx misconception on certification exams. Candidates see 'Multi-AZ' and assume it means cross-Region resilience (as they might think of Route 53 multi-region routing). Remember: Multi-AZ = same Region, different AZs = HA. Cross-Region = different Regions = DR. Always ask: 'Is the question asking for HA or DR?'

Common Mistake

To replicate FSx backups to another Region for disaster recovery, you should use AWS DataSync.

Correct

AWS DataSync is a data migration and transfer service — it moves live file data, not backups. For cross-Region backup copies of FSx file systems, use AWS Backup's cross-Region copy feature. DataSync is the right tool when you need to migrate or sync actual file data; AWS Backup is the right tool for backup replication and DR.

DataSync and AWS Backup are both commonly tested in FSx questions, and their roles are frequently confused. Memory trick: DataSync = 'Sync Data' (live files, migration). AWS Backup = 'Back it Up' (backup copies, retention, DR). If the question mentions RPO, retention, or DR, think AWS Backup. If it mentions migration, cutover, or data transfer, think DataSync.

Common Mistake

FSx automated backups happen weekly or must be manually triggered, so the minimum RPO for backup-based recovery is 7 days.

Correct

FSx automated backups are taken DAILY by default (not weekly) with a configurable retention period of 0–90 days. The minimum RPO achievable with automated backups alone is approximately 24 hours. For RPO requirements shorter than 24 hours, you need application-level replication or Multi-AZ HA (which provides near-zero RPO for AZ failures).

Exam questions frequently test whether candidates know the backup frequency. The trap is assuming backups are weekly (like some on-premises backup schedules) or that only user-initiated backups exist. Remember: FSx automated backups = daily, enabled by default, 7-day retention default.

Common Mistake

Amazon EFS can replace FSx for Windows File Server for Windows workloads because both are managed file storage services.

Correct

EFS only supports NFS protocol and is designed for Linux/POSIX workloads. It does NOT support SMB protocol, Active Directory integration, NTFS permissions, or Windows-specific features like DFS Namespaces and shadow copies. For Windows workloads, FSx for Windows File Server is the only managed AWS file storage option.

Both EFS and FSx appear in the same 'managed file storage' category, leading candidates to treat them as interchangeable. The decision is protocol-based: SMB/Windows = FSx for Windows. NFS/Linux (simple, auto-scale) = EFS. NFS/Linux (high performance, NetApp features) = FSx for ONTAP or OpenZFS.

Common Mistake

FSx for Lustre Scratch file systems replicate data within the AZ, so data is safe if individual storage components fail.

Correct

FSx for Lustre Scratch file systems do NOT replicate data. They are designed for temporary, short-lived HPC workloads where data can be regenerated or is sourced from S3. If the file system fails, data is lost. Only FSx for Lustre Persistent file systems replicate data within the AZ. Use Scratch only when data loss is acceptable.

The word 'Scratch' implies temporary, but candidates sometimes assume all AWS managed services provide implicit data durability. They don't. Scratch = no replication = data loss risk. If durability matters, use Persistent deployment type or link to S3 as the authoritative data source.

Common Mistake

Storing FSx backups only in the primary Region is sufficient for disaster recovery because AWS manages the backup infrastructure.

Correct

Backups stored only in the primary Region are lost or inaccessible if that Region experiences an outage. For true DR, FSx backups must be copied to a secondary Region using AWS Backup cross-Region copy. AWS managing the backup infrastructure does not make it cross-Region by default.

Candidates trust AWS's managed infrastructure and assume regional redundancy is built-in. It is not for backups. You must explicitly configure cross-Region backup copies. The exam tests whether you know the difference between 'AWS manages it' (operational) and 'regionally resilient by default' (it is not).

Memory Tricks

🧠

FSx Four Flavors: 'Windows Loves NetApp's OpenZFS' → Windows File Server, Lustre, NetApp ONTAP, OpenZFS

🧠

Multi-AZ = Same Region HA. Cross-Region = DR. 'AZ = Availability Zone (same city). Region = different country (DR).'

🧠

DataSync = Data Sync (move live data). AWS Backup = Back it Up (protect backups). Never swap them.

🧠

Lustre Scratch = Scratch paper (throw it away). Lustre Persistent = Permanent marker (it stays).

🧠

FSx storage: UP only, never DOWN. 'You can always add a room to a house, but you can't remove the foundation.'

CertAI Tutor · SAA-C03, SAP-C02, DOP-C02, CLF-C02 · 2026-02-21

Ready to test your knowledge?

Practice SAA-C03, SAP-C02, DOP-C02, CLF-C02 exam questions with AI-powered explanations — free to start.

Amazon FSx: The Managed File System Powerhouse

Overview

Key Features

Integration Patterns

Service Limits & Quotas

Pricing Model

Exam Tips

Common Misconceptions & Traps

Memory Tricks

Ready to test your knowledge?

Related Cheat Sheets