预留实例（RI）是一种计费方式，并不是一种实例的类型，简单说就是一种”包年包月“的方式，通过RI我们最高可以获得相较于按需75%的优惠，进而降低您的云使用成本。您可能会说：“你说的这我都知道，并且RI我已经在用了。” 您真的会使用RI吗？
我们都知道预留实例（RI）类型分为两种 :标准RI 与可转换RI（CRI），可转换RI的价格往往较高而不容易被客户接受，而我们又经常遇到需要调整RI的需求，那么我们购买的标准RI能不能进行更加灵活的转换呢？答案是肯定的，AWS为满足客户的需求提供了很多灵活性的设定。标准RI在满足条件下可以灵活的进行匹配、以及进行灵活的合并拆分。
今天主要介绍一下RI的三个灵活属性：大小灵活性匹配，合并拆分，可转换(CRI)，我们暂且这么称呼，三者适用于不同的场景，是互相补充的关系。
大小灵活性匹配
（场景：区域范围RI 、相同实例类型、Linux/Unix ）
当您购买了区域性 Linux/Unix RI，将自动匹配正在运行的按需实例，折扣将立即适用于该实例系列中的实例使用，无论实例大小如何，直接上例子：
- 场景一
假设您在北京区域购买了一个 m5.2xlarge类型 OS为Linux/Unix 的标准RI，并且您的账户在该区域有两个m5.xlarge实例在运行 ,那么两个实例将完全匹配。
- 场景二
或者，如果您的账户在北京区域区域有一个 m5.4xlarge实例（ Linux/Unix），将匹配到 50% 的实例费用
- 场景三
那么，有同学可能有比较刁钻的场景：如果我的账户在该区域有个m5.4xlarge实例（ Linux/Unix）在运行 ,且当前我有一个 m5.2xlarge的标准RI，一个m5.larged的标准RI，我是否需要重新购买m5.4xlarge的标准RI以进行匹配？
这种场景下您的两个RI能够匹配到m5.4xlarge实例费用的75%，并且您只需再购买一个m5.larged的标准RI，这样就可以完全匹配，您无需重新购买m5.4xlarge的RI.
合并拆分
（场景：可用区范围RI）
既然大小灵活性匹配这么方便那么我们为什么要进行合并拆分呢，这里要提醒的是，大小灵活性匹配，如果我们购买可用区范围RI，那么我们将失去大小灵活性匹配优势，这时候RI合并拆分就派上用场了，废话不多说，直接上例子:
场景四
假设您在北京区域购买了两个 m5.2xlarge类型 OS为的cn-north-1a标准RI，由于计算需求改变，我们需要m5.4xlarge的实例以满足业务需求，那么我们可以将两个m5.2xlarge的RI合并成一个m5.4xlarge.
同样我们也可以将m5.4xlarge 进行同实例类型的大小拆分。
场景五
那么当前又回到上面的场景三 ，您在北京区域有个m5.4xlarge实例(AZ cn-north-1a 范围)在运行 ,且当前我有一个 m5.2xlarge的标准RI，一个m5.xlarge的标准RI，那么这种情况下能不能再购买一个m5.xlarge 的标准RI进行合并操作呢？这种情况下则无法通过购买m5.xlarge 标准RI合并为m5.4xlarge 标准RI。
这里就要提到标准RI拆分合并的限制：
标准预留实例的合并，必须在相同的时间过期，换句话说，也就是该批实例必须是同期采购的相同期限的RI。
可转换RI（CRI）
CRI在灵活匹配与合并拆分的基础上增加了更多维度可转换属性：实例类型、操作系统、租期、付款选项，当然价格可能可能上浮10个点左右。可以说CRI提供了最高的灵活可变性，几乎可满足所有的更变需求。唯一的限制：
新可转换预留实例的总价值（预付价格 + 每小时价格 * 剩余小时数）必须大于等于当前总价值！
换句话说客户只能在现有基础上加价，这种也是有道理，AWS 总不能因为您换了小规格实例给你退钱吧…
RI使用的一些建议
-
如果没有容量预留的需求不要选择可用区RI，否则将失去灵活匹配优势
-
针对业务计算需求增加需要调整实例类型机型（非license ） ，无需调整已购买的RI，只需要考虑增加合适RI，以进行自动匹配
-
针对AZ范围的Linux机器，因不适用灵活匹配，可进行同实例类型的合并拆分
-
针对实例类型，OS平台的修改等则需要可转换RI