2. AWS账单与成本数据体系
在FinOps成本治理工程中，所有优化动作都必须建立在可信、可追溯、可归因的成本数据之上。AWS提供的账单与成本数据体系并非单一报表，而是一组从“汇总视图”到“明细记录”再到“自定义账单”的分层工具链。理解它们各自的数据粒度、更新频率、适用场景与相互关系，是搭建成本可观测性的第一步。
一、四类核心数据源的分工
AWS成本数据的核心来源可以按“聚合程度”和“可定制程度”两个维度来理解：
- Cost Explorer（CE）：控制台可视化工具，提供按服务、账户、标签、区域等维度的聚合视图，支持最多13个月的回顾和12个月的前瞻预测。数据通常每日更新一次，适合日常巡检、趋势判断和快速下钻。
- Cost and Usage Report（CUR）：最细粒度的成本与用量明细，以Parquet或CSV格式投递到S3，包含每一笔用量记录、定价信息、资源ID、标签、折扣、摊销与预留实例覆盖情况。它是构建自定义成本数据仓库的“事实表”。
- Billing Conductor：面向MSP、内部结算和成本分摊场景的“账单重构”工具，允许按自定义定价规则、账单分组和账户归属生成独立的pro forma账单，不影响真实付款账单。
- 成本分配标签与账户/OU结构：这是成本归因的“维度体系”。标签回答“这笔钱属于哪个项目/团队/环境”，账户与OU回答“这笔钱属于哪个组织单元”。两者共同构成成本分摊的坐标系。
这四者不是替代关系，而是从不同层次回答同一个问题：这笔钱是谁花的、花在哪里、为什么花。CE提供快速答案，CUR提供可编程的精确答案，Billing Conductor提供可对外结算的答案，标签与OU结构则决定这些答案能否被正确切分。
二、CUR：成本工程的“事实表”
如果只允许保留一个成本数据源，专业FinOps团队通常会选择CUR。原因在于它保留了每一笔用量记录的完整上下文。CUR的典型字段包括：lineItem/UsageAccountId（消费账户）、lineItem/ProductCode（服务代码）、lineItem/UsageType（用量类型）、lineItem/UnblendedCost（未混合成本）、lineItem/BlendedCost（混合成本）、reservation/EffectiveCost（预留实例有效成本）、savingsPlan/SavingsPlanEffectiveCost（Savings Plans有效成本）、resourceTags/user:Project（用户标签）等。
在实际工程中，CUR通常被投递到S3后，通过Glue Crawler建立表结构，再用Athena进行查询。一个典型的成本归因查询会按lineItem/UsageAccountId和resourceTags/user:Project分组，计算每个项目在指定月份的有效成本。需要注意的是，CUR的UnblendedCost并不等于实际摊销后的成本，涉及RI/SP时需要使用EffectiveCost字段才能得到真实的资源级成本。
三、Cost Explorer：快速洞察与预测
Cost Explorer适合回答“这个月比上个月多花了多少”“哪个服务增长最快”“下个月预计花多少”这类问题。它的核心能力包括：按维度分组（服务、账户、标签、区域、用量类型）、按时间粒度查看（日/月/小时）、设置成本异常检测、创建预算与预警、以及基于历史数据的预测。
CE的局限在于：数据是聚合后的，无法下钻到单个资源；标签激活后需要等待最多24小时才能生效；自定义时间范围最多13个月。因此CE适合作为“仪表盘”，而CUR适合作为“数据仓库”。两者配合使用，才能既快又准。
四、Billing Conductor：账单重构与内部结算
当组织需要向内部团队或外部客户出具独立账单时，Billing Conductor提供了“账单重构”能力。它的核心概念包括：
- Billing Group：一组账户的集合，可以按OU、按项目或按客户划分。
- Pricing Rule：自定义定价规则，可以基于公开价、折扣价或固定加价率。
- Custom Line Item：手动添加的费用项，如共享服务分摊、许可证费用。
- Pro Forma Bill：生成的模拟账单，不影响真实付款，但可用于内部结算和利润分析。
Billing Conductor的典型场景是MSP向客户出具账单，或大型企业内部按业务线分摊成本。它不改变AWS实际收费，而是改变“账单的呈现方式”。
五、标签与OU：成本归因的坐标系
无论CE还是CUR，成本能否被正确归因，取决于两个基础结构：成本分配标签和账户/OU结构。
成本分配标签需要在Billing控制台中激活，激活后才会出现在CE和CUR中。建议的标签策略包括：Project（项目）、Team（团队）、Environment（环境）、CostCenter（成本中心）。标签的挑战在于一致性——如果同一个项目在不同账户中使用了不同的标签值，成本就无法聚合。因此需要建立标签规范，并通过AWS Config、Tag Policies或SCP强制实施。
账户与OU结构则提供了另一种归因维度。在AWS Organizations中，OU可以按业务线、环境或合规要求划分。每个成员账户天然是一个成本边界，CE和CUR都可以按账户聚合。OU层级的成本汇总可以通过Organizations的账单功能查看。合理的OU设计应该同时满足成本归因、权限隔离和SCP管控三重需求。
| 数据源 | 粒度 | 更新频率 | 典型用途 | 是否影响实际付款 |
|---|---|---|---|---|
| Cost Explorer | 聚合（服务/账户/标签） | 每日 | 巡检、趋势、预测 | 否 |
| CUR | 行项目级（资源级） | 每日/每小时 | 自定义分摊、单位成本 | 否 |
| Billing Conductor | 账单组级 | 按账单周期 | 内部结算、对外报价 | 否（pro forma） |
| 成本分配标签 | 键值对 | 激活后24小时 | 归因维度 | 否 |
| 账户/OU | 账户级 | 实时 | 天然分组、权限边界 | 否 |
六、如何组合使用这套体系
一个可落地的成本数据架构通常是这样组织的：底层用CUR作为事实表，投递到S3并建立Athena查询；中层用Cost Explorer作为日常巡检和快速下钻的入口；上层用Billing Conductor生成面向内部团队或客户的账单；而标签和OU结构贯穿始终，决定成本能否被正确切分和归因。
在实施顺序上，建议先完成标签规范和OU结构设计，再启用CUR并建立查询能力，最后根据结算需求引入Billing Conductor。如果顺序颠倒，先建了CUR却发现标签缺失，后续的归因分析将无法进行，只能重新补数据或接受一段时间的成本盲区。
总结来说，AWS账单与成本数据体系是一个从明细到聚合、从真实账单到模拟账单、从技术维度到组织维度的多层结构。CUR提供精度，CE提供速度，Billing Conductor提供灵活性，标签和OU提供归因能力。理解它们各自的位置和关系，才能为后续的成本分摊、单位成本计算和优化决策打下可靠的数据基础。