2.4.2. Storage Optimization: EBS Volume Types and Performance
š” First Principle: EBS volume types are not interchangeable ā they have fundamentally different performance characteristics designed for different workloads. Choosing the wrong volume type can bottleneck your application as severely as choosing the wrong instance type.
Think of it like choosing between a sports car and a semi-truck. The sports car (io2 Block Express) delivers maximum acceleration (IOPS) with a small payload. The semi-truck (st1) carries enormous amounts (throughput) but doesn't accelerate quickly. The right choice depends entirely on your workload.
EBS Volume Types:
| Volume Type | Max IOPS | Max Throughput | Latency | Best For |
|---|---|---|---|---|
| gp3 | 16,000 | 1,000 MB/s | Single-digit ms | General workloads; default choice |
| gp2 | 16,000 | 250 MB/s | Single-digit ms | Legacy; prefer gp3 (cheaper, more flexible) |
| io2 Block Express | 256,000 | 4,000 MB/s | Sub-ms | Highest-performance databases (SAP HANA, Oracle) |
| io1 | 64,000 | 1,000 MB/s | Single-digit ms | I/O-intensive databases |
| st1 | 500 | 500 MB/s | Tens of ms | Sequential throughput: Hadoop, data warehouses |
| sc1 | 250 | 250 MB/s | Tens of ms | Cold data, infrequent access |
Key gp3 vs. gp2 insight: gp2 ties IOPS to volume size (3 IOPS/GB, up to 16,000). A 1TB gp2 volume gives you 3,000 IOPS. A 100GB gp2 volume gives only 300 IOPS. With gp3, IOPS and throughput are independently configurable ā you can provision a 100GB volume with 16,000 IOPS. This makes gp3 significantly more flexible and cost-effective.
EBS-Optimized Instances: Not all EC2 instances have dedicated EBS bandwidth. EBS-optimized instances provide a dedicated network path between the instance and its EBS volumes, preventing EBS I/O from competing with instance network traffic. Most current generation instances are EBS-optimized by default.
EBS Multi-Attach: io1 and io2 volumes support multi-attach ā the same EBS volume attached to up to 16 Nitro-based instances in the same AZ simultaneously. This requires a cluster-aware file system (not ext4 or XFS) to manage concurrent writes. Use case: high-availability database clusters that need shared block storage.
Volume Modification: You can change volume type, size, and IOPS without detaching or rebooting the instance (for most modern instance types and volume types). The modification runs in the background. After a resize, you still need to extend the file system inside the OS.
ā ļø Exam Trap: st1 and sc1 volumes cannot be used as boot volumes. Only gp2, gp3, io1, and io2 can be root volumes. If a question asks about a boot volume requiring high throughput, the answer is gp3 or io1/io2, not st1.
Reflection Question: Your database is running on a 500GB gp2 volume and experiencing I/O performance issues at 1,500 IOPS. You need 8,000 IOPS but want to minimize cost. What is the cheapest solution without increasing volume size?
