选实例不能只看 vCPU 和内存数量：两台配置相近的云服务器，持续计算能力可能不同。判断弹性计算实例规格如何匹配业务负载，关键是看 CPU 使用是否长期稳定，还是大多数时间较低、偶尔升高。前者优先评估通用型，后者可考虑突发型。
先看清两类实例的性能机制
突发型：低基准性能，换取短时高算力
突发型实例通常设有 CPU 基准性能，并通过 CPU 积分等机制支持短时超过基准的运行。以 AWS 的 T3、T4g 系列为例，其定位是可突发的通用计算；具体积分规则、处理器架构及费用选项应以对应规格说明为准。它适合负载有明显间歇、峰值持续时间有限的服务。优点是低负载阶段资源利用较经济；若 CPU 长时间高于基准，积分可能消耗，持续性能或成本也可能不符合预期。
通用型：持续性能更适合稳定计算
通用型实例通常面向较均衡的计算与内存需求。AWS M 系列可作为这类规格的例子。它适合持续处理请求、后台任务长期运行，或不能依赖积分机制承受峰值的应用。优势是性能更适合稳定负载；相较突发型，低负载时可能没有充分发挥其持续算力。
用负载曲线，而不是瞬时峰值做选择
比较时至少查看一段代表性业务周期内的 CPU 利用率、峰值持续时间、内存余量、请求延迟和实例重启情况。监控周期宜覆盖日常高低峰；有周周期或批处理任务的服务，也要纳入相应时段。单个瞬时尖峰不足以说明需要更大的持续规格。
- 低位运行、短时升高：例如开发测试环境、间歇运行的内部工具，可先评估突发型，同时确认峰值期间 CPU 积分不会持续下降。
- 长期处于较高 CPU 水平：例如持续执行图像处理或数据计算的工作节点，应优先比较通用型或计算优化型规格，避免把持续负载当作短时突发。
- CPU 不高但响应变慢：先检查内存压力、磁盘 I/O、网络及应用锁竞争。仅更换 CPU 规格，未必能解决瓶颈。
因此，弹性计算实例规格如何匹配业务负载，不能仅凭实例名称判断；还要核对具体型号的处理器、内存配置、基准性能及计费规则。
按步骤验证，降低选型误差
- 列出服务的正常时段、峰值时段和批处理时段，并确认业务是否允许短时性能波动。
- 查看监控中的 CPU 曲线及突发型实例的积分状态；若平台不展示积分，则查阅该型号的性能机制说明。
- 挑选满足内存和架构要求的候选规格，在测试环境或低风险时段运行代表性任务。
- 对比相同工作量下的完成时间、延迟、错误率与费用，并观察高峰结束后能否恢复。
- 上线后继续监控；若积分反复耗尽、延迟恶化或 CPU 长期饱和，应调整规格或改用持续性能更合适的类型。
常见问题
突发型一定比通用型便宜吗？
不一定。费用受型号、区域、操作系统和计费方式影响；持续消耗积分或相关额外费用也可能改变总成本，应按实际运行周期比较。
CPU 利用率平均值低，就适合突发型吗？
不一定。平均值会掩盖长时间高峰。应同时看峰值持续时长、积分变化和延迟，而不是只看平均 CPU。
突发型能否用于线上服务？
可以评估，但要先确认服务能承受的性能波动，并进行高峰测试。对持续负载或延迟要求严格的服务，通用型往往更容易提供稳定的持续算力。
最终应让规格跟随实测负载，而不是反过来迁就规格：确认峰值是否短暂、持续性能是否足够，再决定弹性计算实例规格如何匹配业务负载。