Choosing Between EBS gp2 and gp3: Independent IOPS Scaling and Cost Comparison

Choosing between EBS gp2 and gp3 affects both your AWS bill and your ability to tune storage performance without over-provisioning capacity.

TL;DR: gp2 vs gp3 at a Glance

Dimensiongp2gp3
IOPS scaling modelCoupled to volume size (3 IOPS/GiB)Independent of size — configurable up to 16,000 IOPS
Baseline IOPS3 IOPS/GiB (min 100, max 16,000)3,000 IOPS included at no extra charge
ThroughputUp to 250 MiB/s (burst-dependent)Up to 1,000 MiB/s, configurable independently
Burst modelCredit-based burst to 3,000 IOPSNo burst model — sustained baseline of 3,000 IOPS
Cost profileHigher per-GiB at equivalent performanceGenerally lower cost for same performance target
Migration pathCan be modified in-place to gp3Current recommended general-purpose type

Why the gp2 IOPS Model Creates a Hidden Cost Trap

gp3 is the answer to independent IOPS scaling. With gp2, IOPS are directly coupled to volume size at a ratio of 3 IOPS per GiB, capped at 16,000 IOPS. This means reaching 6,000 IOPS on gp2 requires provisioning at least 2,000 GiB of storage — even if your workload only needs 200 GiB of actual capacity. You pay for storage you do not use, purely to unlock performance headroom.

gp3 decouples these dimensions entirely. Every gp3 volume starts with 3,000 IOPS and 125 MiB/s throughput included in the base price, regardless of size. You can independently increase IOPS up to 16,000 and throughput up to 1,000 MiB/s without changing the volume size.

Think of gp2 like a highway where the number of lanes is fixed by the road's length — to get more lanes, you must build a longer road. gp3 lets you add lanes to any road segment independently.

Architecture: How gp2 and gp3 Handle IOPS Differently

graph LR subgraph gp2_model [gp2 - Coupled Model] G2Size[Volume Size GiB] -->|3 IOPS per GiB| G2IOPS[IOPS Ceiling] G2IOPS -->|burst pool| G2Burst[Burst to 3000 IOPS] G2Burst -->|credits exhausted| G2Drop[Drop to Baseline] end subgraph gp3_model [gp3 - Independent Model] G3Size[Volume Size GiB] G3IOPS[IOPS - configurable up to 16000] G3TP[Throughput - configurable up to 1000 MiBs] G3Size -.->|no dependency| G3IOPS G3Size -.->|no dependency| G3TP end
  1. gp2 path (top): IOPS are derived from volume size. To increase IOPS, you must increase GiB, which increases cost even if capacity is not needed.
  2. gp3 path (bottom): Size, IOPS, and throughput are three independent axes. Each can be modified without affecting the others.
  3. Burst credit pool (gp2 only): Small gp2 volumes accumulate burst credits at idle and spend them during spikes. Once exhausted, performance drops to the baseline 3 IOPS/GiB rate. gp3 has no burst model — the 3,000 IOPS baseline is sustained.

The burst credit exhaustion behavior is the most common source of intermittent I/O latency spikes on gp2 volumes — and the hardest to diagnose because it only manifests under sustained load, not during brief tests.

Step 1: Identify gp2 Volumes in Your Account

Before migrating, audit which volumes are still on gp2. Volumes attached to running instances can be modified without stopping the instance, but you should confirm the current state first.

— Why this step: the AWS Console does not surface volume type across all regions in a single view, so a CLI query is the only reliable way to get a complete inventory before committing to a migration plan.

aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[*].{VolumeId:VolumeId,SizeGiB:Size,IOPS:Iops,AZ:AvailabilityZone}' \
  --output table \
  --region us-east-1

This returns all gp2 volumes in the target region with their current size and IOPS allocation. Run this per region — EBS is a regional service and volumes are not visible across regions.

Step 2: Calculate the Target gp3 IOPS Configuration

For each gp2 volume, the equivalent gp3 IOPS target is the volume's current IOPS value (which equals 3 × size in GiB, up to 16,000). If the resulting IOPS value is 3,000 or below, no additional IOPS configuration is needed on gp3 — the included baseline covers it at no extra charge.

— Why this step: migrating without setting the correct IOPS target on gp3 can silently under-provision a database or application volume that relied on gp2's size-derived IOPS, causing a performance regression that is difficult to attribute post-migration.

aws ec2 modify-volume \
  --volume-id vol-0abc1234def56789a \
  --volume-type gp3 \
  --iops 6000 \
  --throughput 250 \
  --region us-east-1

Set --iops to match or exceed the gp2 baseline. Set --throughput based on your workload's measured MiB/s requirement. If you are unsure, 125 MiB/s (the gp3 default) matches gp2 behavior for most general workloads.

In practice, teams often set --iops 3000 on every volume during bulk migrations without checking the source gp2 IOPS. A 500 GiB gp2 volume delivers 1,500 IOPS — well under 3,000 — so this is safe. But a 4,000 GiB gp2 volume delivers 12,000 IOPS, and migrating it to gp3 with only 3,000 IOPS will immediately degrade a production database.

Step 3: Verify the Modification Completed Successfully

Volume modifications are asynchronous. The modify-volume call returns immediately, but the volume transitions through modifying → optimizing → completed states. Do not assume the new type is active until the state is completed.

— Why this step: a volume stuck in optimizing still operates at the new type's performance characteristics, but monitoring systems that check volume type may report stale data until the modification fully completes, creating a false alarm window.

aws ec2 describe-volumes-modifications \
  --volume-ids vol-0abc1234def56789a \
  --query 'VolumesModifications[*].{VolumeId:VolumeId,State:ModificationState,TargetType:TargetVolumeType,Progress:Progress}' \
  --output table \
  --region us-east-1

Poll this command until ModificationState shows completed. The Progress field shows percentage completion during the optimizing phase.

Step 4: Validate Performance After Migration

Symptom to watch for: after migrating a high-IOPS gp2 volume, CloudWatch VolumeReadOps and VolumeWriteOps metrics drop sharply. The most common misdiagnosis is a filesystem or application issue. The actual cause is usually an under-provisioned IOPS target on the new gp3 volume.

— Why this step: gp3 IOPS are enforced as a hard ceiling — unlike gp2 burst behavior, there is no temporary headroom above the configured value, so a misconfigured limit produces an immediate and sustained throughput reduction.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EBS \
  --metric-name VolumeReadOps \
  --dimensions Name=VolumeId,Value=vol-0abc1234def56789a \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T01:00:00Z \
  --period 300 \
  --statistics Sum \
  --region us-east-1

Compare the post-migration read and write ops against the pre-migration baseline captured from the same metric. If throughput is lower than expected, increase --iops on the volume using another modify-volume call.

gp3 gives you a dial — but only if you turn it to the right position before traffic hits.

IAM Permissions Required for gp2 to gp3 Migration

The modify-volume and describe-volumes-modifications API calls require specific IAM permissions. The policy below follows least privilege — it restricts modification actions to EC2 EBS resources and allows the read actions required for inventory and status checks.

View IAM Policy 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DescribeEBSVolumes",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeVolumes",
        "ec2:DescribeVolumesModifications"
      ],
      "Resource": "*"
    },
    {
      "Sid": "ModifyEBSVolumes",
      "Effect": "Allow",
      "Action": "ec2:ModifyVolume",
      "Resource": "arn:aws:ec2:us-east-1:123456789012:volume/*"
    },
    {
      "Sid": "ReadCloudWatchEBS",
      "Effect": "Allow",
      "Action": "cloudwatch:GetMetricStatistics",
      "Resource": "*"
    }
  ]
}

Note: ec2:DescribeVolumes and ec2:DescribeVolumesModifications do not support resource-level restrictions — "Resource": "*" is required for these actions per the AWS Service Authorization Reference.

Choosing Between gp2 and gp3: Decision Flow

graph LR Start([New or Existing Volume?]) --> IsNew{New volume?} IsNew -->|Yes| UseGP3[Use gp3] IsNew -->|No - existing gp2| CheckSize{Volume oversized for IOPS?} CheckSize -->|Yes| MigrateGP3[Migrate to gp3] CheckSize -->|No - small volume low IOPS| CheckCost{Cost acceptable?} CheckCost -->|Yes| StayGP2[Stay on gp2 - monitor credits] CheckCost -->|No| MigrateGP3 MigrateGP3 --> SetIOPS[Set IOPS to match gp2 baseline] SetIOPS --> Verify[Verify ModificationState completed]
  1. Start: Evaluate whether your workload needs more than 3,000 IOPS or 125 MiB/s throughput.
  2. gp2 with large volume: If you are already on gp2 with a large volume to meet IOPS requirements, you are paying for unused capacity — migrate to gp3.
  3. New volume: For any new general-purpose SSD volume, gp3 is the current recommended type. There is no scenario where gp2 is preferable for new workloads.
  4. Legacy constraint: If an older AMI or snapshot workflow requires gp2 explicitly, validate whether that constraint is still real — most tooling has been updated to support gp3.

Frequently Asked Questions: EBS gp2 vs gp3

Can I migrate from gp2 to gp3 without downtime? Yes. EBS volume modifications are performed on live, attached volumes. The instance does not need to be stopped. I/O continues during the modification, though AWS recommends pausing heavy I/O workloads during the transition for best results.

Is gp3 always cheaper than gp2? For most workloads, yes — particularly when gp2 volumes were oversized to meet IOPS requirements. Pricing varies by region and changes over time. Always verify current pricing in the AWS EBS pricing page before making cost projections.

What happens to gp2 burst credits during migration? Burst credits are a gp2-specific construct. They do not transfer to gp3, and gp3 does not use a credit model. After migration, performance is determined entirely by the configured IOPS and throughput values.

Glossary

gp2
Previous-generation AWS EBS General Purpose SSD. IOPS are coupled to volume size at 3 IOPS/GiB with a burst credit model.
gp3
Current-generation AWS EBS General Purpose SSD. IOPS and throughput are configurable independently of volume size.
IOPS
Input/Output Operations Per Second. A measure of storage performance for random read/write workloads.
Burst Credits (gp2)
A token bucket that accumulates when a gp2 volume operates below its baseline IOPS rate and is consumed during spikes above baseline.
Volume Modification
An EBS operation that changes volume type, size, IOPS, or throughput on a live volume without requiring instance stop.
ModificationState
The lifecycle state of an EBS volume modification: modifying → optimizing → completed.

Related Posts

Comments

Post a Comment

Popular posts from this blog

EC2 No Internet Access in Custom VPC: Fix Internet Gateway and Route Table

EC2 no internet access in a custom VPC is one of the most common launch-day failures — the instance is running, but outbound connectivity is completely silent. TL;DR: EC2 No Internet Access — Fix Checklist Step What to Do Why It Matters Complexity 1 Create and attach an Internet Gateway to the VPC Without an IGW, the VPC has no path to the public internet Low 2 Add a default route (0.0.0.0/0) pointing to the IGW in the subnet's route table The IGW exists but traffic has no route to reach it Low 3 Assign a public IP or Elastic IP to the instance Private IPs are not routable on the public internet Low 4 Verify Security Group allows outbound traffic A restrictive outbound rule silently drops all egress Low 5 Verify Network ...
Read more

EC2 SSH Connection Timeout: Which Security Group Rules to Check

An EC2 SSH connection timeout is one of the most common blockers when launching a new instance — the fix is almost always a missing or misconfigured inbound rule in your Security Group. TL;DR — Diagnostic Steps at a Glance Step What to Check Common Fix 1 Security Group inbound rules Add SSH (TCP 22) from your IP 2 Subnet route table Ensure 0.0.0.0/0 routes to an Internet Gateway 3 Network ACL rules Allow inbound TCP 22 and ephemeral return ports 4 Instance public IP / Elastic IP Confirm a public IP is assigned 5 Key pair and SSH username Use correct private key and AMI-specific username Why SSH Times Out Instead of Refusing A connection refused error means the TCP handshake reached the host but nothing is listening. A connection timed out error means packets never arrived — or replies never returned. On EC2, that silence is almost always a network-layer block, not an OS-level problem. The Se...
Read more

Difference Between IAM User and IAM Role: Which One Should Your EC2 Use?

Understanding the difference between IAM User and IAM Role is critical — choosing wrong means either hardcoded credentials in your app or a silent security exposure you won't catch until an audit. TL;DR: IAM User vs IAM Role at a Glance Dimension IAM User IAM Role Identity type Permanent, named human or service identity Assumable identity with temporary credentials Credential type Long-lived access keys or password Short-lived STS tokens (auto-rotated) Attached to EC2? No native attachment — keys must be embedded Yes — via Instance Profile, injected automatically Rotation required? Manual — your responsibility Automatic — AWS STS handles it Recommended for EC2 → S3? No Yes — always Cross-account access Requires separate user per account Native — assume role across accounts Audit trail Tied to user identity Tied to role + session name in CloudTrail What IAM User and IAM Role Actual...
Read more