“Switching EBS volume types felt like swapping engines mid-flight - exciting but kinda terrifying.” - Alex Morgan
After five years of building web apps that just have to work, I finally sat down with Taylor Reed, AWS Performance Architect, to demystify the shift from gp2 to gp3 volumes. Below is our unfiltered Q&A.
1. Why did AWS even launch gp3? Wasn’t gp2 good enough?
Alex: I’ve happily lived on gp2 for years. Why rock the boat?
Taylor: Performance ceilings. gp2 tied throughput and IOPS directly to volume size - meaning you’d over-provision GBs just to squeeze extra speed. gp3 divorces that marriage: you independently dial IOPS (up to 16K) and throughput (up to 1,000 MB/s) regardless of size. Think of gp2 as a fixed-gear bike; gp3 gives you manual gears and a turbo button.
2. So gp3 is faster and cheaper? What’s the catch?
Alex: Too good to be true alert!
Taylor: On-paper price per GB drops ~20%. But gp3’s base tier includes 3,000 IOPS and 125 MB/s. If your workload already sat comfortably under those gp2 burst limits, you’ll pocket pure savings. Heavy write-intensive workloads, though, may need paid IOPS bumps. Cost-efficiency, yes, but “cheaper” depends on your tuning discipline.
3. How do burst credits differ between gp2 and gp3?
Alex: My dev databases love bursting; will they still party on gp3?
Taylor: gp3 has no burst-credit system. You provision the exact performance you need - zero surprises. gp2 hands out 3,000 IOPS bursts via credits, which refill at 3 IOPS per GB. Large but idle volumes secretly hoard credits; tiny busy ones often starve. gp3 ends that game.
4. Any migration “gotchas” I should prepare for?
Alex: Walk me through the potholes.
Taylor:
- IOPS/Throughput Planning: Snapshot-oriented migrations default gp3 to 3,000/125. Validate production baselines first.
- Older Kernels: Pre-4.14 Linux kernels mis-report gp3 performance stats. Patch before switching.
- Cost Alarms: Savings cheer, but keep CloudWatch budgets on. Over-provisioned IOPS can eat your pizza money.
5. When should I stick to gp2?
Alex: Any scenario where gp2 still wins?
Taylor: Rare, but:
- Short-lived <=170 GB Volumes that spike occasionally - gp2’s free credits might beat gp3’s paid IOPS.
- Legacy AMIs baked with tooling that assumes burst credits.
For 90% of cases, gp3 is the new sensible default.
6. Performance in the real world: have numbers?
| Volume | IOPS | Throughput (MB/s) | Monthly $ per 100 GB |
|---|---|---|---|
| gp2 | 3,000 (burst) | 250 (burst) | ~$10.00 |
| gp3 | 3,000 (base) | 125 (base) | ~$8.00 |
| gp3 max | 16,000 | 1,000 | ~$28.00 (with max IOPS) |
Tip: gp3’s throughput scales linearly with IOPS; set both consciously.
7. Any tooling to automate gp2 ➜ gp3 conversions?
Alex: I’d rather automate than babysit.
Taylor: AWS CLI one-liners work, but for fleets: AWS Compute Optimizer flags under-utilised gp2 volumes and recommends gp3 targets. Pair with AWS Systems Manager Automation to mass-convert during maintenance windows.
Key Takeaways
- gp3 decouples capacity from performance - goodbye over-provisioning.
- Expect ~20% cost savings plus predictable latency.
- Migrate after benchmarking baseline IOPS/throughput; tune accordingly.
Conclusion
Like switching from a pay-as-you-go phone to an unlimited plan, gp3 offers freedom and savings - provided you configure it wisely. Ready to make the jump? Drop your questions for Taylor in the comments.
🚀 Happy optimizing!