# IOPS

**IOPS** (input/output operations per second) is a unit of measure for storage performance: the number of read or write operations a storage device or volume completes in one second. Together with throughput (data transferred per second, usually in MB/s) and latency (the round-trip time of a single I/O request), it is one of the three basic metrics used to describe hard disk and solid state drive performance.<sup>[1](https://www.snia.org/sites/default/files/SNIASSSI.SSDPerformance-APrimer2013.pdf)</sup> The "p" in IOPS stands for "per", so the unit reads as "IOs per second".<sup>[2](https://www.snia.org/blog/2015/storage-performance-benchmarking-qa-0)</sup>

| Key fact | Detail |
|---|---|
| Definition | The number of read and/or write operations a storage device performs per second; the IO transaction rate of the device.<sup>[1](https://www.snia.org/sites/default/files/SNIASSSI.SSDPerformance-APrimer2013.pdf)</sup> |
| Relation to latency | IOPS and response time are inversely related only when one I/O is outstanding; with concurrent I/Os, their relationship depends on the average number of outstanding I/Os, such as a device serving one I/O every 10 ms at queue depth 1 performing 100 IOPS.<sup>[2](https://www.snia.org/blog/2015/storage-performance-benchmarking-qa-0)</sup> |
| Relation to throughput | Throughput = IOPS × I/O size; 6,000 IOPS at 16 KB is about 94 MBps, at 8 KB about 47 MBps, at 4 KB about 23 MBps.<sup>[3](https://cloud.ibm.com/docs/vpc?topic=vpc-capacity-performance)</sup> |
| I/O size dependence | A quoted IOPS number is meaningless without the block size; 4 KiB random I/O is the standard way to measure maximum operations per second, while 256 KiB or larger measures bandwidth.<sup>[4](https://docs.oracle.com/en-us/iaas/Content/Block/Concepts/bv-perf-win-tests.htm)</sup> |
| Queue depth | A single thread with queue depth 1 usually cannot drive the maximum IOPS of a high-performance volume; depths of 64 to 128 or more are used to test saturation.<sup>[4](https://docs.oracle.com/en-us/iaas/Content/Block/Concepts/bv-perf-win-tests.htm)</sup> |
| Cloud example | An Amazon EBS SSD volume provisioned for 3,000 IOPS transfers up to 3,000 I/Os per second on a sufficiently fast EBS-optimized instance, with throughput determined by I/O size.<sup>[5](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-io-characteristics.html)</sup> |
| Efficiency metric | IOPS/W (IOPS per watt) evaluates storage I/O performance per unit of power.<sup>[6](https://www.snia.org/education/online-dictionary/term/iops-w)</sup> |

## Why the I/O size matters

An IOPS number is only meaningful together with the size of each operation. Small random I/O is the standard way to measure maximum operations per second, typically at a 4 KiB block size, while large sequential transfers of 256 KiB or more measure bandwidth instead.<sup>[4](https://docs.oracle.com/en-us/iaas/Content/Block/Concepts/bv-perf-win-tests.htm)</sup> A 4 KiB random IOPS test and a 256 KiB throughput test measure different behavior and should not be compared as if they were equivalent.<sup>[4](https://docs.oracle.com/en-us/iaas/Content/Block/Concepts/bv-perf-win-tests.htm)</sup>

The relationship is arithmetic: throughput equals IOPS multiplied by the average I/O size. IBM Cloud's block storage documentation gives the example that 6,000 IOPS yields about 94 MBps at a 16 KB I/O size, about 47 MBps at 8 KB, and about 23 MBps at 4 KB.<sup>[3](https://cloud.ibm.com/docs/vpc?topic=vpc-capacity-performance)</sup> The same volume can therefore hit its IOPS limit with small I/O or its throughput limit with large I/O. On IBM Cloud VPC, the quoted IOPS value is based on a 16 KB block size with a 50-50 read/write random workload, and each 16 KB of data read or written counts as one operation.<sup>[3](https://cloud.ibm.com/docs/vpc?topic=vpc-capacity-performance)</sup>

Cloud providers also define what counts as a single I/O. On Amazon EBS, the maximum I/O size is capped at 256 KiB for SSD-backed volumes and 1,024 KiB for HDD-backed volumes, because SSDs handle small or random I/O much more efficiently than HDDs.<sup>[5](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-io-characteristics.html)</sup> EBS merges physically sequential small operations into one I/O up to that maximum and splits larger operations: eight sequential 32 KiB operations count as one 256 KiB I/O on an SSD volume, while eight random 32 KiB operations count as eight separate IOPS.<sup>[5](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-io-characteristics.html)</sup>

## Queue depth and latency

Queue depth is the number of outstanding I/O requests submitted to the storage path at the same time. Because each I/O has to finish before the next can be issued, one thread running at a queue depth of 1 typically fails to reach the peak IOPS a high-performance volume can deliver; maintaining a larger queue depth, which allows several requests to be outstanding simultaneously, is generally necessary to verify provisioned IOPS or throughput.<sup>[4](https://docs.oracle.com/en-us/iaas/Content/Block/Concepts/bv-perf-win-tests.htm)</sup> Typical benchmarking practice uses queue depth 1 to measure baseline latency, 32 to 64 for moderate concurrency and throughput, and 64 to 128 or more for saturation behavior and maximum IOPS.<sup>[4](https://docs.oracle.com/en-us/iaas/Content/Block/Concepts/bv-perf-win-tests.htm)</sup> High queue depth can also increase latency, so p95 and p99 latency should be reviewed when testing at depth.<sup>[4](https://docs.oracle.com/en-us/iaas/Content/Block/Concepts/bv-perf-win-tests.htm)</sup>

The inverse relationship between IOPS and response time is only true when one I/O is outstanding; with concurrent I/Os, it depends on the average number of outstanding I/Os, explaining an apparent paradox: a system can deliver more IOPS than another while having a higher response time per I/O, because a simple IOPS count does not include the size of each I/O or the work the controller performs.<sup>[2](https://www.snia.org/blog/2015/storage-performance-benchmarking-qa-0)</sup> In the SNIA worked example, a client issuing one I/O at a time against a device that services each in 10 ms measures 100 IOPS; issuing two at a time against a device that takes 20 ms each also measures 100 IOPS in aggregate.<sup>[2](https://www.snia.org/blog/2015/storage-performance-benchmarking-qa-0)</sup>

On Amazon EBS, latency is defined as the true end-to-end client time of an I/O operation, from sending the I/O to receiving acknowledgement of completion. For maximum consistency, AWS recommends maintaining an average queue depth of one for every 1,000 provisioned IOPS in a minute, so a volume provisioned with 3,000 IOPS should run at an average queue depth of 3; consistently driving more IOPS than provisioned increases latency.<sup>[5](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-io-characteristics.html)</sup> Transaction-intensive applications, which are sensitive to latency, suit SSD-backed volumes with low queue length and high provisioned IOPS, while throughput-intensive applications suit HDD-backed volumes driven with large sequential I/O at high queue length.<sup>[5](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-io-characteristics.html)</sup>

## Provisioned IOPS in cloud storage

Cloud block storage services sell IOPS as a provisioned quantity. On Amazon EBS, an SSD-backed volume supporting 3,000 IOPS can be created in three ways: an `io1` or `io2` volume provisioned at 3,000 IOPS, a `gp2` volume of 1,000 GiB, or a `gp3` volume; when such a volume is attached to an EBS-optimized instance with enough bandwidth, it can transfer as many as 3,000 I/Os per second.<sup>[5](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-io-characteristics.html)</sup> Throughput limits can bind before the IOPS limit: a `gp2` volume under 1,000 GiB with burst credits has an IOPS limit of 3,000 and a throughput limit of 250 MiB/s, so at a 256 KiB I/O size it reaches the throughput limit at only 1,000 IOPS, while at 16 KiB it can sustain the full 3,000.<sup>[5](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-io-characteristics.html)</sup>

Performance targets for service levels are measured relative to the IOPS that have been provisioned. In any given year, `io1` and `io2` EBS volumes are built to meet at least 90% of the IOPS they have provisioned for 99.9% of the time, while `gp2` and `gp3` volumes must sustain 90% of provisioned IOPS 99% of the time; for 16 KiB I/O operations, `io2` Block Express volumes are built to keep average latency below 500 microseconds.<sup>[7](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-optimization.html)</sup> IBM Cloud VPC ties throughput to IOPS through preset multipliers of 16 KB for 3 and 5 IOPS/GB tiered profiles and 256 KB for 10 IOPS/GB or custom profiles, with a maximum throughput of 1,024 MBps.<sup>[3](https://cloud.ibm.com/docs/vpc?topic=vpc-capacity-performance)</sup>

## Measuring IOPS

The standard tool for block-device benchmarking on Linux and Windows hosts is fio (Flexible I/O tester), a configurable workload generator that reports IOPS, bandwidth, submission and completion latency, latency percentiles, and the distribution of I/O depths for each job.<sup>[8](https://fio.readthedocs.io/en/master/fio_doc.html)</sup> Oracle's benchmarking guide for block volumes recommends running an IOPS profile of 4 KiB random reads or mixed I/O at queue depth 64 to 128 with 4 to 8 threads for at least 120 seconds, a throughput profile of 256 KiB sequential I/O at queue depth 32 to 64, and a latency profile of 4 KiB random reads at queue depth 1, repeating each test and using the median result.<sup>[4](https://docs.oracle.com/en-us/iaas/Content/Block/Concepts/bv-perf-win-tests.htm)</sup> A volume that can provide 50,000 IOPS attached to an instance shape supporting only 25,000 IOPS will top out at 25,000, because the instance is the bottleneck; benchmark results must be interpreted against the limits of the whole path, including the instance, attachment, and file system.<sup>[4](https://docs.oracle.com/en-us/iaas/Content/Block/Concepts/bv-perf-win-tests.htm)</sup>

Cloud platforms expose IOPS as a monitoring metric alongside throughput, queue depth, and latency: Amazon EBS publishes per-minute average IOPS and throughput metrics in CloudWatch, plus real-time per-operation statistics including latency histograms on Nitro-based instances, and counters measuring the total time demand exceeded the volume's or instance's provisioned IOPS and throughput limits.<sup>[9](https://docs.aws.amazon.com/ebs/latest/userguide/nvme-detailed-performance-stats.html)</sup> Azure virtual machines expose disk I/O, throughput, queue depth, and latency metrics from both the disk and the virtual machine perspective.<sup>[10](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-metrics)</sup>

## Scale of modern devices

Mechanical drives are limited by [seek time](https://www.edgepedia.org/seek-time) and [rotational latency](https://www.edgepedia.org/rotational-latency), so their random IOPS are low relative to their sequential throughput; HDD throughput in a random workload is limited by seek time, rotations per minute, and the native command queuing configuration.<sup>[11](https://www.seagate.com/files/www-content/ti-dm/_shared/images/model-hd-performance-in-cloud-tp661-1409us.pdf)</sup> Flash-based SSDs remove those mechanical delays, and modern PCIe 5.0 x4 SSDs top at around 14.5 GB/s and deliver 2 to 3 million IOPS for both 4K and 512B random reads.<sup>[12](https://www.tomshardware.com/pc-components/ssds/smi-ceo-claims-nvidia-wants-ssds-with-100m-iops-up-to-33x-performance-uplift-could-eliminate-ai-gpu-bottlenecks)</sup> Storage suppliers have reported that Nvidia is working with partners toward SSDs with random read performance of 100 million IOPS in small-block workloads, motivated by AI accelerators whose HBM3E memory bandwidth of around 8 TB/s exceeds what current storage subsystems deliver.<sup>[12](https://www.tomshardware.com/pc-components/ssds/smi-ceo-claims-nvidia-wants-ssds-with-100m-iops-up-to-33x-performance-uplift-could-eliminate-ai-gpu-bottlenecks)</sup>

## References

1. [SSD Performance - A Primer, SNIA Solid State Storage Initiative (2013)](https://www.snia.org/sites/default/files/SNIASSSI.SSDPerformance-APrimer2013.pdf)
2. [Storage Performance Benchmarking Q&A, SNIA (2015)](https://www.snia.org/blog/2015/storage-performance-benchmarking-qa-0)
3. [Block Storage capacity and performance, IBM Cloud Docs](https://cloud.ibm.com/docs/vpc?topic=vpc-capacity-performance)
4. [Block Volume Performance Tests on Windows-Based Instances, Oracle Cloud Infrastructure documentation](https://docs.oracle.com/en-us/iaas/Content/Block/Concepts/bv-perf-win-tests.htm)
5. [Amazon EBS I/O characteristics and monitoring, AWS User Guide](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-io-characteristics.html)
6. [IOPS/W, SNIA Online Dictionary](https://www.snia.org/education/online-dictionary/term/iops-w)
7. [Amazon EBS optimization, AWS User Guide](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-optimization.html)
8. [fio - Flexible I/O tester documentation](https://fio.readthedocs.io/en/master/fio_doc.html)
9. [Amazon EBS detailed performance statistics, AWS User Guide](https://docs.aws.amazon.com/ebs/latest/userguide/nvme-detailed-performance-stats.html)
10. [Disk metrics for Azure Virtual Machines, Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-metrics)
11. [How to Model Hard Drive Performance in the Cloud, Seagate technology paper](https://www.seagate.com/files/www-content/ti-dm/_shared/images/model-hd-performance-in-cloud-tp661-1409us.pdf)
12. [SMI CEO claims Nvidia wants SSDs with 100 million IOPS, Tom's Hardware (2025)](https://www.tomshardware.com/pc-components/ssds/smi-ceo-claims-nvidia-wants-ssds-with-100m-iops-up-to-33x-performance-uplift-could-eliminate-ai-gpu-bottlenecks)

---
*Topic: Encyclopedia › Technology and the built world › Computing and digital systems › Computer hardware › Storage devices & memory › Magnetic & mechanical storage › Rotating-media performance & benchmarking*

*Initially written Sep 17, 2026 · Reviewed: Sep 17, 2026; Oct 15, 2026 · Edited: Oct 15, 2026 · Last review: Oct 15, 2026*

*Copyright 2026 EdgeChat AI, a subsidiary of Biostate AI.*

License: Edgepedia Community License 1.0, https://www.edgepedia.org/edgepedia/license
