AWS可突增实例积分规范：unlimited与standard怎么选
AWS 的 T 系列属于可突增性能实例（burstable performance instances），定价低于同规格的通用型实例，但性能供给方式不同：它给的是基准性能加上有限的突发能力，而不是持续满载能力。理解这一点是用好 T 系列的前提——用对了成本明显更低，用错了要么性能被限，要么账单反而超过通用型实例。
本文说明积分机制的运作方式、两种积分规范的差异、怎么判断该选哪种，以及什么情况下应该干脆换出 T 系列。
积分机制是怎么运作的
T 系列的 CPU 性能由积分（CPU credits）控制，逻辑分三部分：
基准性能。每种实例规格有一个基准 CPU 利用率，按 vCPU 计算。CPU 使用率低于基准时，实例持续累积积分；高于基准时，消耗积分来支撑超出部分。不同规格的基准比例差别很大，具体数值以 AWS 官方的实例类型文档为准。
积分累积速率与上限。积分按固定速率累积，且有上限。达到上限后继续闲置不会再攒更多，这意味着长期闲置换不来无限的突发额度。
初始积分。新启动的实例会获得一批初始积分，用于应对启动初期的资源需求。这批积分用完之后就依赖正常累积速率，所以刚启动时表现良好不代表长期表现如此。
关键的推论是：T 系列适合平均利用率低、偶尔有短时高峰的负载。如果负载是持续中高利用率，积分会长期处于耗尽状态，实例只能跑在基准性能上，或者在 unlimited 模式下持续产生额外费用。
两种积分规范的差异
standard 模式：积分耗尽后，CPU 性能被限制在基准水平，不产生额外费用。特点是成本可预测，代价是高峰期性能会被压制。
unlimited 模式：积分耗尽后仍可突破基准运行，超出部分按额外费率计费。AWS 会在 24 小时窗口内做平衡——如果这段时间内的平均 CPU 利用率没有超过基准，之前借用的性能由后续累积的积分抵扣，不产生额外费用；只有平均利用率持续超过基准时才实际收费。
不同代次的 T 实例默认模式不同（较新的代次通常默认 unlimited），创建实例时应当明确确认当前设置，不要依赖记忆中的默认值。
怎么判断该用哪种模式
不要凭感觉选，用 CloudWatch 的实际数据判断。需要看两个指标：
CPUUtilization（CPU 利用率）：观察至少一到两周，重点看平均值和高峰的持续时长。
CPUCreditBalance（积分余额）：这个指标比利用率更直接。
按积分余额的形态判断：
- 余额长期维持在较高水平，偶尔下降后能恢复：负载与 T 系列匹配。此时选 standard 即可，偶发高峰有积分覆盖，不会产生额外费用。
- 余额反复触零，但每次都能回升：处于临界状态。选 unlimited 更稳妥——高峰不被限速，且因为平均利用率未超基准，实际额外费用很少或没有。
- 余额长期为零，几乎不回升：负载与 T 系列不匹配。此时 standard 会让业务长期在基准性能下运行，unlimited 会持续产生超额费用。正确做法不是调模式，而是换实例类型。
修改积分规范的操作步骤
运行中和已停止的实例都可以修改，随时可以切回。
- 打开 EC2 控制台，进入实例列表。
- 选中目标实例，可以多选做批量操作。
- 依次选择「操作」→「实例设置」→「更改积分规范」。这个菜单项只对可突增性能实例可用，选中非 T 系列实例时不会出现。
- 勾选设为 unlimited，取消勾选设为 standard。
- 确认保存。
修改立即生效，不需要重启实例，不影响运行中的业务。
需要批量管理时可以通过 API 或 CLI 操作。使用 API 时按最小权限原则配置调用凭据，只授予修改实例属性所需的权限，不要用管理员级别的密钥跑自动化脚本。
超额费用怎么算
unlimited 模式下的额外费用按 vCPU 使用时长计费，费率以 AWS 官方定价页为准。计费的判定基于 24 小时窗口内的平均 CPU 利用率是否超过基准，而不是看某个瞬间是否突发。
实际操作中的注意点：
- 费用不会体现在实例小时价里，需要在账单中单独查看这一项，否则容易忽略。
- 开启账单告警。unlimited 模式的费用上限取决于实际用量，如果负载意外持续走高，费用会持续累积。设置预算阈值告警可以及早发现。
- 在 Cost Explorer 中按服务查看，可以定位超额费用的具体来源。
什么时候该换出 T 系列
出现以下情况时，继续在 T 系列上调参数收益有限，换实例类型更合适：
- 积分余额长期为零且无法回升
- unlimited 模式下的超额费用累积起来接近或超过同规格通用型实例的差价
- 业务对延迟敏感，无法接受积分耗尽时的性能波动
- 负载是持续型而非突发型，例如常驻的计算任务或高并发服务
换型方向通常是同规格的通用型（M 系列）或计算优化型（C 系列），它们提供持续的满额性能，价格更高但可预测。做决定时把 unlimited 的实际超额费用算进对比，很多情况下换型反而更省。
常见误区
"T 系列就是便宜版的通用实例。" 它的性能模型不同，是基准加突发，不是持续满载。适用负载类型有明确边界。
"unlimited 一定会产生额外费用。" 只在 24 小时平均利用率超过基准时才收费。平均利用率不高的负载开 unlimited 通常不产生费用，却能避免高峰被限速。
"实例刚启动跑得很快，说明配置够用。" 初始积分会掩盖长期供给能力，要观察至少一到两周的积分余额趋势。
"闲置越久，能突发的时间越长。" 积分有累积上限，超过上限不再增加。
"改成 unlimited 就解决了性能问题。" 如果积分长期为零，说明负载超出了 T 系列的设计场景，应当换实例类型而不是靠超额付费硬撑。
检查清单
- 已通过 CloudWatch 的 CPUCreditBalance 观察至少一到两周，而不是凭感觉判断
- 明确确认了实例当前的积分规范，没有依赖默认值假设
- unlimited 模式下已设置账单告警，能及早发现异常费用
- 已对比过超额费用与换用通用型实例的差价
- 自动化脚本使用的凭据遵循最小权限原则
官方来源
- AWS 可突增性能实例文档：基准性能、积分累积速率与上限的具体数值
- AWS EC2 用户指南：积分规范的修改方式与 API 接口说明
- AWS 定价页：unlimited 模式超额部分的计费费率
- Amazon CloudWatch 文档：CPUUtilization 与 CPUCreditBalance 指标的查询方法
需要 AWS 账号可通过申请账号开通，已有账号充值见自助充值。实例类型调整前建议先看两周监控数据再决定。
延伸阅读与下一步
常见问题
AWS可突增实例积分规范需要注意什么？
操作前先确认账号属于AWS对应站点，并备份关键数据或记录当前配置。按本文步骤完成后，用连通性、控制台状态或业务探针做一次验证，避免只改配置不验收。
出错后如何快速回滚或止损？
优先恢复到变更前的快照、镜像或原规则；若涉及计费或销毁类操作，先停止继续变更，再按官方控制台状态与工单路径处理。不确定时不要反复点击高危按钮。
没有对应云账号时怎么开始？
可先通过云管家申请页开通国际云账号，再用自助充值完成额度准备。新账号建议先完成 MFA、访问密钥收敛与费用告警，再部署业务。
