基于AWS Cloud Intelligence Dashboards 的定制实践分享

摘要

随着企业云上业务规模的持续扩大，云成本和效率治理（Cloud Financial Management，CFM）越来越成为 CIO / CFO / FinOps 团队关注的重点。AWS Cloud Intelligence Dashboards（CID）为客户提供了一套基于亚马逊云科技原生服务的标准化成本可视化解决方案，但在真实项目中，往往需要结合企业自身财务制度、业务组织结构以及治理目标进行深度定制。

本文以实际项目实践为例，介绍如何在标准 AWS CID 的基础上，通过 Athena 视图、账户映射表、QuickSight 计算字段和自定义图表，实现财年视角的成本对比分析，以及「以 FY25 为基准，FY26 目标成本为 90%」的精细化成本治理方案，帮助业务和财务团队在一个统一的仪表盘上对齐目标、跟踪偏差和驱动优化行动。

一、AWS Cloud Intelligence Dashboards 简介

1.1 方案概述

AWS Cloud Intelligence Dashboards（CID）是一套基于亚马逊云科技原生服务（Cost & Usage Report、Amazon Athena、Amazon QuickSight）的可视化解决方案，旨在帮助客户实现云成本和使用的可视化、分析和优化。该方案包含多个标准仪表盘：

CUDOS（Cost & Usage Dashboards）：提供成本和使用的多维度分析，包括账号、服务、Region、标签等维度拆解
CID（Cloud Intelligence Dashboards）：专注于成本智能分析和优化建议
KPI Dashboard：提供关键绩效指标的可视化，例如 RI/SP 覆盖率、利用率等

这些仪表盘可以单独使用，也可以组合使用，为企业提供从概览到细节的全方位成本治理视角。

1.2 为什么需要高级定制

按照官方指导文档部署完成后，客户即可获得一套开箱即用的成本治理仪表盘，非常适合作为企业云成本治理的「统一起点」。

但现实情况中，很多企业有自己独特的治理诉求，例如：

使用「自定义财年」（例如从每年5 月开始）而非自然年
希望对比「上一财年实际」和「当前财年目标」，而不仅是历史趋势
需要将亚马逊云科技账号映射到公司内部的业务单位、团队、成本中心等维度
需要将标准仪表盘中的指标「产品化」，用于管理层例会汇报
需要结合企业特定的成本分摊规则和预算管理流程

这些诉求都需要在标准 AWS CID 的基础上进行深度定制，本文分享的定制方法可以灵活应用于 CUDOS、CID、KPI 或任何自定义仪表盘中。

二、业务背景与目标：从”看成本”到”对齐目标”

在实际项目中，许多企业的云成本治理面临以下特点：

**使用自定义财年**：财年从每年 5月开始，到次年 4 月结束（例如 FY25 为05 – 2025.04）
**管理层关注财年成本目标**：关注的是「财年成本是否按照预算和降本目标推进」，而不仅是「月度账单」
**目标设定**：FY26 的目标是相比 FY25 成本整体下降 10%，即 FY26 预算控制在 FY25 的 90%

因此，单纯展示「每月成本趋势」已经不足以支撑管理决策。我们需要：

按自定义财年维度重新组织成本数据
计算 FY25 / FY26 的财年成本，并进行逐月对比
将 FY26 目标曲线（90% of FY25）明确可视化
为 FinOps 团队和业务团队提供「清晰且可操作」的视图——例如看到超出目标的月份，进一步 drill down 到账号/团队/服务

这也正是本文所分享的高级定制方案的核心目标。

三、技术架构概览：基于 CID 的扩展设计

整体方案仍然基于官方 AWS Cloud Intelligence Dashboards 架构：

数据源：Amazon Cost & Usage Report（CUR），存储在 Amazon S3
查询层：Amazon Athena，基于 CUR 建立一系列视图（Views）
可视化层：Amazon QuickSight，使用 CUDOS 模板并在其基础上进行定制

在这个定制方案中，我们主要实现了以下几类扩展，这些方法可以灵活应用到 CUDOS、CID、KPI 或其他自定义 Dashboard 中：

**数据层定制（Athena 视图）**：创建 `cost_weekly` 等自定义视图，按周 / 月/财年维度聚合成本数据
**业务维度映射（账号映射表）**：构建 `account_map` 视图，将技术账号映射为业务语言
**计算逻辑定制（Amazon QuickSight 计算字段）**：

– 生成自定义财年逻辑：MoMComparison_FiscalYear

– 创建月份显示和排序字段：MoMComparison_Month、MoMComparison_MonthNum

– 计算多财年对比指标和目标值（如 FY26 目标 = FY25 × 90%）

**可视化定制（自定义图表）**：构建组合图（Combo Chart），展示实际 vs 目标的多维对比

这些定制方法的关键优势在于：它们不改变 AWS CID 的核心架构，而是通过数据层和展示层的扩展，让标准仪表盘更贴合企业实际需求。

四、数据建模：在 Athena 中构建成本与账号视图

4.1 按周粒度的成本视图 `cost_weekly`

在实际项目中，除了标准的月度和日度成本视图，客户还希望能够按周维度进行成本分析和趋势监控。为满足这一需求，我们在 Athena 中创建了一个按周汇总的成本视图。该视图将 unblended cost 和 amortized cost 聚合到 week 级别，并保留账期和账号信息，方便后续在 QuickSight 中进行周级别的可视化分析。

CREATE OR REPLACE VIEW "cost_weekly" AS 
SELECT
  date_trunc('week', line_item_usage_start_date) week_start
, year(line_item_usage_start_date) year
, week_of_year(line_item_usage_start_date) week_num
, CONCAT('W', lpad(CAST(week_of_year(line_item_usage_start_date) AS varchar), 2, '0')) week_label
, bill_billing_period_start_date billing_period
, bill_payer_account_id payer_account_id
, line_item_usage_account_id linked_account_id
, sum(line_item_unblended_cost) unblended_cost
, sum((CASE WHEN (line_item_line_item_type = 'SavingsPlanCoveredUsage') THEN savings_plan_savings_plan_effective_cost WHEN (line_item_line_item_type = 'DiscountedUsage') THEN reservation_effective_cost ELSE line_item_unblended_cost END)) amortized_cost
, SUM((CASE WHEN ("line_item_line_item_type" = 'SavingsPlanRecurringFee') THEN (("savings_plan_total_commitment_to_date" - "savings_plan_used_commitment") * COALESCE((COALESCE("line_item_net_unblended_cost", "line_item_unblended_cost") / NULLIF("line_item_unblended_cost", 0)), 1)) WHEN ("line_item_line_item_type" = 'RIFee') THEN COALESCE(("reservation_net_unused_amortized_upfront_fee_for_billing_period" + "reservation_net_unused_recurring_fee"), ("reservation_unused_amortized_upfront_fee_for_billing_period" + "reservation_unused_recurring_fee")) WHEN ("line_item_line_item_type" = 'SavingsPlanCoveredUsage') THEN COALESCE("savings_plan_net_savings_plan_effective_cost", "savings_plan_savings_plan_effective_cost") WHEN ("line_item_line_item_type" = 'DiscountedUsage') THEN COALESCE("reservation_net_effective_cost", "reservation_effective_cost") WHEN (("line_item_line_item_type" = 'Fee') AND (COALESCE("reservation_reservation_a_r_n", '') = '')) THEN COALESCE("line_item_net_unblended_cost", "line_item_unblended_cost") WHEN ("line_item_line_item_type" IN ('Usage', 'Tax', 'Credit', 'Refund')) THEN COALESCE("line_item_net_unblended_cost", "line_item_unblended_cost") ELSE 0 END)) "net_amortized_cost"
FROM
  cid_cur.cur2_proxy
WHERE (line_item_usage_start_date >= date_add('month', -24, date_trunc('month', current_date)))
GROUP BY 1, 2, 3, 4, 5, 6, 7

这个视图的几个关键点：

使用 `week_of_year` 和 `week_start` 提供周维度信息，便于在 Dashboard 中构建周级趋势图
`unblended_cost` 与 `amortized_cost` 同时保留，支持「现金账单视角」和「摊销成本视角」
WHERE 条件将数据限制在最近 24 个月，兼顾历史分析和查询性能
这种按周聚合的方式可以根据实际需求调整，例如改为按日、按月或按自定义时间粒度

4.2 账号映射视图 `account_map`

为了让仪表盘更贴近业务，我们需要将亚马逊云科技账号映射到公司内部的业务维度，如 Business Unit、Team、Cost Center、Environment 等。

根据 AWS CID 官方指南，账号名称映射提供了三种方式：

**使用 Amazon Organizations API**：自动从 Organizations 获取账号名称
**使用 Amazon Account ID Mapping Lambda**：通过 Lambda 函数动态映射
**使用 CSV 文件上传到 S3**：手动维护账号映射表

在实际项目中，我们推荐使用 CSV 文件方式，原因如下：

更大的定制空间：除了账号名称，还可以添加 Business Unit、Organizational Unit（OU）、Team、Cost Center、Environment 等企业特定的业务维度
灵活的映射逻辑：可以将多个亚马逊云科技账号映射到同一个业务单元，或者建立账号与 OU 的多层级关联
易于维护：通过 CSV 文件，业务团队可以直接参与维护，无需技术背景
版本控制：CSV 文件可以纳入 Git 等版本控制系统，追踪历史变更

以下是一个基于 CSV 文件的账号映射视图实现：

CREATE OR REPLACE VIEW "account_map" AS
SELECT DISTINCT
  a.line_item_usage_account_id "account_id"
, b.account_name
, b.business_unit
, b.organizational_unit
, b.team
, b.cost_center
, b.environment
, b.domain
, b.cx_code
, b.identity
FROM
  (
    SELECT DISTINCT line_item_usage_account_id
    FROM cid_cur.cur
  ) a
LEFT JOIN (
   SELECT DISTINCT
     lpad("account_id", 12, '0') "account_id"
   , account_name
   , business_unit
   , organizational_unit
   , team
   , cost_center
   , environment
   , domain
   , cx_code
   , identity
   FROM cid_cur.account_mapping
) b ON (b.account_id = a.line_item_usage_account_id);

通过在QuickSight 的数据集层面将 cost_weekly 与 account_map 进行关联，我们就可以在任何 Dashboard（CUDOS、CID、KPI 或自定义仪表盘）中用业务语言进行分析，而不仅仅是「账号 ID」。这种基于 CSV 的映射方法具有很强的通用性和灵活性，可以在多个仪表盘间复用。

五、自定义财年与月份：QuickSight 计算字段设计

由于客户的财年从每年 5 月开始，我们需要在 QuickSight 中构建一个自定义财年字段 MoMComparison_FiscalYear，同时还需要用于展示与排序的月份字段。

5.1 自定义财年字段 `MoMComparison_FiscalYear`

下面的计算字段逻辑将账期 billing_period 转换为财年字符串，例如 2024.06 – 2025.05 对应 FY25：

MoMComparison_FiscalYear

concat('FY', substring(toString(
    ifelse(extract('MM', {billing_period}) >= 5,
        extract('YYYY', {billing_period}) + 1,
        extract('YYYY', {billing_period})
    )
), 3, 2))

核心思路：

如果账期月份 `>= 5`，则财年 = 年份 + 1（例如08 → FY26）
否则财年 = 当前年份（例如01 → FY25）
最后通过 `concat(‘FY’, …)` 生成类似 `FY25` 的字符串

5.2 月份显示与排序字段

为了在「财年内」正确排序月份，我们通常会构建两个字段：

`MoMComparison_Month`：用户看到的月份标签，例如 `Jun`, `Jul`, …

MoMComparison_Month

    ifelse(
        extract("MM", {billing_period}) = 01, 'Jan',
        extract("MM", {billing_period}) = 02, 'Feb',
        extract("MM", {billing_period}) = 03, 'Mar',
        extract("MM", {billing_period}) = 04, 'Apr',
        extract("MM", {billing_period}) = 05, 'May',
        extract("MM", {billing_period}) = 06, 'Jun',
        extract("MM", {billing_period}) = 07, 'Jul',
        extract("MM", {billing_period}) = 08, 'Aug',
        extract("MM", {billing_period}) = 09, 'Sep',
        extract("MM", {billing_period}) = 10, 'Oct',
        extract("MM", {billing_period}) = 11, 'Nov',
        extract("MM", {billing_period}) = 12, 'Dec',
        'Unknown'
    )

`MoMComparison_MonthNum`：用于排序的数值字段，例如 1, 2, 3… 对应财年内的顺序

MoMComparison_MonthNum

ifelse(extract("MM", {billing_period})=1, 9,
ifelse(extract("MM", {billing_period})=2, 10,
ifelse(extract("MM", {billing_period})=3, 11,
ifelse(extract("MM", {billing_period})=4, 12,
ifelse(extract("MM", {billing_period})=5, 1,
ifelse(extract("MM", {billing_period})=6, 2,
ifelse(extract("MM", {billing_period})=7, 3,
ifelse(extract("MM", {billing_period})=8, 4,
ifelse(extract("MM", {billing_period})=9, 5,
ifelse(extract("MM", {billing_period})=10, 6,
ifelse(extract("MM", {billing_period})=11, 7,
ifelse(extract("MM", {billing_period})=12, 8, 0))))))))))))

在实际项目中，会根据客户的实际情况定义这两个字段，确保在财年视角下的月份展示顺序从 6 月到次年 5 月。

六、FY25/FY26 高级对比：目标成本 = 去年 90%

在业务沟通中，客户希望有一个非常直观的图表：

X 轴：财年内的月份（按财年顺序排序）
柱状图（Bar）：FY25 实际 unblended cost
折线 1（Line）：FY26 实际 unblended cost
折线 2（Line）：FY26 目标成本 = FY25 的 90%

为实现这个需求，我们在 QuickSight 中设计了一组计算字段。

6.1 基础成本字段

在数据集中，我们先定义统一的成本字段，便于复用：

Cost_Amortized = sum({amortized_cost})

Cost_Unblended = sum({unblended_cost})

6.2 按财年分拆的成本字段

在提供的配置说明中，已经列出了几类关键字段，我们在 QuickSight 中具体实现如下：

FY25_Unblended_Cost = ifelse(
  {MoMComparison_FiscalYear} = 'FY25',
  {unblended_cost},
  null
)

FY26_Unblended_Cost = ifelse(
  {MoMComparison_FiscalYear} = 'FY26',
  {unblended_cost},
  null
)

6.3 FY26 目标成本（90% of FY25）

FY26 目标是以 FY25 为基准整体降低 10%。为了在图表中直观呈现，我们将 FY25 的成本乘以 0.9 作为目标线：

FY26_Target_Cost = ifelse(
  {MoMComparison_FiscalYear} = 'FY25',
  {unblended_cost} * 0.9,
  null
)

需要注意的是：

虽然字段名字是 `FY26_Target_Cost`，但我们在 FY25 的数据行上计算 0.9 倍的成本，用于作为下一财年的目标线
在图表中使用合适的图例名称和说明，避免用户混淆

配置文件中对这些字段的结构化描述如下：

字段名称	数据类型	聚合方式	用途
FY25 Unblended Cost	DECIMAL	SUM	财年对比图的柱状数据
FY26 Unblended Cost	DECIMAL	SUM	财年对比图的折线数据
FY26 Target Cost (90% of FY25)	DECIMAL	SUM	财年对比图的目标线

七、构建”最近两财年对比”组合图（Combo Chart）

在完成计算字段配置后，我们可以在现有的 AWS Cloud Intelligence Dashboards（如 CUDOS、CID 等）中创建或克隆一个视图，并按如下步骤构建高级对比图表。这个方法不局限于特定 Dashboard，可以根据实际需求灵活应用。

Step 1：创建或确认计算字段

确保以下几个字段已经在分析中创建：

`MoMComparison_Month`（字符串，用于 X 轴展示）
`MoMComparison_MonthNum`（整数，用于排序）
`FY25_Unblended_Cost`
`FY26_Unblended_Cost`
`FY26_Target_Cost (90% of FY25)`

Step 2：创建可视化（Combo Chart）

在 QuickSight 中：

**Visual Type**：选择 **Combo chart（柱状 + 折线）**
**X-axis**：`MoMComparison_Month`
**Sort**：按 `MoMComparison_MonthNum` 升序排序
**Bars**：`FY25 Unblended Cost`（聚合：SUM）
**Line 1**：`FY26 Unblended Cost`（聚合：SUM）
**Line 2**：`FY26 Target Cost (90% of FY25)`（聚合：SUM）

Step 3：图表设置优化

在 **Visual properties → Y-Axis** 中启用「**Single Y-axis**」，确保三条数据系列共用一个尺度，便于直观对比
使用不同颜色和线型区分：

– FY25：柱状图（蓝色）

– FY26：实线（绿色）

– FY26 目标：虚线或带明显标识（橙色）

- 在图例中添加简短说明，例如「FY26 目标 = FY25 × 90%」

配置文件中的 chart_usage 结构化描述如下：

{
  "visual_id": "2xxxxxx-23a8-45ab-xxxx-e7401a0428a8",
  "chart_type": "ComboChart",
  "category_field": "MoMComparison_Month",
  "sort_field": "MoMComparison_MonthNum",
  "bar_values": ["FY25 Unblended Cost"],
  "line_values": ["FY26 Unblended Cost", "FY26 Target Cost (90% of FY25)"],
  "description": "展示 FY25 实际、FY26 实际、FY26 目标的 month-over-month 对比"
}

八、实践经验与最佳实践总结

在这个AWS Cloud Intelligence Dashboards 高级定制项目中，有几个经验点值得总结，供参考：

1. 将复杂逻辑前移到 Athena 视图

财年划分、周维度聚合、账号映射等逻辑尽量在 Athena 层实现，QuickSight 只负责轻量级计算和可视化
这样可以提高复用性，也方便其他下游分析工具调用

2. 计算字段尽量语义化命名

例如 `MoMComparison_FiscalYear`、`FY26_Target_Cost (90% of FY25)` 等命名，让仪表盘配置人员和业务用户都一看就懂
在 JSON 或文档中对字段进行结构化说明（数据类型、用途、聚合方式），方便团队协作与后续维护

3. 打通账号与业务维度，提升可行动性

通过 CSV 方式将亚马逊云科技账号映射为 business_unit / organizational_unit / team / cost_center 等业务维度，能够让图表从「技术视角」升级为「业务视角」
CSV 方式提供了最大的定制空间，可以根据企业实际组织架构灵活添加自定义字段
当某个月成本超出目标时，FinOps 团队可以快速 Drill down 到某个 BU、OU 或某个应用团队，并协同制定降本计划

4. 在标准 Dashboard 基础上增量演进，而不是重造轮子

AWS Cloud Intelligence Dashboards（CUDOS、CID、KPI）已经提供了大量成熟的指标和最佳实践，不建议完全自建
在标准仪表盘基础上「克隆 + 定制」，可以更好继承官方迭代能力，同时满足企业个性化需求
不同 Dashboard 之间的定制方法可以互相借鉴和复用

5. 与业务共创指标和图表

FY26 目标设为 FY25 的 90% 并不是纯 IT 决策，而是由财务、业务、FinOps 和技术团队共同讨论后达成的
如果管理层对图表一目了然，并能从中获取可执行的行动项，这个仪表盘就真正发挥了价值

6. 利用配置文件管理复杂度

在本案例中，我们将所有计算字段、图表配置、数据关系等信息记录在一个结构化的 JSON 文件中（类似项目中的 cid-nike-calculated-fields.json），便于：

版本控制：通过 Git 跟踪配置变更
团队协作：新成员快速理解仪表盘设计逻辑
跨 Dashboard 复用：将相同的定制逻辑应用到 CUDOS、CID、KPI 或其他自定义仪表盘
环境迁移：快速将定制方案应用到不同客户或不同亚马逊云科技账号环境

九、总结

通过本文分享的高级定制方法，我们将客户的云成本治理从「事后看账单」升级为「围绕财年目标进行持续监控与优化」。在标准 AWS CID 的基础上，通过少量 Athena 视图、计算字段和可视化配置，就可以构建满足管理层诉求的精细化成本仪表盘。

获取完整方案

本文所述方案已在生产环境中验证并取得良好效果。如果您希望获取完整的技术方案、定制指南或进行技术交流，请联系您的技术客户经理。

参考资料

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

亚马逊AWS官方博客