LEARN. PRACTICE. GROW.Concept and mechanism
IOPS counts operations per second; throughput measures data per second. At the same observed layer, four thousand sixteen-KiB operations per second represent 64000 KiB/s, or 62.5 MiB/s, without overhead. Do not assume application and device operations are identical: the path can merge or split requests. On a fictional resource limited to 125 MiB/s, 256-KiB operations exhaust that limit at five hundred per second, even if another IOPS limit is higher. These numbers illustrate unit relationships without representing universal product specifications. Always record I/O size, measurement window, and observation scope when comparing results.
Guided application
A growing queue with rising latency and plateaued throughput can indicate saturation. Increasing threads does not automatically add capacity and can extend waiting. Compare volume limits, instance limits, and aggregate consumption before buying more IOPS. For Linux cumulative counters, calculate the difference between samples and divide by time, considering resets caused by startup or device changes. Ten thousand to sixteen thousand reads over thirty seconds corresponds to two hundred reads per second. During a batch incident, correlate these measurements with the functional deadline and communicate the impact of containing concurrency. Do not use a counter since boot as an instantaneous rate.
4000 × 16 KiB/s = 62.5 MiB/s; layer and window are part of the measurement.
Common pitfalls
IOPS as MiB/s; more threads as more capacity; volume as the only limit; total counter as rate.
Related topics: Interfaces and dependencies · Capacity and growth · Durability and coordination
Measure the full path and keep counts, units, and limits comparable.
Reference: EBS I/O size, IOPS, throughput and latency · DR Storage 2026-09; selected Linux and AWS storage behavior