AWS waste pattern

How to estimate gp2 to gp3 savings before you migrate EBS volumes

Many AWS accounts still carry gp2 volumes simply because nobody revisited the default. For a large share of workloads, moving to gp3 reduces spend without changing the application architecture.

Most tools stop at visibility. OpsCurb treats findings like work: identify the resource, assign the owner, and keep follow-through visible until it closes.

Often low-risk optimizationCore Scan Role-first detection postureUseful across mature EBS fleets

Optional guided review

Tiered AWS access

Start with the Core Scan Role, add optional capabilities later, and review the public permission mapping before you connect.

Priority context

Frame the issue in monthly and annual impact so the cleanup gets prioritized and tracked.

Owner-ready next step

Use evidence, guardrails, and handoff language instead of raw AWS screenshots alone.

What the issue is

gp2 stayed the default for years, so many accounts still run volumes on a more expensive storage class than they need. The waste is subtle because the workload still performs well and nobody feels immediate pressure to change it.

This is a right-sizing problem, not an orphaned-resource problem. The volume is real and useful, but the storage type is often more expensive than necessary.

Legacy gp2 volumes created before teams standardized on gp3
Fleet-wide storage drift after years of incremental infrastructure changes
Volumes where provisioned performance is not actually needed

How to detect it in AWS

Start by listing gp2 volumes and grouping them by size, workload criticality, and environment. Then compare whether the current performance need actually requires the older pricing model.

For many startup workloads, the main question is not whether gp3 can work. It is whether anyone has created a tracked migration backlog to move the long tail.

List all volumes where VolumeType = gp2
Review IOPS and throughput requirements for each workload tier
Group candidates into low-risk dev and staging first, then production waves

How much it usually costs

The savings come from storage pricing differences, so larger and more numerous volumes make the impact meaningful quickly. Teams with broad EBS usage usually find this is a steady operational savings bucket rather than a one-time anomaly.

The easiest way to frame it is as monthly recurring savings across all remaining gp2 capacity, then annualize it to justify the migration pass.

Savings scale with total gp2 capacity still in use
Even modest per-volume savings matter when repeated across many disks
The ROI is strongest when you batch the migration into a single cleanup sprint

How to remediate it safely

The safe pattern is to validate workload requirements, migrate a small low-risk cohort first, and document exceptions that genuinely need a different storage profile.

Because this is optimization rather than deletion, teams can often move faster once they confirm the performance envelope and maintenance window.

Start with non-production volumes to validate process and monitoring
Track exceptions explicitly so critical workloads are not mixed into the first wave
Measure realized savings after the first batch to build confidence for the rest

How OpsCurb helps monitor it continuously

OpsCurb highlights gp2 volumes that are good gp3 candidates and estimates the recurring savings potential. That turns a vague infrastructure improvement into a prioritized backlog item with measurable upside.

It also helps teams avoid the usual trap: identifying the migration once, then never checking whether new gp2 volumes keep appearing later.

Flags migration candidates during Core Scan Role-first scans
Shows expected savings inside the same findings workflow as other AWS waste
Keeps storage optimization visible as an ongoing hygiene signal

FAQ

Questions buyers ask before they act

These are the friction points teams usually need to clear before they turn a likely savings opportunity into a real cleanup task.

Is gp2 to gp3 always the right move?

Not always. Some workloads need a specific performance profile, but many startup workloads can move to gp3 with little operational risk once requirements are checked.

Why does this get missed so often?

Because the volumes are attached and working, so there is no incident pressure. It becomes background spend drift unless someone reviews storage classes intentionally.