我在AWS上有一个运行的Mysql db.m3.medium RDS实例，使用20GB的SSD运行： RDS机器描述
最后一小时的写入和读取操作如下： 磁盘操作
它看起来像最大（写）+最大（读）操作总计约50 /秒，这意味着它是在3 * disk_capacity = 3 * 20 = 60次/秒。 所以这意味着每一秒我都会得到额外的10个IOP。
考虑到这一点，我目前的信用计数是在这段时间（1小时）+总和（每个第二时间段的贷方余额）之前的信用计数？
这是计算当前IOPS使用情况和信用积累/计数的正确方法吗？
如果是这样，没有显示IOPS信用使用情况的AWS图表，因为存在CPU信用使用情况，是否正确？
正如我如何看到我的IOPS突发信用？ （ 来源 ）：
不幸的是，目前的IOPS信用余额没有像Cloudwatch Metric那样的CPU信用额度。
截至2016年7月，这项工作还没有实施。
AWS文档提供了一个非常好的IOPS突发介绍：
每卷收到的初始I / O贷方余额为540万I / O信用额，足以维持30分钟的最大突发性能3000 IOPS。 初始信用余额旨在为引导卷提供快速的初始引导周期，并为其他应用程序提供良好的引导体验。 卷以每个GiB卷大小3 IOPS的基准性能速率获得I / O信用。 例如，100 GiB gp2卷的基准性能为300 IOPS。
当您的卷需要超过基准性能I / O级别时，它将借用信用余额中的I / O信用来达到所需的性能级别，最高可达3000 IOPS。 大于1,000 GiB的卷具有等于或大于最大突发性能的基线性能，并且其I / O信用余额不会消耗。 如果您的卷使用的I / O信用less于第二次获得的I / O信用，则将未使用的I / O信用添加到I / O信用余额中。 一个交易量的最大I / O信用余额等于初始信用余额（540万I / O信用）。
因此，以您的示例为例，您的20 GB卷的基准性能为60 IOPS。 如果您平均使用50 IOPS，则每秒将有10个I / O信用额度添加到您的贷方余额中，最多达到540万个I / O信用额度。
AWS刚刚发布了这个function，这可以帮助你监控你的IOPS：
Burst Bucket Metric现在可用于Amazon EBS通用SSD（gp2）卷