亚马逊AWS官方博客

AWS 成本管理与优化之四:成本的可观察性

了解可观察性

可观察性的一个主要目的是实现度量和问责。您需要追踪每月成本、最高支出、以及趋势,并通过关注服务、账户、标签或类别等多个维度进行深入挖掘。您希望能够获得更精细的视图,并将其成本和使用量信息与其他数据源集成。这样,您就能够更好地管理自己的 KPI、建立内部计费模式,并提高整个业务的成本透明度,从而确保每个团队对其支出负责。

所有的优化思路都是从理解成本开始,然后增加使用成本的可见性以及透明度,理解成本主要从对账号和服务的使用开始:

理解账号

  • 组织内有哪些账号?
  • 哪些是成本支出大户?
  • 各账号费用的管理方式是什么?

理解服务

  • 组织内都在使用哪些服务?
  • Top 成本的服务是哪些?
  • 各服务使用的计价模式是什么?

常用工具

AWS 提供的多种工具和服务可以帮助您来完成上述目标,这些工具包括 AWS 账单和成本管理面板、Amazon Cost Explorer、成本和使用情况报告、成本分配标签和 Cost Categories 等 AWS 服务。在实际的操作中,您可以根据对成本和用量的粒度要求来选择合适的工具。

Amazon Cost Explorer

示例 1:理解各服务的使用成本

Amazon Cost Explorer 是使用最广泛的成本和用量查看工具,其主要功能包括:帮助您理解基于 AWS 服务的费用构成以及比例;帮助您理解各服务随时间变化的费用变动及模式;支持下载详细数据到本地及收藏常用查询;提供丰富的过滤条件,帮助您从多种维度来查看和分析成本及用量。

上图显示的是某个客户过去 12 个月的成本变化,我们选择了按服务来分组,可清楚的看到每个服务在过去一年里的变化,如果还需要更详细的数据来进行成本分析,还可以选择下载数据到本地。除此之外,在页面的右侧提供了多种筛选条件,您可以根据自己感兴趣的维度进行筛选。

Amazon Cost Explorer 在显示成本的时候,有多种成本的类型可供选择,在这里我们介绍两种最常用的类型:

未混合成本

该成本指标反映了当下(选定的时间段)的实际有效成本。

摊销成本

该成本指标反映了整个账单周期内分摊的预付和月度预订费用的有效成本。

示例 2:基于用量的预测

Amazon Cost Explorer 支持预测,它使用机器学习和基于规则的模型来预测每日或每月的成本和使用情况。这是对历史数据的线性推断,给出了 80% 的置信区间。您可以按任何 Cost Explorer 过滤条件进行预测,例如账户、成本分配标签或特定 AWS 服务。

成本分配标签

在前面章节中,我们已经介绍了什么是成本分配标签和它的重要性,在本节就不再赘述。在成本分配标签的实施过程中,最重要的内容就是成本分配标签的标准化和持续管理。在决定使用成本标签之前,需要现根据标签的最佳实践来定义标签的键和值内容,在这个阶段需要遵循之前提到的最佳实践:将成本分配标签与财务报告维度保持一致,并标记一切资源。比如:可以按照业务方向、业务部门、项目名称、产品归属、开发团队、环境划分、时间周期等来定义标签的键和值,如下是一个可供参考的例子:

示例 3:标签设计样例

Tag Key 描述 Tag Value 示例
Name 以下标签的组合 Environment-Region-Department-Module-Resource-Owner
Department 部门名称 BACKEND, FRONTEND, OPS
Resource 资源名称 S3, SG (Security Group), MSK, EMR, EC2, REDIS 等 AWS 资源
Module 模块名称/项目名称 COMMON, USER, PAY, 等
Environment 环境 PRD, STG, DEV, TEST
Owner 资源所有者 xxxx (xxxx@company.com)

当设计好标签以后,如何才能确保所有的人员遵守规则,正确的给所有资源打上标签呢?除了在您内部制定相应的要求规范以外,更有效率的方式还是借助于 AWS 提供的相关工具来实现成本分配标签的标准化和持续管理。

Amazon CloudFormation

使用 CloudFormation 资源标签属性, 可在创建某些类型的资源时对其应用标签。

IAM 策略

使用条件键,例如 aws:RequestTag 和 aws:TagKey, 可以在特定标签值不存在的情况下防止创建相关资源。

Amazon Organization 标签策略

使用此功能,您可以在 Amazon Organizations 中定义有关如何针对您账户中的 AWS 资源使用标签的规则(包括其大写处理方式以及允许的标签值)。借助标签策略,您可以轻松通过标准化的方法来标记 AWS 资源。

Amazon Config 规则

使用 Amazon Config 托管规则检查资源是否符合您指定的标签规则,并将不符合规则的资源筛选出来,同时也可以添加相应的操作对不符合标签规则的资源进行自动修改的动作。

Amazon Resource Groups 标签编辑器

可以搜索要标记的资源。然后,可以在搜索结果中添加、删除或编辑资源标签。实现批量对资源标签进行管理。

AWS 成本和用量报告

AWS 成本和使用情况报告(CUR)包含了全面详尽的成本和用量数据。这些数据每天更新多次,是精细到资源 ID 粒度的账单信息,支持成本分配标签,并能显示 SP/RI 应用明细。这些数据以多种文件的形式存储在 S3 桶中,可以借助 Athena 服务来进行查询和过滤,同时也支持集成第三方的查询和商业分析工具。

示例 4:分析并洞察成本

背景

某客户发现其 2 月 7 号的成本相比前一天有一个明显的上升,希望对成本进行分析,找出成本上升的原因。比如:成本上升来自哪个服务?成本上升来自哪个部门?哪种服务的实例或者使用类型增加了成本?哪些具体的资源造成成本的上升?

过程

让我们从背景描述里提取一下关键词:服务?部门?实例?适用类型?具体资源?这些关键字对应的正是成本和用量的粒度,对于不同粗细的粒度可以选择不同的 AWS 服务来实现,在这里,我们需要结合 Amazon Cost Explorer、成本分配标签以及 AWS 成本和用量报告来分析和洞察成本。

  • 查看 Amazon Cost Explorer, 按服务对每天的成本进行分组,发现每日成本的上升主要来自 EC2 服务的成本增加。

  • 过滤出 EC2 实例的成本,并按照成本分配标签 Department 对成本进行分组,发现 EC2 服务的成本增加来自名为 REC01 的部门。

  • 设置标签 Department 的筛选条件为 REC01,并按照实例类型对成本进行分组,发现 9xlarge 和 m5.4xlarge 的成本有明显升高。

  • 在 Athena 控制台运行如下 SQL,查找出成本异常时间段内所有的 EC2 资源ID,这样我们就能将成本的增加与具体的资源对应起来了。要实现这部分的功能,需要客户事先启用 AWS 成本和用量报告,并配置好 Athena 服务。
SELECT date(line_item_usage_start_date) AS date,
line_item_resource_id,
line_item_product_code,
product_region,
sum(line_item_normalized_usage_amount) AS usage,
sum(line_item_unblended_cost) AS costs,
product_instance_type
FROM "customer_cur_data"."cur_xxxxx"
WHERE line_item_usage_start_date >= timestamp '2022-02-06 00:00:00' and line_item_usage_start_date <= timestamp '2022-02-07 23:59:59'
AND resource_tags_user_department = 'REC01'
AND line_item_product_code = 'AmazonEC2'
AND product_instance_type = 'c5.9xlarge'
OR product_instance_type = 'm5.4xlarge'
GROUP BY line_item_resource_id, product_region, line_item_product_code, date(line_item_usage_start_date), product_instance_type
ORDER BY date(line_item_usage_start_date), line_item_resource_id, product_region, line_item_product_code, product_instance_type

云智能仪表盘

对于一个企业来说,不同的云参与者因为其角色的不同,对于成本的关注点也不尽相同。尽管 AWS 提供了诸多的工具和服务来帮忙客户去理解成本、分析成本和洞察成本,但是对于您的有些需求并不是随手可得的,还是需要您利用这些工具对大量繁杂的成本和用量数据做一些客制化的分析才能获得。特别是对一些 C-Level 的领导者来说,如何快速的将成本和用量数据通俗易懂的展现在其眼前,并提供一些洞察数据的建议就显得至关重要。

为了能满足您的这些高级需求,AWS 推出了云智能仪表盘的工具,云智能仪表盘是一系列构建在 AWS 原生服务之上的 QuickSight 仪表盘,该方案的数据来源是 AWS 成本和用量数据,赋予客户对其成本和用量数据的精细洞察力。这些仪表盘可以帮助您推动财务问责制、优化成本、跟踪使用目标、实施最佳治理实践,并最终实现卓越运营。其主要特点如下:

  • 使用方便
    • 洞察/见解通俗易懂
    • 按 AWS 服务类别组织
  • 安全
    • 支持 IAM
    • 不需要安装任何代理
    • 数据保留在客户账户
    • 全部使用 AWS 原生服务
  • 深入
    • 支持多达 100 多种内置视图
    • 精细化到具体的资源粒度
    • 完全可定制化
    • 基于机器学习提供见解和洞察
  • 成本低廉
    • 相关服务费用每个月大概几十美金
    • 无服务器架构:按使用付费

上图展示的是云智能仪表盘的基本框架:其数据来源是 AWS 成本和用量报告,数据的筛选、处理和加工主要是通过无服务器架构的 Athena 和 Glue 来完成,最后使用 AWS QuickSight 构建各种的仪表盘,用户只需要打开 QuickSight 仪表盘就能看到各种成本和用量的视图,同时也能获取针对不同视图的洞察见解。

示例 5:成本和用量智能仪表盘

CIO 、CTO、DevOps 和 IT 组织的领导者或其他个人都可以从云智能仪表盘中获得洞察见解。 在本节中,我们主要以成本和用量智能仪表盘为例,成本和用量智能仪表盘开箱即用,是一种交互式、可定制且可方便访问的 QuickSight 仪表盘,既可以用来可视化成本和用量,同时也提供了实时的优化建议,有助于为客户做好成本管理和优化,并可帮助客户做好各种与成本和用量相关的报告工作。主要优势包括(但不限于):

  • 使用内置标签资源管理器按标签对成本和使用情况进行分组和过滤,为每个标签、帐户、业务线、成本中心等构建动态和自定义的成本和用量报告。
  • 查看资源级别的详细信息,例如您的每小时 Amazon Lambda 或单个 Amazon S3 存储桶成本。
  • 获取有关服务级别的详细信息,例如按成本对前 3 位的按需数据库实例进行排名。
  • 提供按服务类别分组的多种视图,例如提供针对数据流量费的视图,可以帮助客户从整体上了解其各种数据流量费的来源和优化建议。

云智能仪表盘有多种不同类型的仪表盘组成,除了上文提到的成本和用量智能仪表盘,还包括:

Trusted Advisor (TA) 仪表盘

Amazon Trusted Advisor 可帮助您优化 AWS 基础设施、提高安全性和性能、降低总体成本并监控服务限制。该仪表盘可让您查看您的 Amazon Organizations 中所有账户的 Trusted Advisor 检查。TA 仪表盘是一组可提供整个 AWS 组织的全面详细信息和趋势的可视化视图。 其优势包括(但不限于):

  • 快速找到尚未轮换 Amazon IAM 密钥的账户。
  • 筛选并按成本或帐户对未使用和未充分使用的资源进行排序。
  • 监控各个账户的服务配额是否达到限制。

KPI 仪表盘

KPI 仪表盘可帮助您的组织将 DevOps 和 IT 基础设施与财务支出相结合,目的是为了帮助企业在 AWS 上更高效地发展。此仪表板可让您设置和跟踪优化目标,例如 OnDemand 百分比、Spot 采用率和 Graviton 使用率。KPI 仪表板的开箱即用优势包括(但不限于):

  • 跟踪所有团队使用的按需资源百分比。
  • 在满足企业目标的前提下,挖掘潜在的节省机会。
  • 快速定位可能成本节省方向。比如:不经常被访问的 S3 桶、过期可被删除的 EBS 备份和可以用 Graviton 机型来替换的资源。

Compute Optimizer 仪表盘 (COD)

COD 可以帮助企业可视化和跟踪来自 Amazon Compute Optimizer 的优化建议。这些建议可以用来:

  • 识别过度预置的资源,并给出成本优化方案。
  • 识别预置不足的资源,及时了解潜在风险。

除了上面介绍的几种仪表盘,云智能仪表盘还提供了如下两种仪表盘可以帮助客户更深入的分析和洞察相关成本,同时还有一些其他的仪表盘正在开发中。

  • 数据传输仪表盘
  • 趋势仪表盘
  • ……

总结

本文首先介绍了什么是成本的可观察性,进而通过一些工具的介绍来指导您去实现成本的可观察性,成本的可观察性是实现成本管理和优化的基础,通过可观察性可以帮助您更好的理解成本,最终实现成本管理和优化的目的。

本篇作者

朱修磊

亚马逊云科技技术客户经理,负责企业级客户的架构和成本优化、技术支持等工作,拥有多年的产品研发、技术布道、IT 架构设计和运维经验。