gp3 has been the recommended default EBS volume type for years now, and AWS has never forced a migration off gp2 to get there. That means a huge number of accounts are still running volumes created years ago on gp2 by default, simply because nothing broke and nobody went back to change it.
Why gp3 is usually the better default
gp2 ties performance to volume size: IOPS scale with capacity, up to a cap, with a burst-credit system for smaller volumes that can throttle hard once credits run out. gp3 decouples performance from size entirely — every gp3 volume gets a baseline of 3,000 IOPS and 125 MB/s throughput regardless of how small it is, with the option to provision more of either independently, for an additional cost, if the workload actually needs it.
On top of that, gp3's per-GB price is lower than gp2's. For a volume that doesn't need more than baseline performance — which describes most general-purpose volumes — that's a straightforward reduction in the storage bill for equal or better performance, with no application changes required.
Relative comparison, not to scale — check AWS's current EBS pricing page for exact per-GB rates in your region.
The migration itself
Converting a volume from gp2 to gp3 is an in-place modification through the EC2 console, CLI, or API — no downtime, no data migration, no detach/reattach. The volume keeps its data and its attachment; only the underlying type and billing change. This is one of the lowest-risk changes available on an AWS bill, which is part of why it tends to sit unaddressed — there's no incident forcing the conversation.
The part worth checking before you migrate everything
The lower per-GB price only tells half the story. If a volume is actually using IOPS or throughput above gp3's baseline — a busy database volume, for example — provisioning that extra performance on gp3 has its own cost, and for a high-performance volume that cost can erode or exceed the per-GB savings. Before converting everything in bulk, it's worth pulling CloudWatch IOPS and throughput metrics for anything performance-sensitive to confirm baseline gp3 actually covers it, or to size the provisioned performance correctly rather than over-provisioning out of caution.
For the large majority of general-purpose volumes — boot volumes, low-traffic application volumes, anything that was never IOPS-constrained on gp2 in the first place — the answer is simple: they were never using more than gp3's baseline, and converting them is a pure cost reduction with no performance trade-off to think about.