如何读懂一份AWS账单的EC2预留实例匹配关系

一、预留实例的计费逻辑

在一份账单中占比最大的部分可能就是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