AWS 提出 Bedrock 成本五阶段治理：先归属和日志，再预算阻断、路由与缓存

AWS 在 10 月 30 日提出管理 Amazon Bedrock 成本的五阶段流程：归属、观察、执行预算、优化默认设置、定期运营复盘。本站将原文编入 11 月 1 日技术刊期。它是 AWS 针对平台工程和 FinOps 的方法说明，不是本站实施后的节省金额报告。尤其是代理工作流一次任务可调用多次模型，按用户交互次数估算成本容易失真。

第一阶段先解决“钱算到谁”。AWS 说 Bedrock 的推理费用可在 CUR 2.0 的 `line_item_iam_principal` 中按调用 IAM 主体归属。组织需开启主体数据导出、给主体加团队和应用等标签、激活成本分配标签，再在账单分析中按维度查看；标签在 Cost Explorer 出现可能需要 24–48 小时。若所有用户都通过同一个网关 IAM role 调用，只会看到共同主体，无法按人核算。原文建议网关按用户 AssumeRole，传会话名和标签并缓存凭据，从而恢复用户和租户归属；这要求正确的 IAM 权限与会话设计。

第二阶段补足请求级可见性。CUR 是账单级归属，不回答一次请求为何耗 token。AWS 建议配置模型调用日志并设置保留、加密和交付核查，在请求上填统一的应用、工作流、租户等 metadata。日志可流向 CloudWatch 或 S3；调用方须注意敏感数据控制。Bedrock 不会强制应用填写 metadata，因此平台网关或共享 SDK 应集中注入并统计覆盖率。账单数据约滞后一天，日志和 OpenTelemetry 可提供更快的运营观察，但它们与最终账单仍是不同口径。

预算执行分三层。第一层是 AWS Budgets 告警，不阻断调用，适合能够由人及时处理的早期阶段。第二层根据日志和用量更新 IAM 拒绝策略或下次发放凭据时拒发，能阻断但异步：策略更新可能在越额调用后数秒到数分钟才生效，凭据方案则要等刷新。第三层把网关放在推理数据路径，同步超额时返回 HTTP 429；因此更及时，却增加必须部署、扩缩和审查的关键组件。直接连 Bedrock 而不经代理的客户端不能凭空获得网关同步阻断。

第四阶段是以真实任务评估默认模型路由、token 上限和提示缓存。AWS 的 2026 年 10 月例子称，在美国东部区某些 Anthropic Claude 模型上，五分钟缓存写入按基础输入费率的 1.25 倍，缓存读取则随模型为 0.1 或 0.05 倍；一小时写入为 2 倍。模型和区域不同，价格会变，不能把这些倍数当全球永久费率。若稳定前缀没有被再次读取，写缓存反而增加花费。因此应测每个工作流的读写比，并对下调模型的任务先做质量评估。

第五阶段把这些数据用于复盘。AWS 建议观察模型组合、失败或超时后的重试、缓存命中与 metadata 覆盖。原文示例评分卡中的每日每开发者 100/300 美元区间和成本效率模型调用占比，不是通用强制阈值；AWS 明说它们是起点，需按自己的规模和费率校准。真正的决策单位应是成功结果的成本，不只是每 token 标价。该方法的判断依据是先有归属与日志，才能正确定位超支并验证优化是否未伤质量；本文未在实际账单中复现 AWS 的效果。

实施成本归属时，团队应先画清请求的身份路径：终端用户、应用网关、IAM 角色、模型调用记录和账单主体分别是谁。如果所有用户最终只以同一网关角色请求，CUR 即使完整也不能从这一个主体反推出个人用量。需要在授权前提下使用每用户 AssumeRole 的会话名与标签，并把可验证的请求标识从网关传至调用日志。标签缺失、日志采样或重试未计入都会使按团队分摊偏低，所以还要持续记录元数据覆盖率。

日志的存在不等于默认就有所有请求细节。CloudTrail Event history 不含 Bedrock 数据事件；若要以 CloudTrail 追踪这类调用，必须配置相应数据事件，不能把普通事件历史当成完整推理审计。模型调用日志也需主动启用，并考虑提示词与回复可能含敏感信息。建立监控时，应将 CloudTrail 的访问审计、模型调用日志的请求细节、CUR 的最终费用和应用自身的成功率分别保存，再用共同请求标识关联，而不是把四种数据视作同一份账。

治理阈值应先以试运行确定。告警通常适合人能及时介入的额度，异步 IAM 阻断需要预留传播窗口，网关硬拦截则要有可用性和故障策略。如果网关本身中断，应用是拒绝请求还是绕过预算控制，会改变实际风险；这一选择必须明确评审。AWS 给出的数额和缓存倍数只是示例，产品与区域价格会变化，落地前需要复核当时价格表和真实请求分布。最终复盘既看成本，也看任务完成率与误拒率，避免通过停止有价值请求取得表面节省。