EBS throughput vs IOPS cost: which one you are actually paying for

Quick answer

On gp3, IOPS and throughput are billed as separate provisioned dimensions: 3,000 IOPS and 125 MB/s come free with every volume, extra IOPS cost $0.005 each per month above 3,000, and extra throughput costs $0.04 per MB/s per month above 125, in us-east-1. IOPS matters for random, small-block access like transactional databases; throughput matters for large sequential reads and writes like log processing, backups, and analytics. Paying for high IOPS on a streaming workload, or high throughput on a random-access database, is wasted money. The fix is to measure your access pattern and provision only the dimension you actually saturate.

One of gp3's best features is that it decouples capacity, IOPS, and throughput, so you pay for exactly the performance you provision rather than buying capacity to get speed. But that decoupling only saves money if you provision the right dimension. IOPS and throughput measure different things, cost differently, and are needed by different workloads. Paying for the wrong one is quiet, common waste.

How the two are priced

Dimension	Free baseline	Cost above baseline
Storage	n/a	$0.08 per GB-month
IOPS	3,000 included	$0.005 per IOPS-month
Throughput	125 MB/s included	$0.04 per MB/s-month

Every gp3 volume comes with 3,000 IOPS and 125 MB/s at no extra charge, which is why gp3 is cheaper than gp2 for most workloads. Above those baselines you provision more of each independently, up to 16,000 IOPS and 1,000 MB/s. Provisioning the full 16,000 IOPS adds $65 per month (13,000 extra at $0.005); provisioning the full 1,000 MB/s adds $35 per month (875 extra at $0.04). Neither is expensive alone, but across a fleet of volumes, provisioning both on volumes that need neither adds up fast.

IOPS versus throughput, physically

IOPS counts operations per second and is what matters for random access to small blocks: a transactional database doing thousands of tiny reads and writes to scattered rows is IOPS-bound. Throughput counts megabytes per second and is what matters for sequential access to large blocks: streaming a log file, restoring a backup, or scanning a large table is throughput-bound. The two are related through block size, but a workload almost always leans hard toward one. Provisioning for the one it does not use is money spent on headroom that never gets touched.

Two workloads, opposite settings

A busy PostgreSQL instance handling OLTP traffic might need 12,000 IOPS but well under 125 MB/s, so you pay for extra IOPS and leave throughput at the free baseline. A log-processing volume ingesting large sequential writes might saturate 500 MB/s while barely exceeding 3,000 IOPS, so you pay for extra throughput and leave IOPS at baseline. Setting both high on both volumes, a tempting default, doubles the performance spend for no benefit. The right answer is asymmetric, and it comes from measurement. See gp2 versus gp3 for why gp3's decoupling saves money in the first place.

How to know which you need

CloudWatch tells you directly. VolumeReadOps and VolumeWriteOps over the period give your IOPS demand; VolumeReadBytes and VolumeWriteBytes give your throughput demand. Look at the sustained peak, not the average, and provision a modest margin above it on the dimension that saturates. If neither exceeds the free baseline, provision nothing extra at all, which is the case for a surprising share of volumes. For workloads that genuinely exceed gp3's ceilings, io2 is the next step, covered in gp3 versus io2.

Provision the dimension, not the fear

Over-provisioning gp3 performance is usually a hedge against not knowing the workload rather than a real requirement. Measure the access pattern, provision only the dimension that saturates, and leave the other at its free baseline. Price the volume, including its IOPS and throughput settings, against the resource catalog before deploy so the performance spend maps to a measured need rather than an untested worst case.

FAQ

How are gp3 IOPS and throughput priced?

Separately. Every gp3 volume includes 3,000 IOPS and 125 MB/s free. Extra IOPS cost $0.005 each per month above 3,000, and extra throughput costs $0.04 per MB/s per month above 125, in us-east-1, up to 16,000 IOPS and 1,000 MB/s. Provisioning the full IOPS adds about $65 per month and the full throughput about $35 per month.

What is the difference between IOPS and throughput?

IOPS counts operations per second and matters for random access to small blocks, like a transactional database doing many tiny reads and writes. Throughput counts megabytes per second and matters for sequential access to large blocks, like log streaming, backups, or table scans. A workload almost always leans hard toward one, so provisioning both high is usually waste.

Which does my workload need, IOPS or throughput?

Check CloudWatch: VolumeReadOps and VolumeWriteOps show IOPS demand, VolumeReadBytes and VolumeWriteBytes show throughput demand. Use the sustained peak, not the average. OLTP databases are usually IOPS-bound; log processing, analytics, and backups are usually throughput-bound. If neither exceeds the free baseline, provision nothing extra.

Why is provisioning both IOPS and throughput wasteful?

Because most workloads saturate only one dimension. A database needs IOPS but little throughput; a log volume needs throughput but few IOPS. Setting both high as a default doubles the performance spend with no benefit for the dimension the workload never uses. The economical setting is asymmetric, based on which one the workload actually saturates.

How does C3X help with EBS performance cost?

C3X prices EBS volumes from Terraform including provisioned IOPS and throughput, so the cost of each performance dimension is visible in the pull request. That makes it easy to spot a volume provisioned high on both when the workload only needs one, and to right-size the setting before deploy rather than paying for untouched headroom.

What to do next

Pay for the performance dimension you actually use. C3X prices EBS IOPS and throughput from Terraform against a live resource catalog. Start with the quickstart.