突发型 EC2 VPN：Standard 还是 Unlimited CPU 积分？

一台小型 VPN 网关通过速度测试，感觉良好，然后在午饭后变慢。实例在测试时并没有说谎；它花的是空闲时攒下的积分。突发型实例正是为此设计的，因此一次短测并不能预测整个下午的传输表现。两种积分模式的失败方式也不同，而在两者之间做选择才是真正的决定。

速度测试的额度是从哪里借的

一个 CPU 积分就是一个 vCPU 满负载运行一分钟。突发型实例按基准线速率赚取积分，并在超出基准线时消耗它们。空闲的夜晚积累余额，忙碌的早晨则把它花掉。

这就是第一次测试看起来不错的原因。实例有一笔存下来的预算，把它花在加密工作上，并报告了健康的速度。结果里没有任何内容告诉你余额归零后会发生什么。基准测试测的是突发，而突发正是实例被设计来提供的。它从未测量你即将依赖的稳态。

你必须做的算术

输入是每个 vCPU 的基准线百分比、vCPU 数量、已累积的余额，以及你预期的负载。仅作示例：假设一台双 vCPU 实例，每个 vCPU 的基准线为百分之十，已累积 24 个积分，一个 vCPU 完全忙碌而另一个空闲。这些数字是声明出来的输入，并不是某种特定实例规格的说明。

Earn rate:       2 x 10% x 60 = 12 credits/hour
Workload usage:  1 x 100% x 60 = 60 credits/hour
Net draw:        60 - 12 = 48 credits/hour
Accrued budget:  24 / 48 = 0.5 hours

在这些假设下，预算大约半小时就会用完。后台工作、变化的负载以及实例自身的核算都会改变结果，而这些都不能预测 VPN 吞吐量。它能预测的是持续约束何时开始起作用。

也注意第二种读法：在这个例子里，一个忙碌的 vCPU 大约占总 CPU 容量的一半。适中的整体百分比可能掩盖一个饱和的核心，所以要把每核心的行为和积分数字放在一起看。

Standard 与 Unlimited：同样的零，不同的含义

在 Standard 模式下，耗尽的余额会把持续 CPU 压向基准线。实例仍在工作，只是更慢，而且上限是可预测的。在 Unlimited 模式下，余额归零后实例仍可继续动用盈余积分，而高于基准线的持续使用可能按服务的核算规则产生费用。

所以 CPUCreditBalance 为零，在一种模式下意味着限流，在另一种模式下则可能意味着计费。这就是全部的比较，也正是只读指标而不读模式会误导人的原因。

盈余也不是按积分简单开票。之后低于基准线的运行可以抵扣盈余用量，并且还适用其他计费条件。请检查已配置的模式和当前的服务规则，而不是依赖旧博客文章里关于免费额度的说法。

真实工作中要观察什么

把 CPUCreditUsage 与 CPUCreditBalance 和传输时长、速率一起记录。在 Unlimited 上，再加上 CPUSurplusCreditBalance 与 CPUSurplusCreditsCharged。AWS 的 CPU 积分监控指南说明了每一项报告什么、多久报告一次。

用有代表性的并发和足够长的时长重新测试，以便看出趋势，并记录起始余额。空闲的早晨和忙碌的下午不是同一个实验，即使命令完全相同。

不是 CPU 的限制

网络带宽有自己的基准线和突发行为，包速率或连接数配额可能比 CPU 更早触顶。当 VPN 实现按连接保存状态时，内存就很重要，而小实例可能在积分耗尽之前很久就耗尽内存。

因此，健康的积分余额只证明一件事：CPU 预算不是当前的约束。它对网络路径只字未提，对并发翻倍时会发生什么也只字未提。把网络指标和积分指标放在同一个时间窗口里观察，这样吞吐下降才有候选原因，而不是一个猜测。

有意识地选择基准线

用实测的持续负载来选择基准线，或者明确接受突发并为它做预算。写下来时两种答案都站得住脚；从别人成功的视频流里推断出来的答案则站不住脚。

如果网关承载关键负载，就把积分模式当作容量规划的一部分，而不是一个你从未打开过的默认值。你选择的模式，就是你能预测的那种故障。