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.