EBS gp3 vs io2: when each makes sense

The EBS volume type decision sounds technical but is mostly a cost decision. gp3 and io2 occupy different performance tiers at very different price points. Most teams use io2 in places where gp3 would work, and overpay 5-10x for capabilities they don't use.

This post walks through the actual specs, the pricing math, and the workload patterns that justify io2.

The two volume types at a glance

The pricing math at concrete sizes

1 TB volume, 5,000 IOPS

gp3 (5,000 IOPS = 2,000 above 3,000 baseline):

• Storage: 1,024 × $0.08 = $81.92
• IOPS: 2,000 × $0.005 = $10
• Total: $91.92/month

io2:

• Storage: 1,024 × $0.125 = $128
• IOPS: 5,000 × $0.065 = $325
• Total: $453/month

io2 is 5x more expensive for this workload. gp3 handles 5,000 IOPS easily.

1 TB volume, 16,000 IOPS (gp3 ceiling)

gp3 (max IOPS):

• Storage: $81.92
• IOPS: 13,000 × $0.005 = $65
• Total: $146.92/month

io2:

• Storage: $128
• IOPS: 16,000 × $0.065 = $1,040
• Total: $1,168/month

Still 8x more expensive for io2. At the gp3 IOPS ceiling, gp3 is dramatically cheaper.

1 TB volume, 50,000 IOPS (gp3 can't do this)

gp3 maxes at 16K IOPS per volume. To get 50K IOPS on gp3, you'd need 4+ volumes with software RAID (operational complexity).

io2:

• Storage: $128
• IOPS tier 1 (0-32K): 32,000 × $0.065 = $2,080
• IOPS tier 2 (32K-64K): 18,000 × $0.046 = $828
• Total: $3,036/month

At this performance level, io2 is required. The $3K/month is the cost of needing 50K IOPS in a single volume.

When you actually need io2

1. Sustained over 16K IOPS per volume

OLTP databases with high write throughput, latency-sensitive time-series databases, message queues at scale. Measure sustained IOPS on the current volume. If it's regularly above 16K, gp3 has hit its ceiling.

2. 99.999% durability requirement

Most workloads don't need this — application-level replication and database HA solve durability better than disk durability. But for single-instance databases without replication where data loss is catastrophic (some legacy systems, regulated financial systems), io2's 100x lower annual failure rate matters.

3. Multi-Attach

Shared storage across multiple instances in an Auto Scaling Group. Required for some HA database configurations (SAP HANA, Oracle RAC, etc.). gp3 doesn't support Multi-Attach; io2 does. If you need this feature, io2 is the only choice.

4. Single-volume large databases

Databases over 16 TB on a single volume. io2 supports 64 TB per volume. For databases that have grown past gp3's 16 TB limit without architectural sharding, io2 is required.

When gp3 wins (most cases)

General-purpose application storage

Web servers, application logs, ECS/EKS persistent volumes, development databases. All these run fine on gp3 with 3K-10K IOPS. The cost difference vs io2 is 5-10x.

Most production databases

Databases under 16K IOPS sustained — which is most of them. PostgreSQL, MySQL, MongoDB, SQL Server on standard workloads. gp3 handles them. Migration from io1/io2 to gp3 commonly cuts 50-70% of EBS costs.

Read-mostly databases

Reporting databases, analytics replicas, caching layers. Reads benefit from OS page cache and don't hammer EBS. gp3 baseline of 3K IOPS is often unused.

Container persistent volumes

Kubernetes PVCs typically have modest IOPS needs (config files, small databases, log buffers). gp3 default at 3K IOPS is usually sufficient.

The migration playbook

For accounts with significant io1/io2 spend that's not justified:

1. Audit io2 volumes via Cost Explorer (filter by Usage Type = io2).
2. For each io2 volume, measure actual IOPS via CloudWatch (VolumeReadOps + VolumeWriteOps).
3. If max sustained IOPS is under 16K, candidate for gp3.
4. If single-instance OLTP without replication, evaluate if 99.999% durability is needed.
5. If Multi-Attach is unused, candidate for gp3.
6. For candidates, modify volume type in-place (no downtime).

For deeper migration patterns, see gp2 to gp3 migration guide — same in-place technique applies for io2 to gp3.

Estimating with c3x

c3x reads the type, size, iops, and throughput attributes from Terraform and applies the right pricing:

resource "aws_ebs_volume" "db" {
  availability_zone = "us-east-1a"
  size              = 1024
  type              = "gp3"
  iops              = 16000
  throughput        = 1000
  encrypted         = true
}

c3x reports: $146.92/month (gp3, 1 TB, 16K IOPS, 1000 MB/s). Switching type to "io2" would change the estimate to $1,168/month. The cost delta is visible at PR time.

FAQ

Summary

Use gp3 by default. Use io2 only when you need over 16K IOPS sustained, 99.999% durability, or Multi-Attach. For most production workloads, the gp3-vs-io2 question is mechanical: check the IOPS requirement, pick the cheaper option that meets it. Audits of long-running fleets commonly find io2 volumes running 2-5K IOPS — those should be gp3 immediately.

For the broader EBS picture including legacy gp2, see when gp2 to gp3 actually saves money. For the EBS resource details, see aws_ebs_volume catalog page.