Amazon Bedrock 成本管理全流程：面向 FinOps 与平台团队的实操手册

AWS 提出一套面向 Amazon Bedrock 的生成式 AI 成本管理方法，核心观点是成本管理属于架构与运营纪律，而非单纯换更便宜的模型或缩短提示词。智能体工作流每次任务会发起多次模型调用并携带更大上下文，token 消耗随自主程度和上下文规模增长，而不是随用户交互次数增长。 该方法由五个阶段组成并循环运行：归因、观测、强制执行、优化、运营。FinOps 团队主导第一和第五阶段，平台工程团队主导第二至第四阶段。文章强调阶段顺序不可跳步，缺少归因和可观测性就直接做优化等于猜测。 归因阶段依托 Amazon Bedrock 的细粒度成本归因能力：推理成本自动归属到发起调用的 IAM 主体，调用方 ARN 写入 AWS CUR 2.0 的 line_item_iam_principal 列，覆盖 IAM 用户、角色、联邦身份和 API 密钥。配置分四步：开启 CUR 2.0 的 IAM 主体数据、给 IAM 主体打团队/应用/成本中心标签、联邦访问通过 OIDC 或 SAML 传递会话名与标签、在 AWS Billing 激活成本分配标签。标签以 iamPrincipal/ 前缀出现在 CUR 2.0，激活后 24–48 小时内进入 Cost Explorer。 文章特别指出共享角色问题：LLM 网关用单一 IAM 角色调用 Bedrock 会把所有费用归到该角色，丧失按用户可见性。解决办法是按用户管理会话——网关为每个用户承担一次 Bedrock 调用角色，把用户身份作为角色会话名、属性作为会话标签，凭证缓存最长一小时，即每用户每小时一次 AWS STS 调用。这需要网关执行角色和 Bedrock 调用角色两个角色。 此外，应用推理配置文件适合应用与模型集合小而稳定的团队，按应用、模型、区域预创建并携带成本分配标签；Projects 面向 bedrock-mantle 端点（Responses API、Chat Completions API），一个项目 ID 可跨多个模型，适合模型使用频繁变化的团队。对 bedrock-runtime 工作负载，文章推荐以 IAM 主体加会话标签作为主要归因机制。 观测阶段使用模型调用日志，将请求数据、响应数据和元数据发送到 CloudWatch Logs、S3 或两者，CloudWatch 用于快速运营查询，S3 加 Athena 用于长期 BI。文章建议把日志当作基础设施用代码预置，并定义保留与加密策略。CUR 归因约有 24 小时延迟，CloudWatch 加 OpenTelemetry 可在数分钟内提供近实时看板。请求元数据（如 application、workflow、tenant、agent）会被写入调用日志，但 Bedrock 不强制校验，平台团队应在共享 SDK 封装或网关中集中注入。 强制执行分三档：第一档用 AWS Budgets 做阈值告警、不阻断，适合早期采用；第二档用 Lambda 汇总每用户 token 与金额计数到 DynamoDB，超阈值即将该身份加入共享 IAM 拒绝策略（拒绝 bedrock:*），直到月度重置或管理员覆盖，全程仅依赖 IAM 与 Bedrock 日志，推理路径无第三方组件。