1 引言

“降本增效”无疑是现在各个公司的主要任务与常见手段，而云商降本是我的主要任务，但降本走到一定程度就很快走到了瓶颈，而且没有数据支撑很难做出正确的决策，还有一个重要的问题，运维数据对细粒度的成本原因并不明确，导致成本也是一路上涨，为此基于现状重新对 AWS 的账单进行对账，寻找真相，数据的准确性是实现 Finops 的基石。

2 拥抱 CUR（Cost & usage reports）

目前 AWS 提供了两种查询账单的方式，分别是 Cost Explorer(CE) 与 Cost & usage reports (CUR)，对比如下：

由于目前的需求是要进行细粒度的分析，通过表格的分析对比，所以“CUR”明显符合需求，重要的是我会 SQL，相对 API 调用方便多了，并且可以减少 API 的聚合数据所带来的错误。

AWS 的数据(无论 CE/CUR)还有一个严重的问题：

各 usage type(SKU)的抵扣并不准确，一般公司与 AWS 会签署的合同价格，最终通过返还 Refund 与 Private Rate Card Discount（PPA）进行抵扣，但这些抵扣并不能真正提现每个 SKU 的抵扣，可能是 A 的 SKU Refund 去到 B 的 SKU Refund，这样导致摊分后的误差更大。

为此 3 月份开始 AWS 已在 CUR 进行改进，添加 EDP_discount，private_rate_discount，total_discount 等各参数，用于标记各个细粒度的抵扣情况，但不一定准确。

3、SKU 自核算

为了清晰看到各个 SKU 的抵扣是否有误，目前方案是实现了一个收集器对 CUR 数据进行拉取，计算折扣。

其目的在于可以基于准确的折后成本，分析各部门与各成本的分布。

以下是实现的架构图：

实现：

• DB 记录了合同的所有折扣

• 收集器通过 DB 获取折扣信息，再对 Athean 获取 CUR 数据，对每个 SKU 进行折扣运算后存储在 DB 中

• 用户可以通过 SQL 直接看到每个 SKU 的折扣后成本，也可以用于数据分析

• 减少对 Athean 的查询频率依赖，降低成本

难点：

• 要熟悉签署合同的折扣

• 设计通用的折扣模型，减少代码的不断修改

• 设计 DB 记录的数据内容，并且要保证其查询性能

• CUR 的数据大，拉取时间长，这个问题同样困扰了我好久，最终我是通过写聚合数据解决，首要解决的是要聚合什么数据（例如 SKU），目前数据按天，拉取一个月数据大概花费 3 个小时，完全满足需求

• 怎样回索，当发现本地数据与 CE 的总额对不上自动回索，这里可以设置校验频率，减少回索的次数，节省成本。

4、收益

该系统开发以来，每个月给财务核账时都会核查自检，体现了它存在的价值与收益：

• 目前该系统进行核算，已发现 AWS 算错的折扣已经高达到好几万刀，并且一一追回。

• 公司与云商每过一段时间就会签署一份新的合同，所以只需要对 DB 的折扣进行更改，即可自动运算，提高效率，减少重新开发的时间，并且可以支持多账号与 payer 账号。

• 每当签署新的合同都可以进行估算，应用新合同的节省是否符合预期

• 体现成本上涨的原因，例如 AWS 的 Credit 分折前折后的，并不是所有都是折后，并且 CE 与 CUR 都没有体现（我也涨认知了!）

• 可以推动 AWS 账单更规范，分摊更明确

最后

云商对账是一件复杂与繁琐的工作，并且要对数据有敏感的嗅觉才能发现问题，为此该系统实现能准确成本的有效分摊，方便用户更加准确寻找成本上涨的原因。目前已经与阿里云紧密合作，尽快支持阿里云。

如果想了解更多关于成本的问题，可以登录https://www.spotmaxtech.com/与我们联系。