先看负载特征，再看价格表
很多团队选实例的方式是「上一个项目用的 m5.xlarge，这次也用它」。结果是内存型负载跑在通用型实例上被迫超配 CPU，或者计算密集型任务被 EBS 吞吐拖住。
沐杉云的做法是先采集 14 天的性能基线：CPU 使用率分布（p50/p95/p99）、内存占用曲线、网络 PPS、EBS IOPS 与吞吐、以及是否存在明显的日内峰谷。有了这组数据，选型就变成一道有约束的最优化题，而不是凭经验拍。
五大家族适用边界
| 家族 | 代表机型 | vCPU : 内存 | 典型负载 | 选型提示 |
|---|---|---|---|---|
| 通用型 M | m7i / m7g / m6i | 1 : 4 | Web 应用、微服务、中小型数据库 | 80% 的业务从这里起步，先看 m7g 能否直接跑 |
| 计算型 C | c7i / c7g / c6i | 1 : 2 | 批处理、编解码、游戏服、机器学习推理 | 关注单核性能与网络带宽上限 |
| 内存型 R / X | r7i / r7g / x2idn | 1 : 8 起 | Redis、Elasticsearch、SAP HANA、大型 OLTP | 先算真实工作集，不要按峰值内存直接乘 2 |
| 存储型 I / D | i4i / im4gn / d3 | 1 : 8 | 本地 NVMe 高 IOPS、NoSQL、日志检索 | 实例存储无持久性，必须有副本或快照策略 |
| 加速型 G / P / Inf | g5 / p5 / inf2 | 按卡型 | 模型训练、推理、图形渲染 | 优先考虑 Spot + 检查点，成本差异极大 |
T 系列（t3/t4g）适合突发型轻载，但要盯住 CPU 积分耗尽风险，生产核心链路慎用。
Graviton 迁移：先测三件事
ARM 架构的 Graviton 3/4 在同等性能下价格通常低 15%-25%，但迁移不是改个实例类型就完事。我们会先跑三项验证：依赖库的 ARM 支持、容器镜像的多架构构建、以及有无 x86 汇编或闭源二进制依赖。
Java、Go、Python、Node.js 生态迁移成本普遍很低；涉及原生扩展、商业中间件或特定加速库的场景，需要逐项确认。
- 依赖清单扫描：pip / npm / maven 全量检查 ARM wheel 与二进制可用性
- 多架构镜像：docker buildx 双架构构建 + ECR manifest list
- 性能回归：同并发下对比 p99 延迟与吞吐，避免只看均值
- 灰度切流：按 5% → 25% → 100% 的节奏，ALB 权重逐步迁移
- 常见降本幅度18% - 25%
- 改造周期（Java/Go）1 - 2 周
- 改造周期（含原生扩展）3 - 6 周
- 回滚方式ALB 权重 / ASG 双模板
用 CLI 快速拉取候选机型的规格对比
#!/usr/bin/env bash
# 对比候选机型的 vCPU / 内存 / 网络 / EBS 带宽，输出为表格
set -euo pipefail
REGION="${1:-ap-northeast-1}"
TYPES="m7i.xlarge m7g.xlarge c7i.xlarge r7g.xlarge"
aws ec2 describe-instance-types \
--region "$REGION" \
--instance-types $TYPES \
--query 'InstanceTypes[].{
Type: InstanceType,
Arch: ProcessorInfo.SupportedArchitectures[0],
vCPU: VCpuInfo.DefaultVCpus,
MemGiB: to_string(MemoryInfo.SizeInMiB),
NetGbps: NetworkInfo.NetworkPerformance,
EbsMbps: EbsInfo.EbsOptimizedInfo.MaximumBandwidthInMbps
}' \
--output table把输出贴进选型表，配合 Compute Optimizer 的建议一起看，比单看价格页靠谱。
别忽略网络与 EBS 上限
同一家族里小规格实例的网络带宽和 EBS 吞吐是「突发」值，长时间打满会被限速。数据密集型任务建议直接选到基准带宽足够的规格，否则会出现「CPU 很闲但吞吐上不去」的诡异现象。