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

生成式 AI 的成本管理不是单一团队的事：一边是构建应用的团队，一边是对云支出负责的团队。AWS 在官方博客中给出的判断是，仅比较各模型每 token 单价、要求应用团队缩短提示词，只能解决一部分问题，无法回答用量扩大后财务和工程负责人真正关心的问题——哪支团队花了这笔钱、花在哪个工作负载上、是否在批准的预算内。

智能体类工作负载让这些问题更紧迫。对话助手通常每个用户轮次发起一次模型调用，而一个 AI 编码助手这类智能体工作流要规划改动、读取文件、调用工具并反复迭代，每个任务会发起多次调用，且每次携带更大的上下文。因此 token 消耗随工作流被授予的自主程度和上下文规模增长，而不是随用户交互次数增长。

五阶段循环

AWS 把这套方法拆成五个阶段，按顺序循环执行，每个阶段依赖前一个阶段：

• 归因：每一美元 Bedrock 支出都落到具体身份、团队和应用上。
• 观测：每次请求都记录足够元数据，能解释支出由什么产生。
• 强制：预算要有约束力，至少配置告警，风险高的场景可硬性阻断。
• 优化：通过模型路由、缓存、token 上限等平台默认值集中消除浪费，而不是要求每个团队自行小心。
• 运营：用一张小型记分卡和固定复盘节奏把数据变成决策。

分工上，FinOps 主导第一和第五阶段，平台工程主导第二至第四阶段，复盘由双方共同进行。AWS 明确提醒，跳过归因和观测直接做优化，等于在猜。

归因：共享角色是主要漏洞

归因的基础是 Bedrock 的细粒度成本归因能力：推理成本自动归因到发起调用的 IAM 主体，覆盖所有模型，无需管理额外资源。调用方 ARN 写入 AWS Cost and Usage Report（CUR）2.0 的 line_item_iam_principal 列，覆盖 IAM 用户、角色、联合身份和 API 密钥。

启用分四步：在 CUR 2.0 数据导出中打开 IAM 主体数据；给 IAM 主体打上团队、应用、成本中心等业务维度标签；对联合访问，配置身份提供方通过 OIDC 或 SAML 声明传递会话名和标签；在 AWS Billing 控制台或通过 UpdateCostAllocationTagsStatus API 将这些标签激活为成本分配标签。激活后标签以 iamPrincipal/ 前缀出现在 CUR 2.0 中，并在 24–48 小时内出现在 Cost Explorer 的 IAM 类别下，可按团队、应用或成本中心筛选分组。

AWS 特别点出“共享角色问题”：一个通过单一 IAM 角色调用 Bedrock 的大语言模型网关，会把每一美元都归到这一个角色上，彻底失去按用户的可视性。解决办法是按用户管理会话——网关为每个用户承担一次 Bedrock 调用角色，把用户身份作为角色会话名、用户属性作为会话标签传入，并缓存凭证最多一小时，即每用户每小时一次 AWS STS 调用，而非每请求一次。这需要两个角色：持有 sts:AssumeRole 和 sts:TagSession 权限的网关执行角色，以及它承担的 Bedrock 调用角色。结果是 line_item_iam_principal 中出现类似 assumed-role/BedrockRuntimeRole/gw-alex 的条目，并携带该用户的标签，从而在共享网关背后恢复按用户和按租户的归因。

编辑部观察

这篇内容的定位是操作手册而非产品发布，五阶段模型本身是方法论建议，不是已经验证的收益承诺。对读者的实际价值在于两点：一是把“成本优化”从提示词层面的微调，前移到身份与元数据的基础设施层；二是明确指出了共享网关这一常见架构会静默吞掉归因能力，并给出了基于会话标签的绕行方案。

需要留意的是，文中提到的 24–48 小时延迟、每小时一次 STS 调用等数字均为 AWS 描述，属于厂商说明，实际环境中的表现需自行验证。此外，五阶段中的“强制”和“优化”涉及硬性阻断与路由默认值调整，这类改动会影响线上业务，建议先在非关键工作负载上试点，确认告警阈值和阻断策略不会误伤正常请求后再推广。