AWS Services
EBS vs EFS vs FSx Edge Cases
Compare Amazon EBS, Amazon EFS, and Amazon FSx edge cases including Multi-Attach, shared file access, Windows file shares, Lustre workloads, NFS, performance modes, and exam traps.
After this, you will understand
Storage edge cases become manageable once learners stop saying shared disk and ask what file protocol, operating system, performance profile, and attachment model the workload needs.
Use EBS for EC2 block storage, EFS for shared Linux NFS file systems, and FSx when you need a managed specialized file system such as Windows File Server or Lustre.
Learners use EBS Multi-Attach as a generic shared filesystem, use EFS for Windows SMB requirements, or miss FSx for high-performance Lustre and Windows workloads.
Check whether the workload needs block device semantics, shared POSIX-style files, Windows SMB, high-performance Lustre, or specialized enterprise file-system behavior.
Think before readingWhy is EBS Multi-Attach not the default answer for shared files?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- EBS block storage
- EBS Multi-Attach
- EFS shared NFS
- EFS Regional and One Zone
- FSx file systems
- Windows SMB shares
- Lustre high-performance file system
- POSIX file workloads
- Attachment and protocol traps
- SAA-C03 storage edge cases
1. Plain-English Mental Model
EBS, EFS, and FSx are all storage services, but they sit at different layers.
EBS = block volume attached to EC2
EFS = managed elastic NFS file system for Linux-style shared files
FSx = managed specialized file systems such as Windows File Server, Lustre, NetApp ONTAP, and OpenZFS
The edge cases matter because exam questions often sound like "shared storage" and then include one decisive clue: Windows, NFS, Lustre, same Availability Zone, high-performance scratch, or concurrent write control.
2. Why This Service Exists
Applications need different storage interfaces.
A database on EC2 often wants a block device. EBS fits that.
Multiple Linux instances or Lambda functions may need a shared POSIX-style file system. EFS fits that.
A Windows application may expect SMB and Active Directory integration. FSx for Windows File Server fits that.
An HPC or machine learning workload may need a high-performance parallel file system integrated with S3. FSx for Lustre fits that.
The edge-case comparison exists because "shared storage" is not one requirement.
3. The Naive Approach And Where It Breaks
The naive approach is to use EBS for every disk-like need.
That breaks when multiple instances need safe shared file access. EBS is normally attached to one EC2 instance in one Availability Zone.
Another naive approach is to see EBS Multi-Attach and assume it replaces EFS. Multi-Attach is a specialized block-storage capability for certain Provisioned IOPS SSD volumes and Nitro instances in the same AZ. Applications must coordinate concurrent writes safely.
Another mistake is choosing EFS for a Windows file share requirement. EFS is NFS. Windows SMB file shares point toward FSx for Windows File Server.
4. Core Primitives
EBS primitives are volumes, volume types, snapshots, provisioned IOPS, throughput, encryption, attachment, and Availability Zone placement.
EBS Multi-Attach lets supported io1 or io2 volumes attach to multiple Nitro-based instances in the same Availability Zone, with important limitations.
EFS primitives are file systems, mount targets, access points, NFS clients, throughput modes, performance modes, storage classes, Regional file systems, and One Zone file systems.
FSx primitives depend on the file system type: Windows File Server, Lustre, NetApp ONTAP, or OpenZFS. Each type brings its own protocol, performance, and management model.
5. Architecture Use Cases
Use EBS for EC2 boot volumes, single-instance application disks, databases on EC2, and workloads needing block-device performance.
Use EFS for shared Linux application files, shared home directories, container shared storage, serverless shared file access, and NFS lift-and-shift workloads.
Use FSx for Windows File Server when Windows applications require SMB shares, Windows ACLs, and Active Directory integration.
Use FSx for Lustre for high-performance compute, machine learning, media processing, and workloads that need fast file access with optional S3 integration.
Use FSx for NetApp ONTAP or OpenZFS when those enterprise file-system features are explicit requirements.
7. Security Model
EBS security is controlled through EC2 attachment, IAM permissions for volume and snapshot APIs, encryption with KMS, and instance-level access.
EFS security uses security groups on mount targets, NFS permissions, access points, IAM authorization where configured, and encryption in transit and at rest.
FSx security depends on the file system. Windows File Server commonly involves Active Directory, SMB permissions, security groups, and encryption. Other FSx types have their own access models.
Protect snapshots and backups. A storage snapshot can become a data-exfiltration path if shared or copied too broadly.
KMS key policies matter when encrypted storage is copied, restored, or accessed across accounts.
8. Reliability And Resilience
EBS volumes are replicated within one Availability Zone and attach to instances in that same AZ. Snapshots can protect and move data across AZs or Regions through restore workflows.
EFS Regional file systems are designed for multi-AZ access through mount targets. EFS One Zone trades multi-AZ resilience for cost and AZ placement.
FSx resilience depends on file system type and deployment option. Read the workload requirement: single-AZ, multi-AZ, scratch, persistent, Windows, Lustre, or enterprise file system.
EBS Multi-Attach does not remove the AZ boundary. It also does not automatically make application writes safe.
Use AWS Backup where supported and test restores.
9. Performance And Scaling
EBS performance is shaped by volume type, IOPS, throughput, instance limits, and file system behavior.
EFS performance is shaped by throughput mode, performance mode, client behavior, file size, metadata operations, and Regional versus One Zone placement.
FSx performance is intentionally specialized. FSx for Lustre is often selected for high-performance parallel file access. FSx for Windows File Server is selected for Windows file serving semantics, not generic object storage.
Multi-Attach performance is aggregate across attached instances. Application-level coordination remains your responsibility.
Do not benchmark storage only by peak throughput. Check latency, protocol, concurrency, metadata operations, and recovery behavior.
10. Cost Model
EBS cost depends on provisioned storage, volume type, provisioned IOPS or throughput, snapshots, and data transfer patterns.
EFS cost depends on stored data, storage classes, throughput mode, and access pattern. It can be expensive if used casually for object-style data.
FSx cost depends heavily on file system type, deployment model, capacity, throughput, backups, and storage tier.
The cost trap is choosing a convenient shared file system for data that belongs in S3, or choosing EC2/EBS operations for a managed file-system requirement.
Use lifecycle, backup, and right-sizing controls.
12. SAA-C03 Exam Signals
"Block storage attached to one EC2 instance" points to EBS.
"Shared Linux NFS file system" points to EFS.
"Windows file share or SMB" points to FSx for Windows File Server.
"High-performance Lustre file system" points to FSx for Lustre.
"Attach one volume to multiple instances in same AZ with app-managed writes" can point to EBS Multi-Attach.
"Shared file access across multiple AZs" usually points to EFS Regional or an appropriate FSx deployment, not normal EBS.
"Temporary local disk" points to instance store, not EBS/EFS/FSx.
13. Common Exam Traps
Do not use EBS Multi-Attach as the generic shared file-system answer.
Do not choose EFS for SMB Windows file shares.
Do not choose FSx just because the word file appears. Check which file system is required.
Do not forget EBS is Availability Zone scoped.
Do not treat snapshots as live shared storage.
Do not use EFS when object storage in S3 is the simpler fit.
15. Related Topics
Review S3 vs EBS vs EFS vs Instance Store, Amazon EFS, Amazon FSx, Amazon EC2, and AWS Backup.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.