Most people still use GP2 as the default EBS volume type in launch templates and infrastructure modules. Not because it is optimal today, but because it has been there for years.
In most production audits I review, oversized GP2 volumes are one of the easiest cost optimizations left untouched.
GP2 performance is tied to volume size and burst credits, which can lead to unstable latency and throughput during sustained workloads. For production databases, search clusters, and write-heavy services, this behavior directly impacts reliability and user experience.GP3 changes this model by separating performance from storage size, enabling consistent throughput, predictable latency, and more efficient cost control.
To understand why this difference matters in real workloads, let’s examine the architecture behind both.
**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 design principle was straightforward: scale storage to scale performance.
That approach worked when workloads were smaller and less sustained. Today, it introduces unnecessary coupling between capacity and predictable performance.---
**The Credit-Based Burst Reality
GP2 uses a token bucket mechanism.
When I/O demand exceeds baseline:
Burst credits are consumed
IOPS temporarily increases
Credits deplete under sustained load
Performance drops back to baseline
In real production systems, this is where instability appears.
Performance looks stable during short load tests.
Thirty to forty minutes into steady write pressure, latency increases and queue depth begins to rise.
In CloudWatch, this typically shows up as:
Increasing VolumeQueueLength
Rising VolumeWriteLatency
Higher variability in VolumeIdleTime
If your workload regularly operates above baseline IOPS for extended periods, GP2 introduces risk.
The issue is not peak performance.
It is sustained behavior under continuous pressure.---
GP3: Decoupled Performance Architecture
GP3 removes the dependency between storage size and performance.
Every GP3 volume includes:
3,000 IOPS baseline
125 MB/s baseline throughput
You can provision up to:
16,000 IOPS
1,000 MB/s throughput
64 TiB storage
IOPS and throughput are explicitly configured and independent of storage capacity.
There is no credit system.
There is no burst window.
Performance is deterministic.---
Architecture Comparison
GP2 provides proportional performance tied to size.
GP3 provides provisioned performance tied to workload requirements.
That architectural difference becomes operationally significant under sustained load.---
**IOPS vs Throughput: Workload Sensitivity
**
Performance tuning requires understanding workload patterns.
Small block workloads (4K–16K) are typically IOPS-bound.
Large block workloads are typically throughput-bound.
GP2 scales both indirectly through volume size.
GP3 allows each dimension to be tuned explicitly.
For production databases running steady transactions, sustained IOPS consistency is often more important than theoretical burst capacity.---
Sustained Workload Benchmark
Test configuration:
500 GB volume
70% write workload
45-minute sustained load
Target: 6,000 IOPS
These numbers reflect typical behavior observed under sustained write-heavy workloads, not short synthetic burst tests
GP2 performs adequately at the beginning of the workload.
Once burst credits deplete, latency variance increases and throughput stabilizes at baseline.
GP3 maintains consistent I/O performance across the entire duration.
Consistency is what production systems require.---
**Real Cost Comparison
Requirement:
6,000 sustained IOPS
500 GB usable storage
GP2
To achieve 6,000 baseline IOPS:6,000 ÷ 3 = 2,000 GB
2 TB × ~$0.10 per GB ≈ ~$200/month
You are paying for capacity purely to achieve performance.---
GP3
Provision:
500 GB storage
6,000 IOPS
Estimated monthly cost:
- 500 GB × ~$0.08 = ~$40
- Additional 3,000 IOPS × ~$0.005 = ~$15
- Throughput adjustment ≈ ~$5–10
Total ≈ ~$60–65/month
The cost difference is not linear. It compounds with scale across environments and accounts.
Across multiple volumes, the annual savings become material.---
*Operational Considerations
*
Migrating from GP2 to GP3 is straightforward
`aws ec2 modify-volume \
--volume-id vol-xxxxxxxx \
--volume-type gp3`
In most cases:
Modification is online
No IAM changes required
Monitoring remains identical
From an operational perspective, the change is minimal.
From a performance predictability perspective, the impact is significant.---
**When GP3 Should Be the Default
**
Production databases
Search and indexing systems
Write-heavy services
Sustained transaction workloads
Cost optimization initiatives
GP2 remains acceptable only where legacy automation or temporary environments prevent modification.---
Conclusion
GP2 ties performance to storage size and depends on burst credits.
GP3 separates capacity from performance and provides sustained deterministic I/O.
Choosing GP2 for new production systems requires justification.
For sustained workloads, GP3 is the rational default.
Top comments (0)