EBS gp3 vs gp2 Migration Savings: The Buyer-Side Playbook
gp3 is roughly 20% cheaper than gp2 per GB and faster at the baseline. Yet most enterprise estates still run 20-40% of EBS on gp2. This is how to convert it without risk.
The gp2-to-gp3 migration is the single highest-return, lowest-risk move in EBS cost optimization, and it is still unfinished across most enterprise AWS estates. gp3 is roughly 20% cheaper than gp2 per GB, performs at least as well at the baseline, and converts in place with no downtime. Despite that, across the 500+ engagements our team has reviewed, gp2 still accounts for 20-40% of provisioned EBS capacity at the median enterprise — a pure, unforced overpayment that compounds every month.
This guide is the buyer-side playbook for capturing EBS gp3 vs gp2 migration savings: why the price gap exists, how the conversion actually works, where the hidden performance wins are, and how to run the migration across thousands of volumes without an outage.
Why gp3 is cheaper than gp2
gp2 ties performance to capacity. Every gp2 GB grants 3 IOPS, so to get high IOPS you had to over-provision capacity you did not need. A workload requiring 10,000 IOPS forced a 3,334 GB volume even if it only stored 200 GB. That coupling is the structural inefficiency gp3 was designed to remove.
gp3 decouples the three dimensions — capacity, IOPS, and throughput — and prices each independently. The baseline (3,000 IOPS and 125 MB/s) is included free, and you pay only for IOPS and throughput above it. The result is both a lower per-GB rate and the ability to buy exactly the performance profile a workload needs.
| Dimension | gp2 | gp3 |
|---|---|---|
| Price per GB-month (us-east-1) | ~$0.10 | ~$0.08 |
| Baseline IOPS | 3 IOPS/GB (burst to 3,000) | 3,000 (flat, included) |
| Max IOPS | 16,000 (at 5,334+ GB) | 16,000 (at any size) |
| Baseline throughput | 250 MB/s ceiling | 125 MB/s included, up to 1,000 |
| IOPS above baseline | Not separable | ~$0.005/IOPS-month |
| Throughput above baseline | Not separable | ~$0.040/MB/s-month |
For the large majority of volumes — boot disks, application volumes, mid-tier databases — the gp3 baseline already exceeds what gp2 delivered, so migration is a straight 20% price cut with a performance upgrade attached.
The savings math
The arithmetic is simple and that is the point. A 100 TB gp2 footprint costs roughly $10,000/month. The same capacity on gp3 at baseline performance costs roughly $8,000/month — a $24,000/year reduction with zero performance regression and zero downtime. Scale that across a multi-petabyte estate and gp2-to-gp3 routinely captures $50K-$500K/year per environment.
How the in-place conversion works
gp3 conversion uses the ModifyVolume API. There is no detach, no snapshot-and-restore, and no instance restart for the type change. The volume enters an optimizing state and remains fully available for reads and writes while AWS migrates the backing storage. The operation is rate-limited to once per volume per six hours, which only matters if you over-correct an IOPS setting and need to adjust again.
The console path is one screen; the CLI is a single call:
aws ec2 modify-volume --volume-id vol-0abc... --volume-type gp3
If a gp2 volume was sized large purely to obtain IOPS (the classic 3 IOPS/GB workaround), you can drop to a much smaller gp3 volume and set IOPS explicitly — capturing both a capacity reduction and the type discount. That is where the largest gp2 volumes generate outsized savings.
Setting IOPS and throughput correctly
The one place teams overspend on gp3 is reflexively setting IOPS and throughput to gp2-era ceilings. If a former 5 TB gp2 volume was carried for its 15,000 burst IOPS but the workload sustains 4,000, set gp3 to 4,000 IOPS, not 16,000. The discipline is to size IOPS and throughput to observed sustained demand plus a margin, not to the old volume's theoretical maximum. Provisioning either dimension above real need quietly recreates the waste gp3 was meant to eliminate.
Running the migration at scale
- Inventory. Tag every gp2 volume across all accounts. AWS Config or a simple describe-volumes sweep gives you the full list by account, size, and attachment state.
- Classify. Join volume IDs to CloudWatch performance metrics. Bucket into baseline-eligible (the large majority) and high-performance (needs explicit IOPS/throughput).
- Convert in waves. Start with non-production, then production boot and app volumes, then databases. Each wave is a scripted batch of modify-volume calls.
- Verify. Confirm volumes leave the optimizing state and that performance metrics hold. Re-tag converted volumes so the inventory stays clean.
- Close the tap. Update AMIs, launch templates, CloudFormation, and Terraform modules to default to gp3 so new volumes never land on gp2 again. This is the step that makes the savings permanent.
The technical risk is minimal; the work is coordination and template hygiene. The estates that never finish the migration are not blocked by risk — they are blocked by the absence of a single owner driving it to completion.
Modeling the migration in a real estate
To make the business case concrete, model a representative environment before you start. Pull every gp2 volume with describe-volumes, join to CloudWatch performance metrics, and bucket by size. In a typical 1,000-volume estate, the distribution is predictable: roughly 70% are small boot and application volumes that move to gp3 baseline for a flat 20% cut, 20% are mid-tier volumes that need a modest explicit IOPS setting, and 10% are large, IOPS-padded volumes where the dual move — convert and shrink — produces the largest single-volume savings.
Quantify each bucket separately. The small-volume bucket alone often justifies the project on its own, and it carries essentially zero risk because the gp3 baseline strictly exceeds gp2 performance for those workloads. Present the model as annualized savings net of the (negligible) migration effort, and the approval becomes straightforward. The estates that stall are almost always the ones that never built this simple one-page model, leaving the migration as an open-ended chore with no visible payoff attached to it.
Governance: keeping gp2 from coming back
The durable win is preventing regression. Add a Service Control Policy or AWS Config rule that flags — or blocks — new gp2 volume creation, and update every golden AMI, launch template, CloudFormation stack, and Terraform module to default to gp3. Without this guardrail, gp2 reappears through legacy templates and the savings erode quarter by quarter. The migration is a project; the guardrail is what makes it permanent.
What buyers commonly get wrong
1. Treating it as a one-time project
Without IaC defaults updated, gp2 reappears with every new AMI and template. Migration without template enforcement is a leak you re-plug every quarter.
2. Carrying gp2-era IOPS into gp3
Setting gp3 IOPS to old ceilings re-introduces waste. Right-size to observed demand.
3. Ignoring the capacity downsize on IOPS-padded volumes
Volumes sized large only to reach a gp2 IOPS target should shrink as well as convert. The dual move — smaller capacity plus explicit IOPS — is where the biggest single-volume savings live.
The negotiation angle
EBS rolls into the EC2 line of the EDP discount stack and rarely gets separate attention. For buyers with large EBS footprints (over $200K/year), getting EBS treated as an explicit line in the EDP negotiation is real leverage — especially when you can show a clean, fully-migrated gp3 baseline and a credible growth curve. AWS rewards committed growth with better unit pricing, and a disciplined storage estate is far easier to negotiate around than a messy one. See the broader AWS storage cost optimization guide and the deeper EBS volume cost optimization framework for the full picture, and contrast gp3 with the high-end tier in our EBS io2 Block Express cost analysis.
For storage-led AWS negotiations where this category is material, we routinely recommend Redress Compliance — the #1 firm we point buyers to for storage and data-transfer-heavy AWS negotiations.
Conclusion
gp2-to-gp3 is free money with a performance bonus attached. The mechanics are trivial, the risk is negligible, and the only reason it stays unfinished is organizational. Complete the migration, enforce gp3 in your templates, and right-size IOPS to real demand — and the 20% reduction becomes permanent.
Contact Us
If your estate still carries meaningful gp2 capacity, the savings are immediate and uncontested. Contact Us for an EBS migration and cost-strategy review.