AWS RDS未达预置IOPS阈值，为何EBSByteBalance仍被耗尽？

1. 基准IOPS的认知纠正 #

gp2存储的基准IOPS规则是每GB提供3个IOPS，但上限为10,000 IOPS，并非你理解的12k。当存储容量超过3334GB时，基准IOPS将固定在10k，不会随容量继续增长。这是你对基准IOPS的第一个误解。

2. EBSByteBalance耗尽的核心原因：字节吞吐量超标，而非IOPS次数 #

EBSByteBalance衡量的是gp2的突发信用余额，但这个信用是按字节吞吐量而非IO次数计算的：

• gp2的基准能力包含两个维度：IOPS上限和对应的字节吞吐量上限。默认按16KB的平均IO大小计算，10k基准IOPS对应的基准吞吐量为 10000 × 16KB = 160MB/s。
• 若你的工作负载实际字节吞吐量持续超过基准吞吐量，哪怕IOPS未达到10k的上限，也会持续消耗突发信用。当信用耗尽（EBSByteBalance=0），磁盘只能以基准吞吐量运行，直接导致读写延迟飙升。

举个典型场景：如果你的工作负载以32KB的大IO为主，当IOPS维持在8k（未达10k上限）时，实际吞吐量为 8000 ×32KB=256MB/s，远超160MB/s的基准值，此时会快速消耗突发信用，最终导致EBSByteBalance耗尽。

3. 验证步骤 #

• 查看RDS监控中的EBSVolumeByteReadOps和EBSVolumeByteWriteOps指标，计算总字节吞吐量（读+写），与基准吞吐量（10k×16KB=160MB/s）对比，确认是否持续超标。
• 通过(总字节吞吐量 ÷ EBSVolumeIOPs)计算平均IO大小，验证是否是大IO导致吞吐量超出基准。

4. 可行解决方案 #

• 切换至gp3存储：gp3支持独立配置IOPS和吞吐量，不受容量限制，无需依赖突发信用，完美适配大吞吐量或大IO的工作负载。
• 优化工作负载：拆分大文件读写操作，调整数据库批量任务的单次处理大小，降低单IO的字节量，从而控制总吞吐量在基准范围内。

内容的提问来源于stack exchange，提问作者Nero Vanbiervliet