Are you paying for “just in case” storage performance that your applications never actually use? While Provisioned IOPS keep databases snappy, many teams overprovision by up to 30%, wasting budget on idle capacity that never hits the disk.
What are AWS IOPS and why do they matter?
Input/Output Operations Per Second (IOPS) is the standard measurement for the maximum number of reads and writes your Amazon Elastic Block Store (EBS) volume can perform every second. However, your actual EBS performance is a complex interaction between IOPS, throughput, and latency.
AWS measures a single I/O operation at a block size of up to 256 KiB for SSD-backed volumes. This means the size of your application’s requests directly impacts your IOPS consumption. For example, if your application sends a 512 KiB request, AWS counts this as two IOPS. This distinction is vital for optimization because high-throughput workloads with large block sizes might hit throughput limits before they ever exhaust their provisioned IOPS. Conversely, transactional databases with small, random I/O depend almost entirely on high IOPS to maintain low EBS latency.
Decoding EBS volume types: gp3 vs. io2
Selecting the correct volume type is the foundation of any EBS cost optimization strategy. While the legacy gp2 tier relied on an unpredictable “burst credit” system, modern volumes offer more granular control.
General Purpose SSD (gp3)
The gp3 volume is the recommended baseline for most applications. It provides a consistent 3,000 IOPS and 125 MiB/s throughput regardless of volume size, completely eliminating the risk of performance cliffs associated with burst credits.
- Flexibility: You can provision up to 80,000 IOPS and 1,000 MiB/s independently of storage capacity.
- Cost Savings: Migrating from gp2 to gp3 typically yields an immediate 20% cost reduction, as gp3 costs approximately $0.08 per GiB compared to $0.10 per GiB for gp2.
- Performance Ratio: For higher requirements, additional IOPS are provisioned at a ratio of 500 IOPS per GiB of volume size.
Provisioned IOPS SSD (io2 and Block Express)
For mission-critical applications requiring sub-millisecond latency and 99.999% durability, io2 is the standard. These volumes are designed for I/O-intensive workloads like large-scale OLTP databases.
- Scalability: io2 Block Express can deliver up to 256,000 IOPS and 4,000 MiB/s of throughput per volume.
- Pricing: These volumes come at a premium, with storage costs around $0.125 per GiB plus tiered charges for provisioned IOPS.
The hidden bottleneck: instance-level limits
A common mistake is provisioning a high-performance volume and attaching it to an undersized EC2 instance. Every instance has a hard ceiling for EBS-optimized throughput and IOPS that acts as a bottleneck, regardless of your volume’s configuration.
For instance, if you use a t3.large instance, it supports a baseline of only 2,780 IOPS. Even if you pay for 50,000 IOPS on an attached io2 volume, the instance will throttle your performance. To achieve the high-tier performance supported by io2, you must use Nitro-based instances that provide the necessary bandwidth. Before tuning your storage, ensure your EBS throughput requirements align with your EC2 instance’s capabilities.
Measuring your real-world IOPS demand
To avoid the waste of overprovisioning, you must move beyond estimates and analyze CloudWatch metrics over a representative period. Benchmarking EBS performance allows you to identify your 95th percentile usage rather than provisioning for rare peaks.
- Calculating Usage: Sum `VolumeReadOps` and `VolumeWriteOps` to find your total IOPS.
- Monitoring Latency: Check `VolumeQueueLength`. If your IOPS are maxed out and the queue length is consistently high, your application will experience increased latency.
- Identifying Waste: If you are paying for 10,000 IOPS but your usage consistently hovers at 2,000, you are paying for idle capacity.
Following AWS EBS best practices involves setting alarms for `VolumeThroughputPercentage` and `VolumeQueueLength` to detect saturation before it impacts your users.
Automating performance and savings
Manual rightsizing is an operational burden in dynamic cloud environments. When engineering teams provision “just in case,” the resulting waste often accounts for 20% to 30% of total EBS spend. Hykell solves this by operating on a performance-first philosophy that automates the optimization lifecycle.
The Hykell platform continuously monitors your actual throughput and IOPS usage to identify underutilized resources. By identifying these gaps and automating the migration from legacy gp2 volumes to the efficient gp3 tier, Hykell helps organizations reduce cloud costs by up to 40% on autopilot.
Because the Hykell fee model is based purely on the savings generated – if you don’t save, you don’t pay – there is no financial risk to streamlining your infrastructure. If you are ready to stop paying for idle performance, use our cost savings calculator to see exactly how much you can reclaim from your AWS bill.
