Most people still use GP2 as the default EBS volume type in launch templates and infrastructure modules.
Not because it is still the best option today — but because it has existed in infrastructure templates for years.
In most production audits I review, oversized GP2 volumes are still one of the easiest cost optimizations left untouched.
The real issue is that GP2 ties storage capacity directly to performance. Under sustained workloads, that coupling starts becoming operationally expensive very quickly.
GP3 changes this model entirely.
Instead of scaling performance through storage size, GP3 separates performance from capacity and gives much more predictable behavior under real workloads.
To understand why this matters operationally, it helps to look at how both architectures actually behave.
How GP2 Was Designed
GP2 follows a size-based performance model:
IOPS = 3 × Volume Size (GB)
Key characteristics:
- Minimum 100 IOPS
- Burst up to 3,000 IOPS
- Maximum 16,000 IOPS
- Credit-based burst model
- Throughput indirectly tied to volume size
The original design made sense at the time.
As storage scaled, performance scaled with it.
But modern workloads are more sustained and much less tolerant of performance variability.
The Credit-Based Burst Problem
GP2 relies on a token bucket credit system.
When workloads exceed baseline performance:
- Burst credits are consumed
- IOPS temporarily increases
- Credits eventually deplete
- Performance drops back to baseline
This is where production instability starts showing up.
Short benchmarks often look fine.
But under sustained write-heavy workloads, latency starts increasing once credits are exhausted.
In CloudWatch, this usually appears as:
- Rising
VolumeQueueLength - Increasing
VolumeWriteLatency - Variability in
VolumeIdleTime
The problem is not peak performance.
The problem is maintaining predictable performance under continuous pressure.
GP3 Changes the Architecture Completely
GP3 removes the dependency between storage size and performance.
Every GP3 volume includes:
- 3,000 IOPS baseline
- 125 MB/s throughput baseline
And you can provision independently:
- Up to 16,000 IOPS
- Up to 1,000 MB/s throughput
- Up to 64 TiB storage
There is no burst-credit behavior.
Performance becomes deterministic instead of temporary.
Why This Matters Operationally
GP2 scales performance indirectly through storage size.
GP3 scales performance directly based on workload requirements.
That difference becomes extremely important for:
- production databases
- sustained write-heavy workloads
- indexing systems
- search clusters
- high-transaction services
In many cases, teams are effectively paying for extra storage capacity only to achieve the IOPS they need.
Real Cost Comparison
Requirement
- 6,000 sustained IOPS
- 500 GB usable storage
GP2
To achieve 6,000 baseline IOPS:
6000 ÷ 3 = 2000 GB
Approximate monthly cost:
2 TB × ~$0.10/GB ≈ ~$200/month
Most of that storage capacity exists only to unlock performance.
GP3
Provision directly:
- 500 GB storage
- 6,000 IOPS
Approximate monthly cost:
- Storage: ~$40
- Additional IOPS: ~$15
- Throughput adjustment: ~$5–10
Estimated total:
~$60–65/month
Once this scales across multiple workloads and environments, the savings become very noticeable.
Migration Is Surprisingly Simple
In most environments, moving from GP2 to GP3 is operationally straightforward:
aws ec2 modify-volume \
--volume-id vol-xxxxxxxx \
--volume-type gp3
In many cases:
- no downtime required
- no IAM changes required
- monitoring stays identical
Operationally, the migration is small.
From a performance predictability perspective, the impact is significant.
When GP3 Should Be the Default
GP3 makes more sense for:
- Production databases
- Search systems
- Sustained workloads
- Write-heavy applications
- Cost optimization initiatives
GP2 mainly survives today because older infrastructure templates still default to it.
Final Thoughts
GP2 ties performance to storage size and depends heavily on burst behavior.
GP3 separates capacity from performance and delivers much more predictable sustained I/O.
For most modern production workloads, GP3 should probably be the default starting point — not the upgrade path.
Top comments (0)