EBS gp2 to gp3: the easiest AWS savings still left on the table in 2026

On every AWS audit we run, the first chart we pull is provisioned EBS by volume type. Most accounts come back the same way. Sixty to eighty percent of provisioned space sits on gp2. The volumes were created years ago, they work, no one had a reason to touch them. And every one of them is overpaying by 20 percent on the storage line, often more.

gp3 launched in December 2020. AWS does not auto-convert. Volumes created before then are still gp2 unless someone migrated them. The savings is the easiest five-figure win we find in audits, and the migration is the safest production change in the AWS catalog. No detach, no snapshot, no instance restart. One CLI command per volume.

The math, briefly

gp2 charges $0.10 per GB per month at the US rate. Baseline IOPS scale at 3 per GB up to 16,000. There is no separate IOPS bill. Throughput scales with volume size up to 250 MB/s.

gp3 charges $0.08 per GB per month, 20 percent less. Every gp3 volume includes 3,000 IOPS and 125 MB/s of throughput regardless of size. Above the included tier, IOPS cost $0.005 per IOPS-month and throughput costs $0.04 per MB/s-month, both capped well above what the gp2 baseline would have given you.

For a 1,000 GB volume:

• gp2: $100 per month, 3,000 baseline IOPS, 250 MB/s.
• gp3: $80 per month, 3,000 IOPS, 125 MB/s.

Same IOPS, less throughput, 20 percent cheaper. If the workload actually used the 250 MB/s, the additional 125 MB/s on gp3 costs $5 per month, still 15 percent cheaper net.

For a 100 GB volume:

• gp2: $10 per month, 300 baseline IOPS (with burst).
• gp3: $8 per month, 3,000 IOPS, 125 MB/s.

20 percent cheaper AND 10x more IOPS. The smaller the volume, the more dramatic the win, because gp2 IOPS are tied to volume size and gp3 IOPS are not.

For a 100 GB volume that needs 8,000 IOPS:

• gp2: not possible. Baseline IOPS at 100 GB is 300. You would have to provision a 2,667 GB gp2 to get 8,000 baseline IOPS, or move to io1/io2 entirely.
• gp3: $8 storage + 5,000 extra IOPS × $0.005 = $33 per month, 8,000 IOPS, 125 MB/s.

gp3 makes high-IOPS small volumes practical for the first time without paying io1/io2 premiums.

For an exact number on your fleet, the EBS gp2 vs gp3 cost calculator takes total provisioned GB, IOPS, throughput, and gives the side-by-side and the annualized savings.

When gp2 wins

Almost never. The two narrow cases are a volume under 100 GB where you do not need the 3,000 IOPS gp3 includes for free, AND you have an automation reason to leave the volume type alone (think baked AMIs that hard-code expectations). Both have to be true. In every other case migrate.

For volumes above 333 GB, gp3 is unconditionally cheaper. That is where most provisioned EBS sits in real accounts.

The migration is the safest change AWS offers

AWS supports in-place volume modification. The volume stays attached, the instance stays running, the application stays online. Performance during the modification is unchanged.

aws ec2 modify-volume \
  --volume-id vol-xxxxxxxx \
  --volume-type gp3 \
  --iops 3000 \
  --throughput 125

The volume goes into modifying for a few seconds, then optimizing for a few minutes to a few hours depending on size. After that it is gp3. Run a one-liner across every gp2 volume:

aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[].VolumeId' --output text | \
xargs -n1 -I{} aws ec2 modify-volume \
  --volume-id {} --volume-type gp3 --iops 3000 --throughput 125

Run it during a quiet hour. There is a six-hour cooldown per volume between modifications, so plan one round and let it finish before sweeping again.

We have run this exact migration against production databases, Kafka brokers, build farms, and EKS persistent volumes. We have not seen a single incident traced to the type change itself. The only failure mode worth naming is the cooldown: if a volume was modified in the last six hours for any reason, the call fails with VolumeModificationRateExceeded. Wait it out.

Should you tune IOPS and throughput per workload?

Yes, but as a second pass. The first pass is to migrate every gp2 to gp3 with the included tier (3,000 IOPS, 125 MB/s). That alone captures the 20 percent storage discount on the entire fleet without changing any performance characteristic.

After the first pass, audit which volumes actually need more IOPS or throughput than the included tier provides. CloudWatch VolumeReadOps and VolumeWriteOps show the real workload. For the long tail of low-IOPS volumes, leaving them at 3,000 IOPS is a free over-provision. For the handful of high-throughput volumes (databases, log aggregators), bump throughput to what they need.

We have seen accounts use the second pass to reduce provisioned IOPS on databases that were migrated from io1 to gp3 with their original io1 IOPS still set. Going from 16,000 provisioned IOPS to a measured 5,000 saved $55 per month per volume on top of the type-change savings.

What we tell every audit customer

Three rules, in order:

Rule one: migrate every gp2 to gp3 with the default included tier. No tuning, no per-workload analysis. Just type-change them all. This is the 20 percent.

Rule two: after the migration settles for a week, audit CloudWatch metrics on the largest 50 volumes. Tune IOPS and throughput up where the workload uses them, leave them alone elsewhere. This is another 5 to 10 percent.

Rule three: set the account-wide default volume type to gp3 in every Launch Template and AMI. New volumes should never be born as gp2 again. This is the polish that keeps the gain steady instead of needing to re-run the migration in two years.

Rule one is the one that returns the savings on day one. The other two close the gap and keep it closed.