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

6-Dimensional Architecture Breakdown

⚙️1. Underlying Mechanism

Execution

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

Scope

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

P0 Risk

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

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

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

Trade-off

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)

REAL-WORLD TELEMETRY

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

Technical terms on this page

MigrationThroughput