EBS vs EFS vs FSx
Block storage for a single instance, shared file storage for many, and specialized file systems for Windows or high-performance computing.
Want a visual for this topic?
Generate a diagram tailored to EBS vs EFS vs FSx — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Explain the difference between block, file, and object storage
- •Choose between EBS, EFS, and FSx for a given workload
- •Explain EBS volume types and when to use each
- •Explain why EFS supports concurrent access from many instances but EBS generally does not
What is it?
EBS (Elastic Block Store), EFS (Elastic File System), and FSx are AWS's three non-object storage services, each solving a different access pattern: EBS provides raw block storage attached to a single EC2 instance (like a virtual hard drive), EFS provides a shared file system that many instances can mount and access concurrently, and FSx provides fully managed, purpose-built file systems (Windows File Server, Lustre, NetApp ONTAP, OpenZFS) for workloads with specific compatibility or performance needs.
Why it exists
Different workloads need fundamentally different storage access patterns. A database needs fast, low-latency block-level access from exactly one instance at a time (EBS). A content management system running on multiple web servers needs all of them to see the same shared files simultaneously (EFS). A Windows application expecting SMB file shares, or an HPC workload needing extremely high-throughput parallel file access, needs storage that speaks their specific protocol natively (FSx). One storage type can't optimally serve all of these.
Problem it solves
EBS solves the need for persistent, low-latency block storage tied to a single instance (surviving instance stop/start, unlike instance store). EFS solves the need for multiple instances to read and write the same files concurrently without building your own shared-storage solution. FSx solves the need for storage that's protocol-compatible with existing Windows or HPC software without re-architecting the application.
Intuition
EBS is like a personal external hard drive plugged into one specific computer — fast and simple, but only that one computer can use it at a time (in the normal case). EFS is like a shared network drive in an office that everyone's computer can access simultaneously, seeing the same files in real time. FSx is like ordering a specialized filing cabinet built exactly to the specifications your particular industry's existing tools already expect, so nothing needs to change on the application side.
Analogy
A restaurant kitchen: EBS is like a chef's personal knife set, dedicated to one station. EFS is like the shared walk-in refrigerator every station can open and use at the same time. FSx is like bringing in specialized equipment (a particular brand of espresso machine) because the barista's existing training and recipes are already built around that exact equipment's interface.
Technical explanation
EBS volumes are Availability-Zone-scoped block devices attached over the network (even though they behave like a local disk to the OS) — a volume must be in the same AZ as the instance it's attached to, and by default only one instance can attach to a volume at a time (EBS Multi-Attach is a specific, limited exception for io1/io2 volumes with cluster-aware file systems). EFS is a fully managed NFS (Network File System) service that scales storage capacity elastically and can be mounted concurrently by thousands of EC2 instances (and on-premises servers via Direct Connect/VPN) across multiple AZs simultaneously, with no pre-provisioned capacity needed. FSx offers several purpose-built variants: FSx for Windows File Server (native SMB protocol, Active Directory integration), FSx for Lustre (extremely high-throughput parallel file system for HPC/machine learning workloads, can integrate directly with S3 as its data repository), FSx for NetApp ONTAP and FSx for OpenZFS (for specific enterprise storage feature compatibility like snapshots, cloning, and deduplication matching those specific platforms).
Architecture
A typical web application uses EBS volumes as the root and data volumes for individual EC2 instances (e.g. a database server's data directory), EFS for shared assets that multiple web server instances in an Auto Scaling Group all need to read/write (e.g. user-uploaded content processed by any instance, or shared application configuration), and FSx only when a specific compatibility requirement exists (e.g. migrating a legacy Windows application that expects an SMB file share, or an ML training pipeline needing Lustre's extreme throughput).
Workflow
- Default to EBS for any single-instance workload needing persistent block storage (most databases, most application root volumes). 2) Reach for EFS when multiple instances genuinely need to see and modify the same files concurrently. 3) Reach for FSx only when there's a specific protocol or compatibility requirement (Windows SMB, Lustre's parallel HPC performance, or ONTAP/OpenZFS feature parity) that EBS or EFS can't satisfy. 4) For EBS specifically, choose the volume type based on the workload's IOPS/throughput profile.
Example
An e-commerce platform runs its PostgreSQL database on EC2 with a gp3 EBS volume for fast, consistent block storage (only the database instance needs it). Its web application tier (multiple EC2 instances in an Auto Scaling Group) all mount the same EFS file system to share uploaded product images so any instance can serve any image regardless of which instance originally received the upload. A separate ML team training image-recognition models on a large dataset uses FSx for Lustre, linked directly to an S3 bucket holding the training data, for the extreme read throughput their training jobs need.
Real-world usage
EBS underlies the vast majority of EC2-attached storage across AWS, being the default choice for anything from small web app root volumes to large database data volumes; EFS is commonly used for WordPress/CMS shared media across multiple web servers and for Lambda functions needing shared, persistent file access; FSx for Lustre is documented by AWS as the standard choice for machine learning training pipelines and HPC workloads needing to read massive datasets at very high throughput directly from S3-backed storage.
Trade-offs
EBS versus EFS is fundamentally a single-instance-low-latency versus multi-instance-shared-access tradeoff — you generally cannot substitute one for the other's core use case without real architectural cost. FSx trades the simplicity and lower cost of EBS/EFS for protocol-level compatibility or extreme specialized performance, which is only worth it when that specific compatibility or performance need genuinely exists; reaching for FSx without that requirement adds unjustified cost and complexity.
Visual explanation
Picture three diagrams. EBS: one EC2 instance icon with a single disk icon attached by a solid line — only that instance connects to that volume (with a narrow exception for EBS Multi-Attach on specific volume types). EFS: multiple EC2 instance icons all connected to one central file-system icon, all reading and writing simultaneously. FSx: a similar multi-instance-to-shared-storage diagram, but labeled with a specific protocol (SMB for Windows File Server, a parallel file system protocol for Lustre) instead of the generic NFS that EFS uses.
Advantages
- —
EBS offers the lowest latency and highest IOPS of the three, ideal for databases and other latency-sensitive single-instance workloads
- —
EFS scales storage capacity automatically with no pre-provisioning, and supports thousands of concurrent connections across AZs
- —
FSx provides native protocol compatibility, letting you lift-and-shift Windows or HPC workloads without re-architecting their storage layer
- —
All three integrate with AWS Backup for centralized, automated backup management
Disadvantages
- —
EBS volumes are AZ-locked and generally single-attach, meaning they can't directly serve a multi-instance shared-access need without extra architecture
- —
EFS has higher per-operation latency than EBS, making it a poor fit for latency-critical database storage despite supporting concurrent access
- —
FSx variants add real cost and operational complexity beyond EBS/EFS, and are genuinely only justified by a specific compatibility or performance requirement
- —
Choosing the wrong one for a workload (e.g. EFS for a high-IOPS database) causes real, sometimes hard-to-diagnose performance problems
Common mistakes
- —
Attempting to attach one EBS volume to multiple instances for shared access without using EBS Multi-Attach's specific, limited support (which requires a cluster-aware file system) — normal EBS volumes don't support this and this will simply fail or corrupt data
- —
Using EFS for a database's primary data storage, hitting unexpected latency and IOPS ceilings compared to what EBS would have provided for that exact same workload
- —
Provisioning FSx when EBS or EFS would have served the actual requirement, adding unnecessary cost and operational surface
- —
Not choosing an EBS volume type matched to the actual IOPS/throughput need — e.g. using a low-performance volume type for a high-transaction database and being surprised by poor performance
- —
Forgetting that an EBS volume and the EC2 instance it's attached to must be in the same Availability Zone — a common source of 'why can't I attach this volume' confusion
In the AWS Console
- 1
AWS Console → EC2 → Elastic Block Store → Volumes → Create volume
Choose a volume type (gp3 is the modern general-purpose default), size, and the same Availability Zone as the instance you'll attach it to.
The volume's AZ must exactly match the target instance's AZ — this is a common source of 'volume not showing as attachable' confusion.
- 2
EC2 → Volumes → select volume → Actions → Attach volume
Select the target instance and confirm the device name, then format and mount the volume from within the instance's operating system.
A newly created EBS volume is raw/unformatted — you must format it with a file system (e.g. ext4, xfs) and mount it before the OS can use it, same as a brand-new physical disk.
- 3
AWS Console → EFS → File systems → Create file system
Choose the VPC, and confirm mount targets are created automatically in each AZ's subnet you select.
You need a mount target in every AZ where you have instances that will mount this file system — a missing mount target in one AZ means instances there can't connect.
- 4
AWS Console → FSx → Create file system
Choose the file system type (Windows File Server, Lustre, ONTAP, or OpenZFS) matching your specific compatibility need, and configure storage capacity and throughput.
Only reach for this screen after confirming EBS or EFS genuinely can't meet a specific protocol or performance requirement — it's the more expensive, more specialized option of the three.
🎤 Interview questions
What's the fundamental difference between EBS and EFS in terms of how many instances can use them at once? (Listen for: EBS is generally single-instance-attach (with a narrow Multi-Attach exception); EFS supports thousands of concurrent connections across many instances and AZs.)
Why wouldn't you put a high-transaction database's data files on EFS? (Listen for: EFS has higher per-operation latency than EBS; a database needing low-latency, high-IOPS block access is better served by EBS.)
When would you reach for FSx instead of EBS or EFS? (Listen for: a specific protocol compatibility need like SMB for Windows applications, or a specialized performance need like Lustre's parallel throughput for HPC/ML training.)
Why must an EBS volume be in the same Availability Zone as the instance it's attached to? (Listen for: EBS is AZ-scoped, network-attached block storage; cross-AZ attachment isn't supported due to the latency and architecture of how EBS works within an AZ.)
Describe a scenario where you'd use all three — EBS, EFS, and FSx — in the same architecture. (Listen for: EBS for a database's data volume, EFS for shared files across a web server fleet, FSx for a specific Windows or HPC compatibility need — showing understanding that they solve different problems, not competing options for the same problem.)