Skip to content
CloudPouch Docs

Case study: $18,890/month saved by migrating EBS GP2 to GP3

In one real AWS account, CloudPouch identified an $18,890 monthly saving — almost a quarter of a million dollars per year — from a single change: migrating Amazon EBS volumes from GP2 to GP3.

This case study is based on a real engagement by CloudPouch’s creator, published as Reduce AWS costs: How I’ve saved $18,890 monthly on EBS drives on DEV. The migration ran at the end of 2021; verify current EBS pricing before applying the exact percentages to your account.

The starting point

Section titled “The starting point”

The account was large:

  • Around 17,000 EBS volumes, all of them GP2.
  • 944,875 GB of provisioned storage — almost a full petabyte.
  • Roughly $100,000 per month billed under the EBS:VolumeUsage.gp2 usage type.

Nothing was broken. Every volume was doing its job. The money was leaking through the volume type: AWS introduced GP3 in December 2020 with up to 20% lower per-GB pricing than GP2, and performance that is configured independently instead of being coupled to volume size. Accounts created before that date — or built by automation that still defaults to GP2 — keep paying the old rate.

How CloudPouch surfaced it

Section titled “How CloudPouch surfaced it”

The whole analysis took a few clicks:

  1. Open CloudPouch in the Current month view.
  2. Scroll to the AWS Services table and select the EC2 - Other row (this is where AWS hides EBS charges).
  3. Open the UsageType cost chart to see EBS:VolumeUsage.gp2 as a distinct line item.
  4. Click Check Cost Insights.
  5. CloudPouch connects to AWS, inspects the deployed volumes, and shows the estimated saving.

For this account, the estimate was 20%, or $18,890 per month. Alongside the GP3 opportunity, the same analysis also covers orphaned volumes, unused Elastic IPs, and idle NAT Gateways.

How the migration was done

Section titled “How the migration was done”

GP2-to-GP3 conversion uses Amazon EBS Elastic Volumes and does not require stopping the attached EC2 instances. At this scale it was automated with two EC2 API calls:

  • DescribeVolumes to list volumes and filter valid GP2 candidates.
  • ModifyVolume to convert each candidate to GP3.

The modification starts asynchronously and can take up to about 6 hours per volume depending on size — but GP3 pricing applies from the moment the migration starts. After converting almost 1 PB of storage, the account had no EBS or EC2 issues attributable to the change.

One follow-up worth planning for: deployment tooling that still creates GP2 volumes will slowly rebuild the problem. In environments where you cannot control how new volumes are provisioned, a small scheduled Lambda that migrates newly created GP2 volumes keeps the saving from drifting away.

Before you migrate your own volumes

Section titled “Before you migrate your own volumes”

The 20% figure came from this account’s mix of regions and volume sizes; yours will differ. Review before converting:

  • Volumes with provisioned IOPS or non-default throughput settings.
  • Volumes attached to latency-sensitive production workloads.
  • Volumes managed by infrastructure-as-code, where the template should change too.

CloudPouch gives you the candidate list and the estimated saving; the migration itself goes through your normal change process.

Section titled “Related pages”