A database moved to EC2 with every volume on gp2 “because that was the default” usually meets a slow month end. Choosing an EBS volume is not a matter of taste. It is arithmetic: how many IOPS, how much throughput, how much latency you can accept, how big, and whether the instance can carry the total. Here are the current documented figures.
The figures
| Type | Size | Max IOPS | Max throughput | What decides it |
|---|---|---|---|---|
| gp3 | 1 GiB to 64 TiB | 80,000 | 2,000 MiB/s | 3,000 IOPS and 125 MiB/s included at any size |
| gp2 | 1 GiB to 16 TiB | 16,000 | 250 MiB/s | 3 IOPS per GiB, burst to 3,000 under 1 TiB |
| io2 Block Express | 4 GiB to 64 TiB | 256,000 | 4,000 MiB/s | average latency under 500 microseconds (16 KiB I/O) |
| io1 | 4 GiB to 16 TiB | 64,000 | 1,000 MiB/s | sustained IOPS beyond 16,000 |
| st1 | 125 GiB to 16 TiB | 500 | 500 MiB/s | 40 MiB/s per TiB baseline |
| sc1 | 125 GiB to 16 TiB | 250 | 250 MiB/s | 12 MiB/s per TiB baseline |
Three rules sit behind the table. SSD types (gp3, gp2, io2, io1) are built for small I/O, where IOPS matter. HDD types (st1, sc1) are built for large, sequential I/O, where throughput matters, and they cannot be boot volumes. Only io2 and io1 support Multi-Attach. io2 Block Express reaches its 256,000 IOPS only on a Nitro-based instance.
gp3: performance without buying size
gp2 ties performance to size. Its baseline is 3 IOPS per GiB, with a minimum of 100 and a maximum of 16,000 reached at 5,334 GiB. A 50 GiB boot volume therefore has a baseline of 150 IOPS. Volumes under 1 TiB can burst to 3,000 IOPS, but only while they have I/O credits, and the BurstBalance metric in CloudWatch shows how many are left. Burst is borrowed time, not capacity. A 12,000 IOPS baseline on gp2 takes 4,000 GiB of disk.
gp3 breaks that link. Every gp3 volume gets 3,000 IOPS and 125 MiB/s at baseline, included in the price of storage, at any size. You can provision more IOPS, up to 80,000, at up to 500 IOPS per GiB, and more throughput, up to 2,000 MiB/s, at up to 0.25 MiB/s per provisioned IOPS. gp3 does not burst: it sustains what you provision. The documentation also puts its price per GiB 20 percent below gp2. So a 500 GiB volume that needs 12,000 IOPS and about 190 MiB/s stays at 500 GiB on gp3, with the IOPS and throughput provisioned separately.
What gp3 does not give you is the lowest latency. The guide describes both gp3 and gp2 as “single-digit millisecond”.
io2 Block Express: when the bar is under a millisecond
If a requirement names sub-millisecond latency, such as a database vendor’s bar for redo log writes, the General Purpose volumes are out. The documentation lists io2 Block Express for workloads needing “consistent sub-millisecond latency with average latency under 500 microseconds”, and recommends it for latency-sensitive workloads. It is also the durable one: 99.999 percent, against 99.8 to 99.9 percent for gp3, gp2, io1, st1 and sc1.
io2 is not the default answer for speed in general. Every IOPS on io2 is provisioned, while gp3 includes 3,000 in the price of storage. If the requirement is IOPS without a latency bar, gp3 can provision up to 80,000, and the guide recommends the General Purpose volumes for most workloads.
st1 and sc1: throughput by the TiB
For a large sequential job, such as a nightly archive copy or log processing, an HDD volume is the low-cost way to get throughput. Their performance comes from size. st1 has a baseline of 40 MiB/s per TiB, capped at 500 MiB/s, and bursts at 250 MiB/s per TiB from a credit bucket. A 5 TiB st1 volume has a baseline of 200 MiB/s. sc1 has a baseline of 12 MiB/s per TiB, so the same 5 TiB gives 60 MiB/s. sc1 is for cold data you rarely read, where the lowest storage cost matters more than speed.
Small random I/O is inefficient on these volumes: an I/O of 1 MiB or less counts as a full 1 MiB credit. And their throughput is always the smaller of the volume’s limit and the instance’s.
The instance is the second ceiling
An EBS-optimized instance has dedicated bandwidth for EBS I/O, and the EBS-optimized instance tables list it for each instance type as a baseline and a maximum. An m6i.xlarge, for example, has a baseline of 1,250 Mbps (156.25 MB/s) and 6,000 IOPS, with a maximum of 10,000 Mbps and 40,000 IOPS. That maximum is not sustained. Instances marked this way “can sustain the maximum performance for 30 minutes at least once every 24 hours”, then return to baseline.
So a volume provisioned with 20,000 IOPS, attached to an instance whose baseline is 6,000, delivers about 6,000 for any job that outlasts the 30-minute maximum. Add up what every attached volume needs, then pick an instance whose baseline carries the total. The lower ceiling wins.
Shared block: Multi-Attach
Multi-Attach lets one io1 or io2 volume attach to up to 16 Nitro-based instances in the same Availability Zone, each with full read and write access. Standard file systems such as XFS and EXT4 are not built for that, so the guide tells you to use a clustered file system. Windows instances support Multi-Attach on io2 only, and a Multi-Attach volume cannot be a boot volume. gp3 cannot do it at all.
What the exam guides ask
The SOA-C03 guide asks you to “analyze Amazon EBS performance metrics, troubleshoot issues, and optimize volume types to improve performance and reduce cost” (Skill 1.3.2). The SAA-C03 guide asks you to “determine high-performing and/or scalable storage solutions” (Task 3.1) and “design cost-optimized storage solutions” (Task 4.1). The SAP-C02 guide asks you to “design a solution to meet performance objectives” (Task 2.5).
Scenario questions on this topic give you a workload in numbers and ask for the most cost-effective volume. The distractors follow patterns:
- A bigger gp2 volume. It works, by paying for capacity you do not need to reach the IOPS.
- io2 everywhere. It meets every requirement, and provisions every IOPS that gp3 would have included.
- The cheapest HDD. sc1 looks thrifty until you multiply 12 MiB/s by the size.
- More IOPS on the volume. Useless when the instance’s EBS baseline is the ceiling.
- gp3 with Multi-Attach. Not supported.
Play it
The free stage below puts these numbers on a meter. Harbourline Ferries has moved its booking database to EC2, every volume still on gp2. You size five volumes in the Tuner: a boot volume, data files, redo logs that must commit in under a millisecond, a 5 TiB archive copy, and a volume two reporting nodes must share. Then you choose an instance that can carry them all. Each row tells you whether its workload is met, and the last row checks the monthly bill against a budget. The cheapest design that passes every row is the answer.