How to Migrate EBS Volumes from gp2 to gp3

Introduction

gp3 launched in late 2020. It's cheaper than gp2, has a better baseline, and migrating to it takes zero downtime. Five years later, most AWS accounts we look at still have gp2 volumes sitting around, quietly costing 20% more than necessary.

Nobody owns old storage cleanup. The volumes were provisioned years ago, they work fine, and there's no alert firing. This post covers why gp3 is a strict upgrade for general purpose workloads, what the live migration actually does under the hood, and how to roll the change out safely.

Why gp3 wins for most volumes

gp3 is roughly 20% cheaper per GiB than gp2 in every AWS region. In us-east-1 that's $0.08/GiB-month versus $0.10. A 2 TiB volume saves around $44 a month. Across a fleet the savings add up fast.

The performance story is also better for most volumes. gp3 ships with a flat 3,000 IOPS and 125 MiB/s of throughput at any size. gp2 scales with size: 3 IOPS per GiB of baseline, with burst up to 3,000 IOPS for volumes under 1 TiB. So a 100 GiB gp2 volume baselines at 300 IOPS and leans on burst credits for anything above that. Small gp2 volumes are throttled by design. gp3 removes the throttle entirely at the low end.

gp3 costs less, performs better at the low end, and the migration is a live API call. The one catch is large volumes, which we'll get to.

For general purpose workloads, the case for staying on gp2 is weak. gp3 matches gp2 on durability, uses the same block interface, is a supported AWS migration path, and AWS Trusted Advisor itself flags gp2 volumes as a cost optimization finding. The only wrinkle is large volumes that relied on gp2's size-scaled baseline, which we cover below.

What the migration actually does

The migration is a single AWS API call: ModifyVolume with VolumeType=gp3. AWS changes the type in place while the volume stays attached and mounted. No detach, no snapshot, no remount, no reboot. Your application keeps serving traffic while the change runs in the background.

The volume enters an optimizing state during the transition. You can watch it with:

aws ec2 describe-volumes-modifications \
  --volume-ids vol-0123456789abcdef0

Optimization can take a few hours depending on volume size, and while it runs you can't issue another ModifyVolume on that volume. AWS also enforces a 6 hour cooldown between successive modifications. Plan around that if you're batching modifications in a loop, otherwise you'll hit VolumeModificationRateExceeded and have to wait it out.

Once optimization completes, the volume is gp3 and the new pricing applies immediately. There's no pro-ration surprise, no reserved capacity to buy, no long-term commitment. From the instance's perspective gp3 is a drop in replacement. No reboot, no remount, no OS level changes.

The performance regression trap

This is the edge case that turns a "free" migration into an incident. gp2 scales both IOPS and throughput with volume size. gp3 doesn't. If you migrate a large gp2 volume to gp3 at defaults, you can silently cut its baseline performance.

Two things to check before migrating.

Baseline IOPS. gp2 gives you 3 * size_gib baseline IOPS, capped at 16,000, with a floor of 100. A 1 TiB gp2 volume baselines at 3,072 IOPS. A 5.3 TiB+ gp2 volume baselines at the 16,000 cap. gp3's default is 3,000 IOPS flat. For any gp2 volume over ~1 TiB, a default gp3 is a regression on baseline IOPS. You need to provision IOPS explicitly to match.

Baseline throughput. gp2 throughput scales up to 250 MiB/s, which it reaches at 334 GiB. gp3's default is 125 MiB/s. So any gp2 volume 334 GiB or larger was getting up to 250 MiB/s baseline, and a default gp3 will halve that. Provision throughput explicitly when the size crosses that threshold.

For volumes under ~1 TiB, default gp3 is equal or better. For larger volumes, provision IOPS and throughput to match the gp2 baseline or you're paying less for worse performance.

Volumes under 334 GiB are always safe at gp3 defaults. They were never getting more than 125 MiB/s or 3,000 baseline IOPS on gp2 to begin with. In the fleets we've looked at, that covers most volumes.

Even with provisioned IOPS and throughput, gp3 is usually still cheaper than the equivalent gp2 volume. You only pay extra for IOPS above 3,000 and throughput above 125 MiB/s, and the per-GB saving covers most of the delta. But the savings number has to reflect the provisioning cost, not the naked per-GB delta, or you're lying to yourself about the win.

Rollout

You don't need a maintenance window. The migration is online, but we still recommend staging it:

1. Pick one non-critical volume first. Run the change, watch the optimization complete.
2. Verify the workload is healthy on gp3 for a day or two.
3. Ship the rest in reasonable batches.

The reason to stage isn't technical risk from the migration itself, it's giving yourself a feedback loop. If something in your monitoring or tooling cares about volume type (it shouldn't, but it might), you want to find out on volume one, not volume eighty.

Rollback is symmetrical. Change the type back to gp2 and AWS runs another live ModifyVolume in reverse. No data loss, no downtime. We've never actually seen a rollback in practice, gp3 is strictly better, but the option is there.

If you manage EBS volumes in code (Terraform, CloudFormation, CDK), the change is a one line type swap. Just make sure the plan shows a modification, not a destroy-and-create. If your tool wants to replace the volume instead of modifying it in place, stop and figure out why before applying.

Conclusion

Migrating gp2 to gp3 is close to mechanical, but not quite. For volumes under 334 GiB, default gp3 is a strict upgrade. For larger volumes, calculate what the gp2 baseline IOPS and throughput were from the size and match them on gp3. Do that and the migration is safe across the fleet, with savings that hold up once you factor in the provisioning cost.

The hard part isn't the change. It's finding every gp2 volume across every account and region, and making sure none get forgotten. That's the part worth automating.