AWS offers several EBS volume types, each optimized for a different price-to-performance trade-off. Choosing the wrong type is one of the most common causes of database performance problems in AWS — and one of the most common cost-optimization opportunities.
1. General Purpose SSD (gp3) — The Modern Standard
gp3 is the right choice for the vast majority of workloads. It replaced gp2 as the default volume type in 2021.
The key innovation in gp3 is decoupled performance: storage capacity and I/O performance are configured independently. You can have a 10 GB volume with 16,000 IOPS, or a 10 TB volume with only 3,000 IOPS. You pay for each dimension separately.
Baseline specs (included in the base price, no extra charge):
- 3,000 IOPS
- 125 MB/s throughput
Maximum specs (additional cost to provision):
- 16,000 IOPS
- 1,000 MB/s throughput
Cost: gp3 storage is approximately 20% cheaper per GB than gp2, and the baseline performance is free. For most teams, migrating from gp2 to gp3 is a pure cost reduction with a performance improvement.
2. Provisioned IOPS SSD (io2 Block Express) — The Heavy Hitter
For mission-critical databases that require sub-millisecond latency and extreme throughput, io2 Block Express is the answer. It runs on AWS's specialized Nitro storage hardware, which implements a dedicated storage area network (SAN) architecture in software.
Specs:
- Up to 256,000 IOPS per volume
- Up to 4,000 MB/s throughput
- 99.999% durability (five nines — compared to 99.8–99.9% for gp3)
The durability difference matters for compliance. If you are running Oracle or SAP HANA and your SLA requires five-nines storage durability, io2 is the only EBS option that qualifies.
Cost: Significantly more expensive than gp3. Provision io2 only when you have a specific, measurable requirement that gp3 cannot meet.
3. Throughput Optimized HDD (st1) and Cold HDD (sc1) — Spinning Disks
These are magnetic hard drives, not SSDs. They cannot be used as boot volumes.
st1: Optimized for sequential reads of large datasets — log processing, data warehouses, Kafka brokers. Cheap per GB, high throughput, but high latency.sc1: The cheapest EBS option. For data that is accessed infrequently — archives, cold backups. Lowest cost, lowest performance.
Use HDD volumes when your access pattern is sequential and large (reading through a 500 GB log file from start to finish), not random and small (reading individual database rows).
4. The Legacy: gp2 and the Burst Balance Trap
Understanding gp2 is important because many AWS accounts still have gp2 volumes running in production, and the failure mode is subtle and dangerous.
In gp2, performance is tied to size: you get 3 IOPS per GB of storage, up to a maximum of 16,000 IOPS. A 100 GB volume gets 300 IOPS. A 1,000 GB volume gets 3,000 IOPS.
For small volumes (under 1 TB), gp2 uses a burst credit bucket to handle spikes. The bucket fills at 3 IOPS/GB when the volume is idle and drains when the volume is under load. When the bucket empties, the volume is throttled to its baseline IOPS — which for a 100 GB volume is only 300 IOPS. A database under this throttle will appear to hang.
The insidious part: the bucket drains silently. There is no alarm by default. Your database slows to a crawl at 2 AM during a batch job, the bucket empties, and by morning your application is timing out. The CloudWatch metric to watch is BurstBalance — if it drops below 20%, you have a problem.
Action: Audit your account for gp2 volumes and migrate them to gp3. AWS provides a one-click migration path with zero downtime.
Interviewers frequently ask: "Your RDS database was fast all morning but started timing out at 2 PM. What would you check?" The answer they are looking for is EBS burst balance depletion on a gp2 volume. Check the BurstBalance CloudWatch metric. The fix is to migrate to gp3 or increase the gp2 volume size. This scenario is extremely common in production and demonstrates real operational experience.