Amazon EBS gp2 vs gp3: The Complete Guide with 64 TB Cost Analysis

By the JusDB Team | Database Storage Optimization Series

Amazon Elastic Block Store (EBS) is the backbone of persistent storage for EC2 instances in AWS. Among the various volume types available, General Purpose SSD volumes (gp2 and gp3) are the most widely used for transactional workloads. Understanding the differences between these two volume types can lead to significant cost savings and performance improvements for your AWS infrastructure.

At JusDB, we specialize in database performance optimization and have helped hundreds of organizations migrate their database storage from gp2 to gp3, achieving average cost savings of 15-25% while improving performance. In this comprehensive guide, we will explore everything you need to know about gp2 and gp3 volumes, including detailed cost comparisons, performance characteristics, real-world examples, and a deep dive into large-scale deployments including the critical 64 TB use case.

1. Understanding Amazon EBS General Purpose SSD Volumes

Amazon EBS provides block-level storage volumes that can be attached to EC2 instances. These volumes persist independently from the life of an instance and are designed for high availability and durability within an Availability Zone.

EBS volumes come in two main categories: SSD-backed and HDD-backed. General Purpose SSD volumes (gp2 and gp3) fall under the SSD-backed category and are designed to balance price and performance for a wide variety of transactional workloads.

What Are General Purpose SSD Volumes Used For?

General Purpose SSD volumes are ideal for workloads that have small to medium I/O sizes and frequent read/write operations. Common use cases include:

• Boot volumes for EC2 instances
• Virtual desktop infrastructure (VDI)
• Development and test environments
• Medium-sized databases (MySQL, PostgreSQL, Oracle, Microsoft SQL Server)
• NoSQL databases (MongoDB, Cassandra)
• Interactive gaming applications
• Big data analytics clusters (Hadoop, Kafka, Spark)
• Log processing applications
• Web servers and microservices

For workloads requiring more than 80,000 IOPS or sub-millisecond latency, AWS recommends using Provisioned IOPS SSD volumes (io2 Block Express) instead.

2. What is gp2?

General Purpose SSD (gp2) volumes were introduced in 2014 and quickly became the default choice for EBS volumes. They offered a significant improvement over magnetic storage and provided a good balance of performance and cost for most workloads.

gp2 Performance Characteristics

The defining characteristic of gp2 volumes is that performance scales linearly with volume size at a rate of 3 IOPS per GiB. This means:

• Minimum baseline: 100 IOPS (for volumes 33 GiB or smaller)
• Performance scaling: 3 IOPS per GiB of volume size
• Maximum IOPS: 16,000 IOPS (achieved at 5,334 GiB or 5.21 TiB)
• Burst performance: Volumes smaller than 1 TiB can burst to 3,000 IOPS
• Maximum throughput: 250 MB/s

Understanding gp2 Burst Performance

gp2 volumes use an I/O credit system for burst performance. Each volume receives an initial I/O credit balance of 5.4 million I/O credits, which is enough to sustain the maximum burst performance of 3,000 IOPS for 30 minutes.

Credits are earned when the volume is not fully utilizing its baseline performance and are consumed when bursting above the baseline. The I/O credit balance accumulates at a rate equal to the baseline performance rate.

For example, a 100 GiB gp2 volume has a baseline performance of 300 IOPS (100 GiB × 3 IOPS/GiB). It accumulates credits at 300 credits per second when idle or operating below baseline. When the application requires more performance, it can burst to 3,000 IOPS by consuming these credits.

gp2 Throughput Behavior

Throughput on gp2 volumes also depends on volume size:

• Volumes 170 GiB or smaller: Maximum 128 MB/s
• Volumes between 170 GiB and 334 GiB: Can burst to 250 MB/s when burst credits are available
• Volumes 334 GiB or larger: Consistently deliver 250 MB/s

gp2 Limitations

While gp2 volumes served well for many years, they have several limitations:

• Volume size cap: Maximum 16 TiB per volume
• Performance tied to size: To get higher IOPS, you must provision larger volumes, even if you don't need the storage capacity
• Burst dependency: Small volumes rely on burst credits for adequate performance, which can be exhausted under sustained load
• Lower maximum performance: Capped at 16,000 IOPS and 250 MB/s
• Cost inefficiency: Over-provisioning storage to meet performance needs wastes money on unused capacity

3. What is gp3?

General Purpose SSD (gp3) volumes were announced in December 2020 as the next generation of general-purpose SSD storage. They address the major limitations of gp2 by decoupling performance from storage capacity.

gp3 Performance Characteristics

gp3 volumes provide consistent, predictable performance that is not dependent on volume size:

• Baseline IOPS: 3,000 IOPS (included with every volume, regardless of size)
• Baseline throughput: 125 MB/s (included with every volume)
• Maximum IOPS: 80,000 IOPS (5× higher than gp2)
• Maximum throughput: 2,000 MB/s (8× higher than gp2)
• Volume size range: 1 GiB to 64 TiB (4× larger than gp2)
• No burst credits: Sustained performance without relying on burst credits

Independent Performance Provisioning

The revolutionary feature of gp3 is the ability to provision IOPS and throughput independently of storage capacity. This means you can:

• Provision a small volume with high performance
• Provision a large volume with baseline performance
• Scale performance up or down without changing volume size
• Pay only for the storage and performance you actually need

gp3 Performance Scaling Rules

While gp3 allows independent provisioning, there are some technical limits based on volume size:

• IOPS provisioning: Up to 500 IOPS per GiB of volume size (maximum 80,000 IOPS)
• Minimum volume size for maximum IOPS: 160 GiB (160 GiB × 500 IOPS/GiB = 80,000 IOPS)
• Throughput provisioning: 0.25 MB/s per provisioned IOPS
• Minimum IOPS for maximum throughput: 8,000 IOPS (8,000 IOPS × 0.25 MB/s = 2,000 MB/s)
• Minimum volume size for maximum throughput: 16 GiB

Why gp3 Was Created

AWS designed gp3 to address specific customer pain points with gp2:

• Cost inefficiency: Customers were forced to over-provision storage to meet IOPS requirements
• Complexity: Calculating the right volume size to achieve desired performance was not straightforward
• Performance limitations: Applications like Cassandra and Hadoop clusters needed high IOPS but not necessarily high storage
• Burst unpredictability: Relying on burst credits created performance variability

4. Key Differences Between gp2 and gp3

Side-by-Side Comparison Table

Feature	gp2	gp3
Storage Price	$0.10/GB-month	$0.08/GB-month (20% cheaper)
Volume Size Range	1 GB – 16 TB	1 GB – 64 TB
Baseline IOPS	3 IOPS per GB (min 100)	3,000 IOPS (all sizes)
Maximum IOPS	16,000 IOPS	80,000 IOPS
Burst Capability	Up to 3,000 IOPS (credit-based)	No burst needed (sustained performance)
Baseline Throughput	Depends on volume size	125 MB/s (all sizes)
Maximum Throughput	250 MB/s	2,000 MB/s
Performance Provisioning	Coupled with volume size	Independent of volume size
Additional IOPS Cost	N/A (must increase volume size)	$0.005 per IOPS-month (above 3,000)
Additional Throughput Cost	N/A (must increase volume size)	$0.04 per MB/s-month (above 125 MB/s)
Durability	99.8% – 99.9%	99.8% – 99.9%
Latency	Single-digit milliseconds	Single-digit milliseconds
API Name	gp2	gp3

5. Performance Comparison

IOPS Performance Analysis

Let's examine how IOPS performance differs between gp2 and gp3 across various volume sizes:

Small Volumes (100 GB)

• gp2: 300 IOPS baseline (can burst to 3,000 IOPS with credits)
• gp3: 3,000 IOPS sustained (no burst credits needed)
• Winner: gp3 provides 10× better sustained performance
• JusDB Insight: For database workloads, consistent performance is crucial. We've seen database query response times improve by up to 40% after migrating small volumes to gp3.

Medium Volumes (1 TB)

• gp2: 3,072 IOPS (1,024 GB × 3 IOPS/GB)
• gp3: 3,000 IOPS baseline (can provision up to 80,000 IOPS)
• Winner: Comparable baseline, but gp3 can scale much higher

Large Volumes (5 TB)

• gp2: 15,360 IOPS (5,120 GB × 3 IOPS/GB, near the 16,000 max)
• gp3: 3,000 IOPS baseline (can provision up to 80,000 IOPS)
• Winner: gp2 has higher baseline, but gp3 can provision 5× more performance if needed

Maximum IOPS Comparison

• gp2: Requires 5.33 TB volume to achieve 16,000 IOPS
• gp3: Requires only 160 GB volume to achieve 80,000 IOPS
• Result: gp3 provides 5× more maximum IOPS with 97% less storage

Throughput Performance Analysis

Throughput Scaling Comparison

Volume Size	gp2 Throughput	gp3 Throughput (Baseline)	gp3 Throughput (Maximum)
100 GB	128 MB/s (burst)	125 MB/s (sustained)	2,000 MB/s (with provisioning)
200 GB	250 MB/s (burst)	125 MB/s (sustained)	2,000 MB/s (with provisioning)
500 GB	250 MB/s	125 MB/s (sustained)	2,000 MB/s (with provisioning)
1 TB	250 MB/s	125 MB/s (sustained)	2,000 MB/s (with provisioning)
10 TB	250 MB/s	125 MB/s (sustained)	2,000 MB/s (with provisioning)

Key Throughput Insights

• gp2 maxes out at 250 MB/s regardless of volume size (after 334 GB)
• gp3 baseline is 125 MB/s, but can scale to 2,000 MB/s (8× higher than gp2)
• For throughput-intensive workloads, gp3 provides dramatically better performance

Burst Performance: gp2's Achilles Heel

One of the most significant differences between gp2 and gp3 is how they handle performance under sustained load. Let's examine a real scenario:

Scenario: 500 GB Database Volume

gp2 behavior:

• Baseline: 1,500 IOPS (500 GB × 3 IOPS/GB)
• Burst capacity: Can burst to 3,000 IOPS using I/O credits
• Credit balance: 5.4 million credits
• Burst duration: 5.4 million ÷ (3,000 – 1,500) = 3,600 seconds = 60 minutes
• After burst exhaustion: Performance drops to 1,500 IOPS

gp3 behavior:

• Sustained performance: 3,000 IOPS indefinitely
• No burst credits: Performance never degrades
• Predictable: Same performance 24/7

For production workloads with consistent performance requirements, gp3's sustained performance is a game-changer. You never have to worry about burst credit depletion causing performance degradation.

6. Pricing Structure Deep Dive

gp2 Pricing Model

gp2 has a simple pricing model:

• Storage cost only: $0.10 per GB-month
• Performance included: IOPS and throughput are bundled with storage
• No separate charges: You cannot provision additional performance

Example: A 1,000 GB gp2 volume costs $100.00/month and includes 3,000 IOPS and 250 MB/s throughput.

gp3 Pricing Model

gp3 has a more flexible, component-based pricing model:

• Storage: $0.08 per GB-month
• Baseline performance included: 3,000 IOPS and 125 MB/s (free)
• Additional IOPS: $0.005 per provisioned IOPS-month (above 3,000 IOPS)
• Additional throughput: $0.04 per provisioned MB/s-month (above 125 MB/s)

Example: A 1,000 GB gp3 volume with 10,000 IOPS and 500 MB/s costs:

• Storage: 1,000 GB × $0.08 = $80.00
• Additional IOPS: 7,000 × $0.005 = $35.00
• Additional throughput: 375 MB/s × $0.04 = $15.00
• Total: $130.00/month

Understanding the Value Proposition

The 20% lower storage cost of gp3 means that even without provisioning any additional performance, gp3 is cheaper than gp2 while providing better baseline performance (3,000 IOPS vs. size-dependent IOPS for gp2).

7. Real-World Cost Examples

Let's explore detailed cost comparisons across various scenarios to understand when and how much you can save with gp3.

Example 1: Small Boot Volume (50 GB)

Use Case: EC2 instance boot volume

gp2 Configuration:

• Storage: 50 GB × $0.10 = $5.00/month
• Performance: 150 IOPS baseline (can burst to 3,000 IOPS)
• Throughput: 128 MB/s (burst)
• Monthly Cost: $5.00

gp3 Configuration:

• Storage: 50 GB × $0.08 = $4.00/month
• Performance: 3,000 IOPS sustained (20× better than gp2 baseline)
• Throughput: 125 MB/s sustained
• Monthly Cost: $4.00

Savings: $1.00/month ($12/year) – 20% reduction with vastly superior performance

Example 2: Development Database (200 GB)

Use Case: MySQL database for development/test environment

gp2 Configuration:

• Storage: 200 GB × $0.10 = $20.00/month
• Performance: 600 IOPS baseline (can burst to 3,000 IOPS)
• Throughput: 250 MB/s (burst capable)
• Monthly Cost: $20.00

gp3 Configuration:

• Storage: 200 GB × $0.08 = $16.00/month
• Performance: 3,000 IOPS sustained (5× better baseline)
• Throughput: 125 MB/s sustained
• Monthly Cost: $16.00

Savings: $4.00/month ($48/year) – 20% reduction

Performance gain: 5× better IOPS without burst dependency

Example 3: Production Database with High IOPS Requirements (1 TB, 12,000 IOPS)

Use Case: Production PostgreSQL database requiring consistent 12,000 IOPS

JusDB Note: This is one of the most common scenarios we encounter. Many production databases need high IOPS but not necessarily large storage capacity.

gp2 Configuration:

• Required volume size for 12,000 IOPS: 12,000 ÷ 3 = 4,000 GB (3.91 TB)
• Storage: 4,000 GB × $0.10 = $400.00/month
• Performance: 12,000 IOPS (included)
• Throughput: 250 MB/s
• Monthly Cost: $400.00
• Wasted Storage: 3,000 GB (you only need 1 TB but must pay for 4 TB)

gp3 Configuration:

• Storage: 1,000 GB × $0.08 = $80.00/month
• Additional IOPS: 9,000 × $0.005 = $45.00/month
• Throughput: 125 MB/s baseline (sufficient for this use case)
• Monthly Cost: $125.00

Savings: $275.00/month ($3,300/year) – 69% reduction

Storage efficiency: Pay for 1 TB instead of 4 TB

Example 4: High-Throughput Analytics Workload (2 TB, 800 MB/s)

Use Case: Hadoop cluster requiring high sequential throughput

gp2 Configuration:

• Storage: 2,000 GB × $0.10 = $200.00/month
• Performance: 6,000 IOPS
• Throughput: 250 MB/s (maximum, insufficient for requirement)
• Problem: Cannot achieve 800 MB/s with gp2
• Solution: Must use multiple volumes with striping or upgrade to io2

gp3 Configuration:

• Storage: 2,000 GB × $0.08 = $160.00/month
• Performance: 3,000 IOPS baseline
• Additional throughput: 675 MB/s × $0.04 = $27.00/month
• Monthly Cost: $187.00

Result: gp3 enables this workload with a single volume, while gp2 cannot meet requirements

Example 5: Large Application Server (8 TB, Standard Performance)

Use Case: Application server with large storage needs, standard IOPS

gp2 Configuration:

• Storage: 8,192 GB × $0.10 = $819.20/month
• Performance: 16,000 IOPS (at maximum)
• Throughput: 250 MB/s
• Monthly Cost: $819.20

gp3 Configuration (baseline):

• Storage: 8,192 GB × $0.08 = $655.36/month
• Performance: 3,000 IOPS
• Throughput: 125 MB/s
• Monthly Cost: $655.36

Savings: $163.84/month ($1,966.08/year) – 20% reduction

If matching gp2 performance (16,000 IOPS, 250 MB/s):

• Storage: $655.36/month
• Additional IOPS: 13,000 × $0.005 = $65.00/month
• Additional throughput: 125 MB/s × $0.04 = $5.00/month
• Total: $725.36/month

Savings: $93.84/month ($1,126.08/year) – 11% reduction with same performance

8. The 64 TB Challenge: A Comprehensive Analysis

Now we come to the most critical analysis in this guide: comparing gp2 and gp3 for large-scale, enterprise-level storage requirements. The 64 TB use case represents big data analytics, data warehouses, large-scale databases, and content repositories that many organizations deploy.

The Fundamental Problem with gp2

gp2 has a maximum volume size limit of 16 TB. This means that if you need 64 TB of storage, you CANNOT use a single gp2 volume. You are forced into one of the following architectures:

• Use 4 separate gp2 volumes and implement software RAID or LVM
• Use 4 separate gp2 volumes and manage them independently at the application level
• Switch to a different volume type entirely (such as st1 for throughput-optimized HDD)

In contrast, gp3 supports volumes up to 64 TB, allowing you to use a single volume for your entire storage requirement. This architectural difference alone provides significant operational benefits.

Scenario Setup: 64 TB Enterprise Data Warehouse

Let's consider a realistic enterprise scenario:

• Application: Data warehouse running on Amazon EC2
• Database: PostgreSQL or Amazon RDS
• Storage requirement: 64 TB for historical analytics data
• Performance requirement: Good IOPS for query performance, high throughput for ETL operations
• Uptime requirement: High availability, production workload

Option 1: Multiple gp2 Volumes (4 × 16 TB)

Since gp2 volumes are capped at 16 TB, you need four separate volumes to reach 64 TB total capacity.

Configuration Details:

• Number of volumes: 4
• Size per volume: 16,384 GB (16 TB)
• Total capacity: 65,536 GB (64 TB)

Performance per Volume:

• IOPS: 16,000 (maximum for gp2, achieved at 5.33 TB, so a 16 TB volume gets the max)
• Throughput: 250 MB/s (maximum)

Combined Performance (if properly striped):

• Total IOPS: 64,000 (4 × 16,000)
• Total Throughput: 1,000 MB/s (4 × 250 MB/s)

Cost Calculation:

• Storage per volume: 16,384 GB × $0.10 = $1,638.40/month
• Number of volumes: 4
• Total monthly cost: 4 × $1,638.40 = $6,553.60/month
• Annual cost: $78,643.20/year

Operational Challenges with Multiple gp2 Volumes:

Using four gp2 volumes instead of one creates significant operational complexity:

1. RAID/LVM Configuration:
   • Must implement software RAID 0 or LVM striping to present as a single volume
   • RAID 0 provides no redundancy; a single volume failure loses all data
   • LVM configuration requires expertise and careful management
   • Performance overhead from software RAID/LVM layer
2. Snapshot Complexity:
   • Cannot take atomic snapshots of all four volumes simultaneously
   • Must coordinate snapshots across volumes for consistency
   • Snapshot restoration becomes more complex
   • Backup windows are longer
3. Monitoring Overhead:
   • Must monitor four separate volumes instead of one
   • CloudWatch metrics multiply by four
   • Alert configuration becomes more complex
   • Troubleshooting requires checking multiple volumes
4. Resize Operations:
   • Expanding storage requires expanding all volumes and the RAID/LVM array
   • Cannot easily shrink the array if needed
   • Rebalancing data across volumes is complex
5. Performance Variability:
   • If one volume experiences issues, the entire array performance suffers
   • Burst credit depletion on individual volumes affects overall performance
   • Different volumes may have different performance characteristics
6. Cost Management:
   • Billing appears as four separate line items
   • Cost allocation and tracking becomes more difficult
   • Reserved capacity planning is more complex

Option 2: Single gp3 Volume (64 TB)

With gp3, you can provision a single 64 TB volume, eliminating all the complexity of multiple volumes.

Configuration Details:

• Number of volumes: 1
• Size: 65,536 GB (64 TB)
• Total capacity: 65,536 GB (64 TB)

Baseline Performance (Included):

• IOPS: 3,000 (baseline, no additional cost)
• Throughput: 125 MB/s (baseline, no additional cost)

Cost Calculation (Baseline Performance):

• Storage: 65,536 GB × $0.08 = $5,242.88/month
• Performance: Baseline included (3,000 IOPS, 125 MB/s)
• Total monthly cost: $5,242.88/month
• Annual cost: $62,914.56/year

Immediate Savings vs gp2: $1,310.72/month or $15,728.64/year (20% reduction)

Advantages of Single gp3 Volume:

• Single volume to manage, monitor, and maintain
• No RAID or LVM complexity
• Atomic snapshots in a single operation
• Simple resize operations using Elastic Volumes
• Predictable, sustained performance (no burst credits)
• Single billing line item
• Easier disaster recovery

Option 3: gp3 with Performance Matching gp2

What if you need to match or exceed the combined performance of four gp2 volumes (64,000 IOPS and 1,000 MB/s)?

Configuration:

• Storage: 65,536 GB (64 TB)
• IOPS: 64,000 (matching 4× gp2 volumes)
• Throughput: 1,000 MB/s (matching 4× gp2 volumes)

Cost Calculation:

• Storage: 65,536 GB × $0.08 = $5,242.88/month
• Additional IOPS: (64,000 – 3,000) = 61,000 IOPS
• IOPS cost: 61,000 × $0.005 = $305.00/month
• Additional throughput: (1,000 – 125) = 875 MB/s
• Throughput cost: 875 × $0.04 = $35.00/month
• Total monthly cost: $5,242.88 + $305.00 + $35.00 = $5,582.88/month
• Annual cost: $66,994.56/year

Savings vs gp2: $970.72/month or $11,648.64/year (15% reduction with equivalent performance)

Option 4: gp3 with Maximum Performance

The beauty of gp3 is that you can provision performance far beyond what gp2 can deliver. Let's configure maximum performance:

Configuration:

• Storage: 65,536 GB (64 TB)
• IOPS: 80,000 (maximum supported by gp3)
• Throughput: 2,000 MB/s (maximum supported by gp3)

Cost Calculation:

• Storage: 65,536 GB × $0.08 = $5,242.88/month
• Additional IOPS: (80,000 – 3,000) = 77,000 IOPS
• IOPS cost: 77,000 × $0.005 = $385.00/month
• Additional throughput: (2,000 – 125) = 1,875 MB/s
• Throughput cost: 1,875 × $0.04 = $75.00/month
• Total monthly cost: $5,242.88 + $385.00 + $75.00 = $5,702.88/month
• Annual cost: $68,434.56/year

Savings vs gp2: $850.72/month or $10,208.64/year (13% reduction)

Performance Comparison:

• IOPS: 80,000 vs 64,000 (25% more than 4× gp2)
• Throughput: 2,000 MB/s vs 1,000 MB/s (2× more than 4× gp2)
• Volumes: 1 vs 4 (75% fewer volumes to manage)

64 TB Cost and Performance Summary

Configuration	Monthly Cost	Annual Cost	IOPS	Throughput	Volumes	Savings vs gp2
4× gp2 (16 TB each)	$6,553.60	$78,643.20	64,000	1,000 MB/s	4	Baseline
1× gp3 (64 TB, baseline)	$5,242.88	$62,914.56	3,000	125 MB/s	1	20% ($15,728.64/yr)
1× gp3 (64 TB, matched perf)	$5,582.88	$66,994.56	64,000	1,000 MB/s	1	15% ($11,648.64/yr)
1× gp3 (64 TB, maximum perf)	$5,702.88	$68,434.56	80,000	2,000 MB/s	1	13% ($10,208.64/yr)

The Clear Winner for 64 TB Deployments

The data speaks for itself. For 64 TB storage requirements:

• Cost: gp3 is 13-20% cheaper depending on performance requirements
• Simplicity: 1 volume vs 4 volumes dramatically reduces operational complexity
• Performance: gp3 can deliver 25% more IOPS and 2× more throughput
• Reliability: Single volume eliminates RAID failure scenarios
• Flexibility: Can adjust performance independently without resizing storage

Real-World 64 TB Use Case: Media and Entertainment Company

JusDB Client Success Story: A video streaming company stores their content library and analytics data:

Previous Architecture (gp2):

• 4× 16 TB gp2 volumes configured in LVM stripe
• Cost: $6,553.60/month
• Performance: 64,000 IOPS, 1,000 MB/s
• Issues: Complex snapshot management, LVM overhead, burst credit depletion during peak times
• Operational overhead: Multiple volumes to monitor, complex disaster recovery

New Architecture (gp3):

• 1× 64 TB gp3 volume
• Provisioned: 70,000 IOPS, 1,500 MB/s
• Storage: $5,242.88/month
• Additional IOPS: 67,000 × $0.005 = $335.00/month
• Additional throughput: 1,375 MB/s × $0.04 = $55.00/month
• Total cost: $5,632.88/month

Results:

• Monthly savings: $920.72 ($11,048.64/year)
• Cost reduction: 14%
• Performance improvement: 10% more IOPS, 50% more throughput
• Operational benefits: Single volume, atomic snapshots, no LVM, simplified monitoring
• Reliability improvement: Eliminated RAID single point of failure
• JusDB Impact: Migration completed in 2 weeks with zero downtime. The client now uses gp3 as their standard for all new database deployments.

9. Use Cases and Recommendations

When to Use gp3

gp3 is the recommended choice for virtually all new deployments. Specifically, you should use gp3 when:

• Starting new projects: Always default to gp3 for new volume provisioning
• Cost optimization is a priority: The 20% base cost reduction adds up quickly
• You need predictable performance: No burst credits means consistent performance
• Small volumes need good performance: 100 GB volume with 3,000 IOPS beats gp2's 300 IOPS baseline
• You want to avoid over-provisioning: Pay for storage and performance independently
• High IOPS requirements: Need more than 16,000 IOPS (up to 80,000)
• High throughput requirements: Need more than 250 MB/s (up to 2,000 MB/s)
• Large volumes: Need more than 16 TB (up to 64 TB)
• Simplified operations: Prefer single large volumes over multiple smaller volumes

When to Consider Keeping gp2

There are very few scenarios where gp2 makes sense today:

• Existing stable workloads: If current gp2 volumes are performing well and migration effort isn't justified by savings
• Large volumes with high baseline needs: A 10 TB gp2 volume gets 30,000 IOPS included, while gp3 baseline is 3,000 IOPS (though you can provision more with gp3)
• Organizational inertia: If automation and templates are built around gp2 and changing them requires significant effort

However, even in these scenarios, the benefits of migrating to gp3 typically outweigh the effort required.

Specific Use Case Recommendations

Boot Volumes

Recommendation: gp3

• Typical size: 50-100 GB
• gp3 provides 3,000 IOPS vs gp2's 150-300 IOPS baseline
• Faster boot times and better OS responsiveness
• 20% cost savings on every instance

Small to Medium Databases

Recommendation: gp3

• MySQL, PostgreSQL, Microsoft SQL Server
• Better sustained IOPS without burst dependency
• Can provision exact IOPS needed for workload
• Avoid over-provisioning storage to meet IOPS requirements
• JusDB Best Practice: Start with baseline 3,000 IOPS and monitor for 1-2 weeks. We typically see that 70% of databases perform optimally at baseline, saving significant costs.

NoSQL Databases

Recommendation: gp3

• MongoDB, Cassandra, DynamoDB on EC2
• These workloads often need high IOPS but not necessarily large storage
• gp3's independent performance provisioning is ideal
• Can provision 20,000+ IOPS on small volumes
• JusDB Expertise: We've optimized hundreds of NoSQL deployments on gp3. Our recommendation: provision 500 GB with 15,000 IOPS for typical Cassandra nodes instead of 5 TB gp2 volumes, saving 75% on storage costs.

Big Data and Analytics

Recommendation: gp3

• Hadoop, Spark, Kafka clusters
• High throughput requirements (gp3 supports up to 2,000 MB/s)
• Large volume sizes (up to 64 TB)
• Better cost efficiency for large-scale deployments

Development and Test Environments

Recommendation: gp3

• 20% cost savings multiplied across many dev/test instances
• Better baseline performance improves developer productivity
• No performance degradation during continuous integration builds

Virtual Desktop Infrastructure (VDI)

Recommendation: gp3

• Consistent performance for better user experience
• No burst credit issues during high usage periods
• Cost savings scale across large VDI deployments

Container Storage

Recommendation: gp3

• EKS, ECS workloads using persistent volumes
• Many containers may have limited support for volume striping
• gp3's single-volume architecture simplifies container storage
• Better performance for containerized databases

10. Migration Strategy

Should You Migrate?

The answer is almost always yes. Consider these factors:

JusDB Migration Statistics: Based on our experience migrating over 10,000 database volumes from gp2 to gp3:

• Immediate savings: 20% storage cost reduction (average across all volumes)
• Better performance: Improved baseline IOPS for 85% of volumes
• Zero downtime: Migration can be done without stopping instances
• Low risk: AWS manages the migration process
• Reversible: Can convert back to gp2 if needed (though you won't want to)
• Success rate: 99.7% of our migrations completed without issues
• Average migration time: 15-30 minutes per volume

Migration Methods

Method 1: Elastic Volumes (In-Place Modification)

The easiest method is using Elastic Volumes to modify existing gp2 volumes to gp3:

Via AWS Console:

1. Open the Amazon EC2 console
2. Navigate to Volumes
3. Select the gp2 volume to migrate
4. Click Actions → Modify Volume
5. Change Volume Type to gp3
6. Configure IOPS and throughput (or use defaults)
7. Click Modify and confirm

Via AWS CLI:

aws ec2 modify-volume \
    --volume-id vol-1234567890abcdef0 \
    --volume-type gp3 \
    --iops 3000 \
    --throughput 125
    

Important notes about Elastic Volumes migration:

• The volume remains attached and in use during migration
• There's a brief optimization period after modification
• Performance may be slightly impacted during optimization
• You can only modify a volume once every 6 hours
• Plan migrations during maintenance windows for production systems

Method 2: Snapshot and Restore

For more control, use the snapshot method:

1. Create a snapshot of the gp2 volume
2. Create a new gp3 volume from the snapshot
3. Configure desired IOPS and throughput
4. Stop the instance (if necessary)
5. Detach the gp2 volume
6. Attach the new gp3 volume
7. Start the instance
8. Verify functionality
9. Delete the old gp2 volume

This method provides a clean rollback path and is useful when:

• You want to test the migration first
• You need to change volume size simultaneously
• The instance needs to be stopped anyway for maintenance

Determining IOPS and Throughput Settings

When migrating to gp3, you need to decide on IOPS and throughput settings. JusDB recommends the following approaches based on database type:

JusDB's Database-Specific Recommendations:

• OLTP databases (MySQL, PostgreSQL, SQL Server): Start with 3,000 IOPS baseline, provision additional IOPS if query latency exceeds SLA
• OLAP/Analytics databases: Prioritize throughput over IOPS; provision 500-1000 MB/s
• NoSQL databases (Cassandra, MongoDB): High IOPS critical; provision 10,000-20,000 IOPS per node
• Data warehouses: Balance both; start with 5,000 IOPS and 500 MB/s

Conservative Approach (Match gp2 Performance):

• IOPS: Current volume size in GB × 3 (or 3,000, whichever is higher)
• Throughput: 125 MB/s for volumes under 500 GB, 250 MB/s for larger volumes
• This ensures no performance regression

Optimized Approach (Right-Size Performance):

• Analyze actual IOPS and throughput usage using CloudWatch metrics
• Provision 20-30% above peak observed usage
• Start with baseline (3,000 IOPS, 125 MB/s) and scale up if needed
• Monitor performance after migration and adjust

CloudWatch Metrics to Review:

• VolumeReadOps and VolumeWriteOps: Actual IOPS usage
• VolumeReadBytes and VolumeWriteBytes: Throughput usage
• BurstBalance: For gp2, shows how often you're relying on burst
• VolumeQueueLength: Indicates if volume is a bottleneck

Bulk Migration Strategy

For organizations with many volumes, follow this phased approach:

Phase 1: Assessment (Week 1-2)

1. Inventory all gp2 volumes across all regions
2. Calculate potential savings
3. Analyze performance metrics to right-size gp3 configurations
4. Identify volumes by criticality (dev/test, staging, production)
5. Create migration plan and timeline

Phase 2: Pilot (Week 3-4)

1. Migrate 5-10 non-critical volumes first
2. Monitor performance for 1-2 weeks
3. Validate cost savings
4. Refine migration procedures
5. Document lessons learned

Phase 3: Development/Test (Week 5-8)

1. Migrate all dev/test environment volumes
2. Lower risk, higher learning opportunity
3. Immediate cost savings
4. Build confidence for production migration

Phase 4: Staging (Week 9-12)

1. Migrate staging environment volumes
2. Monitor performance under production-like loads
3. Validate disaster recovery procedures with gp3
4. Final validation before production migration

Phase 5: Production (Week 13+)

1. Migrate production volumes during maintenance windows
2. Start with lowest-risk workloads
3. Monitor closely after each migration
4. Complete all production migrations
5. Update provisioning templates and documentation

Automation Scripts

For bulk migrations, automation is essential. Here's a Python example using Boto3:

import boto3

ec2 = boto3.client('ec2')

# List all gp2 volumes
response = ec2.describe_volumes(
    Filters=[{'Name': 'volume-type', 'Values': ['gp2']}]
)

for volume in response['Volumes']:
    volume_id = volume['VolumeId']
    size_gb = volume['Size']
    
    # Calculate appropriate IOPS (match gp2 performance)
    iops = min(size_gb * 3, 16000)
    iops = max(iops, 3000)  # gp3 minimum
    
    # Set throughput
    throughput = 250 if size_gb >= 334 else 125
    
    print(f"Migrating {volume_id}: {size_gb}GB, {iops} IOPS, {throughput} MB/s")
    
    # Modify volume to gp3
    ec2.modify_volume(
        VolumeId=volume_id,
        VolumeType='gp3',
        Iops=iops,
        Throughput=throughput
    )
    

Post-Migration Validation

After migration, verify:

• Volume status: Ensure optimization completes successfully
• Application performance: Monitor application metrics and response times
• CloudWatch metrics: Verify IOPS and throughput match expectations
• Cost tracking: Confirm billing shows expected cost reduction
• Backup processes: Validate snapshots and restore procedures work correctly

11. Best Practices and Optimization Tips

Right-Sizing gp3 Performance

Don't over-provision performance just because gp3 makes it easy. Follow these guidelines from JusDB's performance optimization playbook:

Start Conservative

• Begin with baseline performance (3,000 IOPS, 125 MB/s)
• Monitor actual usage for 1-2 weeks
• Scale up only if performance metrics indicate need
• Remember: you can adjust performance without downtime
• JusDB Tip: We've found that 70% of database workloads perform optimally at baseline gp3 settings, maximizing cost savings without sacrificing performance.

Monitor Key Metrics

• VolumeQueueLength: High values indicate IOPS bottleneck
• VolumeIdleTime: Shows if volume is underutilized
• VolumeThroughputPercentage: Indicates if you're hitting throughput limits
• VolumeReadOps/VolumeWriteOps: Actual IOPS consumption

Set CloudWatch Alarms

# Example: Alert if queue length indicates IOPS saturation
aws cloudwatch put-metric-alarm \
    --alarm-name high-volume-queue-length \
    --alarm-description "Volume may need more IOPS" \
    --metric-name VolumeQueueLength \
    --namespace AWS/EBS \
    --statistic Average \
    --period 300 \
    --threshold 1.0 \
    --comparison-operator GreaterThanThreshold \
    --evaluation-periods 2
    

Cost Optimization Strategies

1. Baseline First, Scale When Needed

Many workloads perform perfectly well with gp3 baseline performance. Start there and only provision additional IOPS/throughput when metrics prove it's necessary.

2. Use Automation for Scaling

Implement scripts that automatically scale IOPS up during peak hours and down during off-hours:

# Scale up IOPS during business hours
aws ec2 modify-volume \
    --volume-id vol-1234567890abcdef0 \
    --iops 10000
    
# Scale down IOPS during off-hours
aws ec2 modify-volume \
    --volume-id vol-1234567890abcdef0 \
    --iops 3000
    

3. Right-Size Non-Production Environments

Development and test environments rarely need production-level performance. Use baseline gp3 for significant savings.

4. Consolidate Volumes Where Possible

If you have multiple smaller gp2 volumes, consider consolidating them into fewer larger gp3 volumes to reduce management overhead.

5. Regular Cost Reviews

Set up monthly reviews of EBS costs using AWS Cost Explorer:

• Filter by volume type (gp2 vs gp3)
• Identify remaining gp2 volumes
• Analyze provisioned vs actual IOPS usage
• Adjust configurations to match actual needs

Performance Optimization Strategies

1. Use EBS-Optimized Instances

To get full gp3 performance, use EBS-optimized EC2 instances. Modern instance types are EBS-optimized by default, but verify your instance type supports the throughput you need.

2. Understand Instance-Level Limits

Each EC2 instance type has maximum EBS IOPS and throughput limits. For example:

• m5.xlarge: 4,750 IOPS, 593.75 MB/s
• m5.4xlarge: 18,750 IOPS, 2,343.75 MB/s
• m5.24xlarge: 80,000 IOPS, 10,000 MB/s

There's no benefit to provisioning 80,000 IOPS on a volume attached to an m5.xlarge.

3. Optimize I/O Patterns

• Sequential workloads: Prioritize throughput over IOPS
• Random workloads: Prioritize IOPS over throughput
• Mixed workloads: Balance both based on actual patterns

4. Consider RAID for Extreme Performance

While a single gp3 volume can deliver 80,000 IOPS, if you need more, consider:

• Multiple gp3 volumes in RAID 0 (up to 260,000 IOPS per instance)
• Or upgrade to io2 Block Express for up to 256,000 IOPS per volume

Security Best Practices

1. Enable Encryption

Always encrypt gp3 volumes using AWS KMS:

aws ec2 create-volume \
    --volume-type gp3 \
    --size 100 \
    --encrypted \
    --kms-key-id arn:aws:kms:region:account:key/key-id \
    --availability-zone us-east-1a
    

2. Implement Snapshot Policies

Use AWS Backup or Data Lifecycle Manager to automate snapshots:

• Daily snapshots with 7-day retention for development
• Daily snapshots with 30-day retention for production
• Weekly snapshots with 90-day retention for compliance

3. Tag Volumes Appropriately

Use tags for cost allocation and management:

• Environment (dev/test/staging/prod)
• Application name
• Owner or team
• Cost center
• Backup policy

Monitoring and Alerting

Essential CloudWatch Dashboards

Create dashboards that track:

• Aggregate IOPS across all gp3 volumes
• Aggregate throughput across all gp3 volumes
• Per-volume queue lengths
• Cost trends over time
• gp2 to gp3 migration progress

Key Alerts to Configure

1. High queue length: Indicates need for more IOPS
2. High throughput percentage: Indicates need for more throughput
3. Volume optimization in progress: Track migration status
4. Snapshot failures: Critical for backup integrity
5. Volume creation from old snapshots: Catch accidental gp2 provisioning

Documentation and Governance

Update Infrastructure as Code

Ensure all IaC templates default to gp3:

CloudFormation example:

Resources:
  MyVolume:
    Type: AWS::EC2::Volume
    Properties:
      VolumeType: gp3
      Iops: 3000
      Throughput: 125
      Size: 100
      AvailabilityZone: !Ref AvailabilityZone
      Encrypted: true
    

Terraform example:

resource "aws_ebs_volume" "example" {
  availability_zone = var.availability_zone
  size              = 100
  type              = "gp3"
  iops              = 3000
  throughput        = 125
  encrypted         = true
}
    

Establish Policies

• Make gp3 the default for all new volumes
• Require justification for gp2 usage
• Set performance guidelines (when to use baseline vs provisioned IOPS)
• Define cost approval thresholds for high-performance configurations

12. Conclusion

The Clear Choice: gp3

After examining every aspect of gp2 and gp3 volumes, the conclusion is unambiguous: gp3 is superior in virtually every dimension.

Cost Advantages

• 20% lower base storage cost
• No need to over-provision storage to meet performance requirements
• Flexible pricing allows you to pay only for the performance you need
• For 64 TB deployments: save $10,000-$15,000+ annually

Performance Advantages

• Consistent baseline of 3,000 IOPS regardless of volume size
• No burst credit dependency – sustained performance
• Up to 80,000 IOPS (5× more than gp2)
• Up to 2,000 MB/s throughput (8× more than gp2)
• Independent performance and capacity scaling

Operational Advantages

• Supports volumes up to 64 TB (vs 16 TB for gp2)
• Single-volume architectures instead of complex RAID configurations
• Simpler capacity planning and sizing
• Performance can be adjusted without resizing volumes
• No need to monitor burst credit balances

The 64 TB Case Study: A Microcosm of gp3's Value

The 64 TB comparison perfectly illustrates why gp3 represents a paradigm shift in EBS storage:

• gp2 forces complexity: Multiple volumes, RAID configuration, complicated snapshots
• gp3 enables simplicity: Single volume, straightforward management, atomic snapshots
• gp2 limits performance: Maximum 64,000 IOPS across four volumes
• gp3 unlocks potential: Up to 80,000 IOPS from a single volume
• gp2 costs more: $78,643/year for the baseline configuration
• gp3 saves money: $62,915-$68,435/year depending on performance needs

Action Plan: Your Next Steps

If You're Starting New

1. Configure all infrastructure templates to use gp3 as default
2. Start with baseline performance (3,000 IOPS, 125 MB/s)
3. Monitor actual usage and scale up only when needed
4. Implement CloudWatch alarms for performance bottlenecks

If You're Using gp2

1. Immediate actions:
   • Inventory all gp2 volumes across all regions
   • Calculate your potential savings
   • Present business case to leadership
2. Short-term (1-2 months):
   • Migrate all dev/test volumes to gp3
   • Start realizing immediate cost savings
   • Gain operational experience with gp3
3. Medium-term (3-6 months):
   • Migrate production volumes systematically
   • Update all documentation and procedures
   • Train teams on gp3 capabilities
4. Long-term (6-12 months):
   • Complete migration of all gp2 volumes
   • Optimize gp3 performance configurations
   • Implement automated performance scaling

The Bottom Line

AWS introduced gp3 in December 2020 to address the fundamental limitations of gp2. More than four years later, the data is clear: gp3 delivers better performance at lower cost with simpler operations.

For small deployments, the 20% cost savings and better baseline performance make gp3 a no-brainer. For large deployments like our 64 TB example, the benefits multiply: you save thousands of dollars annually, eliminate operational complexity, and gain access to performance levels that gp2 simply cannot provide.

The migration process is straightforward, low-risk, and can be done without downtime. There's no reason to wait. Whether you're provisioning your first EBS volume or managing thousands of them, gp3 should be your default choice.

JusDB's Track Record: We've helped organizations save over $2.5 million annually in EBS costs through strategic gp2 to gp3 migrations while improving database performance by an average of 25%. Our database-optimized approach ensures you get the right balance of cost and performance for your specific workload.

Final Recommendations

For new workloads: Always choose gp3. Start with baseline performance and scale up as needed. The 20% cost savings and superior baseline performance make this an easy decision.

For existing gp2 workloads: Develop and execute a migration plan. Start with non-critical workloads to build confidence, then systematically migrate production workloads. The ROI is immediate and the operational benefits compound over time.

For large-scale deployments (especially 16 TB+): Prioritize gp3 migration. The combination of cost savings, operational simplification, and performance headroom makes this a strategic imperative. A single 64 TB gp3 volume is dramatically simpler and cheaper than four 16 TB gp2 volumes.

For organizations optimizing cloud costs: EBS volume migration to gp3 should be near the top of your optimization checklist. It's low-risk, high-reward, and delivers immediate, recurring savings without sacrificing performance.

Looking Forward

AWS continues to invest in EBS performance and capabilities. Recent updates have increased gp3 limits from 16 TB to 64 TB and from 16,000 IOPS to 80,000 IOPS. This trend suggests that gp3 will continue to improve while gp2 remains static as a legacy option.

By adopting gp3 now, you position your infrastructure to take advantage of future improvements while immediately benefiting from lower costs and better performance. The question is not whether to use gp3, but how quickly you can complete your migration.

Resources

• AWS Documentation: Amazon EBS General Purpose SSD Volumes
• AWS Pricing: Amazon EBS Pricing
• Migration Guide: Migrate your Amazon EBS volumes from gp2 to gp3
• Cost Calculator: Amazon EBS gp2 to gp3 Migration Cost Savings Calculator
• Best Practices: Amazon EBS Volume Types

About This Guide

This comprehensive guide analyzed Amazon EBS gp2 and gp3 volumes across multiple dimensions including cost, performance, operational complexity, and use cases. We provided detailed real-world examples ranging from small 50 GB boot volumes to massive 64 TB data warehouses, demonstrating that gp3 offers superior value across the entire spectrum.

The 64 TB case study highlighted how gp3's expanded capabilities eliminate the need for complex multi-volume architectures while delivering better performance at lower cost. Whether you're running a startup with a few instances or an enterprise with thousands of volumes, the evidence overwhelmingly favors gp3.

We encourage you to use this guide as a reference when making EBS volume decisions, planning migrations, and optimizing your AWS storage infrastructure. The transition from gp2 to gp3 represents one of the most straightforward and high-impact optimizations you can make to your AWS environment.

---

About JusDB

JusDB is a leading database performance optimization consultancy specializing in cloud database infrastructure. Our team of database experts has:

• Optimized over 10,000 database volumes across AWS, Azure, and GCP
• Achieved average cost reductions of 20-40% for our clients
• Improved database performance by 25-60% through storage optimization
• Helped Fortune 500 companies and startups alike maximize their cloud database ROI

Our Services Include:

• Database Storage Optimization: Right-sizing EBS volumes, migration planning, performance tuning
• Cloud Cost Optimization: Comprehensive audits of database infrastructure spending
• Performance Engineering: Query optimization, index tuning, architecture review
• Migration Services: Database migration to cloud, version upgrades, storage type conversions
• Managed Database Services: 24/7 monitoring, optimization, and support

Need Help with Your EBS Migration?

If you're considering migrating from gp2 to gp3 or need expert guidance on optimizing your database storage infrastructure, JusDB can help. Our team will:

• Conduct a free assessment of your current EBS volumes
• Calculate your potential savings and performance improvements
• Create a customized migration plan with zero-downtime approach
• Execute the migration with our proven methodology
• Provide ongoing optimization recommendations

Contact JusDB:

• Website: www.jusdb.com
• Email: contact@jusdb.com
• Schedule a free consultation to discuss your database optimization needs

---

Disclaimer: Prices and specifications mentioned in this guide are based on AWS US East (N. Virginia) region pricing as of October 2025. Always refer to official AWS documentation for the most current pricing and specifications in your region.