gp2 to gp3: What the Migration Actually Saves

• What actually changed between the two
• Where the twenty percent holds
• Measure before you provision
• Doing the conversion
• Counting the saving without counting it twice
• When to leave a volume alone
• Frequently asked questions

gp3 costs $0.08 per GB-month against gp2's $0.10. That is twenty percent off every general-purpose volume in the account, the conversion runs online with no downtime, and for most volumes gp3 is also faster. It is the closest thing to free money in an AWS bill, which is why it is worth understanding the two cases where the twenty percent is not the real number.

What actually changed between the two

The important difference is not price. It is that gp2 ties performance to size and gp3 does not.

On gp2, a volume earns 3 IOPS per GB, with a floor of 100 and a ceiling of 16,000. A 100 GB gp2 volume has a baseline of 300 IOPS. To get more, you buy a bigger disk than you need for the space, which is why so many gp2 volumes are oversized on purpose. Volumes under 1,000 GB can burst to 3,000 IOPS by spending credits, and credits run out under sustained load.

On gp3, every volume gets 3,000 IOPS and 125 MB/s included, at any size, sustained, with no credit system. Performance beyond that is bought separately from capacity: $0.005 per provisioned IOPS-month above 3,000, and $0.04 per MB/s-month above 125.

Where the twenty percent holds, and where it erodes

Twenty percent is the saving on storage price. It holds exactly as long as the included 3,000 IOPS and 125 MB/s are enough for the workload. Above 1,000 GB, gp2's baseline exceeds 3,000 IOPS, so matching the old volume's headline specification means provisioning the difference.

us-east-1 list prices. The right-hand columns provision enough IOPS and throughput to match what the gp2 volume could theoretically deliver, including gp2's 250 MB/s for volumes at or above 334 GB against gp3's included 125 MB/s.

Two conclusions follow, and the second is the one people miss.

gp3 is cheaper in every row, even matched specification for specification. There is no size at which staying on gp2 is the cheaper choice for equivalent performance. The saving narrows from 20% to about 7% at the largest volumes, but it never inverts.

Matching the old specification is usually the wrong target. The 500 GB row is the instructive one: matching gp2's theoretical 250 MB/s costs $5 a month and halves the saving, and most 500 GB volumes are nowhere near 250 MB/s. You are provisioning for a number the old volume type happened to expose, not for anything the workload does. Measure first.

Measure before you provision

Before converting a volume larger than 1,000 GB, look at what it actually uses. CloudWatch has the answer for free:

aws cloudwatch get-metric-statistics \
  --namespace AWS/EBS \
  --metric-name VolumeReadOps \
  --dimensions Name=VolumeId,Value=vol-0abc123 \
  --start-time 2026-08-10T00:00:00Z \
  --end-time 2026-09-09T00:00:00Z \
  --period 300 --statistics Maximum \
  --region ap-south-1

VolumeReadOps and VolumeWriteOps are counts per period, so divide by the period in seconds to get IOPS. Take the maximum across at least 30 days rather than the average. An average hides the nightly batch window that is the only reason the volume needs the IOPS at all.

If the observed peak sits under 3,000, convert at gp3's defaults and take the full twenty percent. If it does not, provision to the measured peak with headroom, not to gp2's nominal ceiling.

Doing the conversion

One call per volume. No detach, no stop, no snapshot restore.

# Straight conversion, gp3 defaults (3,000 IOPS / 125 MB/s)
aws ec2 modify-volume --volume-id vol-0abc123 --volume-type gp3 --region ap-south-1

# Or with measured performance
aws ec2 modify-volume --volume-id vol-0abc123 --volume-type gp3 \
  --iops 5000 --throughput 250 --region ap-south-1

# Watch it complete
aws ec2 describe-volumes-modifications --volume-ids vol-0abc123 --region ap-south-1

The volume stays attached and readable throughout. It enters an optimizing state and continues serving I/O, at somewhat reduced performance while the change settles. Because the size is not changing, there is nothing to do in the guest: no partition resize, no filesystem grow, no reboot.

Two operational limits worth knowing before you script this across an account:

• There is a cooldown of about six hours after a modification before the same volume can be modified again. If you convert and then decide to adjust IOPS, you wait. Get the target right, or accept two windows.
• Root volumes are eligible. There is no need to exclude them, and they are frequently the forgotten gp2 volumes in an account because attention goes to data disks.

Finding every candidate is one call per region:

aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --region ap-south-1 \
  --query 'Volumes[].{ID:VolumeId,GB:Size,State:State}' \
  --output table

Counting the saving without counting it twice

This is where cost tooling tends to quietly inflate, and it is worth explaining because it is the failure mode you cannot see from the outside.

gp2 volumes are visible to two different analyses. AWS Compute Optimizer returns them as over-provisioned with its own savings figure. A direct check of volume types finds the same volumes and computes the same class of saving independently. If a report merges both without recognising that they describe one volume, that volume is counted twice and the headline total is wrong by exactly the amount that makes the report look best.

Deduplicating requires the two sources to agree on what identifies a volume. They do not agree by default: Compute Optimizer returns a full ARN, and a direct description returns a bare volume ID.

# Compute Optimizer returns:
arn:aws:ec2:ap-south-1:123456789012:volume/vol-0abc123

# describe-volumes returns:
vol-0abc123

Those are the same disk and different strings. Any deduplication keyed on the identifier fails silently, producing two findings and one inflated total.

The general rule is in the AWS cost optimization guide: findings must be deduplicated on resource type, resource ID and region, and every source has to normalise to the same key before they meet.

When to leave a volume alone

gp3 is not universally the answer. Three cases where the conversation is different:

io1 and io2. These are a different tier for latency-sensitive and high-durability workloads, with separately billed provisioned IOPS. io1 to io2 is worth doing on its own merits, at the same per-GB price with substantially better durability, but it is a reliability upgrade rather than a saving. Our analyzer reports that finding at zero dollars for precisely that reason.

Volumes needing more than 16,000 IOPS or 1,000 MB/s. That is above gp3's ceiling and points at io2 rather than gp3.

Volumes that are about to be deleted anyway. Converting an orphan is optimising something you should be removing. Sweep for unattached volumes first, delete what is dead, and convert what is left.

Frequently asked questions

How much does migrating from gp2 to gp3 actually save?

Twenty percent on storage price, from $0.10 to $0.08 per GB-month, and that figure holds as long as gp3's included 3,000 IOPS and 125 MB/s are enough for the workload. Above 1,000 GB, gp2's baseline exceeds 3,000 IOPS, so matching the old volume's full specification means provisioning the difference and the saving narrows to roughly 7 to 15 percent. gp3 is cheaper than gp2 at equivalent performance at every size.

Is gp3 always cheaper than gp2?

For equivalent delivered performance, yes at every volume size. The saving narrows from 20 percent on small volumes to about 7 percent on a 5,334 GB volume provisioned to match gp2's 16,000 IOPS ceiling, but it never inverts. There is no size at which staying on gp2 is the cheaper option.

Does converting gp2 to gp3 require downtime?

No. aws ec2 modify-volume runs online with the volume attached. It enters an optimizing state and keeps serving I/O at somewhat reduced performance while the change settles. Because the size is unchanged there is no partition resize, no filesystem grow and no reboot.

Is gp3 faster than gp2?

For volumes under 1,000 GB, usually yes. gp2 provides 3 IOPS per GB as baseline, so a 100 GB gp2 volume has 300 baseline IOPS and reaches 3,000 only by spending burst credits that deplete under sustained load. Every gp3 volume gets 3,000 IOPS sustained at any size with no credit system.

How do I know how many IOPS to provision on gp3?

Read VolumeReadOps and VolumeWriteOps from the AWS/EBS CloudWatch namespace, divide by the period in seconds, and take the maximum across at least 30 days rather than the average. An average hides the nightly batch window that is often the only reason the volume needs the IOPS. Provision to the measured peak with headroom, not to gp2's nominal ceiling.

Can I modify a gp3 volume again right after converting it?

Not immediately. There is a cooldown of roughly six hours after a volume modification before the same volume can be modified again, so if you convert and then want to adjust IOPS you will wait. Set the target correctly the first time or plan for two windows.

Should I convert the root volume too?

Yes, root volumes are eligible and are frequently the forgotten gp2 volumes in an account, because attention usually goes to data disks.