Provisioned IOPS for databases: when paying for I/O is worth it

Provisioned IOPS is the storage decision most likely to double a database bill without anyone noticing, because it is a per-unit charge on a number that looks like a configuration parameter rather than a purchase. Here is what each option costs and how to decide which you actually need.

The pricing, side by side

The gap between gp3's $0.02 and io1's $0.10 per IOPS-month is a factor of five, and it is the single most expensive misconfiguration available in database storage. A team migrating an old io1 volume forward without revisiting the IOPS figure can pay five times the necessary rate for years.

Worked comparisons

Two conclusions jump out. First, io1 has essentially no remaining use case: io2 delivers better durability and higher limits at a lower IOPS rate. If you still run io1 volumes, migrating to io2 is a pure saving, roughly 35 percent off the IOPS line, with no downside. Second, gp3 handles a very large share of real database workloads at a fraction of the price, and its 16,000 IOPS ceiling on RDS is higher than most OLTP databases actually need.

How many IOPS do you actually need

Measure, do not guess. On RDS, look at ReadIOPS plus WriteIOPS in CloudWatch at one-minute granularity over a representative fortnight. Take the p99 rather than the maximum, because a single backup window spike is not a provisioning requirement. Then add 30 percent headroom for growth and for the maintenance operations that burst I/O, such as index builds and vacuum.

The number that surprises people is how low it usually is. A well-indexed OLTP database with a working set that fits in the buffer pool does most reads from memory and generates far less disk I/O than its query rate suggests. A database serving 4,000 queries per second frequently sits at 1,500 to 3,000 disk IOPS, well inside gp3's free tier. If you are seeing 20,000 IOPS on an OLTP workload, the first question is whether an index is missing or the instance has too little memory, because buying I/O to compensate for a bad plan is the most expensive fix available.

Memory is usually the cheaper lever

Consider a database at 18,000 read IOPS because its working set exceeds the buffer pool. Option one: buy 18,000 provisioned IOPS on io2, about $1,170 per month. Option two: move from db.r6g.xlarge (32 GB, $378 per month) to db.r6g.2xlarge (64 GB, $756 per month), an increase of $378, and let the larger buffer pool absorb the reads. The memory route costs less than a third as much and improves latency more, because a page served from RAM beats a page served from NVMe by orders of magnitude.

This is the general rule: on read-heavy workloads, buy memory before you buy IOPS. Provisioned IOPS is genuinely necessary for write-heavy workloads where the write rate exceeds what gp3 can absorb, for latency-sensitive workloads that need consistent single-digit millisecond I/O, and for very large datasets where no realistic amount of memory holds the working set.

Throughput is the other half

IOPS is not the only limit. Analytical queries doing large sequential scans are throughput-bound, not IOPS-bound. gp3 includes 125 MB/s and sells more at $0.08 per MB/s-month, so raising it to 500 MB/s costs an extra $30 per month, which is inexpensive relative to the IOPS meter. If your slow queries are big scans, check throughput saturation before you touch IOPS at all.

Price storage type, IOPS, and throughput from Terraform before you merge, because these are three independent meters and only one of them is usually the constraint. Compare storage options against the resource catalog, and see throughput against IOPS pricing for the block-storage detail.

FAQ

What to do next

See what an IOPS number costs before you commit to it. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.