3.4 EBS, EFS, and FSx — Block, File, and Specialized Storage
Key Takeaways
- EBS provides block storage for single EC2 instances; choose gp3 (general purpose SSD) for most workloads, io2 Block Express for highest IOPS (256,000).
- EFS provides shared NFS file storage that can be mounted by thousands of EC2 instances across AZs — scales automatically and is fully managed.
- FSx for Lustre provides high-performance parallel file system for HPC, ML, and media workloads with S3 integration.
- FSx for Windows File Server provides fully managed Windows-native file shares with SMB protocol and Active Directory integration.
- EBS is tied to a single AZ; EBS snapshots are stored in S3 and can be copied cross-Region for DR.
EBS, EFS, and FSx — Block, File, and Specialized Storage
Quick Answer: EBS = block storage for a single EC2 instance (SSD/HDD volumes). EFS = shared NFS file storage for multiple instances across AZs. FSx for Lustre = high-performance parallel file system for HPC/ML. FSx for Windows = managed Windows file shares (SMB). Choose based on protocol, sharing needs, and performance requirements.
Amazon EBS (Elastic Block Store)
EBS provides persistent block-level storage volumes for EC2 instances. Think of EBS volumes as virtual hard drives.
EBS Volume Types
| Volume Type | API Name | Max IOPS | Max Throughput | Use Case |
|---|---|---|---|---|
| General Purpose SSD | gp3 | 16,000 | 1,000 MB/s | Most workloads (boot volumes, dev/test, small DBs) |
| General Purpose SSD | gp2 | 16,000 | 250 MB/s | Legacy; gp3 is preferred |
| Provisioned IOPS SSD | io2 | 64,000 | 1,000 MB/s | Critical databases (SQL Server, Oracle, SAP) |
| Provisioned IOPS SSD | io2 Block Express | 256,000 | 4,000 MB/s | Largest, most I/O-intensive databases |
| Throughput Optimized HDD | st1 | 500 | 500 MB/s | Big data, data warehouses, log processing |
| Cold HDD | sc1 | 250 | 250 MB/s | Infrequent access, lowest cost HDD |
Key EBS Facts
| Feature | Detail |
|---|---|
| AZ-bound | EBS volumes exist in one AZ — cannot be attached across AZs |
| Multi-attach | io2/io2 Block Express support multi-attach (up to 16 instances in same AZ) |
| Encryption | AES-256, using KMS keys; no performance impact |
| Snapshots | Stored in S3 (cross-AZ); can copy cross-Region |
| Boot volume | gp3, gp2, io2 (SSD only — cannot boot from HDD) |
gp3 vs. gp2
| Feature | gp3 | gp2 |
|---|---|---|
| Baseline IOPS | 3,000 (independent of size) | 3 IOPS/GB (max 16,000 at 5,334 GB) |
| Baseline throughput | 125 MB/s (independent of size) | Scales with volume size |
| Cost | 20% cheaper than gp2 | Legacy pricing |
| IOPS provisioning | Independently set up to 16,000 | Tied to volume size |
On the Exam: gp3 is the default recommendation for most workloads. Choose io2 when you need guaranteed IOPS above 16,000 or sub-millisecond latency for critical databases.
Amazon EFS (Elastic File System)
EFS provides fully managed NFS file storage that can be shared across thousands of EC2 instances.
EFS Features
| Feature | Detail |
|---|---|
| Protocol | NFS v4.1 |
| Sharing | Thousands of instances across multiple AZs |
| Scaling | Automatically scales to petabytes |
| Performance | Up to 10+ GB/s throughput |
| Storage classes | Standard, Standard-IA, One Zone, One Zone-IA |
| OS | Linux only (not Windows) |
| Encryption | At rest (KMS) and in transit (TLS) |
EFS Performance Modes
| Mode | Description |
|---|---|
| General Purpose | Low latency; best for most workloads (web, CMS) |
| Max I/O | Higher throughput, higher latency; for big data, media processing |
EFS Throughput Modes
| Mode | Description |
|---|---|
| Elastic | Automatically scales throughput; recommended for most workloads |
| Provisioned | Fixed throughput regardless of storage size |
| Bursting | Throughput scales with storage size (legacy) |
Amazon FSx
FSx provides fully managed third-party file systems.
FSx for Windows File Server
| Feature | Detail |
|---|---|
| Protocol | SMB (Windows native) |
| Active Directory | Full integration with AWS or self-managed AD |
| Features | DFS namespaces, shadow copies, quotas, file-level restore |
| Multi-AZ | Supports Multi-AZ for high availability |
| Use case | Windows applications, SharePoint, SQL Server, user home directories |
FSx for Lustre
| Feature | Detail |
|---|---|
| Performance | Hundreds of GB/s throughput, millions of IOPS |
| S3 integration | Seamlessly read from and write to S3 |
| Deployment | Scratch (temporary, highest performance) or Persistent (replicated, durable) |
| Use case | HPC, ML training, video processing, financial modeling |
FSx for NetApp ONTAP
| Feature | Detail |
|---|---|
| Protocols | NFS, SMB, iSCSI |
| Features | Data deduplication, compression, snapshots, cloning |
| Use case | Multi-protocol access, migrating NetApp workloads |
FSx for OpenZFS
| Feature | Detail |
|---|---|
| Protocol | NFS |
| Performance | Up to 1 million IOPS, sub-millisecond latency |
| Features | Snapshots, compression, copy-on-write |
| Use case | High-performance Linux workloads, migrating ZFS environments |
Storage Comparison
| Feature | EBS | EFS | FSx for Lustre |
|---|---|---|---|
| Type | Block | File (NFS) | File (POSIX) |
| Sharing | Single instance (io2 multi-attach up to 16) | Thousands of instances | Thousands of instances |
| AZ scope | Single AZ | Multi-AZ | Single AZ or Multi-AZ |
| OS | Linux + Windows | Linux only | Linux only |
| Performance | Up to 256K IOPS | Up to 10+ GB/s | Hundreds of GB/s |
| Best for | Databases, boot volumes | Shared Linux storage | HPC, ML, media |
A Linux-based application requires shared file storage accessible from multiple EC2 instances across different Availability Zones. Which storage service should be used?
A critical Oracle database requires consistent, sub-millisecond latency with 100,000 IOPS. Which EBS volume type should be used?
A company needs a high-performance file system for their machine learning training jobs that can also seamlessly read data from S3. Which service should they use?
A Windows-based application requires SMB file shares with Active Directory integration. Which AWS storage service should be used?
An EBS gp2 volume is experiencing burstable IOPS limitations. The application needs a consistent baseline of 10,000 IOPS. What is the MOST cost-effective solution?