Update:用于计算 t2 CPU 积分余额的规则似乎已更改，因此提示此问题的问题不应再产生影响。
根据客户反馈，我们使用新的 CPU 积分分配策略更新了 T2 实例，该策略在所有情况下都与之前的策略相同或更好。
...
现在，在实例终止或停止之前，获得的 CPU 积分不会过期。 T2 实例仍然可以获得实例大小允许的相同最高级别。现在，只要当前 CPUCreditUsage 低于基线，CPUCreditBalance 就会增加，并且可以增长到实例大小允许的最大值
https://forums.aws.amazon.com/ann.jspa?annID=5196 https://forums.aws.amazon.com/ann.jspa?annID=5196
h/t: 上周 AWS https://lastweekinaws.com/用于更新。
原来的答案如下。
在过去的几个小时里，这个问题给我带来了相当大的精神痛苦，因为根据我对 t2 实例的了解，这些图表几乎是有意义的。几乎，但不完全是，我无法指出问题所在。这是最糟糕的一种。尤其是 t2 机器所提供的价值主张的忠实粉丝。
但我终于明白这是怎么回事了。
文档似乎没有解释 CPU 积分的一个概念，但数学是可行的，并且该解释在现实世界的观察下很好地成立：
最近获得的 CPU 积分首先被花费，而不是最后。
顺序重要吗？确实如此。
为了进行测试，我使用了 t2.micro（主要是因为我有一个闲置的，已经运行了几天，需要做点什么，而且我不希望新实例的额外“初始”积分被云化）观察），但 t2 类中的所有实例类型都有类似的行为。
背景知识：在 t2 类中，以不同的速率获得 CPU 积分，但该类中的所有实例类型都以相同的速率使用 CPU 积分：
CPU 积分可提供完整 CPU 核心的性能一分钟。
t2.micro 和 t2.small 只有一个核心，因此在 CPU 利用率为 100% 时，它们每分钟最多可消耗 1 个积分，每小时可消耗 60 个积分。 t2.medium 和 t2.large 是双核，因此在两个核心的 CPU 利用率均为 100% 时，它们每分钟最多可消耗 2 个积分，或每小时 120 个积分。
如果 1 个积分 = 1 个核心 1 分钟的 100%，那么 1 个积分也等于 1 个核心 5 分钟的 20%。由于 Cloudwatch 图形间隔以 5 分钟为增量，因此我设置了以下测试：
在基本上没有负载的情况下运行了几周的 t2.micro 上，我安装了lookbusy https://www.devin.com/lookbusy/，一个方便的实用程序，允许您使用指定的参数使计算机“看起来很忙”——例如，将 CPU 保持在 20% 的利用率。
$ screen -S eat_cpu
$ ./lookbusy -v -c 20 -r fixed
这正是您所期望的，每 5 分钟消耗 1 个 CPU 积分。 “CPU 积分使用情况”图表证实了这一点，显示每 5 分钟使用 1 个积分。 （CPU 利用率图，以及top，都确认了 20%。）
但我的信用余额怎么了？每 5 分钟就会消耗 1 个积分。这似乎是错误的，不是吗？我的意思是，是的，我只是说这就是我正在使用的数量，但是...我还应该每小时赚取 6 个积分，所以我每 5 分钟应该只消耗 0.5 个积分，对吗？
等一下...再检查一下数字：我每小时赚 6 美元，每小时花 12 美元，所以，是的...这看起来应该是每小时净减少 6 美元，而不是 12 美元...正确的？显然，有些事情并没有按照我的预期进行，因为我的余额每小时肯定会减少 12，而我的 CPU 肯定只以 20% 的速度运行。
我似乎没有获得任何积分来抵消我的使用量。这怎么可能？
除非...
给定 5 分钟间隔内未使用的积分将在获得后 24 小时后过期
好吧，24 小时前，我的实例完全闲置。在那一小时内，我获得了 6 个我……没有（？）使用的学分。我现在不使用它们了吗？我不应该这样吗？
在添加任何新获得的积分之前，所有过期的积分都会立即从 CPU 积分余额中删除
粗鲁的。这可能有关系吗？这一小时，我获得了 6 个新学分。但就在这之前，我失去了 24 小时前的 6 个学分。然后我这一小时花费了 12 个积分...所以我的余额下降了 6，上升了 6，又下降了 12。好吧，这解释了这一小时的 -12 变化，但是...
这可能是原因吗？
我是文档的贪婪读者，所以我知道过期积分方面......但我一直认为这只不过是空闲实例徘徊在其最大余额附近的原因，并且没有任何其他意义。怎么可能呢？如果我的积分少于最大值（t2.micro 为 6 x 24 = 144），那么我怎么能让积分需要过期呢？
如果我24小时前的积分总是对我不利，那么无论我做什么，我的余额不是都会趋向于零吗？
除非...
经过大半夜的辗转反侧，同时考虑在虚拟桌面（代表时间）上的一堆虚拟代币（代表 CPU 积分）上滑动之后……我意识到，“过期”规则将导致我们观察到的行为，如果：与直觉相反，学分是not花费的顺序是按照赚取的顺序（先进先出），而不是按照相反的顺序（后进先出）。
按照这个推理，我的 20% CPU 测试实际上在做什么的解释是这样的，我测试的第一个小时是“小时 0”——
| spends 6+6 credits | expire 6 credits
test | earned this many | earned this many
hour | hours before hour 0 | hours before hour 0
-----+---------------------+--------------------
0 -1, -2 -24
1 -3, -4 -23
2 -5, -6 -22
3 -7, -8 -21
4 -9, -10 -20
5 -11, -12 -19
6 -13, -14 -18
7 -15, -16 -17
他们在中间相遇。
这是真的吗，还是我猜的？我不是猜测，证据如下：
8 小时后，我的 CPU 积分使用情况图表保持稳定，仍然稳定在每 5 分钟 1 个积分，但在同样的 8 小时后，我的 CPU 积分余额finally开始以我最初预期的（较慢）速度消耗：每 5 分钟 0.5 个积分。
显然，当我在时间上倒退时，花掉以前获得的积分“最新的优先”，我赶上了即将过期的旧积分，最终达到了在它们有机会过期之前使用它们的地步。现在，我没有 24 小时内的积分，因此没有积分会过期 - 因此在获得新积分之前我不会再失去积分。我现在能够保留每小时赚取的 6 个，因为我用完了旧的，从而将对我的信用余额的净影响降低到预期水平。
这解释了我对问题中的图表的唯一保留：为什么当利用率下降时，余额需要很长时间才能反弹？
The TL;DR答案是这样的：在大量使用之后，余额不会立即反弹，因为您仍然有 24 小时前未使用的积分，这些积分会抵消您新获得的积分，直到您到达不使用的时间点。没有任何 24 小时内未使用的积分。当这种情况发生时，您的信用余额会再次增加。
让实例完全空闲 24 小时，您最终会看到余额（在很大程度上）再次稳定上升到最大值，正如预期的那样。任何少于 24 小时的完全闲置都会导致您的余额永远低于最大值。
我的测试脚本最终几乎耗尽了我的信用余额。当我杀死吃CPU的进程时，信用余额开始恢复立即地，预计每小时 6 个学分。
相反，当我使用一台 24 小时利用率较低的另一台机器，将其 CPU 运行到 100% 几分钟，然后将其恢复空闲状态时，积分并没有立即开始累积...被抵消旧的、即将到期的。
报价来自http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instances.html http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instances.html.
