gp2 vs gp3: The EBS Discount Most Accounts Never Claim

Amazon launched gp3 volumes at re:Invent 2020, and they remain one of the cleanest cost wins on any AWS bill: the same durability and use case as gp2, a 20 percent lower storage price, and performance you dial in independently of capacity. Yet in the accounts we scan, gp2 routinely still holds a large share of provisioned block storage. Nobody chose that. It is simply the default nobody revisited.

What actually changed between gp2 and gp3

gp2 couples performance to size: every gigabyte buys you 3 IOPS, with a floor of 100 IOPS and a burst allowance up to 3,000 IOPS for volumes under one terabyte. If a workload needs more IOPS, your only lever is provisioning more gigabytes you may not need, like renting a bigger apartment because you wanted a second parking space. That coupling is the design gp3 removed.

gp3 decouples the two. Every gp3 volume includes 3,000 IOPS and 125 MB/s of throughput at its base price, no matter how small it is, and you can provision up to 16,000 IOPS and 1,000 MB/s on top as separate line items. Performance becomes something you buy by the unit instead of something you back into by oversizing storage.

The burst mechanics matter more than they look. gp2's 3,000-IOPS burst for sub-terabyte volumes runs on a credit balance that refills at the volume's baseline rate, so a 100 GB volume (300 baseline IOPS) that bursts regularly will exhaust its credits and fall back to baseline exactly when the workload is busiest. gp3's 3,000 IOPS are sustained, with no credit accounting at all. For every small, occasionally busy volume, gp3 is cheaper and also removes a failure mode that is genuinely hard to debug from inside the instance.

The pricing math, side by side

Two worked examples make the shape obvious.

A 500 GB volume with ordinary needs: gp2 costs $50.00 a month and gives 1,500 baseline IOPS with bursting. gp3 costs $40.00 and gives 3,000 IOPS sustained, no burst credits to think about. gp3 is 20 percent cheaper and roughly twice as fast at baseline.

A 2 TB volume that genuinely needs 10,000 IOPS: gp2 has to grow to about 3,334 GB just to reach that IOPS level, costing $333 a month. gp3 stays at 2,048 GB ($163.84) and provisions 7,000 extra IOPS ($35.00) for $198.84 total. The gap widens exactly where gp2 looks like it should win.

Where gp2 deserves a second look

Honestly: almost nowhere on price. The cases worth pausing on are operational, not economic.

Very large volumes already sized for IOPS are the one pattern to check. A gp2 volume grown past 5.3 TB to hit the 16,000 IOPS cap carries its performance in its size; the gp3 equivalent needs the full 13,000 extra IOPS provisioned. Run the numbers: at that scale gp3 still comes out ahead ($427 storage plus $65 IOPS against $533 on gp2 for the same capacity), but the margin narrows enough that a volume already scheduled for rearchitecture may not be worth touching twice.

Throughput-heavy sequential workloads on mid-size gp2 volumes get up to 250 MB/s without an explicit charge, where gp3 includes 125 MB/s. Matching 250 MB/s on gp3 adds $5.00 a month. That rarely flips the verdict, but it belongs in the comparison rather than in the fine print.

How to find your gp2 fleet

Before migrating anything, get the denominator. A one-line query lists every gp2 volume in a region with its size:

aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[].{id:VolumeId,size:Size,state:State}' \
  --output table

Multiply the summed gigabytes by $0.02 and you have the monthly saving the migration is worth before any performance tuning. Do the same per account across the organization; the totals concentrate in the oldest accounts, because gp2 was the default for every volume created before you started specifying otherwise, including every root volume your AMIs and launch templates quietly created. Updating those templates to gp3 matters as much as migrating the existing fleet, or the gp2 share simply grows back.

How to migrate without downtime

EBS volume modification handles the change live. From the console or CLI, modify the volume type from gp2 to gp3 on an attached, in-use volume; the change applies with no detach and no restart:

aws ec2 modify-volume --volume-id vol-0123456789abcdef0 --volume-type gp3

A few practical notes:

1. Modify during a quiet window anyway. Performance can be briefly variable while the volume is in the optimizing state.
2. Set IOPS and throughput deliberately. The defaults (3,000 and 125) are already above what most gp2 volumes were getting; only carry over an explicit provisioned level if monitoring shows the workload consuming it.
3. Mind the six-hour cooldown. A volume can only be modified once every six hours, so get size, type, and performance right in one pass.
4. Sweep by tag or by account, not by hand. One-off migrations leave the long tail in place, and the long tail is where the spend is.