When gp2 to gp3 actually saves money (and when it doesn't)

AWS launched gp3 in late 2020 as the replacement for gp2. Five years later, most production AWS accounts still have gp2 volumes sitting around, costing 20% more than they need to. This post covers exactly when gp3 saves money, when it doesn't, and how to do the migration safely.

The pricing difference, in dollars

At the same size, gp3 is roughly 20% cheaper than gp2 per GB-month. In us-east-1:

• gp2: $0.10/GB-month
• gp3: $0.08/GB-month

For a 1 TB volume that's a $20/month savings, $240/year. Multiply by every volume in your account. Even a moderate-sized AWS account with 50 TB of gp2 across various EC2 instances pays $1,000/month more than necessary by staying on gp2.

The savings get bigger when you factor in IOPS. gp2's IOPS scale at 3 IOPS per GB, with a minimum of 100 IOPS and a maximum of 16,000. A 100 GB gp2 volume gives you 300 IOPS. A 1 TB gp2 gives 3,000 IOPS. To get more IOPS on gp2, you had to grow the volume size, meaning you paid for storage you didn't need.

gp3 includes 3,000 baseline IOPS at any size. A 50 GB gp3 volume has the same 3,000 IOPS as a 1 TB gp3 volume. Volume size and IOPS are decoupled. If you previously over-provisioned gp2 storage to get IOPS, you can downsize gp3 and save further. For the full pricing breakdown and how C3X estimates EBS volumes, see the aws_ebs_volume catalog page.

When gp3 doesn't save money

Two situations where you should pause before migrating:

1. Very small volumes where IOPS aren't useful

For volumes under ~50 GB, the 3,000 baseline IOPS on gp3 are usually overkill. A 20 GB gp2 boot disk with 100 IOPS is fine for most workloads, and a 20 GB gp3 still costs 20% less. But the 20% savings on a $2/month volume is $0.40/month. Don't expect this to move the needle.

Still migrate (the savings stack across volumes), but don't expect any one tiny volume to matter.

2. Volumes already paying for high provisioned IOPS

If you've already migrated to gp3 and are paying for, say, 16,000 provisioned IOPS at $0.005/IOPS-month, that's $65/month on top of storage. If you don't actually need 16,000 IOPS, you're overspending worse than on gp2.

Check CloudWatch's VolumeReadOps and VolumeWriteOps. Sum the two for total IOPS. If your p99 is well below your provisioned amount, reduce the provisioned IOPS.

The migration: ModifyVolume API

AWS supports in-place volume type changes via the ModifyVolume API. The volume stays attached, the instance keeps running. There's no downtime.

One volume at a time (AWS CLI)

aws ec2 modify-volume \
  --volume-id vol-0123456789abcdef0 \
  --volume-type gp3

That's the whole command. After it returns, the volume enters "optimizing" state for a few minutes to a few hours depending on size. Performance is reduced during this period but the volume stays usable.

Many volumes via Terraform

If your volumes are managed in Terraform, change the type attribute and apply. Terraform issues ModifyVolume under the hood.

resource "aws_ebs_volume" "data" {
  availability_zone = "us-east-1a"
  size              = 1000
  type              = "gp3"  # was "gp2"

  tags = {
    Name = "data-volume"
  }
}

For inline EBS block devices on aws_instance:

resource "aws_instance" "api" {
  ami           = "ami-..."
  instance_type = "m6i.large"

  root_block_device {
    volume_type = "gp3"  # was "gp2"
    volume_size = 100
  }

  ebs_block_device {
    device_name = "/dev/sdf"
    volume_type = "gp3"  # was "gp2"
    volume_size = 500
  }
}

Many volumes at once via a script

For volumes outside Terraform's control (snapshots, old volumes, legacy infrastructure), a simple AWS CLI script does bulk migration:

#!/bin/bash
# Migrate all gp2 volumes in current region to gp3

VOLUMES=$(aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[].VolumeId' \
  --output text)

for vol in $VOLUMES; do
  echo "Migrating $vol..."
  aws ec2 modify-volume --volume-id "$vol" --volume-type gp3
done

Run this in non-production first, watch CloudWatch for any IOPS issues, then run in production. The change is reversible with ModifyVolume back to gp2.

How much will you actually save?

The savings depend on three things: total gp2 storage, average volume size, and whether you've been over-provisioning gp2 storage to get IOPS.

Conservative estimate

Take your current gp2 storage in GB. Multiply by $0.02/GB-month (the 20% savings). That's the floor of what you'll save.

An account with 100 TB of gp2 saves at minimum $2,000/month after migration. Larger accounts save proportionally more.

Aggressive estimate

If you've been over-provisioning gp2 size for IOPS (e.g., 1 TB gp2 volumes that only use 200 GB of actual storage but you needed the size for IOPS), gp3 lets you downsize. The same 1 TB workload on gp3 might fit in 200 GB if you weren't using the storage, saving an additional $64/month per volume.

What to do about new volumes

Set gp3 as your default. In Terraform, that means setting the type explicitly:

# In your modules/standard-ec2/main.tf
root_block_device {
  volume_type = "gp3"
  # ...
}

For AWS-managed services that create EBS volumes (EKS managed node groups, ECS-optimized AMIs, etc.), check the launch template's volume type and update to gp3. RDS instances should also use storage_type = "gp3" where supported.

Adjacent optimizations

While you're auditing EBS volumes, two related optimizations have similar mechanics:

• Delete detached volumes. EBS bills continuously regardless of attachment. Run aws ec2 describe-volumes --filters Name=status,Values=available and delete what isn't needed. Each $40/month volume detached for a year wasted $480.
• Audit snapshot retention. Snapshots live forever by default. Each is billed for the unique blocks it represents. Tag and lifecycle them. Old snapshots from deleted volumes are common sources of bill bloat.
• Newer instance generations. EBS performance is partly limited by the EC2 instance's EBS bandwidth. Newer generations (m6i, m7i) give more bandwidth than older (m5) at similar cost. Migrating both volume and instance generation is often a coordinated cost+performance win.

FAQ

How to plan and verify the migration

Three steps from triage to done:

1. Inventory. aws ec2 describe-volumes --filters Name=volume-type,Values=gp2 gives you the full list. Sum the sizes to see total potential savings.
2. Estimate impact with C3X. Run c3x estimate --path . on your Terraform before changing volume types, then again after. The diff shows exact savings per resource.
3. Migrate in waves. Start with non-production. Wait 24 hours, watch IOPS metrics, then continue. For production, do a handful of volumes at a time.

For more detail on EBS pricing dimensions and how Terraform configs map to costs, the aws_ebs_volume catalog page has the full reference. For getting started with C3X in general, see the quickstart guide.