Convertible RI 交换策略：何时换、如何换、换到哪

概要与建议

Convertible RI（可转换预留实例）允许在承诺期内将现有 RI 以“剩余价值”为基准，交换为一组等值或更高价值的新 RI，从而在家族、操作系统、租赁方式、作用域等维度上灵活适配业务变化。合理的交换策略可以将错配损耗降到最低，并避免过度承诺带来的沉没成本。

适合人群：

• 已大量持有 Convertible RI，且实例家族/区域/OS/租赁方式发生变化
• 需要随业务迭代进行“家族升级/降配/跨区域迁移”的团队
• 需要在合并计费（Organizations）中动态调配 RI 覆盖的 FinOps 团队

基础概念复盘

• Convertible RI 只能与 Convertible RI 互换，不能与 Standard RI 混用或相互转换。
• 交换的“基准”是 AWS 计算的剩余价值（Remaining Value），新目标 RI 的总价值必须 ≥ 剩余价值；差额通过一次性补差（通常为 Upfront）完成。
• 支持改变的维度：实例家族、大小、平台（OS/License）、租赁方式（Shared Tenancy ↔ Dedicated）、区域作用域（Region/AZ）等。
• 期限规则：接受交换后，新 RI 的期限重置为新的 1 年或 3 年期，不继承旧期限的剩余时长。
• 市场限制：Convertible RI 不可在 RI Marketplace 转售（仅 Standard RI 支持）。

何时应该“换”

常见触发场景：

• 家族迁移：例如从 C5 → C7g（Arm）或 M5 → M7i
• OS 策略调整：Windows → Linux/Unix（许可成本与折扣结构不同）
• 租赁方式变更：从 Dedicated Tenancy 迁回 Shared，或相反
• 区域迁移：数据主权/延迟/价差导致的 Region 变化
• 架构调整：容器编排/Serverless 渗透后，EC2 覆盖基线下降

不建议立即交换的情形：

• 仅短期波动或灰度期（建议先用按需/短期 RI 或 SP 过渡）
• 不能明确验证“新基线”的稳定性与回本周期

可交换与不可交换的维度

可变更：实例家族、大小、平台（Linux/Windows/RHEL/…）、租赁（Shared/Dedicated）、容量预留作用域（Region/AZ）、付款方式（All/Partial/No Upfront）。

不可变更/限制：

• 不能从 Convertible 变为 Standard，也不能反向
• 由 RI Marketplace 购买的条目通常不可交换（以 AWS 最新政策为准）
• 某些平台/租赁组合的可用供给受限（目标产品需可采购）

价值模型与“补差”

AWS 在报价阶段会根据旧 RI 的“剩余价值”与目标 RI 的“总价值”计算差额：

flowchart TD
  A[选择目标配置] --> B[GetExchangeQuote]
  B --> C{目标价值 >= 剩余价值?}
  C -- 否 --> D[调整数量/家族/付款方式]
  D --> B
  C -- 是 --> E[差额 = 目标价值 - 剩余价值]
  E --> F[AcceptExchangeQuote]
  F --> G[生成新 RI 合同并重置期限]

实践建议：

• 以“等值或略高”价值为目标，尽量减少一次性补差支出
• 先做分批小额验证（Split → Exchange → 合并补齐）
• 善用 No/Partial Upfront 组合，平衡现金流与长期折扣

操作流程（安全可复用）

前置检查清单：

• 确认变更后的长期基线（至少 6–12 个月稳定）
• 盘点现有 Convertible RI：数量、支付方式、剩余期限、平台/家族/作用域
• 确认目标实例类型、区域、平台、租赁方式与期限
• 评估差额预算与回本周期（现金流影响）
• 在沙盒或小批量中验证覆盖效果与账单变化

CLI 示例：

# 1) 查询现有 Convertible RI
aws ec2 describe-reserved-instances \
  --filters Name=state,Values=active Name=product-description,Values=Linux/UNIX \
  --query 'ReservedInstances[?OfferingClass==`convertible`].[ReservedInstancesId,InstanceType,InstanceCount,Scope,ProductDescription,Start,End]' \
  --output table

# 2) 生成交换报价（示例：将若干 C5 转到 C7g）
aws ec2 get-reserved-instances-exchange-quote \
  --reserved-instances-ids ri-0123456789abcdef0 ri-0abc... \
  --target-configurations '[
    {
      "InstanceCount": 10,
      "OfferingId": "offer-xxxxxxxx",  # 通过 describe-reserved-instances-offerings 获取
      "TargetConfiguration": {
        "InstanceType": "c7g.large",
        "Scope": "Region",
        "Platform": "Linux/UNIX",
        "AvailabilityZone": null
      }
    }
  ]'

# 3) 审核报价（差额/期限/明细）并接受
aws ec2 accept-reserved-instances-exchange-quote \
  --reserved-instances-ids ri-0123456789abcdef0 ri-0abc... \
  --target-configurations '[...]' \
  --dry-run

Python（boto3）伪代码：

import boto3
ec2 = boto3.client('ec2')


quote = ec2.get_reserved_instances_exchange_quote(
    ReservedInstancesIds=['ri-0123...', 'ri-0456...'],
    TargetConfigurations=[{
        'InstanceCount': 10,
        'OfferingId': 'offer-xxxx',
        'TargetConfiguration': {
            'InstanceType': 'c7g.large',
            'Platform': 'Linux/UNIX',
            'Scope': 'Region'
        }
    }]
)

cost = quote['EstimatedExchangeCost']  # 含差额等关键信息
# 评估 cost，再决定是否接受

# ec2.accept_reserved_instances_exchange_quote(...)

注意：目标产品需先通过 describe-reserved-instances-offerings 列表定位 OfferingId；配合 Location（区域或 AZ）、ProductDescription（平台）等过滤条件。

策略模板（可直接落地）

1) 家族升级（x5 → x7）

• 动因：新家族单位性能更高/价效比更优
• 策略：分批按月交换 20–30%，观察 CPU/内存账单走势；稳定后继续
• 指标：单位吞吐成本（$/rps）、已覆盖小时占比、差额/台时

2) OS 迁移（Windows → Linux）

• 动因：许可成本与可维护性
• 策略：先在按需侧完成 OS 迁移与稳定性验证，再对 RI 进行转换，避免双向错配
• 风险：短期并存导致覆盖率下降；可用 SP 对基线做临时“兜底”

3) 区域迁移（Region A → Region B）

• 动因：数据主权/延迟/价差/客户分布
• 策略：目标区域先按需→短期 SP 过渡→稳定后将 RI 交换到新区域
• 注意：跨区时务必对比目标区域的 RI 折扣矩阵与可供给情况

4) Dedicated ↔ Shared 租赁变更

• 动因：合规/隔离诉求变化
• 策略：严格核对 Dedicated 溢价与实际必要性，谨慎做大规模转换

风险与限制清单

• 期限重置：交换后新 RI 重新起算 1/3 年期；请结合现金流与折旧周期
• 市场限制：Convertible 不可在 RI Marketplace 转售
• 供给限制：部分平台/租赁/区域的可用 OfferingId 可能不足
• 组合错配：分批交换期间要用 SP 或按需“兜底”以维持覆盖
• 会计处理：差额一次性计入当期支出（视会计政策）

计量与监控（KPI）

• 覆盖率：按实例家族/区域/平台分层统计（CoveredHours / TotalHours）
• 真实折扣率：1 – (Blended / OnDemand)
• 差额摊销：Exchange Delta / 新 RI 有效小时
• 间隙成本：交换窗口的未覆盖小时 × 按需价

实施监控：

• Cost Explorer：筛选 PurchaseOption = Reserved、OfferingClass = Convertible、分组 InstanceType/Region/Platform
• CUR 维度：reservation/ReservationARN、lineItem/UsageType、product/instanceType、pricing/term、pricing/operatingSystem

与 SP 的协同

• 原则：SP 兜底“通用基线”，RI 精准“家族/区域位”；交换期间用 SP 填补临时空档
• 风险控制：避免同时对同一基线做“双重承诺”；每次交换先评估 SP 覆盖重叠

常见问答（FAQ）

Q1：能把多个小 RI 换成一个大家族 RI 吗？

可以。Convertible 支持“合并”与“拆分”，只要目标价值 ≥ 剩余价值即可。

Q2：能把 Convertible 换成 Standard 吗？

不可以。两者体系不同，Convertible 只能与 Convertible 互换。

Q3：如何估算“剩余价值”？

不要手算，使用 get-reserved-instances-exchange-quote 的结果为准（AWS 账单引擎口径）。

Q4：交换会影响合并计费下的折扣传导吗？

不会改变 Organizations 的共享规则，但家族/区域/平台变化会改变折扣可以覆盖的用量集合，需要同步调整工作负载编排。

结论：Convertible RI 交换是应对架构与用量变化的强有力工具。通过“分批验证、等值为先、SP 兜底”的方法论，可以在保证现金流与稳定覆盖的前提下，持续优化成本结构。