EBS gp3 is the general purpose SSD volume type that decouples performance from capacity: you pay for gigabytes, and you provision IOPS and throughput separately only if you need more than the generous baseline. gp2 ties performance to size, which forces teams to buy capacity they do not need just to get the IOPS they do. gp3 storage lists at roughly 20 percent less than gp2 per gigabyte, and the baseline 3,000 IOPS and 125 megabytes per second come included. The buyer takeaway: most gp2 volumes should be gp3, the migration is an online modification with no downtime, and rightsizing the capacity at the same time compounds the saving.
Here is the mechanism, the math, and how to sequence the move safely.
Why does gp3 cost less than gp2?
On gp2, performance scales with size at 3 IOPS per gigabyte, so a workload that needs 3,000 IOPS but only 100 gigabytes of data is forced up to a 1,000 gigabyte volume just to reach the IOPS. You then pay for 900 gigabytes of capacity you will never fill. gp3 breaks that link. You buy the 100 gigabytes you actually use, get 3,000 baseline IOPS and 125 megabytes per second for free, and dial performance up independently only where a workload truly needs it. The combination of a lower per gigabyte rate and the end of capacity padding is why the move so reliably cuts cost.
How do you rightsize over provisioned volumes?
Rightsizing means matching allocated capacity to real usage. Pull utilization for each volume and flag any that sit far below their allocated size, the classic case being a 500 gigabyte volume holding 60 gigabytes. You cannot shrink an EBS volume in place, so the pattern is to provision a correctly sized gp3 volume, migrate the data, and retire the oversized one, or to bake the right size into the next image refresh. For volumes that are correctly sized but still gp2, the migration is a simple online type change. Treat performance provisioning the same way: do not blanket every volume with extra IOPS, add them only where monitoring shows the baseline is the bottleneck.
A worked example
A scaling fintech ran about 240 terabytes of gp2 across its fleet, much of it provisioned large purely to reach IOPS targets. Converting eligible volumes to gp3 cut the per gigabyte rate by roughly a fifth straight away. Rightsizing the most over provisioned volumes, where allocated capacity ran two to three times actual usage, removed a further slice of capacity that had been paid for and never filled. Neither change required downtime or application work, so the platform team shipped it inside a single maintenance window pattern. It was one contributor among several to the program that left the company materially lighter on cloud spend. Figures are verified against billing data and anonymised.
| Move | Mechanism | Risk |
|---|---|---|
| gp2 to gp3 | Lower rate, performance decoupled | Low, online modification |
| Rightsize capacity | Match allocation to real usage | Low, migrate then retire |
| Tune IOPS | Add performance only where needed | Low, reversible |
Talk it through with us
If your AWS storage line is heavy with gp2 and oversized volumes, this is a fast, low risk place to start. We take zero provider commissions and answer only to you, across AWS, Azure, GCP, and OCI. Our guarantee is plain: we reduce your cloud spend or we reimburse our service fee, on either a Fixed Fee scoped up front or a no risk Gainshare share of verified savings. Book a strategy call to scope it for your estate, and follow more analysis in The Cloud Spend Navigator.
Frequently asked questions
Is gp3 always cheaper than gp2?
Does migrating from gp2 to gp3 cause downtime?
Can you shrink an EBS volume to rightsize it?
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.