IOPS Has an Exchange Rate

A database team provisions an EBS volume at 80,000 IOPS, runs a benchmark, and gets 31,000. They open a support case. The vendor is not shortchanging them, nothing is misconfigured, and the instance is not the bottleneck. The volume is behaving exactly as documented. What went wrong happened earlier, in a spreadsheet, when the number 80,000 was chosen from a dropdown without anyone asking what I/O size the workload uses.

That question is the whole article. Cloud block storage is sold as two dials, IOPS and throughput, and the console presents them as independent. They are not. They are the same dial observed at two different I/O sizes, and the conversion between them is fixed, published in the fine print, and nearly identical across four vendors. Once you know the coefficient, the second number on the pricing page stops being a specification and becomes a constraint on the first.

1. The Exchange Rate Nobody Quotes

Start with four footnotes from four vendors, collected on the same afternoon.

AWS documents gp3 this way: throughput can be provisioned up to a maximum of 2,000 MiB/s "at a ratio of 0.25 MiB/s per provisioned IOPS", and maximum throughput is reachable "at 8,000 IOPS or higher". Amazon's arithmetic is printed in the same sentence: 8,000 × 0.25 = 2,000.

Azure documents Premium SSD v2 almost identically: "the maximum throughput that can be set increases by 0.25 MB/s per set IOPS", and "2,000 MB/s is the maximum throughput supported for disks that have 8,000 IOPS or more". Azure's Ultra Disk repeats it with a different ceiling: "the maximum throughput limit of an Ultra Disk is 0.25 MB/s for each provisioned IOPS, up to a maximum of 10,000 MB/s per disk".

Google documents Hyperdisk Balanced as a formula rather than a sentence, but the same constant is inside it. Maximum throughput is the minimum of 2,400 MiB/s and the provisioned IOPS divided by four. One quarter of a mebibyte is 0.25 MiB. Hyperdisk Extreme states it directly: 250 MiB/s per 1,000 IOPS, up to 5,000 MiB/s.

Seven products, four vendors, one coefficient. Nobody advertises it, no console shows it, and it is the same number to three significant figures everywhere it appears. That is not a coincidence and it is not competitive convergence. It is a statement about what an IOPS is assumed to be.

2. 256 KiB per IOPS

Take the coefficient apart. At 0.25 MiB/s per IOPS, one unit of IOPS buys a quarter of a mebibyte per second of throughput. A mebibyte is 1,024 KiB, so a quarter of one is 256 KiB.

One IOPS, therefore, is a ledger entry worth 256 KiB per second. Provision 8,000 of them and you have bought 8,000 × 256 KiB = 2,048,000 KiB/s, which is exactly 2,000 MiB/s. The two numbers on the pricing page are not two purchases. They are one purchase, quoted in two units, and the exchange rate is published in a footnote.

This reframes what over-provisioning IOPS means. If you configure a volume at 80,000 IOPS, you have not bought 80,000 discrete operations per second. You have bought the right to move 80,000 × 256 KiB = 20,480,000 KiB/s, which is 20,000 MiB/s, subject to a separate absolute ceiling. On gp3 that ceiling is 2,000 MiB/s, so the right is capped twenty-fold and the cap, not the IOPS count, is what governs any workload with large I/Os.

Put the two statements side by side and the shape of the problem appears. The IOPS dial says: you may perform 80,000 operations. The throughput dial says: you may move 2,000 MiB. Both are true simultaneously, and they are only compatible if each of your operations averages 2,000 MiB divided by 80,000, which is 0.025 MiB, or 25.6 KiB.

3. The 25.6 KiB Line

That 25.6 KiB number is not something I derived and then went looking for confirmation of. AWS prints it, in a table footnote, as a dagger beside every IOPS figure in the volume-type comparison.

The footnote reads: "Represents the required I/O size to reach maximum IOPS within the volume's throughput limit." Beside gp3's 80,000 IOPS the footnote says 25.6 KiB I/O. Beside gp2 and io1's 16,000 and 64,000 it says 16 KiB. Beside io2 Block Express's 256,000 it says 16 KiB. In the HDD table, beside st1's 500 IOPS and sc1's 250, the parenthetical says 1 MiB I/O.

Every one of those numbers is the same calculation. Divide the throughput ceiling by the IOPS ceiling and you get the I/O size at which both are reached at once. AWS measured it, printed it as a footnote, and moved on without giving it a name. I am going to call it the break-even I/O size, because that is what it is: the size at which your IOPS budget and your throughput budget are exhausted at the same moment.

Look at the AWS column. Six volume types, three families, two media types, and the break-even size takes exactly three values: 25.6 KiB, 16 KiB, and 1 MiB. The HDD types sit at 1 MiB because mechanical drives are throughput devices pretending to have an IOPS rating. The SSD types sit at 16 KiB because 16 KiB is the natural transfer unit of the virtualisation path. And gp3, the general-purpose tier, sits at 25.6 KiB, which is 1.6 times larger, because gp3 is the one tier engineered to sell bandwidth cheaply.

The Azure and Google numbers land in a narrow band between 14.6 and 24.4 KiB. That band is where the industry thinks a block I/O lives. The Samsung drive at the bottom, at 5.2 KiB, is where it actually lives when nobody is throttling you.

4. Your Break-Even Size Is a Division, Not a Constant

The table above lists the break-even size at maximum provisioned IOPS. Provisioning less moves it. The formula is one line, and it is the only formula in this article worth memorising:

break_even_IO_size = throughput_ceiling ÷ provisioned_IOPS

Hold the throughput ceiling at gp3's 2,000 MiB/s and walk the IOPS dial down. The break-even size moves up in inverse proportion.

The bottom row is the one that should stop people. Eight thousand IOPS is the minimum AWS says you need to provision 2,000 MiB/s, and at 8,000 IOPS the break-even size is 256 KiB. If your workload uses 256 KiB I/O, which is what any sequential reader, log shipper, or backup agent uses, then 8,000 IOPS saturates the volume's bandwidth completely. The other 72,000 IOPS available on that volume would buy you nothing at all.

This is the inverse of the usual advice. The usual advice is that databases need many IOPS and streaming needs bandwidth, prose that treats the two as separate purchases. The actual rule is that IOPS count and I/O size are two ends of a see-saw anchored at a fixed throughput ceiling. Raise one and the other becomes unspendable.

5. What Over-Provisioning IOPS Actually Buys

Run the numbers on the case that opens this article. A volume at 80,000 IOPS, 2,000 MiB/s ceiling, and a workload with a 64 KiB average I/O size.

To honour 80,000 IOPS at 64 KiB, the volume would have to move 80,000 × 64 KiB = 5,120,000 KiB/s, which is 5,000 MiB/s. The ceiling is 2,000. So the throughput ceiling binds, and the delivered IOPS is 2,048,000 KiB/s divided by 64 KiB, which is 32,000.

Sixty percent of the provisioned IOPS is unreachable. The customer in the opening scene did not get shortchanged by 49,000 IOPS as a matter of policy. They got exactly the throughput they paid for, delivered at an I/O size that made most of the IOPS line item meaningless. And because gp3 prices IOPS above the 3,000 free baseline per unit, they paid for the meaningless part.

Now run the same volume at 16 KiB. 80,000 × 16 KiB = 1,280,000 KiB/s = 1,250 MiB/s, comfortably under the 2,000 ceiling. Here the IOPS ceiling binds and all 80,000 are delivered. The only difference between the two cases is the average I/O size, and the same hardware delivered 32,000 or 80,000 depending on which one the application happened to use.

The line where unused IOPS starts climbing is exactly the break-even size, and it is marked in the table. Everything below it is a workload where the IOPS dial matters. Everything above it is a workload where the throughput dial is the only one being read, and the IOPS figure is decoration.

There is one honest exception. A workload can have a bimodal I/O distribution: 4 KiB for the index, 256 KiB for the table scan, and the average lands somewhere meaningless. Averaging hides this, which is why the diagnostic in section ten works on the average and then checks the queue depth before believing it.

6. The Same 0.25 Is Not the Same

Here the story acquires a wrinkle that this site has written about before, and it is worth being precise about because it is a different wrinkle from the usual one.

AWS says 0.25 MiB/s per IOPS. Google says 0.25 MiB/s per IOPS. Azure says 0.25 MB/s per IOPS, and Azure's disk documentation is explicit that it means what it says: the Ultra Disk page defines MB/s as 10^6 bytes per second, and the Premium SSD v2 throughput increments are quoted in the same decimal unit.

One IOPS therefore buys 262,144 bytes per second on AWS and Google, and 250,000 bytes per second on Azure. The ratio is 1.048576, so the Azure exchange rate is 4.86 percent worse.

That is not the 7.37 percent gap between GB and GiB. It is a smaller number and it comes from a different place. The storage marketing gap compares 10^9 with 2^30, which is a ratio of 1.0737. This one compares 10^6 with 2^20, which is 1.0486. Same family of confusion, a different exponent, and if you assume the two gaps are the same you will be wrong by about 2.5 percentage points in whichever direction you guessed.

The break-even sizes carry the same fingerprint. Azure's 25,000 bytes per IOPS works out to 24.41 KiB, while AWS's 256 KiB per IOPS against a different ceiling lands on 25.6 KiB. They look like nearly the same number in a table because they are nearly the same number, but they are not the same number, and a capacity plan that treats 24.41 and 25.6 as interchangeable is off by 4.9 percent at exactly the boundary where the answer flips.

7. IOPS Is a Queue, Not a Disk

Everything above assumes you can actually issue the I/Os. That assumption is where single-threaded applications fail, and it fails silently.

An IOPS rating is a rate of completion, and completion requires concurrency. If one I/O takes one millisecond to complete and you allow exactly one to be outstanding, you complete one thousand per second. Not eight thousand, not eighty thousand. One thousand, because the arithmetic is 1 divided by 0.001.

The relationship is Little's law applied to a device: the number of requests in flight equals the completion rate multiplied by the time each one takes. Written for storage, it is outstanding = IOPS × latency. To reach 80,000 IOPS at one millisecond, you need eighty requests in flight. AWS describes gp3 as delivering single-digit-millisecond latency, so the range between one and nine milliseconds puts the required concurrency somewhere between 80 and 720 outstanding requests.

An application that opens a file, reads 4 KiB, processes it, and reads again, with no queue and no threads, has one request in flight. It will peak at about 1,000 IOPS on that volume no matter what the volume is provisioned for, and it will look like a provisioning problem to everyone reading the graph.

This is why the standard advice to increase queue depth exists, and also why it stops working. Past the point where the queue is deep enough to saturate the ceiling, adding depth adds latency and no throughput. The curve is not linear and the knee is exactly the provisioned IOPS. Below the knee, more concurrency buys completions. Above it, more concurrency buys queueing time, which is the mechanism behind the P99 spikes that get blamed on the storage tier.

8. Why Local NVMe Sits at 5 KiB

The break-even size is not a cloud invention. Every storage device has one, and putting a local drive next to the cloud tiers makes the quota visible.

Samsung publishes the 990 PRO at 7,450 MB/s sequential read, 1,400,000 IOPS of 4 KiB random read at queue depth 32, and 22,000 IOPS of the same random read at queue depth 1. Divide the sequential figure by the random figure and the drive's break-even size is 5,321 bytes, or 5.20 KiB.

Read the queue-depth pair instead and a different number falls out. At depth one the drive completes 22,000 operations per second, so a single request takes about 45 microseconds. At depth thirty-two it completes 1,400,000, so thirty-two requests take about 22.9 microseconds each. Throughput rose 63.6-fold while concurrency rose 32-fold, which means the drive got more efficient under load, not less. Nothing in that behaviour is available from a volume whose latency is quoted in whole milliseconds.

Two gaps, and they compound. The local drive answers in 45 microseconds and a cloud volume in hundreds to thousands, so at the same queue depth the local drive is twenty to fifty times more responsive. And the local drive converts IOPS to throughput at 5.2 KiB while the cloud converts at 16 to 25.6, so each cloud IOPS carries three to five times more bandwidth behind it.

Those two facts point in opposite directions and explain the whole shape of the market. Cloud volumes are latency-poor and bandwidth-rich per IOPS. Local NVMe is latency-rich and bandwidth-poor per IOPS. A workload that is latency-bound, which includes most databases, will always prefer the local drive and will pay for the privilege in durability. A workload that needs a durable 2,000 MiB/s at a modest operation count, which includes most backups and log pipelines, is well served by eight thousand IOPS and a big I/O size.

9. Three Numbers, Not One

By now the word "IOPS" has been used to mean three different things, and they are not interchangeable. On a single volume there are three separate granularities in play, and each answers a different question.

The first is the break-even size, which answers how fast you can go. The second is the metering unit, which answers how many operations you will be charged for. The third is the physical page and erase-block size inside the drive, which answers how much extra work the flash has to do to honour a write. Only the first appears in a provisioning console.

Azure is unusually explicit about the second. Its Premium SSD documentation states that each I/O operation of 256 KiB or less is counted as a single I/O operation, and that operations larger than 256 KiB are counted as multiple I/Os of 256 KiB each. On a Premium SSD the metering unit is therefore 256 KiB, while the break-even size on a P80 is 43.95 KiB. The two differ by a factor of 5.8, and they are both correct, because they measure different things.

Watch what that does to a real request. A 256 KiB read on a P80 counts as exactly one I/O operation, which sounds generous until you price the bandwidth. Twenty thousand of those per second would move 5,120,000 KiB/s, or 5,242 MB/s, against a published ceiling of 900 MB/s. The bandwidth ceiling arrives first: 900 MB/s divided by 256 KiB is 3,433 IOPS. The meter says one operation; the ceiling says you may have 3,433 of them per second. An engineer reading only the metering rule would conclude that 256 KiB requests are cheap. They are cheap to count and expensive to move.

The reverse error is just as easy. A 4 KiB random write on a P80 counts as one operation and moves almost nothing, so an engineer reading only the throughput ceiling would conclude that small I/Os are free. They are free to move and expensive to count, and at 20,000 IOPS the ceiling binds long before the bandwidth does.

The third granularity sits below both. NAND flash is written in pages, typically 4 to 16 KiB, and erased in blocks measured in hundreds of kilobytes to several megabytes. A 4 KiB write that lands in a page already holding data cannot be written in place; the controller reads the whole page, modifies it, and writes it back, so the device does more internal work than the host asked for. That is write amplification, it is a property of the medium rather than of the quota, and it is why random writes age a drive faster than sequential ones at identical IOPS. No provisioning decision changes it. It is also the reason the local drive in the previous section, which has the same physics, still answers in tens of microseconds while a cloud volume answers in hundreds: the physics is shared, the virtualisation path is not.

The practical consequence is that the break-even size is the only one of the three that should be compared against your measured average I/O size. Doing so tells you which ceiling binds. The metering unit tells you what the invoice will say, which is a different question with a different answer, and the erase block tells you why the drive wears out. Conflating them is how a capacity plan ends up internally consistent and externally wrong.

10. Three Columns, One Diagnosis

None of this requires a benchmarking harness. The average I/O size is already in the output of iostat -x, sitting in columns that most people scroll past on the way to the utilisation figure.

Take rkB/s plus wkB/s, which are kibibytes per second read and written, and divide by r/s plus w/s, which are completed read and write requests per second. The result is your average I/O size in kilobytes. Note the units: sysstat prints kB but computes in KiB, a discrepancy its own manual flags in a BUGS note, so the number you get is already in the same family as the break-even sizes above and can be compared to them without conversion.

Then read the queue column. In current sysstat it is called aqu-sz; in older versions, and in most blog posts and dashboards still in service, it is avgqu-sz. Both mean the average number of requests issued to the device and outstanding. The rename is recent enough that a monitoring query written against the old name is a plausible reason your graph went blank.

The diagnosis is a two-step decision, and it is worth writing down because the two failure modes look identical on a throughput graph.

The first row is the expensive one, because the instinct is to provision more IOPS and that is the one action guaranteed not to help. The third row is the embarrassing one, and it is far more common than its reputation suggests. A single-threaded process on an 80,000-IOPS volume shows a throughput graph that looks like a provisioning failure and a queue column that reads 0.9.

One caveat on the averaging. A workload that mixes 4 KiB metadata reads with 256 KiB sequential scans produces an average somewhere in between, and neither ceiling is actually binding at that average. When the average lands near the break-even size, split the measurement by request size before concluding anything. The formula works on unimodal workloads and lies politely on the others.

11. Frequently Asked Questions

Why does my gp3 volume with 80,000 IOPS only deliver 32,000?

Because the throughput ceiling binds first. The volume tops out at 2,000 MiB/s, and 80,000 IOPS only reaches that ceiling if each I/O averages 25.6 KiB or less. At a 64 KiB average, 80,000 IOPS would require 5,000 MiB/s, so the volume is throttled to 2,048,000 KiB divided by 64 KiB, which is 32,000. Sixty percent of the provisioned IOPS is unusable at that block size, and it was paid for anyway.

Can I provision IOPS and throughput independently?

You can set both values independently, but they are not independent in effect. AWS gp3, Azure Premium SSD v2 and GCP Hyperdisk Balanced all impose a ratio of roughly 0.25 MiB/s per provisioned IOPS on top of an absolute ceiling, and the smaller of the two ceilings is what the workload sees. Independence in the console is worth nothing if your average I/O size pushes you past the break-even point.

Is 0.25 MiB/s per IOPS the same on every cloud?

The coefficient is the same, the unit is not. AWS and Google quote MiB/s, making one IOPS worth 262,144 bytes per second. Azure quotes MB/s and defines it as 10^6 bytes, making one IOPS worth 250,000. The gap is 4.86 percent, which is a different number from the 7.37 percent that separates GB from GiB, and confusing the two will misprice a plan at the boundary.

Why is local NVMe so much faster than a cloud volume?

Two reasons that get conflated. Latency: the 990 PRO reaches 22,000 IOPS at queue depth one on 4 KiB random reads, implying about 45 microseconds per I/O, while a cloud volume quotes single-digit milliseconds, or roughly 1,000 IOPS at the same depth. And the exchange rate: that drive pairs 1,400,000 IOPS with 7,450 MB/s for a break-even of 5.2 KiB, against 25.6 KiB for gp3. A cloud volume is not a slice of a local drive; it is a quota with a different exchange rate.

My benchmark showed a million IOPS. Why is that not 4 GB/s?

Because a million IOPS at 4 KiB is 4,096,000 KiB/s, about 4 GiB/s, and a million IOPS is a random-read figure measured at high queue depth. Sequential throughput is measured with large I/Os, typically 128 KiB or more, at a depth the controller can pipeline. A drive rated at 1,400,000 random 4 KiB IOPS and 7,450 MB/s does not do both at once; the sequential figure requires an average I/O of 5.2 KiB, and the random figure does not survive the access pattern becoming contiguous.

How do I find out which ceiling I am hitting?

Divide throughput by IOPS using the columns iostat already prints: the sum of rkB/s and wkB/s over the sum of r/s and w/s is your average I/O size in kilobytes. Compare it to the break-even size of the volume type. Then read aqu-sz, called avgqu-sz in older sysstat. A queue near one with IOPS far below provisioned means the application is serial and the volume is idle. A high queue that still falls short of provisioned means a real ceiling.

12. Methodology & Disclosure

Every specification in this article was read from the vendor's own documentation on 2026-10-23, and every derived figure is arithmetic on those specifications, reproducible with a calculator. No number here comes from a benchmark I ran, and none is extrapolated from a marketing claim.

What was taken as given. AWS volume-type limits, the dagger footnote on required I/O size, and the 0.25 MiB/s per provisioned IOPS ratio from the gp3 and gp2 pages. Azure Premium SSD v2 and Ultra Disk limits and the 0.25 MB/s per provisioned IOPS rule, together with Azure's explicit definition of MB/s as 10^6 bytes. Google Hyperdisk Balanced limits and its MIN(2,400, P/4) throughput formula, Hyperdisk Extreme's 250 MiB/s per 1,000 IOPS, and Google's statement that reaching the IOPS limit requires 4 KiB I/O while reaching the throughput limit requires at least 256 KiB. Samsung's published 990 PRO figures: 7,450 MB/s sequential read, 1,400,000 IOPS of 4 KiB random read at QD32, 22,000 IOPS of the same at QD1. The iostat field definitions and the kB-versus-KiB note from the sysstat manual, including the recent renaming of avgqu-sz to aqu-sz.

What was computed. Break-even size is always throughput ceiling divided by IOPS ceiling, with both sides converted to the same unit. Where a vendor quotes MiB/s the calculation uses 1,024 KiB per MiB; where a vendor quotes MB/s it uses 1,000,000 bytes, per that vendor's own definition. The 4.86 percent gap is 2^20 divided by 10^6. The 7.37 percent figure is 2^30 divided by 10^9. The concurrency requirement in section seven is IOPS × latency, evaluated at the latencies each vendor states rather than at a measured value.

What is an assumption. The one-millisecond figure used for gp3 concurrency is the low end of AWS's "single-digit millisecond" wording, not a measured latency. The required-concurrency numbers in section seven should be read as a range, not a point. The QD1 column for cloud volumes is derived from that assumption and is illustrative. Bimodal I/O workloads are explicitly outside what the average-based diagnostic can resolve.

What this article is not. It is not a benchmark, a price comparison, or a recommendation of one vendor over another. It contains no pricing claims: the cost argument in section five is about quantity, not money, because per-IOPS and per-MiB/s prices differ by region, tier, and contract, and any dollar figure here would be stale before it was published. Verify against your own iostat output and your own volume's provisioned settings before changing a quota.

Independence. No vendor sponsorship and carries no affiliate links. No cloud provider was contacted, and none supplied data for this briefing.

References & Further Reading

1. AWS. Amazon EBS volume types — the comparison tables for gp3, gp2, io1, io2 Block Express, st1, and sc1; the dagger footnote defining "the required I/O size to reach maximum IOPS within the volume's throughput limit" as 25.6 KiB for gp3 and 16 KiB for the provisioned-IOPS tiers. docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html
2. AWS. Amazon EBS General Purpose SSD volumes — gp3's 3,000 IOPS and 125 MiB/s baseline, 80,000 IOPS and 2,000 MiB/s maxima, 500 IOPS per GiB and 0.25 MiB/s per provisioned IOPS ratios, and the statement that maximum throughput is reachable at 8,000 IOPS or higher. docs.aws.amazon.com/ebs/latest/userguide/general-purpose.html
3. AWS. gp2 volume performance — the 3 IOPS per GiB scaling rule, the 16,000 IOPS ceiling at 5,334 GiB, the 128 to 250 MiB/s throughput range, and the formula throughput = IOPS × I/O size / 1,024. Same document as above.
4. Microsoft. Azure managed disk types — Premium SSD v2's 80,000 IOPS and 2,000 MB/s maxima with the 0.25 MB/s per set IOPS rule, Ultra Disk's 400,000 IOPS and 10,000 MB/s with the same ratio, the 256 KiB I/O metering rule for Premium SSD, and the statement that MB/s means 10^6 bytes per second. learn.microsoft.com/azure/virtual-machines/disks-types
5. Google Cloud. Hyperdisk performance overview — the per-volume maxima for Balanced, Extreme, Throughput, and ML, and the rules 250 MiB/s per 1,000 IOPS and 4 IOPS per MiB/s. cloud.google.com/compute/docs/disks/hyperdisk-performance
6. Google Cloud. About Hyperdisk Balanced — the throughput formula MIN(2,400, P/4) where P is provisioned IOPS, the minimum MAX(140, P/256), and the statement that the IOPS limit requires 4 KiB I/O while the throughput limit requires at least 256 KiB. cloud.google.com/compute/docs/disks/hd-types/hyperdisk-balanced
7. Samsung. 990 PRO PCIe 4.0 NVMe M.2 SSD, 2 TB specifications — 7,450 MB/s and 6,900 MB/s sequential, 1,400,000 and 1,550,000 IOPS of 4 KiB random read and write at QD32, 22,000 and 80,000 IOPS of the same at QD1. samsung.com/memory-storage/nvme-ssd/990-pro-2tb
8. sysstat. iostat(1) manual page — definitions of r/s, w/s, rkB/s, wkB/s, await, and aqu-sz, the note that the field was previously named avgqu-sz, and the BUGS entry stating that displayed kB figures are computed in kibibytes. man7.org/linux/man-pages/man1/iostat.1.html
9. Related: IOPS to Throughput Estimator · GiB to GB Marketing Gap · Redis RAM to Raw JSON Ratio · The Latency Budget · Database Instance Sizing · All Data Magnitude Tools · Methodology

📜 Copyright & Attribution