2. 成本治理基础

成本治理不是“月底看一张账单”，而是把云支出变成可观测、可归因、可干预的持续过程。在 AWS 上，这个过程依赖三类能力：可见性工具（Cost Explorer、Budgets、Cost and Usage Report）、归因机制（标签策略与成本分配标签）、以及分摊方法（把共享成本拆到团队、项目或业务线）。三者缺一不可：没有可见性就发现不了问题，没有归因就找不到责任人，没有分摊就无法做内部结算和决策。

三类核心工具的定位差异

很多团队把这三个工具混着用，结果既慢又贵。它们的定位其实非常清晰：

• Cost Explorer（CE）：交互式探索与趋势分析。适合回答“过去 3 个月哪个服务涨得最快”“按标签分组的日成本曲线是什么样”。它提供按服务、区域、账户、标签、使用类型等维度的筛选与分组，并支持预测。默认保留 12 个月历史，粒度到日（部分维度可到小时）。
• AWS Budgets：阈值监控与告警。适合回答“本月支出超过 8000 美元时通知我”“EC2 月度成本预测将超过预算的 80% 时告警”。它支持成本预算、用量预算、RI/SP 覆盖率与利用率预算，可绑定 SNS 主题或 Chatbot 推送到 Slack/邮件。
• Cost and Usage Report（CUR）：最细粒度的原始账单数据。它以 CSV/Parquet 形式按小时或按天投递到 S3，包含每一笔用量、费率、折扣、摊销、RI/SP 分摊等字段，是 Athena/QuickSight/Redshift 做自定义成本分析的事实来源。CUR 是“明细账”，CE 是“查询界面”，Budgets 是“报警器”。

标签策略：让成本可归因的前提

标签是成本归因的骨架。AWS 生成的成本分配标签（Cost Allocation Tags）只有在 Billing 控制台激活后，才会出现在 CE 和 CUR 中。激活本身不收费，但激活后需要最多 24 小时才会在账单中生效，且只对激活之后的用量生效，不会回溯历史数据——这是很多团队第一次做成本分析时踩的坑。

标签分两类：AWS 生成的标签（如 aws:createdBy）和用户自定义标签。真正决定治理效果的是自定义标签的命名规范。一个可落地的标签策略通常包含以下强制字段：

仅有规范不够，还要有强制手段。AWS Organizations 的 Tag Policies 可以定义允许的标签键和值，并对不合规资源标记为不合规；配合 SCP 可以阻止未打标签的资源创建（例如拒绝不带 CostCenter 标签的 EC2 RunInstances 请求）。此外，可用 AWS Config 规则 required-tags 持续检测存量资源的标签合规性，把“漏标”变成可追踪的待办项。

成本分配与分摊方法

标签解决“直接成本”的归因，但共享资源（如 NAT Gateway、ALB、集中式日志、共享 EKS 集群、数据传输费）无法直接归属单一团队，必须分摊。常见方法有三类：

1. 按用量比例分摊：最适合可度量的共享服务。例如共享 NAT Gateway 月费 300 美元，团队 A 的流量占 70%、团队 B 占 30%，则分别承担 210 和 90 美元。数据可从 VPC Flow Logs 或 CUR 中按 usage type 拆分。
2. 平均分摊：适合无法度量、金额较小的共享项，如集中式安全扫描工具。按受益方数量均分，简单但可能引发争议。
3. 固定比例分摊：按事先约定的权重（如按各团队上月直接成本占比）分摊，适合预算编制和内部结算，需定期复核权重。

在 CUR 中实现分摊的典型做法是：用 Athena 查询原始明细，对带标签的资源直接按标签聚合；对共享资源，用 line_item_usage_account_id、line_item_resource_id 或 line_item_usage_type 识别后，乘以约定的分摊系数，再 UNION 回主查询。下面是一个简化的 Athena 查询骨架，用于按 Project 标签汇总月度摊销成本：

SELECT
  COALESCE(resource_tags['Project'], 'untagged') AS project,
  SUM(line_item_unblended_cost) AS unblended_cost,
  SUM(line_item_amortized_cost)  AS amortized_cost
FROM cur_db.cur_table
WHERE year = '2025' AND month = '06'
GROUP BY 1
ORDER BY amortized_cost DESC;

注意 line_item_unblended_cost 是未摊销的原始成本，而 line_item_amortized_cost 会把 RI/SP 的预付费用按小时摊平，做内部结算时应优先使用摊销成本，否则会出现“买了 RI 的月份成本暴涨、后续月份成本为零”的失真。

从工具到闭环：一个可执行的最小治理流程

把上述能力串起来，一个可落地的最小闭环是：先激活成本分配标签 → 用 Budgets 设置总预算和按 Project 标签的分项预算 → 每周用 CE 看趋势 → 每月用 CUR+Athena 出分摊报表 → 对未打标签资源用 Config 规则生成整改清单。其中 Budgets 的分项预算可以直接按标签过滤，例如“Project=data-platform 且 Environment=prod”的月度预算设为 5000 美元，预测值达到 80% 时触发 SNS 告警。

最后强调一个判断依据：如果 CE 中按 Project 标签分组的成本曲线与财务口径的总账差异超过 5%，通常意味着存在未激活的标签键、未打标的资源，或共享成本分摊系数需要更新。此时应回到 CUR 明细逐项核对，而不是直接调整 CE 的筛选条件——CE 只是视图，CUR 才是事实。