EBS gp3 volumes offer lower per-GB pricing and configurable baseline IOPS and throughput compared to legacy gp2 volumes. This finding flags attached or available volumes still on gp2 where an in-place migration to gp3 is strictly cheaper at the same effective performance.
This is different from orphaned EBS volumes: orphaned volumes are unattached and wasting storage charges entirely, while gp2 volumes may be actively in use but on an older volume type.
Before you migrate
- Confirm the volume is not part of a legacy application that explicitly requires gp2 (rare, but check runbooks).
- Review current IOPS and throughput needs — gp3 defaults may differ from gp2 burst behavior on smaller volumes.
- Take a snapshot first if the volume holds data you cannot recreate; type changes are in-place but snapshots provide a rollback point.
- Schedule the change during a maintenance window for production volumes; the modify call is usually non-disruptive but applications sensitive to brief latency spikes should be monitored.
Paid plans include remediation scripts that modify the volume type to gp3. No detach or instance stop is required for the migration.
What triggers this finding
An attached or available EBS volume still on the gp2 volume type instead of gp3.
Typical fix
Modify the volume type to gp3 in place. No detach or snapshot is required for the migration.
Example savings
About 20% lower per-GB storage cost compared to gp2 — e.g. $2–$20+/month on larger volumes.
See also: Severity and savings estimates for how Parsivex calculates figures on your report.
Two pricing models, not one cheaper rate
The headline is that gp3 storage costs $0.08 per GB-month against gp2's $0.10, a flat 20% off in us-east-1. The complication is that the two types bundle performance differently, and the bundle is where the arithmetic actually happens.
On gp2, performance is welded to size. You get 3 IOPS per GB — floored at 100 and capped at 16,000 — and a throughput ceiling of 128 MB/s below 170 GB or 250 MB/s above it. None of that is separately priced; you buy it by buying capacity.
On gp3, performance is unbundled. Every volume includes 3,000 IOPS and 125 MB/s regardless of size, and anything beyond that is bought explicitly at $0.005 per provisioned IOPS-month and $0.04 per provisioned MB/s-month.
Parsivex estimates the saving conservatively, by pricing a gp3 volume that matches the gp2 volume's ceiling exactly: same capacity, enough provisioned IOPS to reach 3 IOPS per GB, and enough provisioned throughput to reach 128 or 250 MB/s. A volume is only reported when that like-for-like comparison saves more than $1 a month.
Where the threshold actually lands
Working that model through produces three distinct bands, and they are not intuitive.
Below 170 GB, gp3 needs just 3 MB/s of extra throughput — twelve cents a month — so the storage discount dominates almost immediately. Volumes from about 57 GB upward clear the $1 floor.
Between 171 GB and 300 GB, the picture inverts. Crossing 170 GB pushes gp2's throughput ceiling to 250 MB/s, which costs $5.00 a month to reproduce on gp3, and that lands in one step. A 171 GB volume costs $17.10 on gp2 and $18.68 on the matched gp3 configuration — genuinely more expensive. Break-even sits at 250 GB, and the finding does not appear again until about 301 GB.
Above 1,000 GB, gp2's IOPS entitlement passes 3,000 and gp3 starts paying for the excess, but the storage discount still wins comfortably: a 2 TB volume saves roughly $20 a month, a 16 TB volume several hundred.
So a gp2 volume that produces no finding is usually small, or sitting in that 171–300 GB dead zone. Neither is a bug.
The number is a floor, not a forecast
The matched-ceiling model is the conservative reading, and for most volumes it understates the saving substantially.
Very few workloads actually consume 250 MB/s. If yours does not, you can leave gp3 at its included 125 MB/s baseline and pay nothing for throughput at all — which turns that $5.00 line into zero and makes volumes throughout the 171–300 GB dead zone worth migrating even though no finding was raised for them. Check the real numbers before assuming the ceiling matters:
aws cloudwatch get-metric-statistics --namespace AWS/EBS \
--metric-name VolumeReadBytes \
--dimensions Name=VolumeId,Value=vol-0123456789abcdef0 \
--start-time 2026-07-13T00:00:00Z --end-time 2026-08-12T00:00:00Z \
--period 86400 --statistics Sum Maximum
Small volumes gain in the other direction. A 100 GB gp2 has a baseline of just 300 IOPS and relies on burst credits to reach 3,000; the same volume on gp3 gets a flat 3,000 IOPS with no credit balance to exhaust. The migration is a performance upgrade there, not only a discount.
Cases where gp2 stays
The detector does not filter by volume state, so both attached and unattached gp2 volumes are reported. An unattached one will usually also appear as an orphaned EBS volume — delete it rather than migrating it, and both findings resolve at once.
Beyond that, the genuine exceptions are few: volumes about to be deleted or resized as part of other work, volumes whose burst-credit behaviour a legacy application has been tuned against, and volumes governed by a vendor support matrix that names gp2 explicitly. Boot volumes are not an exception — gp3 is fully supported as a root device.
In-place, online, and reversible
This is the least disruptive fix Parsivex reports. modify-volume changes the type on a live volume with no detach, no instance stop, and no snapshot-and-restore cycle. The volume moves through modifying and optimizing states while AWS works, stays fully readable and writable throughout, and performs at no worse than its original level during the transition. Nothing is unmounted and no file system operation is required.
aws ec2 modify-volume --volume-id vol-0123456789abcdef0 --volume-type gp3
Two operational limits are worth knowing. A volume can only be modified once every six hours, so a mistake is not instantly correctable — you can move back to gp2, but not immediately. And optimization on a large volume can take hours to complete in the background, even though the volume is usable the whole time.
As with every EBS change, update the infrastructure code that created the volume. A launch template or Terraform module still specifying gp2 will recreate the old type on the next replacement, and the finding returns.