An application volume is provisioned for 12,000 IOPS, yet during peak load it never exceeds about 8,000 IOPS while the EBS VolumeQueueLength CloudWatch metric stays persistently high and request latency climbs. The instance is a smaller general-purpose type. What is the most likely cause an operator should investigate first?
- AThe volume is degraded and should be replaced from a snapshot, because a healthy gp3 volume always delivers its full provisioned IOPS under any instance type.
- BThe IOPS were under-provisioned and the fix is to raise the volume to 20,000 IOPS so the queued requests finally drain at peak.
- CThe CloudWatch metric resolution is too coarse, so switching VolumeQueueLength to high-resolution publishing will reveal the volume is actually meeting target.
- DThe instance EBS bandwidth limit caps aggregate volume performance, so a larger or EBS-optimized instance type is needed to reach the provisioned IOPS. Correct
Why A is wrong: Restoring assumes hardware fault, but a high queue with normal volume health usually points to an instance-side bandwidth cap rather than a degraded volume.
Why B is wrong: Adding IOPS looks logical, but the volume already cannot reach its current 12,000, so more provisioned IOPS will not clear a queue caused elsewhere.
Why C is wrong: Finer metric resolution changes only sampling detail, not the throughput the volume delivers, so it cannot explain real queuing and rising latency.
Why D is correct: Smaller instances cap EBS throughput and IOPS regardless of volume settings, so a persistently high queue below provisioned IOPS points to the instance bandwidth ceiling.