EBS gp2 vs gp3 Calculator
Compare gp2 against gp3 on your real volume sizes, including the paid IOPS and throughput gp3 needs to match a large gp2 volume. Most migrations save 20%; the ones that do not are the reason this does the arithmetic properly.
Group volumes of the same size. The IOPS toggle matters only above 1,000 GiB.
Per volume group
| Group | Size | gp2 IOPS | gp2 | gp3 | Saving |
|---|---|---|---|---|---|
| app-data x12 | 500 GiB | 1,500 | $600.00 | $480.00 | $120.00 |
| db-primary x2 | 2,000 GiB | 6,000 | $400.00 | $365.00 | $35.00 |
What this model assumes
- gp2 IOPS are a function of size. 3 IOPS per GiB, floored at 100 and capped at 16,000. A volume over 1,000 GiB therefore carries more than gp3’s included 3,000 — and matching that on gp3 costs $0.005 per IOPS-month. This is the entire reason the answer is not always “save 20%”.
- Matching IOPS is off by default because most volumes do not need it. Turning it on is the conservative choice for a database and an expensive one for a filesystem.
- Snapshots are not included. They cost the same ($0.05/GB-month) on both volume types, so including them would add an identical number to both sides and change no decision.
- Burst credits are not modelled. gp2 volumes under 1,000 GiB burst to 3,000 IOPS on a credit balance. A volume that relies on burst rather than its baseline will behave differently on gp3’s flat 3,000 — usually better, since gp3 does not run out.
- EBS volumes and snapshots — source, read 4 Aug 2026
US East (N. Virginia) list prices, excluding any negotiated or committed-use discount. Your effective rate is lower if you have one.
Frequently asked questions
How much cheaper is gp3 than gp2?
gp3 storage costs $0.08 per GB-month against gp2 at $0.10 — 20% less. That is the whole story for volumes under 1,000 GiB. Above that, gp2 provisions more than 3,000 IOPS for free (3 per GiB), and matching that performance on gp3 costs $0.005 per IOPS-month, which eats into and occasionally exceeds the storage saving.
Should I migrate from gp2 to gp3?
For most volumes, yes — it is a 20% saving with no downtime and no snapshot. The exception is a large volume that genuinely uses the IOPS its size gives it on gp2. Check actual IOPS consumption before assuming you need to match provisioned IOPS: most volumes sized for capacity never approach their gp2 ceiling.
Does changing EBS volume type cause downtime?
No. A volume type change is an online modification — the volume stays attached and the instance keeps running. The volume enters an optimising state during which performance is somewhere between the two types, and you cannot make another modification for six hours.
How many IOPS does a gp2 volume have?
Three per GiB, with a floor of 100 and a ceiling of 16,000. A 100 GiB volume gets 300 IOPS; a 1,000 GiB volume gets 3,000; anything above 5,334 GiB is capped at 16,000. Volumes under 1,000 GiB can also burst to 3,000 IOPS on a credit balance, which gp3 replaces with a flat, non-depleting 3,000.
Is gp3 faster than gp2?
For small volumes, considerably — gp3 gives every volume 3,000 IOPS and 125 MB/s regardless of size, where a 100 GiB gp2 volume has 300 IOPS once its burst credits run out. For very large volumes gp2 provides more baseline IOPS, and matching it on gp3 is a paid option.
Finding the volumes is the hard part, not the arithmetic.
Finitizer inventories every EBS volume across every account, checks actual IOPS consumption rather than provisioned, flags the volumes where matching would cost money, and ships the migration as a Terraform PR.