gp3 volumes cost about 20% less than gp2 for the same size and give every volume 3,000 IOPS as a baseline. Here is how to find your gp2 volumes, size gp3 correctly, and convert them online.
Amazon EBS gp3 replaced gp2 as the general-purpose SSD in 2020, yet most AWS accounts we review still have more gp2 than gp3. The reason is simple: nothing ever forces the change, and the default in older launch templates, AMIs and infrastructure code is still gp2. The change is worth making. In us-east-1, gp3 storage lists at $0.08 per GB-month against $0.10 for gp2, about 20% less for the same size, and the conversion runs while the volume stays attached and in use.
This guide shows how to find every gp2 volume, how to give each one the right gp3 performance so nothing slows down, and how to convert them in place.
How gp2 and gp3 differ
The two types price performance differently, and that is the one thing to get right before converting.
| gp2 | gp3 | |
|---|---|---|
| Baseline IOPS | 3 per GB, at least 100 | 3,000 for any size |
| Burst | up to 3,000 IOPS on volumes under 1,000 GB, from a credit bucket | no bursting: the baseline is always available |
| Throughput | up to 250 MB/s, depending on size | 125 MB/s included, up to 1,000 MB/s for an extra charge |
| Extra IOPS | only by making the volume bigger | up to 16,000, paid separately from size |
For volumes under about 1 TB, gp3's included 3,000 IOPS and 125 MB/s meet or beat what gp2 actually delivers, so the conversion is a straight saving. Larger gp2 volumes get more than 3,000 IOPS from their size (a 2,000 GB gp2 volume has 6,000), so their gp3 replacement should be given the same IOPS explicitly. Even with that extra charge, gp3 is usually still cheaper.
1. Find your gp2 volumes
Console: EC2 › Volumes, filter by Volume type = gp2.
CLI (repeat in each region you use):
aws ec2 describe-volumes --filters Name=volume-type,Values=gp2 \
--query 'Volumes[].[VolumeId,Size,Iops,State,Attachments[0].InstanceId]' --output table
The Iops column shows what each volume gets today. Anything at 3,000 or below converts to plain gp3 with no performance setting. Anything above 3,000 needs its IOPS carried over.
2. Check what each volume really uses
The numbers above are what gp2 can provide, not what the workload uses. For a large or busy volume, look at its real peak before choosing the gp3 settings.
Console: select the volume › Monitoring, and look at Read and Write operations (IOPS) and Read and Write bandwidth over the last two weeks.
CLI (peak read operations per minute for one volume over two weeks; divide by 60 for IOPS):
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeReadOps \
--dimensions Name=VolumeId,Value=vol-0123456789abcdef0 \
--start-time 2026-10-06T00:00:00Z --end-time 2026-10-20T00:00:00Z \
--period 60 --statistics Sum --query 'max_by(Datapoints,&Sum).Sum'
Do the same for VolumeWriteOps, and add the two. If the peak stays under 3,000 IOPS and 125 MB/s, the plain gp3 baseline is enough even for a big volume.
3. Convert each volume in place
Elastic Volumes changes the type while the volume stays attached and the instance keeps running. There is no detach, no snapshot and no reboot.
Console: select the volume › Actions › Modify volume, set Volume type to gp3, and set IOPS and throughput if step 2 says so.
CLI:
# a volume that needs no more than the gp3 baseline
aws ec2 modify-volume --volume-id vol-0123456789abcdef0 --volume-type gp3
# a large volume that had 6,000 IOPS and 250 MB/s on gp2
aws ec2 modify-volume --volume-id vol-0fedcba9876543210 --volume-type gp3 --iops 6000 --throughput 250
The volume moves through the states modifying, optimizing and completed. It is usable throughout, and the new price applies once it is in optimizing. Two limits are worth knowing: after a change, the same volume can't be modified again for six hours, and a very large volume can take hours to finish optimizing. Track progress with:
aws ec2 describe-volumes-modifications --volume-ids vol-0123456789abcdef0 \
--query 'VolumesModifications[].[VolumeId,ModificationState,Progress]' --output table
4. Stop new gp2 volumes from appearing
Converting today's volumes fixes the bill until the next instance launches from an old template. Close the doors it comes back through:
- Launch templates and AMIs: set the root and data volumes to gp3 in every launch template, and rebuild the AMIs your teams launch from with gp3 block-device mappings.
- Infrastructure code: search your Terraform and CloudFormation for
gp2(thevolume_typeandVolumeTypesettings) and change the defaults. - The account default: there is no account-wide default volume type, so the templates and code are the only defence. A periodic check for gp2 volumes is what keeps it that way.
What it adds up to
For a fleet with 20 TB of gp2 storage, the move saves about $400 a month in us-east-1 at list prices, every month, for an afternoon of work, and most volumes get a higher guaranteed baseline at the same time.
Cloud Health Check checks every region of every connected AWS account for gp2 volumes each week, together with a few hundred other cost and security checks, and lists each one with its saving and the exact fix. You can see a sample report on demo data with no cloud access required.
Questions about your own account? Email contact@parlak.us or try Cloud Health Check on sample data.