IOPS → Throughput Estimator
IOPS × block size = throughput. 10,000 IOPS at 4 KB blocks = 40 MB/s. 10,000 IOPS at 256 KB blocks = 2,560 MB/s. Same IOPS count. Two orders of magnitude difference in throughput. The block size you benchmark at is not the block size your application uses.
Bidirectional IOPS / Throughput Converter
Bidirectional IOPS to throughput converter. Start at 4 KB baseline, then see what happens at 8 KB and 64 KB. The difference is not linear — and your EBS volume's block size may not match your benchmark.
Cloud Volume IOPS Reference
Typical provisioned IOPS and throughput for common cloud block storage tiers.
| Volume Tier | Max IOPS | Throughput (MB/s) |
|---|---|---|
| AWS EBS gp3 (Baseline) | 3,000 | 125 |
| AWS EBS gp3 (16K IOPS) | 16,000 | 1,000 |
| AWS EBS io2 (Max) | 256,000 | 4,000 |
| Azure Ultra Disk | 160,000 | 4,000 |
| NVMe Gen4 (Single Drive) | ~1,000,000 | ~7,000 |
| NVMe Gen5 (Single Drive) | ~1,500,000 | ~14,000 |
IOPS vs. Throughput: The Block Size Coupling
IOPS and throughput are coupled by I/O size: Throughput = IOPS × Block Size. At the common 4 KB filesystem block boundary, 10,000 IOPS ≈ 40 MB/s. At 64 KB — typical for sequential read workloads like video streaming or log ingestion — the same 10,000 IOPS delivers 640 MB/s. This is why database workloads (small random I/O) are IOPS-bound while media serving (large sequential I/O) is throughput-bound.
When provisioning cloud volumes, the IOPS-to-throughput ratio is critical. AWS gp3 volumes decouple the two (you can scale IOPS and throughput independently), while older gp2 volumes are tied at a fixed 3:1 IOPS-to-MB/s ratio. Under-provisioning throughput for a high-IOPS, large-block workload creates a silent bottleneck that manifests as P99 latency spikes under load. Use this estimator to validate your tier selection before deployment.