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.
- Region
- US East (N. Virginia)
- Currency
- USD
- Rate basis
- Public list price, no negotiated or committed discount
- Prices verified
- 4 Aug 2026
Each one fills every field below with a plausible shape for that workload. Change anything afterwards; nothing is locked.
Group volumes of the same size. The IOPS toggle matters only above 1,000 GiB.
- On gp2 today
- $1,000.00/mo
- On gp3
- $845.00/mo
- Volumes that get worse
- 0 of 2
$1,860.00 a year across 14 volumes.
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 |
Make the change
gp2 to gp3 is an online change: no snapshot, no detach, no downtime. The one thing to get right is which volumes need their IOPS bought back.
Modify one volume, watch it finish, and list the rest. The volume stays attached and usable throughout. Do not pass --iops or --throughput unless the volume genuinely needs more than the 3,000 IOPS and 125 MiB/s gp3 includes; that is what turns a saving into a regression.
# gp2 to gp3 is an online modification: no snapshot, no detach, no
# downtime. The volume enters "optimizing" and stays fully usable.
#
# The default gp3 volume includes 3,000 IOPS and 125 MiB/s. Passing --iops
# or --throughput buys MORE than that and is charged for, so only pass them
# where the volume was genuinely relying on the IOPS gp2 gave it for free.
aws ec2 modify-volume --volume-id vol-xxxxxxxx --volume-type gp3
# Watch it complete before touching the next one.
aws ec2 describe-volumes-modifications --volume-ids vol-xxxxxxxx \
--query 'VolumesModifications[0].[ModificationState,Progress]' --output text
# Every gp2 volume in the region, with its size, so you can work down the list.
aws ec2 describe-volumes --filters Name=volume-type,Values=gp2 \
--query 'Volumes[].[VolumeId,Size,Iops,Attachments[0].InstanceId]' \
--output tableWhat 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.
Related tools
The questions this one tends to raise next.
EC2 Idle & Rightsizing Calculator
What idle instances cost, and what stopping them actually saves.
OpenS3 Storage Class Calculator
Where the break-even really is, once transitions and minimums are counted.
OpenRDS Cost & Rightsizing Calculator
Multi-AZ doubles more than you think. Price it before you enable it.
OpenEvery tool on this site that touches storage and lifecycle, across every cloud.
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.