2. AWS账单与成本数据体系

做FinOps，第一件事不是省钱，而是“看清钱花在哪”。AWS的账单数据并不是一张简单的月度发票，而是一套从明细到聚合、从原始数据到可视化、从真实账单到模拟账单的多层体系。理解这套体系，才能让后续的成本分摊、预算告警、优化决策有可靠的数据基础。本节围绕五个核心对象展开：Cost Explorer、Cost and Usage Report（CUR）、Billing Conductor、成本分配标签、账户结构设计。

一、从“看数”到“取数”：Cost Explorer与CUR的分工

Cost Explorer（CE）是控制台里的可视化成本分析工具，适合快速查看按服务、按账户、按标签、按区域维度的成本趋势，支持按日/月粒度、按使用类型（Usage Type）下钻，也能直接查看RI/Savings Plans的覆盖率与利用率。它的优势是开箱即用、交互直观，适合日常巡检和初步定位。但CE的粒度、保留期和导出能力有限，无法承载精细到“每小时、每个资源、每个成本分配标签组合”的分摊需求。

Cost and Usage Report（CUR）则是账单数据的“原始底账”。它以CSV或Parquet格式，按小时粒度输出每一笔用量与成本记录，字段包括lineItem/UsageAccountId、lineItem/ProductCode、lineItem/UsageType、lineItem/UnblendedCost、lineItem/ResourceId、resourceTags/*、costCategory/*等。CUR可以投递到S3，再用Athena、Glue、Redshift或QuickSight做二次分析。简单说：CE负责“快速看”，CUR负责“精细算”。

二、Billing Conductor：把“真实账单”变成“可模拟账单”

Billing Conductor（BC）解决的是“账单口径”问题。在多账户、多业务线、内部结算或对外转售场景中，直接拿AWS原始账单给业务方看，往往因为共享成本、折扣分摊、加价规则而难以解释。BC允许你创建billing group，把一组账户归入其中，并配置定价规则（pricing rule）、成本分摊（cost allocation）和加价/折扣（margin）。它生成的是“模拟账单”，不影响真实付款，但可以按你定义的规则重新计算每个账户应承担的成本。

典型用法是：把共享的Savings Plans折扣按各账户实际用量比例分摊，把支持费用按业务线收入比例分摊，再对内部结算加一个固定比例的margin。这样业务方看到的账单既反映真实资源消耗，又符合内部结算口径。

三、成本分配标签：让成本“有主可归”

标签是成本分摊的基石。AWS支持两种成本标签：AWS生成的标签（如aws:createdBy）和用户自定义标签。要让标签进入成本报表，必须在Billing控制台的“Cost allocation tags”中激活，激活后通常需要24小时左右才会出现在CE和CUR中。

设计标签时，建议至少覆盖四个维度：业务归属（如BusinessUnit、Product）、环境（Environment：prod/staging/dev）、成本中心（CostCenter）、负责人（Owner）。标签值要统一大小写和命名规范，例如Environment统一用prod/staging/dev，不要混用Production、PROD、prod。未打标签的资源会落入“untagged”黑洞，成为分摊争议的来源。

四、账户结构设计：用OU和账户边界承载成本边界

AWS Organizations的OU（Organizational Unit）和账户结构，直接决定了成本数据的天然分组方式。常见做法是按“业务线—环境—团队”三层设计：顶层OU按业务线划分，第二层按环境划分，第三层按团队或产品划分。每个账户只承载一个明确的成本归属主体，避免一个账户里混放多个团队的生产资源。

账户结构设计要与标签策略配合：账户提供粗粒度边界，标签提供细粒度切分。例如，一个业务线账户下可能有多个产品，这时用Product标签区分；而跨账户的共享服务（如网络、日志、安全工具）则单独放在Shared Services账户，再通过BC或CUR分摊规则把成本摊回各业务线。

五、把五者串成一条数据链

实际落地时，这五个对象不是并列的，而是一条有先后依赖的数据链。第一步，设计账户结构，让每个账户有明确的成本归属主体；第二步，制定标签规范并在资源创建时强制打标（可用SCP、Tag Policies或IaC模板约束）；第三步，在Billing中激活成本分配标签；第四步，用CUR投递到S3，通过Athena按账户、标签、服务、UsageType做聚合分析；第五步，对共享成本和内部结算场景，用Billing Conductor重算口径；第六步，把聚合结果接入Cost Explorer、Budgets和QuickSight，形成日常巡检与告警。

一个常见的教学示例：某公司有三个业务线（Retail、Media、Platform），每个业务线下有prod和dev两个环境。账户结构设计为三个顶层OU，每个OU下两个账户，共6个账户。标签规范要求所有资源必须打BusinessUnit、Environment、CostCenter三个标签。共享的NAT Gateway和日志账户放在Shared Services OU，每月约1200美元。通过BC把Shared Services成本按各业务线prod账户的实际计算用量比例分摊：Retail 50%、Media 30%、Platform 20%。这样每个业务线看到的月度成本既包含自身账户直接成本，也包含分摊后的共享成本，口径清晰、可追溯。

最后要强调的是，Cost Explorer、CUR、Billing Conductor、成本分配标签、账户结构设计这五者共同构成AWS成本数据的“事实来源”。FinOps的所有优化动作——无论是RI/SP购买建议、闲置资源清理，还是预算超支归因——都建立在这套数据体系之上。数据口径不清，后续的节省数字就不可信；归属边界不明，责任就无法落实到团队。先把这套体系搭稳，再谈优化，才是可持续的成本治理路径。