IOPS

IOPS measures how many read and write operations a storage system completes each second. It is particularly useful when sizing storage for workloads that perform many small requests, such as transactional databases, virtual machine disks, and application metadata stores. An IOPS requirement is meaningful only when accompanied by information such as request size, read/write mix, access pattern, concurrency, and acceptable latency.

IOPS and throughput measure different things. Throughput is the volume of data transferred per second. When operations have a consistent size and are counted at the same layer, throughput approximately equals IOPS multiplied by operation size. For example, 10,000 operations per second at 16 KiB each require about 156 MiB/s. At 256 KiB each, the same operation rate requires 2,500 MiB/s. A storage configuration can therefore reach its throughput limit before reaching its advertised IOPS limit.

Operation counting also matters. An application request is not necessarily one storage operation: the operating system can merge adjacent requests, and storage services can split large requests according to their accounting rules. Database transactions may generate several reads and writes, while caching may eliminate some physical reads entirely. Do not equate transactions per second, API requests per second, and disk IOPS without measuring the relationship.

In cloud environments, performance is constrained by the entire storage path. A block volume has its own IOPS and throughput limits, while the attached compute instance can impose separate aggregate storage limits. CPU availability, network capacity, filesystem behavior, and database settings can create additional bottlenecks. For example, provisioning a volume for 20,000 IOPS will not deliver that rate if the instance supports only 10,000 IOPS across its attached volumes. Adding more volumes does not bypass an instance-level ceiling.

Latency and concurrency determine whether an application can use available IOPS. A workload issuing one request at a time with 2 ms average completion latency can achieve roughly 500 IOPS. Multiple outstanding requests can increase aggregate operation rate, but excessive queueing increases response time. Benchmark with realistic concurrency and inspect tail latency, not just average IOPS. A storage system that completes many operations while violating the application's response-time target is not meeting the requirement.

Select storage according to the workload rather than choosing the highest advertised number. SSD-backed storage generally suits small random operations, while HDD-backed storage can be economical for supported workloads dominated by large sequential transfers. General-purpose SSD storage may satisfy ordinary application needs; provisioned-performance configurations are appropriate when sustained requirements exceed those capabilities or demand more predictable performance. Burst-based configurations require special attention because short tests may consume credits and hide lower sustainable performance.

On AWS, Amazon EBS gp3 allows IOPS and throughput to be configured separately from capacity, within applicable limits. EBS io2 is designed for demanding workloads requiring provisioned IOPS and consistent low latency. In either case, match the EC2 instance's EBS capabilities to the volumes. For managed databases, evaluate the database instance class, storage configuration, and engine behavior together rather than assuming that increasing provisioned storage performance will fix every slow query.

Measure representative peak demand and leave headroom for growth, maintenance, and recovery activity. Compare completed operations, bytes transferred, latency, queue depth, and any relevant burst-credit metrics over the same intervals. Use sustained load tests rather than brief peaks, and verify durability and availability requirements separately: high IOPS does not itself provide replication, backups, or persistence after an instance is terminated.