Why Are gp3 Volumes More Cost-Effective Than gp2 on EC2?

Decoupling storage performance from storage capacity allows Amazon EBS gp3 volumes to deliver significant cost savings compared to legacy gp2 volumes. Under the older gp2 pricing model, Input/Output Operations Per Second (IOPS) and throughput scale linearly with the size of the provisioned disk, often forcing users to buy terabytes of unnecessary storage just to achieve higher disk performance. With gp3 volumes, AWS offers a lower baseline price per gigabyte while providing a consistent baseline of 3,000 IOPS and 125 MiB/s of throughput regardless of volume size. When workloads require additional speed, administrators can provision extra IOPS and throughput independently without paying for unused gigabytes of capacity.

How the Legacy gp2 Performance Model Works

In the Amazon Elastic Block Store (EBS) gp2 architecture, performance is directly tied to the provisioned storage capacity of the volume. A gp2 volume earns baseline performance at a rate of 3 IOPS per gigabyte of storage, up to a maximum of 16,000 IOPS. The mathematical relationship for gp2 baseline IOPS is defined as:

\[\text{IOPS}_{\text{gp2}} = \min(\max(100, 3 \times \text{Size in GiB}), 16000)\]

While volumes smaller than 1,000 GiB can temporarily burst up to 3,000 IOPS using a burst bucket credit system, sustaining high performance requires provisioning a larger disk. Once the burst credits are depleted, performance drops back to the baseline of 3 IOPS per GiB.

Throughput on gp2 is similarly constrained by volume size:

  • Volumes of 170 GiB or less deliver a maximum of 128 MiB/s.
  • Volumes between 170 GiB and 334 GiB can burst up to 250 MiB/s if burst credits are available.
  • Volumes of 334 GiB or larger deliver a flat 250 MiB/s, regardless of how much larger they grow.

This linear coupling creates a costly inefficiencyknown as over-provisioning for performance. If a database only requires 100 GiB of actual disk space but needs a sustained 6,000 IOPS to handle transactional load, an administrator using gp2 must provision a 2,000 GiB volume (\(\frac{6000}{3} = 2000\text{ GiB}\)). In this scenario, the organization pays for 1,900 GiB of completely empty storage solely to unlock the required IOPS.

How Decoupling Works in gp3 Volumes

Amazon EBS gp3 eliminates the linear relationship between disk size and disk speed. Every gp3 volume, whether it is 1 GiB or 16 TiB, includes an unthrottled, non-bursting baseline performance of:

  • 3,000 IOPS at no additional cost.
  • 125 MiB/s throughput at no additional cost.

Beyond this baseline, storage capacity, IOPS, and throughput act as three independent sliders:

  1. Storage Capacity: Priced at \(\$0.08\) per GiB-month (in us-east-1), which is \(20\%\) lower than gp2's price of \(\$0.10\) per GiB-month.
  2. Additional IOPS: Can be provisioned up to 16,000 IOPS for \(\$0.005\) per provisioned IOPS-month above the free 3,000 baseline (maintaining a maximum ratio of 500 IOPS per GiB).
  3. Additional Throughput: Can be provisioned up to 1,000 MiB/s for \(\$0.04\) per provisioned MiB/s-month above the free 125 MiB/s baseline (maintaining a maximum ratio of 0.25 MiB/s per provisioned IOPS).

Direct Cost and Performance Scenarios

To understand the financial impact of decoupling, we can model the monthly cost of gp2 versus gp3 using standard US East (N. Virginia) pricing.

For a gp2 volume, the monthly cost is solely a function of the capacity needed to satisfy both space and IOPS requirements:

\[\text{Cost}_{\text{gp2}} = \text{GiB}_{\text{provisioned}} \times \$0.10\]

For a gp3 volume, the monthly cost is the sum of the actual capacity required plus any performance provisioned above the baseline:

\[\text{Cost}_{\text{gp3}} = (\text{GiB} \times \$0.08) + (\max(0, \text{IOPS} - 3000) \times \$0.005) + (\max(0, \text{Throughput} - 125) \times \$0.04)\]

Scenario 1: Small Boot or Application Volumes (100 GiB)

Consider a standard 100 GiB EC2 root volume or microservice datastore.

  • On gp2: A 100 GiB volume costs \(100 \times \$0.10 = \$10.00\) per month. It provides a baseline of 300 IOPS (with temporary bursting to 3,000 IOPS) and 128 MiB/s of throughput.
  • On gp3: A 100 GiB volume costs \(100 \times \$0.08 = \$8.00\) per month. It provides a sustained, permanent baseline of 3,000 IOPS and 125 MiB/s of throughput without relying on burst credits.

By switching to gp3, the user saves \(20\%\) on monthly storage costs while gaining a \(10\times\) increase in sustained baseline IOPS.

Scenario 2: High-IOPS, Low-Capacity Databases

Consider a relational database that stores 200 GiB of data but requires a sustained 6,000 IOPS and 250 MiB/s of throughput to prevent query latency during peak hours.

  • On gp2: To get 6,000 sustained IOPS without exhausting burst credits, you must provision a 2,000 GiB volume (\(6000 / 3 = 2000\)). At \(\$0.10\) per GiB, the monthly cost is: \[\text{Cost}_{\text{gp2}} = 2000 \times \$0.10 = \$200.00\text{ per month}\]
  • On gp3: You only need to provision the 200 GiB of storage you actually use, and then independently add 3,000 extra IOPS (to reach 6,000 total) and 125 MiB/s of extra throughput (to reach 250 MiB/s total): \[\text{Storage Cost} = 200 \times \$0.08 = \$16.00\] \[\text{IOPS Cost} = (6000 - 3000) \times \$0.005 = \$15.00\] \[\text{Throughput Cost} = (250 - 125) \times \$0.04 = \$5.00\] \[\text{Total Cost}_{\text{gp3}} = \$16.00 + \$15.00 + \$5.00 = \$36.00\text{ per month}\]

In this scenario, decoupling capacity from performance reduces the monthly EBS bill from \(\$200.00\) to \(\$36.00\), representing an \(82\%\) cost reduction for identical IOPS and throughput.

Scenario 3: High-Throughput Sequential Workloads

Workloads such as big data analytics, log processing, and Kafka brokers often require high sequential throughput rather than massive capacity or extreme IOPS. Suppose an application needs 500 GiB of storage, 3,000 IOPS, and 500 MiB/s of throughput.

  • On gp2: A single gp2 volume is hard-capped at 250 MiB/s of throughput regardless of size. To achieve 500 MiB/s with gp2, an administrator would have to provision multiple volumes (at least two 334+ GiB volumes) and stripe them together using RAID 0 at the operating system level, adding operational complexity and increasing failure domains.
  • On gp3: A single 500 GiB gp3 volume can be configured with 500 MiB/s of throughput directly. The cost is \((500 \times \$0.08) + ((500 - 125) \times \$0.04) = \$40.00 + \$15.00 = \$55.00\) per month, eliminating the need for software RAID arrays.

Additional Operational Advantages of Decoupling

Beyond raw monthly cost savings, separating IOPS and throughput from disk size solves several operational challenges in AWS environments:

  • Elimination of the Burst Bucket Cliff: Small and medium gp2 volumes (< 1,000 GiB) rely on I/O credits that accumulate when demand is low and drain when demand exceeds 3 IOPS/GiB. Many production outages occur when a database runs smoothly for hours on burst credits, exhausts its bucket, and suddenly drops from 3,000 IOPS to 300 IOPS. Because gp3 provides 3,000 baseline IOPS permanently without a credit system, performance remains predictable under sustained load.
  • Right-Sizing Without Shrinking Disks: In Amazon EBS, you can increase the size of a volume online, but you cannot decrease the size of an existing volume without creating a new smaller volume and migrating data at the filesystem level. Under gp2, if you scaled a disk up to 3,000 GiB for a temporary holiday traffic spike (to get 9,000 IOPS), you were stuck paying for 3,000 GiB forever unless you performed a complex migration. With gp3, you can dynamically dial IOPS and throughput up for a traffic event and dial them back down afterward using Elastic Volumes, without ever inflating the underlying disk capacity.