总览
Reserved Instances（RI）分为 Standard 与 Convertible 两类：
- Standard RI：折扣率更高、价格最优，但灵活性较低；不支持跨家族/平台更换，支持 RI Marketplace 转售。
- Convertible RI：折扣略低，但支持在承诺期内更换到等值或更高价值的其他家族/平台/租赁方式（通过“交换”）。
选择本质是“折扣率 vs 灵活性”的取舍，应结合用量稳定性、架构演进节奏与现金流偏好综合决策。
核心差异一览
| 维度 | Standard | Convertible |
|---|---|---|
| 折扣率 | 较高（同期限/付款方式下更优） | 略低 |
| 灵活性 | 低：家族/平台不可变更 | 高：支持交换（等值或加值） |
| 期限 | 1 年/3 年 | 1 年/3 年 |
| 付款 | All/Partial/No Upfront | All/Partial/No Upfront |
| 市场 | 可在 RI Marketplace 转售 | 不可转售 |
| 组合 | 精准“家族位” | 容错“基线位” |
实际折扣矩阵以 AWS 区域和时段为准；本文关注策略层。
折扣与覆盖行为
- 覆盖口径：RI 优先按“匹配度”覆盖对应实例的按需账单（实例家族、区域、平台、租赁等要素匹配）。
- 标准化大小映射：同家族不同大小之间可按“规格因子”映射（如 4×large ≈ 1×4xlarge），但仅限于相同家族/平台。
- 共享范围：合并计费组织内可共享（取决于作用域：Region 或 AZ）。
- 容量预留：作用域为 AZ 的 RI 默认提供容量预留；Region 作用域不保证容量，但有折扣。
灵活性：可变更 vs 不可变更
- Standard：购买后无法更换到其他家族/平台/区域；可在 Marketplace 转售挽回一部分价值（存在手续费与供需风险）。
- Convertible：通过 Exchange 机制在承诺期内灵活更换，目标价值 ≥ 剩余价值（差额一次性补齐）。交换后期限重置（1 或 3 年）。
标准选择场景与建议
选择 Standard 的典型信号：
- 用量“家族位”高度稳定（≥12–18 个月），实例类型明确且迁移概率低
- 有成熟的容量管理与发布节奏，不依赖跨家族/平台灵活性
- 希望最大化折扣并接受较低的变更权
策略建议：
- 把最稳定的“硬基线”（例如长期在线的核心服务）放入 Standard，以 3 年 + All/Partial Upfront 获取最大折扣
- 注意碎片化：用规格因子合并大小，减少小规格分散导致的闲置
- 预留“安全边界”：不要 100% 用 Standard 覆盖，留给 SP/Convertible 或按需应对波动
使用 Convertible 的场景与建议
选择 Convertible 的典型信号：
- 家族升级或平台迁移在 6–12 个月内有较高概率（如 C5→C7g、Windows→Linux）
- 区域/租赁方式存在变动可能（跨区、Dedicated↔Shared）
- 需要与 SP 协同，在“基线位”上做长期但可调的承诺
策略建议：
- 以 1–3 年期分批建立“可交换基线”，每月/每季度滚动调整
- 避免大额一次性交换，采用“验证—补齐”的渐进式方法（见 RI 交换策略文）
- 与 SP 协同：SP 兜底通用基线，Convertible 负责 EC2 家族/平台层面的可调覆盖
与 Savings Plans 的组合
合理的组合通常如下：
- SP（Compute/EC2）兜底“通用基线”，应对跨家族/区域/OS 的灵活性需求
- Convertible RI 覆盖“可调家族位”，在家族/平台稳定期进一步提高折扣
- Standard RI 压住“最稳定家族位”，追求最大折扣
注意事项：
- 避免对同一“基线位”重复承诺（SP 与 RI 重叠）
- 组合顺序：先 SP（小额试水）→ Convertible（确认家族/平台后扩容）→ Standard（稳定后上限）
选型矩阵（决策表）
| 条件 | 推荐 |
|---|---|
| 基线非常稳定，家族/平台 12–18 月无变更 | Standard（3Y + Partial/All Upfront） |
| 需家族/平台灵活，或区域/租赁将变更 | Convertible（1Y/3Y，分批建立） |
| 大量跨家族/区域基线，需最大灵活性 | SP（Compute/EC2） + 少量 Convertible |
| 现金流紧张，希望平衡折扣与 upfront | Partial/No Upfront 组合（SP/RI 混合） |
TCO 建模与 KPI
关键指标：
- 覆盖率（CoveredHours/TotalHours）：按家族/区域/平台分层
- 折扣率（1 - Blended/OnDemand）：真实折扣（含波动与空隙）
- 间隙成本：未覆盖小时 × 按需价
- 承诺效率：已承诺金额/覆盖小时，观察是否“高承诺低利用”
建模建议：
- 用 CUR + Athena 生成“家族×区域×平台×小时”的用量时间序列，模拟不同承诺组合的覆盖与折扣
- 对“Standard/Convertible/SP”的边际贡献进行敏感性分析（±10–20% 负载波动）
实操清单（购买与监控）
购买：
# 列出可购的 RI Offerings（示例过滤：区域/平台/期限/付款方式）
aws ec2 describe-reserved-instances-offerings \
--filters Name=product-description,Values=Linux/UNIX Name=scope,Values=Region \
--offering-class standard \
--instance-type m7i.large \
--include-marketplace \
--offering-type Partial Upfront
# 购买示例（Standard）
aws ec2 purchase-reserved-instances-offering \
--reserved-instances-offering-id rio-xxxxxxxx \
--instance-count 10
# 购买示例（Convertible）
aws ec2 purchase-reserved-instances-offering \
--reserved-instances-offering-id rio-yyyyyyyy \
--instance-count 10
监控：
- Cost Explorer：分组
PurchaseOption、OfferingClass、InstanceType/Region/Platform - CUR 字段：
reservation/ReservationARN、lineItem/UsageType、product/instanceType、pricing/term、pricing/operatingSystem
风险控制（常见坑）
- 过度承诺：追求折扣最大化导致闲置；用 SP/Convertible 先行，Standard 后置
- 碎片化：小规格分散难以完全覆盖；合并规格因子
- 市场流动性：Standard 转售并非随时可行；不要把“可转售”当成随时退出机制
- 叠加承诺：SP 与 RI 重叠覆盖同一基线位，导致边际效益降低
FAQ
Q：Standard 折扣到底能比 Convertible 高多少？
一般 1–8%（视区域/实例/时段），但在 3 年 All Upfront 的场景差值可能更明显。请以当期官方矩阵为准。
Q：Convertible 的“期限重置”会不会影响我原来的回本周期？
会。接受交换后新 RI 重新起算，请在模型中考虑差额与新期限的摊销。
Q：EC2 Instance Savings Plans 和 Standard RI 怎么选？
若家族位高度稳定且追求极致折扣，Standard 更优；如需灵活跨家族/区域/OS，优先 SP，再配合 Convertible/Standard。
结论：Standard 与 Convertible 各有侧重。把“最稳定家族位”交给 Standard，使用 SP + Convertible 管理“通用/可调基线”，并以数据驱动的 TCO 模型与 KPI 监控持续校准，是兼顾折扣与灵活性的行业最佳实践。