集中分析 Bedrock 跨账号调用与成本

Amazon Bedrock 的账单能告诉你花了多少钱，却很难回答：哪次请求花的、谁发起的、提示词里有什么、回答为什么被截断。AWS 团队给出的方案，是把多个账户里的模型调用日志集中到一个可用 SQL 查询的数据湖，再关联成本数据。

这套方案值得看的地方，是它把「看 token 总量」推进到了「检查每次调用」。但从记录 token 到准确分摊费用，再到判断回答质量，中间仍有几道不能省略的核验。

账单解释不了的问题，要回到每次调用

Amazon Bedrock 原生支持模型调用日志，可以把请求与响应记录交给 Amazon S3 或 Amazon CloudWatch。作者要解决的主要问题，是这些数据散落在不同 AWS 账户里：平台团队能看到账单，却难以统一排查某个团队的用量突增。

集中后的记录包括提示词、模型响应、输入与输出 token 数、模型、停止原因、账户、时间戳，以及发起调用的 IAM role。展开后的查询视图还包含缓存 token、提示词和响应预览。

这些字段能把排查落到具体请求。例如，用量突然增加时，可以检查输入是否变长、模型选择是否变化，以及哪些身份发起了调用。看到 stop_reason = max_tokens，则可以定位因生成上限而结束的响应。

不过，日志记录了回答内容，不等于系统已经知道回答好不好。原文没有提供质量评分、人工标注或自动评测机制。输入与输出 token 的比例也只能提供线索：摘要任务、代码生成和问答任务，合理比例可能完全不同。

这套数据湖提供的是分析证据，优化结论仍需要结合任务目标判断。

作者把这件事放在 tokenomics，也就是 AI token 消费的经济管理框架里。按原文说法，它在 2026 年 FinOps Foundation 大会上被宣布为正式的 FinOps 领域，沿用 See、Save、Run、Plan 四个支柱。对开发团队而言，先不必记术语，关键是把「用了多少」追踪到「谁为哪类任务用了多少」。

五段管道，怎样把日志变成可查询的表

这套架构的主线很清楚：源账户产生日志，中央账户负责接收、清洗、存储和查询。

第一步，在每个源账户开启 Amazon Bedrock 调用日志，指定 CloudWatch log group，以及允许写入的 IAM role。原文说可以通过一次 API 调用配置，但没有给出具体 API 名称。

第二步，CloudWatch 的订阅过滤器把新日志转发给中央账户里的 CloudWatch Logs destination。可以把它理解为持续生效的转发规则。源账户把事件交给接收入口，后续处理由中央账户自己的角色完成，无需给源账户开放整条管道的权限。

第三步，用一个 Lambda 清洗日志。CloudWatch 送来的数据经过批量封装、压缩和编码，不能直接作为普通 JSON 入表。Lambda 需要拆出单条记录，过滤维护消息和权限验证通知，再把嵌套的调用者身份提到顶层。过滤环节很实际：一条「日志权限配置正确」的文本，也可能破坏下游的数据格式转换。

第四步，Amazon Data Firehose 缓冲记录，把 JSON 转为 Parquet，写入 S3，并按日期组织路径，例如 year=2026/month=08/day=27/。Parquet 是适合分析查询的列式文件格式，查询时可以按所需字段读取；但原文没有提供转换前后的查询耗时或费用对比。

第五步，AWS Glue table 描述这些文件的结构，让 Amazon Athena 能通过 SQL 查询。开发者既可以查原始表，也可以查展开后的视图，不必每次都手动处理嵌套字段。

这里有一个时效性边界：验证时需要等待 Firehose 刷出缓冲区，大约一分钟，有时更久。因此，它适合调用回查、用量分析和审计。原文没有展示它作为实时告警链路的效果。

部署完成，不代表日志和视图已经可用

作者用两个 AWS CloudFormation 模板部署基础设施，但操作顺序不能颠倒。

先部署中央账户栈，保存输出的 CloudWatch Logs destination ARN。每个源账户栈都要引用它。中央栈还会输出 AWS Quick Sight role ARN，后续部署看板时需要使用。

再向各个源账户部署日志栈，每个栈接收前面的 destination ARN。随后，还要单独开启 Amazon Bedrock 调用日志，并且只启用 CloudWatch 投递。

CloudFormation 栈创建成功，不代表模型调用日志已经开启。

原因是，按原文方案，Amazon Bedrock 日志属于账户级设置，并不是模板里已经完成配置的 CloudFormation 资源。

验证也要走完两层。先在源账户发起一次测试调用，等待 Firehose 写入，确认 S3 的 data/ 前缀下出现 Parquet 文件；然后执行中央栈保存的 Athena 命名查询，真正创建展开视图。模板只保存了查询定义，没有执行它。后续查询应在专用 Athena workgroup 中运行。

准备环境时，需要为各账户配置 AWS CLI 凭据，具备 CAPABILITY_IAM 和 CAPABILITY_NAMED_IAM 权限，并准备 Python 3 与 Boto3，安装命令是 pip install boto3，用于端到端测试脚本。逻辑上至少需要一个源账户和一个中央账户，两者也可以是同一个账户。

可视化是可选项。原文提供 AWS Quick Sight 看板，通过 cid-cmd deploy 部署，还需要配置角色和数据源。看板可以补充团队元数据，但不会自动解决团队归属问题。

我的判断

我认可作者先集中调用证据、再讨论优化的顺序。对于已经跨多个 AWS 账户使用 Amazon Bedrock 的团队，这比人工翻日志更有组织性；相比自建一整套采集服务，它也复用了 CloudWatch、Firehose、S3 和 Athena。

但「每次调用成本」需要打个问号。原文建议把处理后的表与 CUR 2.0 关联，连接键是 IAM ARN，却没有在正文展开匹配粒度和分摊公式。一个 IAM role 可能发起很多次调用。仅凭身份相同，还不足以证明费用能准确对应到每条请求，需要检查时间范围、记录粒度和连接后的重复计数。这部分应视为待核验的成本归因方案。

同样，原文没有给出部署规模、管道运行费用、日志完整率或性能对照数据。「快速」「高效」更多是架构目标和经验描述，不能据此承诺上线后能节省多少费用。

安全方面，方案使用 AWS KMS 进行服务端静态加密，通过 IAM 控制 S3 和 Athena 查询结果的访问权限。这些措施有必要，但完整提示词和响应集中存储后，也会集中潜在的个人身份信息（PII）。原文没有展开脱敏、保留期限或删除策略，落地团队仍需补齐。

如果只是单账户、少量调用，先使用原生调用日志也合理；如果应用需要按用户、业务请求或评测结果分析，则还要检查现有字段是否足够。原文展示的是账户和 IAM 身份维度，不能默认等同于业务用户维度。

能拿来做什么

• 已经跨账户使用 Amazon Bedrock 的团队，可以按作者建议从一两个源账户开始，先验证提示词、响应、token 和身份字段能够完整查询，再扩大接入范围。
• 在日常 AI 编程或代码生成任务中，可以筛选 stop_reason = max_tokens 的记录，回看是否出现代码截断，再结合任务要求调整提示词和生成上限。
• 对接成本报表前，先拿一个小时间窗口核对 CUR 2.0 与调用日志的粒度，检查 IAM ARN 关联是否放大记录数，再决定费用如何分摊。
• 将「S3 已有文件」和「Athena 视图可查询」都列入部署验收。清理资源时，按原文要求先清空 S3 bucket，再删除 CloudFormation 栈，并手动删除 Athena workgroup。