3.4 Block and File Storage - EBS, EFS, and FSx
Key Takeaways
- EBS is single-AZ block storage attached to one EC2 instance (io2/io2 Block Express support Multi-Attach to up to 16 instances in the same AZ).
- gp3 baselines at 3,000 IOPS / 125 MB/s independent of size and can be provisioned up to 80,000 IOPS and 2,000 MB/s; io2 Block Express reaches 256,000 IOPS and 4,000 MB/s for the largest databases.
- EFS is fully managed NFS shared across thousands of Linux instances and multiple AZs; FSx for Windows is SMB with Active Directory.
- FSx for Lustre is a parallel POSIX file system for HPC/ML that integrates natively with S3 (read from and write back to a linked bucket).
- Pick by protocol and sharing: single instance block -> EBS; shared Linux NFS -> EFS; Windows SMB -> FSx for Windows; HPC/ML scratch -> FSx for Lustre.
Quick Answer: EBS = single-AZ block volume for one instance. EFS = elastic shared NFS for many Linux instances across AZs. FSx for Windows = managed SMB with Active Directory. FSx for Lustre = high-throughput parallel file system for HPC/ML with native S3 integration. Choose on protocol, sharing scope, and performance target.
Amazon EBS (Elastic Block Store)
EBS volumes are network-attached virtual disks bound to a single Availability Zone. They persist independently of the instance lifecycle, support encryption with KMS (no measurable performance hit), and back up via incremental snapshots stored in S3 (which can be copied cross-Region for DR).
| Volume type | API name | Max IOPS | Max throughput | Use case |
|---|---|---|---|---|
| General Purpose SSD | gp3 | 80,000 | 2,000 MB/s | Default for most workloads, boot, mid DBs |
| General Purpose SSD | gp2 | 16,000 | 250 MB/s | Legacy; migrate to gp3 |
| Provisioned IOPS SSD | io2 | 64,000 | 1,000 MB/s | Critical Oracle/SQL Server/SAP |
| Provisioned IOPS SSD | io2 Block Express | 256,000 | 4,000 MB/s | Largest, most I/O-intensive databases |
| Throughput HDD | st1 | 500 | 500 MB/s | Big data, log warehouses, streaming reads |
| Cold HDD | sc1 | 250 | 250 MB/s | Infrequent access, lowest-cost HDD |
gp3 vs gp2 (a frequent exam contrast)
| Feature | gp3 | gp2 |
|---|---|---|
| Baseline IOPS | 3,000 at any size | 3 IOPS/GB (burst to 3,000) |
| Baseline throughput | 125 MB/s at any size | scales with size |
| Max IOPS | 80,000 (provisioned independently) | 16,000 |
| Performance vs capacity | Decoupled - pay only for IOPS you need | Coupled - must oversize disk for IOPS |
| Price | ~20% cheaper than gp2 | Legacy pricing |
The key gp3 advantage is decoupling performance from capacity: with gp2 you had to grow the volume to 5,334 GB just to hit 16,000 IOPS, but gp3 lets you keep a small disk and dial IOPS/throughput up independently. Choose io2 / io2 Block Express when you need provisioned IOPS above gp3's range, the highest durability (99.999%), sub-millisecond latency, or Multi-Attach to up to 16 instances in the same AZ.
Amazon EFS (Elastic File System)
EFS is fully managed NFS v4.1 that grows and shrinks automatically and mounts simultaneously on thousands of Linux instances across multiple AZs - the answer whenever multiple instances need a shared POSIX file system. It is Linux-only (no Windows/SMB).
| Setting | Options |
|---|---|
| Performance mode | General Purpose (low latency, default) or Max I/O (higher aggregate throughput) |
| Throughput mode | Elastic (recommended), Provisioned, or Bursting |
| Storage classes | Standard, Standard-IA, One Zone, One Zone-IA (lifecycle moves cold files to IA) |
| Encryption | At rest (KMS) and in transit (TLS) |
Amazon FSx Family
| Variant | Protocol | Signature strength | Use case |
|---|---|---|---|
| FSx for Windows File Server | SMB | Active Directory, DFS, shadow copies, quotas | Windows apps, SharePoint, home directories |
| FSx for Lustre | POSIX (Lustre) | Hundreds of GB/s, native S3 import/export | HPC, ML training, media, financial modeling |
| FSx for NetApp ONTAP | NFS, SMB, iSCSI | Dedup, compression, snapshots, multi-protocol | NetApp migrations, mixed-OS access |
| FSx for OpenZFS | NFS | Up to 1M IOPS, sub-ms latency, snapshots | High-performance Linux, ZFS migrations |
FSx for Lustre deploys as Scratch (temporary, highest performance, no replication) or Persistent (replicated, durable) and can transparently link to an S3 bucket so jobs read input from S3 and write results back - the standard HPC/ML answer.
Storage Comparison
| EBS | EFS | FSx for Lustre | |
|---|---|---|---|
| Type | Block | File (NFS) | File (parallel POSIX) |
| Sharing | 1 instance (io2 Multi-Attach up to 16, same AZ) | Thousands, multi-AZ | Thousands |
| AZ scope | Single AZ | Multi-AZ | Single or Multi-AZ |
| OS | Linux + Windows | Linux only | Linux only |
| Peak performance | 256K IOPS / 4 GB/s | 10+ GB/s | Hundreds of GB/s |
| Best for | Databases, boot volumes | Shared Linux storage | HPC, ML, media |
On the Exam: "Many Linux instances across AZs need one shared file system" -> EFS. "Windows SMB with Active Directory" -> FSx for Windows. "ML training reading training data from S3 at high throughput" -> FSx for Lustre. "Single high-IOPS database volume" -> io2 / io2 Block Express.
Worked Scenario: Right-Sizing EBS Performance
A reporting database on a gp2 volume needs a steady 10,000 IOPS but currently underperforms because gp2 delivers only 3 IOPS per GB - reaching 10,000 baseline IOPS would force the volume to roughly 3,334 GB even if the data is far smaller. The cost-optimal fix is to convert to gp3 and provision 10,000 IOPS independently of capacity, keeping the disk sized to the data and paying only for the performance needed. Reserve io2 / io2 Block Express for the cases gp3 cannot serve: more than 80,000 IOPS, 99.999% durability, single-digit-microsecond-class latency, or Multi-Attach across up to 16 instances in one AZ.
The decoupling of performance from capacity is the single most-tested gp3 concept.
Common Traps to Avoid
- EBS Multi-Attach across AZs. Multi-Attach (io2 only) shares a volume with up to 16 instances, but they must all be in the same AZ. If the question needs cross-AZ sharing, the answer is EFS, not EBS.
- EFS for Windows. EFS is NFS and Linux-only; a Windows SMB requirement points to FSx for Windows File Server.
- Oversizing gp2 for IOPS. Growing a gp2 volume purely to gain IOPS wastes money; gp3 provisions IOPS separately and is about 20% cheaper at baseline.
- Confusing st1 with high-IOPS needs. st1 is throughput-optimized HDD for large sequential reads (logs, big data); it caps near 500 IOPS and is wrong for random-access databases.
- FSx for Lustre durability. Lustre Scratch deployments are not replicated - they are for temporary, highest-performance scratch space; use Persistent deployments when the data must survive.
A Linux web fleet of 30 instances spread across three Availability Zones must read and write a common set of files concurrently. Which storage service fits?
A mission-critical Oracle database needs sustained sub-millisecond latency and 150,000 provisioned IOPS on a single volume. Which EBS volume type should be selected?
A machine-learning training job needs a high-throughput parallel file system that ingests training data directly from an S3 bucket and writes results back to S3. Which service is purpose-built for this?