EBS gp2-to-gp3 Savings: Calculate the Real Cost

AWS advertises a 20 percent lower storage price per gigabyte for gp3 compared to gp2. That percentage represents a storage-rate difference rather than a guaranteed reduction in your total monthly bill. Because the gp3 volume type introduces separate charges for provisioned IOPS and throughput above its included baseline, swapping a volume without analyzing its performance demand can increase your cloud spend.

To manage the financial risk of infrastructure changes, route them through an approval-first workflow. FinOps AI does not raise gp2-to-gp3 findings or modify volumes, so this migration stays in your own change process. Where FinOps AI does act on EBS, for example deleting an unattached volume, the change goes through approval and guardrails, gets a post-action check, and its estimated saving is booked and re-checked about seven days later.

Evaluating the baseline costs of a gp2-to-gp3 conversion

AWS storage rates alone make the gp3 volume type look universally cheaper. At standard illustrative rates, gp3 storage prices sit at $0.08 per GB-month, while gp2 storage costs $0.10 per GB-month, yielding a 20 percent price difference for the storage capacity itself. The total invoice calculation changes, however, because gp3 separates performance from capacity.

An active database or a high-throughput application will require more than the 3,000 IOPS and 125 MB/s of throughput included in the base gp3 price, and every unit of performance configured above those baselines adds a discrete charge to the monthly cost. Savings depend directly on the specific settings the workload demands, which means an equivalent-performance volume might yield a 10 percent cost reduction, a 5 percent drop, or even cost more than the original resource.

Evaluating the financial impact before altering the storage layer prevents billing surprises. Run the change the way you would any production change: record why each volume should move, review the estimated cost impact, and get the change approved. A staged rollout ensures you can test a small cohort of volumes, verify the new performance profile, and evaluate the result. This structure separates the approval and tracking of the cost optimization from the technical EBS profiling performed before setting the target values.

Calculating EBS gp2 to gp3 savings

Building an accurate estimate for EBS gp2 to gp3 savings requires comparing the original capacity-driven gp2 cost against the distinct capacity, IOPS, and throughput variables of the new volume. AWS publishes benchmark illustrative USD pricing for Amazon EBS General Purpose Volumes that demonstrates how these charges accumulate. In these examples, gp2 storage is priced at $0.10 per GB-month, while gp3 storage costs $0.08 per GB-month and includes 3,000 IOPS and 125 MB/s of throughput at no additional cost. Configuring additional gp3 IOPS adds $0.005 per provisioned IOPS-month, and extra throughput costs $0.04 per provisioned MB/s-month.

Constructing the comparison requires calculating both sides of the equation using the selected AWS Region’s specific rates in this monthly formula:

gp2 monthly cost = provisioned capacity × gp2 rate

gp3 monthly cost = provisioned capacity × gp3 rate + max(0, target IOPS − 3,000) × IOPS rate + max(0, target throughput − 125) × throughput rate

Monthly savings equal the gp2 monthly cost minus the gp3 monthly cost, and you calculate the savings percentage by dividing that figure by the original gp2 monthly cost.

Applying this formula to a 2,000-GiB gp2 volume illustrates why the 20 percent storage-rate reduction does not automatically translate to a 20 percent total savings for high-performance workloads. Under standard gp2 performance rules, a 2,000-GiB volume receives a baseline of 6,000 IOPS, and volumes of at least 334 GiB also receive a 250-MiB/s throughput limit.

The gp2 volume costs $200 per month (2,000 GiB × $0.10). Matching that exact performance profile on gp3 requires provisioning 6,000 IOPS and 250 MiB/s of throughput. The gp3 storage capacity costs $160 per month (2,000 GiB × $0.08), while the required IOPS exceed the included baseline by 3,000, adding $15 per month (3,000 × $0.005). Because the required throughput exceeds the baseline by 125 MiB/s, that adds another $5 per month (125 × $0.04). The resulting gp3 volume costs $180 per month, saving $20 or 10 percent compared to the gp2 original.

Keeping the arithmetic consistent supports accurate planning, and the AWS Pricing Calculator lets you estimate costs for specific workloads. Because AWS notes that fees depend on service usage, model the workload you plan to run.

These examples rely on monthly calculations based on provisioned performance, rather than the performance the workload consumes. Because AWS bills gp3 storage, IOPS, and throughput in per-second increments with a 60-second minimum, actual invoiced costs depend on exactly how long each configuration remains provisioned during the billing cycle. Prices vary by AWS Region, so check the AWS Pricing Calculator for the specific region hosting the volume before authorizing a modification.

Check workload performance before setting gp3 IOPS and throughput

Understanding why the original gp2 capacity affects the comparison requires looking at how AWS provisions performance for older volume types. The EBS General Purpose SSD documentation notes that gp2 IOPS scale directly with volume size at a rate of 3 IOPS per GiB, enforcing a minimum of 100 IOPS and a maximum of 16,000 IOPS. gp2 volumes smaller than 1 TiB and provisioned with less than 3,000 IOPS can burst to 3,000 IOPS when they have I/O credits available.

Throughput on gp2 volumes also depends on size: volumes measuring 170 GiB or smaller deliver up to 128 MiB/s, eligible volumes larger than 170 GiB but smaller than 334 GiB can burst up to 250 MiB/s, and volumes of 334 GiB or larger deliver up to 250 MiB/s continuously.

By contrast, the gp3 architecture removes this dependency on capacity. The volume includes 3,000 IOPS and 125 MiB/s of throughput regardless of its size, so performance does not rely on a bursting mechanism or accumulated credits. You configure capacity, IOPS, and throughput independently to access higher available limits subject to specific volume and instance constraints. Since Outposts deployments enforce different gp3 performance boundaries, these rules apply specifically to standard AWS Regions.

To select EBS performance targets, monitor workload IOPS and throughput against the volume's provisioned limits. But average IOPS and throughput metrics can understate bursts shorter than a minute, so check the VolumeIOPSExceededCheck and VolumeThroughputExceededCheck metrics as well. While analyzing those spikes, review application latency, I/O size, and volume queue length. AWS defines volume queue length as the number of pending I/O requests, while latency is the end-to-end time from sending an I/O to EBS to receiving a completion acknowledgment. That same EBS I/O characteristics and monitoring documentation explains that, for SSD-backed volumes, a workload with large I/O sizes can hit the volume's throughput limit before its IOPS limit.

Accounting for gp2 burst behavior remains a core requirement for smaller volumes. The BurstBalance metric displays the remaining percentage of gp2 I/O credits for an eligible volume. Sampling performance during a period of low demand or while the volume holds a healthy credit balance might mask the sustained performance requirements the application demands during heavy usage.

Volume configurations represent only one side of the performance equation, as the host EC2 instance also applies limits to storage operations. Accordingly, overall EBS performance is bounded by the instance's Amazon EBS optimized performance limits or by the aggregate performance of its attached volumes, whichever value is lower. That means provisioning a volume with more IOPS than the instance can support cannot raise EBS performance above the instance's limit. Checking both boundaries helps avoid provisioning volume performance that the compute layer cannot use.

Stage the volume change without assuming defaults

Transitioning infrastructure requires a bounded rollout strategy. After choosing explicit gp3 settings based on the workload evidence gathered during the measurement phase, you estimate the new monthly cost and obtain formal approval from workload owners. Validating a small representative cohort is recommended before expanding the modification across the environment.

Omitting explicit performance settings during the gp2-to-gp3 modification leaves the decision to AWS's defaults. When IOPS and throughput are left unspecified, AWS provisions either the equivalent source performance or the gp3 baseline, whichever is higher. The Elastic Volumes modification guide details this behavior: converting a 500-GiB gp2 volume running at 1,500 IOPS and 250 MiB/s of throughput without specifying new settings results in a gp3 volume provisioned at 3,000 IOPS and 250 MiB/s. The extra 125 MiB/s is billed above the gp3 baseline: in US East (N. Virginia) that volume costs about $45 a month, against $50 on gp2 and $40 if left at the gp3 baseline. Check whether the workload needs that throughput before you accept the default, and review a concrete cost estimate before you submit the change.

For instances supporting the Elastic Volumes feature, modifying a volume from gp2 to gp3 can occur without detaching the resource or restarting the instance. This online modification process can take anywhere from a few minutes to several hours depending on the volume size and activity. Once you submit the modification request, it cannot be canceled. The new gp3 configuration begins accruing charges as soon as the modification starts, even while the optimization process continues in the background.

Treating the approval stage as a pre-change checkpoint provides a safeguard because modifying a volume initiates an immediate billing change. A supported reversal requires initiating a distinct, corrective modification rather than canceling the pending request. FinOps AI does not modify EBS volumes, so its guardrails and approvals do not cover this change: keep the review, the limit on how many volumes change at once, and the evidence behind the new IOPS and throughput targets in your own change process.

Separate the concept of type conversion from capacity rightsizing, as the ModifyVolume API does not allow you to decrease the size of an EBS volume. Historically, administrators often overprovisioned gp2 capacity to acquire a higher IOPS baseline, leaving terabytes of storage empty. Recovering the cost of that unused capacity requires migrating the data to a new, smaller volume, because you cannot perform an in-place resize to shrink it.

Verify performance and savings after conversion

Completing the remediation loop involves comparing post-change metrics against the original workload baseline and service objectives. Monitor the application latency, volume queue length, achieved IOPS, and utilized throughput during representative peak loads and scheduled batch jobs. Confirming that the resulting gp3 volume settings match the approved target values ensures the infrastructure aligns with the initial cost estimate. If the application misses its performance objectives after the conversion, pause the expansion of the rollout and address the issue by provisioning higher IOPS or throughput through a supported, corrective modification request.

Reconciling expected monthly savings with actual charges validates the financial outcome of the project. Because AWS documents distinct usage types for EBS components within its cost and usage data, review the billing and usage reports for Amazon EBS for the specific account, Region, and billing period. Look separately at the consumption lines for gp2 storage, gp3 storage, gp3 IOPS above 3,000, and gp3 throughput above 125 MB/s.

Comparing these distinct billing components confirms whether the gp2 storage usage dropped as expected and whether the newly added gp3 performance charges match the approved configuration. Account for how long each volume configuration was active during the month, since mid-month modifications result in prorated billing for both volume types.

Once the final cost is confirmed on your bill, record the result where finance can see it; FinOps AI's cost trend shows the change in your AWS spend. A structured workflow helps every storage modification balance cost reduction with performance stability, turning a theoretical rate difference into a measured reduction in your actual cloud spend.

---

Ready to route cloud waste findings through an approval-gated workflow? Use FinOps AI to find AWS waste, route supported fixes through approvals and guardrails, and track the savings that held.