一、预留实例的计费逻辑

在一份账单中占比最大的部分可能就是EC2，EC2部分也包含了诸如EKS集群使用的node节点等用量。在部分机型是On-demand按需运行，部分机型是有多个RI预留时候，账单可能显示的比较复杂，晦涩难懂。那么如何解读账单中体现的EC2用量呢？本文以某个场景为例进行分析和解读。在开始解读账单之前，首先要看下RI预留实例的计费逻辑。

AWS云上计费方式灵活的体现之一就是RI预留实例。预留实例是按照同一个EC2机型资源池化计算的。例如，本月运行了2台m5.2xlarge，那么购买预留预留实例时候可以购买1台m5.4xlarge的预留实例，也可以分别购买2台m5.2xlarge预留实例，也可以购买4台m5.xlarge，只要他们的总量相等就可以实现完全匹配。此外，是否全预付、还是无预付，只是财务付款手段，与实例资源匹配（抵扣）情况无关。

在同一个机型池化计算RI匹配的同时，还允许用户灵活升降配，升降配和新开资源产生的超期使用，将按照独立的按需实例付费。例如，用户之前购买了1台m5.4xlarge的RI预留实例，实际情况是从月初就运行2台m5.2xlarge。如果什么变化都不做，那么本月会实现RI和实际资源的完美匹配。但是，某一天（例如20日）用户将其中1台变更了配置从m5.2xlarge提升到m5.4xlarge；然后在25日又新增了第3台m5.xlarge机型。此场景下如何计费呢？

我们看下由此产生的变量，20日做变更时候，从2xlarge提升到了4xlarge，这就造成了原先的RI覆盖不足。原来两个EC2加起来总量恰好是4xlarge，实现完美匹配的。这次变更配置，比原来的RI多出来了2xlarge的用量，这部分用量从20日开始到月底结束，多出来了10天2xlarge的用量。然后，在25日做变更时候，又新增了一台m5.xlarge，也是不在RI覆盖范围的，这部分将产生5天的用量。最后本月总账单将会是RI预留实例m5.4xlarge全月的费用，加10天m5.2xlarge按照On-demand按需账单费用，加5天m5.xlarge按照On-demand按需账单费用的。就是账单总和。

如果觉得这部分复杂，可参考AWS成本管理器里边的RI匹配功能，可自动计算RI是否覆盖完整，并建议采购新的RI预留实例。

搞明白了RI逻辑，现在开始分析账单。

二、账单示例

我们以以下的账单为例，将其中划分为标记（1）、（2）、（3）的三个区域，分别对应不同按需实例（On-demand，简称OD）、全预付预留实例（全预付RI）、无预付预留实例（无预付RI）共三种计费方式。

标记绿色划线的两个区域虽然分别隶属2和3两种不同RI预付方式，但是他们是同一种资源池（EC2 m5机型），因此最终匹配RI预留实例是按照合并同类项后进行的抵扣。如下截图。

三、详细解读

这里按照是否是预留实例（RI）以及是否是池化的资源匹配程度来分别解释。

1、按需实例部分

在以上账单中，带有如下标签的表示按需机型的Linux机型：

Amazon Elastic Compute Cloud running Linux/UNIX             ¥2,933.59
3.943 CNY per On Demand Linux c5.4xlarge Instance Hour.     744.000 Hrs     ¥2,933.59

这一台是Windows机型（价格含License）：

Amazon Elastic Compute Cloud running Windows                ¥1,060.20
1.425 CNY per On Demand Windows r5a.large Instance Hour.    744.000 Hrs     ¥1,060.20

以上这两行表示目前这两台EC2分别运行了满一个月。使用量744小时即表示24小时x31天=744小时。前边的数字价格表示每小时单价，例如c5.4xlarge在宁夏区域的单价是3.943元/小时，r5a.large的Windows机型在宁夏区域的单价是1.425元/小时。这个价格可以在AWS官网查询。

2、单一机型完全匹配的RI部分

这一部分比较好处理，因为在账单截图中标记为（2）的部分且画了红色框的部分，是单一机型完全匹配，这部分最好解读。例如以下这两行账单：

CNY 0.0 hourly fee per Windows (Amazon VPC), r5a.large instance                                     1,488.000 Hrs       ¥0.00
CNY 0.0 per Windows (Amazon VPC), r5a.large reserved instance applied, r5a.large instance used      1,488.000 Hrs       ¥0.00

开头的0.0表示这是一个全预付的预留实例，也就是在购买RI的第一个月就付清了后续所有月份的款项，后续的12个月或36个月的有效周期内，本资源继续有效，但是本月账单就是显示为0了，因为第一个月就付了所有费用。

每一个RI都有两行信息：

• 第一行是显示本RI的机型，数字1488.00小时表示本规格的2台，也就是每月1台是744小时。计算逻辑是24小时x31天=744小时，再乘以2台即744小时x2台=1488小时。由此就能看到，r5a.large总计买了2台全预付，本月在有效期内。
• 第二行是显示RI的使用率情况。买了RI后，系统会在月末把相同资源机型的归集汇总进行匹配。r5a.large reserved instance applied这一句表示当前要匹配的RI型号，r5a.large instance used表示实际匹配上的机型。最后显示的小时数是1488.00小时，和RI折算31天后的小时数匹配。

以上信息可以看到两个完全匹配：一是购买RI和实际开机的EC2机型大小完全匹配，二是使用小时数完全匹配。那么，有无可能出现以上两种情况都不完全匹配的呢？下文进行讲解。

3、按池化资源匹配的部分

前文提到过，付款方式是否全预付还是无预付只是财务付款手段，与实例资源匹配（抵扣）情况无关。不过我们依然先来看账单中一个无预付的信息。

CNY 1.683 hourly fee per Linux/UNIX (Amazon VPC), m5.4xlarge instance   744.000 Hrs     ¥1,252.15

以账单截图中标记为（3）的这一行为例，这是一个无预付的预留实例，每小时费用是1.683，全月744小时，费用1251.15元。这个信息可以在官网中功能获取，例如官网标价中的如下信息可对应到1.683元/小时。如下截图。

通过以上截图可以看到，m5.4xlarge一年无预付RI预留实例，折算每小时1.683元。网页截图中红线标记的部分每月价格显示显示1228.59元每月，而账单又显示为744小时1251.15元，这两个数字不相同。这又是什么原因呢？这是因为官网给出的每月参考价格是按照平均每月730小时（30.417天）计算的，而实际每月有30天也有31天，也有28天、29天，因此每月的运行小时数可能不是744小时，而是720小时或者更小。由此可以看到本文已开始的截图是一个大约（即31天），总小时744小时，RI总计费用1251.15元。

对照清楚了无预付RI，现在我们来按照池化来看下m5机型的RI的匹配。本文开始的账单里边有多个m5机型RI，他们分别是

CNY 0.0 hourly fee per Linux/UNIX (Amazon VPC), m5.xlarge instance      1,488.000 Hrs   ¥0.00
CNY 1.683 hourly fee per Linux/UNIX (Amazon VPC), m5.4xlarge instance   744.000 Hrs     ¥1,252.15

前文我们获得知识可知，1个月31天是744小时，1488小时等于2个744，也就是2台运行满整个月。那么以上RI可以看到是2台xlarge的RI加上1台4xlarge的RI，总量等于6xlarge的RI。

算清楚获得了用量后，再看现有资源的累积。

CNY 0.0 per Linux/UNIX (Amazon VPC), m5.xlarge reserved instance applied, m5.4xlarge instance used  372.000 Hrs
Linux/UNIX (Amazon VPC), m5.4xlarge reserved instance applied, m5.2xlarge instance used 744.000 Hrs
Linux/UNIX (Amazon VPC), m5.4xlarge reserved instance applied, m5.4xlarge instance used 372.000 Hrs

以上信息每一条都包含了2个部分，前半部分是xxx reserved instance applied表示与某个RI匹配可以计入资源池，后半句xxx instance used表示本台EC2使用的部分。我们对以上信息做汇总求和可以看到，第一行m5.4xlarge 372小时（372=0.5×744，即半个月），第二行m5.2xlarge一整个月，第三行m5.4xlarge 372小时。加起来是1台2xlarge一个月和1台4xlarge一个月，总计6xlarge一个月。这个信息，与上边核算已经购买RI的总量相等。

根据以上对池化资源的分析，RI购买规格合理，当前资源使用与RI完全匹配。

三、小结

本文介绍了RI的资源池化逻辑，主要是面向分析用户账单与实际使用情况进行交叉对照的场景。如果觉得测算逻辑复杂，建议直接访问AWS控制台上的成本管理器，通过成本管理器的预留实例建议来快速的查看RI匹配程度最为便捷。

四、参考文档

中国区EC2价格：

https://www.amazonaws.cn/ec2/pricing/ec2-linux-pricing/?nc1=h_ls

成本管理器预留实例建议

https://docs.aws.amazon.com/zh_cn/cost-management/latest/userguide/ri-recommendations.html