Amazon EBS – Consider Upgrading gp2 Volumes to gp3

The Amazon EBS gp2-to-gp3 policy flags Amazon Elastic Block Store (Amazon EBS) volumes on General Purpose SSD (gp2) and recommends moving them to gp3. gp3 costs up to 20% less per GiB than gp2 and includes 3,000 IOPS and 125 MiB/s at any size. Teams stop buying extra capacity just to reach a performance target. Apply this policy to any aws_ebs_volume resource with type = "gp2", or with no type set, since the AWS provider defaults to gp2.

Why This Policy Matters

How It Helps Reduce Cloud Costs

Amazon EBS gp2 volumes tie performance to size. Each gp2 volume gets 3 IOPS per GiB, with a 100 IOPS floor. A 200 GiB gp2 volume has a baseline of only 600 IOPS.

gp2 volumes smaller than 1 TiB can burst to 3,000 IOPS using I/O credits. Those credits drain under sustained load, and performance drops back to the size-based baseline once they run out.

gp3 removes that link between size and speed. Every Amazon EBS gp3 volume includes a sustained 3,000 IOPS and 125 MiB/s baseline at no extra charge, with no burst credits to manage.

This is why gp2 drives quiet over-provisioning. Teams that need more IOPS from gp2 have one lever: allocate more storage than the data requires.

On top of the performance change, AWS lists gp3 at $0.08 per GiB-month versus $0.10 for gp2 in US East (N. Virginia). That 20% difference applies to every gp3 volume, whether or not the workload ever uses the extra performance headroom.

Potential Savings

Savings from the Amazon EBS gp2-to-gp3 migration come from two sources: the lower per-GiB price, and the option to stop over-allocating storage to buy IOPS.

For volumes under 1,000 GiB, the full 20% storage discount usually applies with no other change. gp3's included 3,000 IOPS already matches or beats what a gp2 volume of that size delivers.

For larger volumes, the saving narrows. AWS estimates savings of roughly 8% to 19% when gp3 is configured to match a large gp2 volume's performance. The gap narrows because gp3 charges $0.005 per IOPS-month above 3,000 and $0.04 per MiB/s-month above 125.

This is a configuration change, not a usage reduction. That makes the Amazon EBS gp2-to-gp3 migration low risk to apply across a fleet of volumes.

Implementation Guide

Infrastructure-as-Code Example (Terraform)

The following examples show an Amazon EBS volume provisioned as gp2, and the corrected gp3 configuration.

Non-compliant configuration: Amazon EBS volume on gp2

resource "aws_ebs_volume" "app_data" {
  availability_zone = "us-east-1a"
  size              = 500
  type              = "gp2"
  encrypted         = true

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

resource "aws_ebs_volume" "app_data" {
  availability_zone = "us-east-1a"
  size              = 500
  type              = "gp2"
  encrypted         = true

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

resource "aws_ebs_volume" "app_data" {
  availability_zone = "us-east-1a"
  size              = 500
  type              = "gp2"
  encrypted         = true

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

This 500 GiB gp2 volume has a 1,500 IOPS baseline and costs about $50 per month in US East (N. Virginia). This is a common source of wasted spend. The team pays the higher gp2 rate and gets less sustained performance than gp3 includes by default.

Compliant configuration: Amazon EBS volume on gp3

resource "aws_ebs_volume" "app_data" {
  availability_zone = "us-east-1a"
  size              = 500
  type              = "gp3"
  iops              = 3000
  throughput        = 125
  encrypted         = true

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

resource "aws_ebs_volume" "app_data" {
  availability_zone = "us-east-1a"
  size              = 500
  type              = "gp3"
  iops              = 3000
  throughput        = 125
  encrypted         = true

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

resource "aws_ebs_volume" "app_data" {
  availability_zone = "us-east-1a"
  size              = 500
  type              = "gp3"
  iops              = 3000
  throughput        = 125
  encrypted         = true

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

The same 500 GiB volume on gp3 costs about $40 per month and sustains 3,000 IOPS and 125 MiB/s. Setting iops = 3000 and throughput = 125 is optional, since those are the gp3 defaults. Writing them out makes the performance baseline explicit in code review.

The iops and throughput attributes are only valid when type is gp3 (and iops for io1 or io2). Raise them only when monitoring shows the workload needs more than the baseline.

Step-by-Step Fix Instructions

1. Search Terraform configuration for every aws_ebs_volume resource with type = "gp2" or no type value, since the AWS provider defaults type to gp2.

2. Check other places gp2 can hide: the volume_type argument in root_block_device and ebs_block_deviceblocks on aws_instance, and in block_device_mappings on aws_launch_template.

3. For volumes of 1,000 GiB or more, review CloudWatch VolumeReadOps and VolumeWriteOps to find actual peak IOPS before choosing gp3 iops and throughput values.

4. Change type to "gp3", adding iops and throughput only where the workload needs more than 3,000 IOPS or 125 MiB/s.

5. Run terraform plan and confirm the change on aws_ebs_volume is an in-place update, not a replacement. Amazon EBS Elastic Volumes changes the type without detaching the volume or stopping the instance.

6. Apply during a low-traffic window. A volume enters an optimizing state during migration, and AWS notes a fully used 1 TiB volume typically takes about 6 hours.

7. Add Infracost to CI/CD so any new aws_ebs_volume on gp2 is flagged in the pull request before it merges.

Best Practices

• Set type = "gp3" as the default in shared Terraform modules, so no team gets gp2 by omitting the attribute.

• Size gp3 iops and throughput from observed CloudWatch metrics, not from the old gp2 size formula.

• Migrate in batches. Wait for each Elastic Volumes modification to reach the completed state before changing the same volume again, since AWS allows up to four modifications per volume in a rolling 24-hour period.

• This policy does not apply to io1 or io2 volumes running latency-sensitive databases. Those belong to a separate provisioned IOPS review.

Tools and Scripts

How does Infracost detect gp2 volumes automatically?

The Amazon EBS gp2-to-gp3 policy is available in Infracost, including in the free trial. When Infracost runs in CI/CD, it checks aws_ebs_volume resources in each pull request. It flags gp2 volumes in the PR comment, with the file and line to change.

This catches gp2 before the volume exists, when the fix is a one-word change in the same pull request. Infracost also scans connected repositories for existing gp2 volumes. FinOps and platform teams can then burn down that backlog and track progress on a burndown chart.

Teams can set the policy to warn engineers or to block pull requests that fail it, depending on how strictly they want to enforce gp3.

To list gp2 volumes in the current region with the AWS CLI:

aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query "Volumes[].[VolumeId,Size,State]" \
  --output

aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query "Volumes[].[VolumeId,Size,State]" \
  --output

aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query "Volumes[].[VolumeId,Size,State]" \
  --output

To migrate one volume in place outside Terraform:

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

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

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

If a volume is managed by Terraform, update the type in code as well, or the next terraform apply will try to change it back to gp2.

Examples of Impact

Illustrative example: a fleet of mid-sized volumes. A platform team runs 200 Amazon EBS gp2 volumes of 500 GiB each in US East (N. Virginia). At $0.10 per GiB-month, that is roughly $10,000 per month. On gp3 at $0.08, it drops to roughly $8,000, saving about $24,000 per year.

Illustrative example: a large, high-IOPS volume. A 1,024 GiB gp2 volume costs about $102 per month and delivers 3,072 IOPS and 250 MiB/s. Matching that on gp3 means paying for 72 extra IOPS and 125 extra MiB/s. The total is about $87 per month, still about 15% cheaper.

The larger the volume, the more the saving depends on how much provisioned performance the workload actually needs.

(These are illustrative scenarios using published US East (N. Virginia) list prices, not specific customer accounts.)

Considerations and Caveats

gp3 is the right default for general-purpose Amazon EBS storage, but large or throughput-heavy volumes need sizing before migration.

• Large volumes need sizing. gp2 volumes over 1,000 GiB deliver more than 3,000 baseline IOPS, so gp3 may need extra provisioned IOPS to match them.

• Throughput above 125 MiB/s costs extra. gp2 volumes larger than 170 GiB can reach 250 MiB/s; on gp3 that requires provisioning additional throughput.

• Instance limits still apply. Amazon EC2 instance types cap EBS throughput and IOPS. Provisioning more gp3 performance than the instance supports adds cost without benefit.

• Volumes cannot shrink. Elastic Volumes can change type and grow a volume, but reducing size requires a new volume and a data copy.

• Provider-specific. This policy targets Amazon EBS through the aws_ebs_volume resource. Azure and Google Cloud disks use different tiers and attribute names.

Related Policies and Concepts

• RDS - consider upgrading gp2 storage type to gp3: the same gp2-to-gp3 change applied to storage_type on Amazon RDS instances.

• EMR - consider upgrading gp2 storage type to gp3: the same storage-type upgrade applied to Amazon EMR cluster volumes.

• Amazon EBS - consider updating io1/io2 volumes to gp3: a Block Storage policy for provisioned IOPS volumes whose workloads fit within gp3 limits.

• Amazon EBS - consider upgrading io1 volumes to io2: a Block Storage policy moving volumes that need provisioned IOPS to the newer io2 type.

• Azure Disk Storage - consider updating Premium SSD disk to v2: the Azure equivalent of decoupling disk performance from disk size.

Frequently Asked Questions (FAQs)

Is this policy supported in Infracost?

Yes. The Amazon EBS gp2-to-gp3 policy is supported in Infracost and available in the free trial. Infracost flags aws_ebs_volume resources using gp2 in pull requests, so the team can switch to gp3 before the volume is created.

Can this policy be customized?

Yes. Teams can configure how Infracost enforces the Amazon EBS gp2-to-gp3 policy. For example, a finding can warn engineers or block the pull request, and can trigger on new resources only.

Does Infracost automatically fix violations?

No. Infracost identifies Amazon EBS gp2 volumes and reports them in the pull request with the file and line to change. Changing type to gp3 and applying the update is a decision the team makes and reviews.

Is this policy cloud-agnostic?

No. The Amazon EBS gp2-to-gp3 policy targets AWS through the aws_ebs_volume Terraform resource. Azure managed disks and Google Cloud persistent disks have their own performance tiers with different resource and attribute names.

How often should I review Amazon EBS volume types?

Teams running Infracost in CI/CD get an Amazon EBS volume type check on every pull request that touches an aws_ebs_volume resource. For existing volumes, a quarterly review is a reasonable cadence to catch gp2 volumes created outside Terraform.

Does migrating an Amazon EBS volume from gp2 to gp3 require downtime?

No. Amazon EBS Elastic Volumes changes a gp2 volume to gp3 in place, without detaching it or stopping the instance. The volume stays in use while it moves through the optimizing state.

Is Amazon EBS gp3 always cheaper than gp2?

For the same size and performance, Amazon EBS gp3 is cheaper in published AWS pricing. The saving is smaller on volumes over 1,000 GiB. Larger Amazon EBS volumes may need paid gp3 IOPS or throughput above the baseline to match gp2.