EBS Volumes & Snapshots

## Two different pricing-and-performance models Both `gp2` and `gp3` are general-purpose SSD volume types, and for most workloads either will work. The difference is *how you buy performance*. ### gp2: performance is welded to size A `gp2` volume gets a **baseline of 3 IOPS per GiB**, with a floor of 100 IOPS and a ceiling of 16,000 IOPS (reached at 5,334 GiB). A 100 GiB gp2 volume therefore has a 300 IOPS baseline. On top of that, gp2 volumes smaller than 1,000 GiB can **burst to 3,000 IOPS** by spending from an I/O credit bucket. Credits accrue at the baseline rate whenever you use less than baseline, and the bucket starts full. This is the mechanism that produces the most common gp2 incident: a 100 GiB volume happily serves 3,000 IOPS during a load test or the first hour of a batch job, exhausts its credits, and then drops to 300 IOPS — a tenfold cliff, with no code change and no alarm on the volume itself. The tell is a saturated queue and rising latency on a volume whose CloudWatch burst-balance metric has hit zero. The workaround people reached for was **over-provisioning capacity to buy IOPS**: needing 3,000 sustained IOPS on gp2 meant a 1,000 GiB volume, whether or not you had 1,000 GiB of data. You paid for storage you did not want, to get performance you did. ### gp3: two independent dials `gp3` breaks that link. Every gp3 volume, from the smallest to the largest, includes a **baseline of 3,000 IOPS and 125 MiB/s at no extra charge**, and IOPS and throughput are then provisioned separately from size — up to **16,000 IOPS and 1,000 MiB/s** per volume (limits as of 2025). There is no credit bucket: the performance you provisioned is the performance you get, continuously. The dials are not fully independent of each other. gp3 constrains throughput relative to provisioned IOPS (roughly 0.25 MiB/s per IOPS), so reaching the 1,000 MiB/s ceiling requires provisioning a few thousand IOPS as well, and there is a maximum IOPS-per-GiB ratio that bounds tiny volumes. But within those rails you size capacity for data and performance for load, which is how you would want to reason about it anyway. gp3 also carries a **lower price per GiB-month than gp2** (about 20% lower at the time of writing), with extra IOPS above 3,000 and throughput above 125 MiB/s billed separately. For the very common case — a volume that needs steady 3,000 IOPS and modest throughput — gp3 is both faster in the sustained sense and cheaper. ## Migrating is an online operation Converting is a single `ModifyVolume` call on an attached, in-use volume: ```bash aws ec2 modify-volume --volume-id vol-0abc \ --volume-type gp3 --iops 3000 --throughput 125 ``` No detach, no stop, no snapshot dance. The volume passes through `modifying` and `optimizing` states and stays usable throughout, though performance during optimisation is somewhere between the old and new settings. ## When gp3 is not the answer gp3 is the right default, not a universal one: - **Above 16,000 IOPS, or when you need sub-millisecond consistent latency and the higher 99.999% durability figure** — that is `io2`, and `io2 Block Express` for the very large and very fast end. Provisioned IOPS volumes are also the only ones that support Multi-Attach. - **Large sequential scans on a budget** — `st1` (throughput-optimised HDD) and `sc1` (cold HDD) are far cheaper per GiB for streaming reads, and terrible for random I/O. They cannot be boot volumes. - **Extreme low-latency scratch space** — a local NVMe instance store beats any network-attached volume, at the cost of losing the data when the instance stops. ## What the interviewer is really checking That you know performance on gp2 is a side effect of size and credits, that gp3 replaced that with explicit provisioning, and that you can name the migration as a no-downtime modify rather than a rebuild. The bonus point is spotting that the instance itself has an EBS bandwidth ceiling — provisioning 16,000 IOPS on a volume attached to a small instance simply moves the bottleneck.