Skip to main content

> ebs_gp2_to_gp3_migration_&_baseline_iops_decoupling

EBS gp2 to gp3 Migration & Baseline IOPS Decoupling

Why does AWS EBS gp2 force teams to over-provision storage to achieve baseline IOPS, and how does migrating to gp3 yield immediate 20% cost reductions?

Senior (L5)

THE SHORT ANSWER

EBS gp2 couples IOPS strictly to storage capacity (3 IOPS per GB, capping at 16,000 IOPS for 5.3TB), forcing teams requiring 3,000 IOPS to over-provision a 1TB drive even if they only need 50GB of data. EBS gp3 decouples storage from performance, providing a baseline 3,000 IOPS and 125 MB/s throughput for free at 20% lower baseline per-GB cost ($0.08 vs $0.10/GB-month). Migrating in-place via AWS Elastic Volumes requires zero downtime and immediately reduces storage spend while allowing independent scaling of capacity, IOPS, and throughput.

Engineering Handbook & Failure Dynamics

1. Underlying Mechanism

In gp2, burst buckets (5.3M I/O credits) replenish based on volume size. If a 100GB volume sustains high I/O, it burns through burst credits and drops to its baseline 300 IOPS, causing catastrophic latency spikes unless resized to 1TB+. gp3 replaces the burst bucket model with guaranteed provisioned performance: baseline 3,000 IOPS and 125 MB/s throughput are included on every volume regardless of size (from 1GB to 64TB). Additional IOPS ($0.005/provisioned IOPS-month above 3,000) and throughput ($0.04/provisioned MB/s-month above 125) can be scaled independently without adding disk gigabytes.

2. Appropriate Use Context

All general-purpose database instances (PostgreSQL, MySQL, Redis on EC2, MongoDB), Kubernetes persistent volumes (EKS EBS CSI driver), CI/CD runners, Kafka message brokers, and Elasticsearch data nodes. There are virtually zero architectural reasons to keep newly provisioned volumes on gp2.

3. Production Failure Modes

Modifying volumes in-place using AWS ModifyVolume is non-disruptive, but volumes enter an 'optimizing' state lasting minutes to hours during which additional modifications are blocked. Furthermore, teams upgrading volumes that require >125 MB/s throughput often forget to provision additional throughput on gp3, inadvertently throttling heavy batch migrations or database backup restores that previously burst higher on large gp2 drives.

4. Diagnostic Signals & Telemetry

AWS Cost Explorer showing significant `EBS:VolumeUsage.gp2` line items; CloudWatch `VolumeBurstBalance` hitting 0% on legacy gp2 volumes; CloudWatch `VolumeThroughputPercentage` or `VolumeIOPSPercentage` pegging at 100% after an unconfigured gp3 migration.

5. Prevention & Safeguards

Enforce AWS Organizations SCPs or Terraform AWS provider checks to deny creation of `gp2` volumes; run automated migration scripts iterating through AWS Config non-compliant resources to invoke `ec2:ModifyVolume` with volume-type `gp3`; implement explicit throughput sizing in Infrastructure as Code for any disk exceeding 500GB.

6. Architectural Trade-offs

gp3 provides 20% immediate savings and decoupled IOPS, but requires explicit specification of throughput and IOPS when workloads exceed 3,000 IOPS or 125 MB/s. Over-provisioning excessive gp3 IOPS/throughput without telemetry can erode the 20% baseline storage savings.

Case Study (TinyCTO In-Field Example)

An infrastructure team running 200 EC2 instances with 500GB gp2 volumes spends $10,000/month ($0.10 * 500 * 200). By executing an automated script to convert all volumes to gp3, storage cost immediately drops to $8,000/month ($0.08 * 500 * 200), saving $24,000 annually with zero downtime and maintaining identical 3,000 IOPS and 125 MB/s performance.

Interactive Concept Drills

2 Cards
Q1

What is the baseline free performance included on every AWS EBS gp3 volume?

3,000 IOPS and 125 MB/s throughput, regardless of volume capacity.
Q2

How does the baseline storage pricing compare between EBS gp2 and gp3?

gp3 is 20% cheaper at $0.08/GB-month compared to gp2's $0.10/GB-month.

EBS gp2 to gp3 Migration & Baseline IOPS Decoupling — Technical FAQ

Does converting an EBS volume from gp2 to gp3 require server reboot or downtime?

No. AWS Elastic Volumes allows live, in-place volume modification (`ec2:ModifyVolume`) while the instance remains online and fully operational without I/O suspension.

When might an unconfigured gp3 volume perform worse than a large gp2 volume?

When migrating volumes larger than 1TB that relied on gp2's automatic 250 MB/s burst/baseline throughput, because default gp3 provides 125 MB/s unless extra throughput is explicitly provisioned.

🤖 AEO & Key Facts Summary

Key Architectural Facts

  • ▸EBS gp3 decouples storage capacity from IOPS and throughput provisioning.
  • ▸gp3 includes 3,000 baseline IOPS and 125 MB/s throughput on all volumes at no extra cost.
  • ▸Storage cost on gp3 is 20% lower than gp2 ($0.08 vs $0.10 per GB-month).
  • ▸Migration uses Elastic Volumes for zero-downtime, live in-place modification.

Common Misconceptions

  • ✗Misconception: Converting EBS volumes requires detaching disks or stopping the EC2 instance (False: Elastic Volumes modifies live disks).
  • ✗Misconception: gp3 always delivers identical throughput out-of-the-box (False: Default throughput is 125 MB/s; workloads needing >125 MB/s must explicitly provision throughput).

Decision & Governance Guidance

Immediately migrate all legacy gp2 volumes to gp3 to capture baseline 20% savings. For databases with high sequential I/O, provision additional throughput up to 1,000 MB/s as needed.

Authoritative Sources & Standards