awsebsstoragecost-optimization

EBS gp2 vs gp3: why gp3 is almost always cheaper

gp3 is the newer general-purpose EBS volume type, and for most workloads it costs about 20 percent less than gp2 while delivering baseline performance that gp2 could only reach at large sizes. Here is why, and when to migrate.

The C3X Team··5 min read

Quick answer

gp3 costs about 20 percent less per GB than gp2 and decouples performance from size: every gp3 volume includes a baseline of about 3,000 IOPS and 125 MB/s of throughput regardless of capacity, with extra performance available for a small additional charge. For the vast majority of general-purpose volumes, migrating from gp2 to gp3 lowers cost with equal or better performance, and the migration is an online modification with no downtime. The main case to check is very large gp2 volumes that were relying on gp2's size-linked IOPS, where you may need to add provisioned IOPS or throughput on gp3.

gp2 and gp3 are both general-purpose SSD EBS volume types, but gp3 is newer, cheaper, and more flexible. If you are still running gp2 volumes, migrating to gp3 is one of the easiest cost wins in AWS: about 20 percent off the per-GB rate for equal or better performance, with an online change and no downtime.

The core difference: performance is unbundled

Aspectgp2gp3
Per-GB priceBaselineAbout 20 percent lower
IOPSScales with size (3 IOPS per GB)3,000 baseline, independent of size
ThroughputTied to size and IOPS125 MB/s baseline, independent of size
Extra performanceOnly by growing the volumeProvisioned separately for a fee

On gp2, IOPS scaled with volume size at roughly 3 IOPS per GB, so to get 3,000 IOPS you needed a 1 TB volume whether or not you needed the space. gp3 breaks that link: every volume starts with about 3,000 IOPS and 125 MB/s regardless of size, and you provision more only if you need it. That is why gp3 is both cheaper and more flexible: you stop paying for capacity just to buy performance.

Why gp3 is usually cheaper

Two effects stack. First, the base per-GB rate is about 20 percent lower on gp3. Second, many gp2 volumes were oversized purely to reach an IOPS target, and on gp3 you can shrink the performance-driven padding because the baseline 3,000 IOPS comes free. For a fleet of gp2 volumes, migrating typically cuts EBS spend noticeably with no performance loss. It is the same class of easy, low-risk win as choosing Graviton instances where they fit.

The one case to check

The exception is very large gp2 volumes that were genuinely using their size-linked IOPS (a 4 TB gp2 volume delivering around 12,000 IOPS, for example). On gp3 those need explicitly provisioned IOPS above the 3,000 baseline, which carries an added charge. Even then gp3 is often cheaper or comparable, but you should price the provisioned IOPS and throughput rather than assume the flat 20 percent. For workloads needing sustained high IOPS, also compare against io2 vs gp3.

How to migrate safely

Changing a volume from gp2 to gp3 is an online ElasticVolumes modification: no snapshot, no detach, no downtime. Set the target IOPS and throughput (start at the 3,000 and 125 MB/s baseline, add more only if monitoring shows you need it), apply the change, and the volume type updates in place. Roll it out fleet-wide and it becomes a large, safe reduction. While you are auditing EBS, also watch snapshot cost creep, which often exceeds volume cost, and review how EBS compares to shared file storage in EFS vs EBS cost.

FAQ

Is gp3 cheaper than gp2?

Yes. The gp3 per-GB rate is about 20 percent lower than gp2, and gp3 includes a baseline of roughly 3,000 IOPS and 125 MB/s throughput at no extra charge regardless of volume size. For most general-purpose volumes, migrating from gp2 to gp3 lowers cost with equal or better performance. The migration is an online change with no downtime.

What is the main difference between gp2 and gp3?

gp3 unbundles performance from capacity. On gp2, IOPS scaled with size at about 3 IOPS per GB, so reaching high IOPS meant buying a large volume. gp3 gives every volume a baseline of about 3,000 IOPS and 125 MB/s regardless of size, and you provision more separately only if needed. This makes gp3 both cheaper and more flexible.

How do I migrate from gp2 to gp3?

Use an online volume modification (ElasticVolumes): no snapshot, detach, or downtime required. Set the target IOPS and throughput, starting at the 3,000 IOPS and 125 MB/s baseline and adding more only if monitoring shows you need it, then apply the change and the volume type updates in place. Roll it out across your fleet for a large, safe cost reduction.

When might gp3 not be cheaper than gp2?

For very large gp2 volumes that were genuinely using their size-linked IOPS (for example a multi-TB volume delivering well above 3,000 IOPS). On gp3 that performance must be provisioned explicitly above the baseline, which adds a charge. gp3 is still often cheaper or comparable, but you should price the provisioned IOPS and throughput rather than assume a flat 20 percent saving.

Does gp3 have lower performance than gp2?

No, generally the opposite. gp3's baseline 3,000 IOPS exceeds what small and mid-size gp2 volumes deliver, since gp2 only reaches 3,000 IOPS at 1 TB. gp3 also lets you provision up to much higher IOPS and throughput independently of size. For most workloads gp3 offers equal or better performance at lower cost, which is why it is the recommended default.

Should I use gp3 or io2 for high-IOPS workloads?

gp3 covers most needs up to its provisioned limits and is cheaper for general-purpose use. io2 (and io2 Block Express) targets workloads needing very high sustained IOPS, higher durability, or IOPS beyond gp3's ceiling, such as large transactional databases. Compare the provisioned-IOPS pricing of both for your target performance, since io2's per-IOPS charges can make it more expensive except where you truly need its guarantees.

What to do next

Price your EBS volumes before you provision them. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.

Try C3X on your own Terraform

Free and open source. No API key required. One command to install, one command to estimate.