跳到正文
AWS Machine Learning Blog· Aswath Ram A Srinivasan·· 3 小时前AI 评分59

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

Managing Amazon Bedrock costs end to end: A playbook for FinOps and platform teams

AI 导读

AWS 机器学习博客发布 Amazon Bedrock 成本管理手册，提出归因、观测、强制、优化、运营的五阶段闭环。

正文 · AI 翻译

生成式 AI 的成本管理是构建应用的团队与对云支出负责的团队之间的共同责任。许多团队首先比较各模型的 token 费率，并要求应用团队缩短提示词。这些做法有帮助，但无法回答随着使用规模扩大后财务和工程负责人提出的问题：这笔支出来自哪个团队、用于哪个工作负载，以及该支出是否在批准的预算之内？

智能体工作负载让这些问题更加紧迫。会话式助手通常在每轮用户交互中发起一次模型调用。而智能体工作流（例如规划变更、读取文件、调用工具并不断迭代的 AI 编码助手）在每个任务中会发起多次调用，并且每次调用都携带更大的上下文。因此，token 消耗随你赋予工作流的自主程度及其携带的上下文规模而扩展，而不是随用户交互次数而扩展。由于消耗是工作负载设计与运营方式的函数，生成式 AI 的成本管理是一门架构与运营学科。公布的平均值无法替代你自己的数据：使用 AWS Pricing Calculator 和 Amazon Bedrock 定价页面来模拟费率，并使用本文的步骤 2 来测量你的工作负载的实际消耗。

解决之道不是更便宜的模型或更短的提示词，而是一种运营模式：一个可重复的闭环，将每一美元归属到明确的负责人，使每个请求都可观测，在超支加剧之前发出告警并强制执行预算，优化导致大部分浪费的平台默认设置，并按固定节奏审查整个系统。

在本文中，你将学习如何通过五个步骤管理 Amazon Bedrock 的成本。你将把每一美元归属到明确的负责人，使每个请求都可观测，通过预算和强制执行控制支出，优化导致大部分可避免支出的平台默认设置，并运营一个将数据转化为决策的审查节奏。这一方案由 AWS 构建模块构成，你可以对其进行定制并应用到自己的环境中。本文面向两类读者：负责归属、分摊、预算和异常审查的 FinOps 从业者，以及负责日志记录、请求元数据、强制执行和路由默认配置的平台工程团队。

一图看懂运营模式

五个阶段，作为一个闭环运行。归属：每笔 Amazon Bedrock 支出在账单流水线中都落到具体的身份、团队和应用上。观测：每个请求都被记录，并带有足以解释支出来源的元数据。强制：预算要有约束力，至少要有告警，风险需要时还要有硬性阻断。优化：由平台默认设置（模型路由、缓存、token 限制）集中消除浪费，而不是要求每个团队自行谨慎行事。运营：用一个简短的记分卡和固定的审查节奏把数据转化为决策。FinOps 负责阶段一和阶段五，平台工程负责阶段二到四，审查则共同进行。这些阶段的顺序是刻意安排的，每个阶段都依赖于之前的阶段；那些跳过归属和观测而直接进入优化的团队只是在凭空猜测。

Five-stage Amazon Bedrock cost operating model loop: attribute, observe, enforce, optimize, operate

图 1：五阶段运营模式，作为一个持续闭环运行

阶段 1：将每一美元归属到明确的负责人

无法归因就无法管理，而下游的一切（成本分摊、预算、执行、异常检测）都依赖这一阶段。其基础是 Amazon Bedrock 的细粒度成本归因（参见 Introducing granular cost attribution for Amazon Bedrock）：Amazon Bedrock 会自动将推理成本归因于发起调用的 AWS Identity and Access Management (IAM) 主体，覆盖所有模型，且无需管理任何资源。调用者的 ARN 会出现在 AWS Cost and Usage Report (CUR) 2.0 的 line_item_iam_principal 列中，覆盖范围包括 IAM 用户、角色、联合身份和 API 密钥。

设置只需四步：

  1. 在 CUR 2.0 数据导出中启用 IAM 主体数据。
  2. 为 IAM 主体打上团队、应用、成本中心等业务维度的标签。对于联合访问，请配置身份提供商通过 OIDC 或 SAML 声明传递会话名称和标签。
  3. 在 AWS Billing（控制台或 UpdateCostAllocationTagsStatus API）中将这些标签激活为成本分配标签。
  4. 分析这些标签：它们会在激活后 24–48 小时内以 iamPrincipal/ 前缀的形式出现在 CUR 2.0 中（例如 iamPrincipal/team），并显示在 AWS Cost Explorer 的 IAM 类别下，可供按团队、应用或成本中心进行筛选和分组。

这是发票级的、按身份的归因，无需任何自定义基础设施。

共享角色问题

最值得关注的模式是共享角色问题，因为大多数平台正是在这里悄悄失去了归因能力。通过单一 IAM 角色调用 Amazon Bedrock 的大语言模型（LLM）网关，会把每一美元都归因到那一个角色上，完全消除了按用户查看的可见性。解决方法是基于用户会话的管理。网关为每个用户代入一次 Amazon Bedrock 调用角色，将用户身份作为角色会话名称、用户属性作为会话标签传递，然后缓存这些凭证最长一小时（每小时每个用户一次 AWS Security Token Service (AWS STS) 调用，而不是每次请求一次）。

这需要两个角色：一个持有 sts:AssumeRole 和 sts:TagSession 权限的网关执行角色，以及它所代入的 Amazon Bedrock 调用角色。其结果是产生 line_item_iam_principal 条目，例如 assumed-role/BedrockRuntimeRole/gw-alex，每条都携带其用户的标签：在共享网关背后恢复了按用户和按租户的归因。

import boto3

sts = boto3.client("sts")

# One call per user; cache the returned credentials up to 1 hour
response = sts.assume_role(
    RoleArn="arn:aws:iam::123456789012:role/BedrockRuntimeRole",
    RoleSessionName="gw-alex", # the user, not the gateway
    Tags=[
        {"Key": "team", "Value": "sales-ai"},
        {"Key": "application", "Value": "renewal-agent"},
        {"Key": "costCenter", "Value": "CC-2041"}
    ]
)

关于应用程序推理配置文件和 Projects 的说明

Amazon Bedrock 还提供另外两种归因机制，各自适用于不同的模式。应用程序推理配置文件是 bedrock-runtime 端点上预先创建的、按应用程序划分的资源，携带成本分配标签。你需要为每个应用程序、每个模型、每个 AWS 区域创建一个配置文件，调用者引用该配置文件的 ARN，这适合应用程序和模型集合较小且稳定的团队。Projects 和工作区服务于 bedrock-mantle 端点（Responses API、Chat Completions API）。项目不绑定特定模型，因此单个项目 ID 可跨越多个模型，这适合模型使用频繁变化的团队。你在客户端初始化时传入项目 ID，其标签会流入 CUR 2.0 和 Cost Explorer（参见 Manage AI costs with Amazon Bedrock Projects）。Projects 是 Amazon Bedrock 上 OpenAI 兼容工作负载的归因路径。

对于 bedrock-runtime 工作负载，我们推荐通过会话标签进行 IAM 主体归因作为主要机制。它可以随你的身份系统扩展，无需预先创建资源，并且覆盖所有模型和 API 操作。当少量、稳定的业务单元需要发票级的计费隔离而不改变身份设计时，应用推理配置文件效果良好。对于使用 Responses API 或 Chat Completions API 的 bedrock-mantle 工作负载，请使用项目。

阶段 2:让每个请求都可观测

CUR 告诉你谁花了钱。调用日志告诉你发生了什么。Amazon Bedrock 支持将请求数据、响应数据和元数据的模型调用日志记录到 Amazon CloudWatch Logs、Amazon Simple Storage Service (Amazon S3),或同时记录到两者。使用 Amazon CloudWatch 进行快速运维查询,使用 S3 加 Amazon Athena 进行长期商业智能 (BI) 访问。将日志视为基础设施,而非手动开关:通过代码预置日志组或存储桶,定义保留和加密策略,并在环境搭建期间验证日志投递。如果日志只存在于开发环境或只存在于一个区域,一旦使用量增长,你的成本计划就会变得支离破碎。

日志还能弥补延迟差距:CUR 归因大约滞后 24 小时,但 CloudWatch 加 OpenTelemetry 可以支持近实时仪表板,在几分钟内显示每位开发者的支出(使用 CloudWatch 和 OpenTelemetry 分析 Claude Code 用量端到端地演示了这一点)。

用于工作负载级归因的请求元数据

原始日志回答身份级的问题。要回答工作负载级的问题(哪些功能、工作流或租户产生了这些 token),请在每次调用时附上请求元数据。Amazon Bedrock 会在调用日志中捕获这些元数据以供后续分析:

以下示例通过美国跨区域推理配置文件在 Amazon Bedrock 上使用 Anthropic Claude Sonnet 5.5。完整模型列表请参阅Amazon Bedrock 支持的基础模型。各区域可用性请参阅Amazon Bedrock 中按 AWS 区域划分的模型支持。

response = client.converse(
    modelId="us.anthropic.claude-sonnet-5-5",
    messages=[...],
    requestMetadata={
        "application": "renewal-copilot",
        "workflow": "renewal-risk-summary",
        "tenant": "enterprise-sales",
        "agent": "renewal-agent"
    }
)

Amazon Bedrock 不会强制要求请求元数据,当每个应用各行其是时,团队很快就会陷入不一致的架构。平台团队应在共享的 SDK 包装器或网关中集中注入必需的元数据,规范化键集合,并将元数据覆盖率视为平台健康指标。

诊断查询

有了日志和元数据,CloudWatch Logs Insights 就能回答那些常见问题。谁消耗的 token 最多:

fields @timestamp, identity.arn as caller, modelId,
input.inputTokenCount as inTokens,
output.outputTokenCount as outTokens
| stats sum(inTokens + outTokens) as totalTokens,
count(*) as calls
by caller, modelId
| sort totalTokens desc
| limit 25

将同一查询改为按 requestMetadata.application 和 requestMetadata.workflow 而非 caller 分组,即可得到工作负载级的排行榜:当计费回摊对话开始时,产品团队和工程团队会立刻向 FinOps 索要这一视图。

注意:上述查询中显示的字段路径仅为示例。请对照你的调用日志架构进行验证,该架构可能因模型、API 操作和日志配置而异。

阶段 3:强制执行预算

有了归因和可观测性,强制执行就成为一种架构选择,而不是一种愿望。有三个可行的层级。选择哪一个取决于你的支出速度、对超支的风险容忍度,以及你的工具如何连接到 Amazon Bedrock。

层级 1:监控和告警(不阻断)

Amazon Bedrock 会自动将主体身份写入计费管道。你可以在其上配置 AWS Budgets 实现阈值告警，并结合第 2 阶段的 OpenTelemetry 仪表板弥补 24 小时 CUR 的空档，实现日常可视化。无需部署任何东西，使用原生 AWS 计费，推理调用也没有额外延迟。它适用于直接调用 Amazon Bedrock 的工具。没有任何机制能硬性停止支出，因此你只能在问题发生后才看到它。适合早期采用阶段，即告警加人工干预已经足够的情况。有两篇构建指南详细介绍了这一层：限制 Bedrock 使用量并控制成本，以及利用 AWS Budgets 和标签在 Claude Code 中管理 Bedrock 的深度解析。

第 2 层：IAM 标签强制执行（超限即拒绝）

一个聚合器 AWS Lambda 函数根据调用日志数据，在 Amazon DynamoDB 中统计每个用户的令牌与金额计数。当用户超出其阈值时，该函数会将其身份添加到共享的 IAM 拒绝策略中（拒绝 bedrock:*），直到每月重置或管理员解除为止。这一强制执行完全基于 IAM 和 Amazon Bedrock 日志运行，推理路径中没有任何第三方组件，并且适用于直接调用 Amazon Bedrock 的工具。AWS Solutions Library 中的 Guidance for Claude Code with Amazon Bedrock 提供了一个可部署的变体。它在签发凭证时会根据每用户和每团队限额检查各用户的使用量，并在用户超出限额后拒绝签发凭证。由于该检查使用客户端发出的使用遥测数据，其数值可能与 CUR 不同。无论哪种形式，强制执行都是异步的。通过更新 IAM 策略实施的封禁会在违规调用后数秒到数分钟内生效，而凭证检查则在下次凭证刷新时生效。该管道由你的平台团队负责维护。这一层适合需要真正的强制执行、能够容忍这种延迟、并希望让第三方软件远离数据路径的团队。

第 3 层：网关强制执行（同步阻断）

网关位于推理数据路径中，同步执行预算限制，一旦用户或团队超出限额就立即返回 HTTP 429。你可以获得亚秒级阻断、每用户模型允许列表、令牌速率限制，以及集中强制执行的路由规则。代价是：数据路径中多了一个必须部署、扩展并通过安全审查的组件。客户端必须配置为通过网关发送请求。

对于 Claude Code 和 Claude Desktop 部署群，Claude apps gateway for AWS 是官方推荐方案。它随 CLI 二进制文件一同交付，以单个无状态容器的形式运行，由 PostgreSQL 提供支持。开箱即用地提供 OIDC 身份认证、集中管理的策略、OpenTelemetry 遥测、多区域 Amazon Bedrock 路由，以及按用户/组/组织的支出上限。对于跨越多个提供商的混合模型工作负载，通用网关仍是正确选择：可通过 Amazon Elastic Container Service (Amazon ECS) on AWS Fargate 参考架构使用 LiteLLM，或采用 Build a proactive AI cost management system for Amazon Bedrock, Part 2 中描述的无服务器替代方案。

选择合适的层

有两个因素起决定性作用。

连接方式：如果开发者直接调用 Amazon Bedrock 而不经过代理，则只有第 1 层和第 2 层可行。

支出增速: 如果每月支出已达数百万美元级别,现在就构建强制管控。如果告警还能撑一个季度,先投入第 1 和第 2 阶段,等数据需要时再增加强制管控。

大多数组织应该分阶段推进: 在第 1 层先观察,再逐步升级。把这三者都视为过渡桥梁,而非终点: Well-Architected Agentic AI Lens 已经把智能体成本治理确立为一流架构关注点,而第 1 阶段建立的归因基础,正是任何托管式强制管控将要依托的地基。

第 4 阶段: 优化默认设置

大多数 Amazon Bedrock 浪费并非个体的疏忽,而是无人设置的平台默认值。影响最大的两个杠杆都由平台掌控。

模型路由

并非每个任务都需要前沿模型。常规补全(样板代码、lint 建议、小型重构)可以运行在更小、更便宜的模型上,把高质量留给复杂推理,方式是通过模型家族内的智能提示词路由,或在网关处设置路由规则(完整操作步骤见 Reduce costs and latency with Amazon Bedrock Intelligent Prompt Routing and prompt caching)。哪些工作流可以降级是一个实证问题: 从第 2 阶段拉取工作负载排行榜,对排名靠前的条目在更便宜的模型上运行质量评估,让通过评估的流量走便宜模型。对于样板代码占调用量主导的智能体编程机群来说,超过一半的调用落在更便宜模型上是一个可实现的目标。

提示词缓存

提示词缓存奖励稳定重复的前缀。截至 2026 年 10 月,美国东部(弗吉尼亚北部)区域 Anthropic Claude 模型公布的 Amazon Bedrock 定价为: 使用 5 分钟存活时间(TTL)时,缓存写入按基础输入费率的 1.25 倍计费(1 小时 TTL 为 2 倍)。缓存读取在 Claude Sonnet 4.6 和 Claude Haiku 4.5 上按基础输入费率的 0.1 倍计费,在 Claude Sonnet 5.5 和 Claude Opus 5.5 上为 0.05 倍。请在你所用模型和区域的定价页面上核实,因为这些倍率因模型而异,且可能变化。盈亏平衡的账比团队想象的更划算。使用 5 分钟 TTL 时,单次复用就已收回写入成本,对稳定前缀的十次调用成本约为未缓存价格的五分之一(0.1 倍读取费率下约 22%,0.05 倍下约 17%)。唯一的亏损情形是写入后从未被读取,这在 5 分钟 TTL 下多花 25%,在 1 小时 TTL 下翻倍。因此平台仪表盘应按工作流追踪缓存读取量与缓存写入量的对比。读取比例过低意味着前缀实际上并不稳定(通常是在缓存点之前嵌入了时间戳或会话 ID)。

候选优化项可直接从调用日志中发现:

fields requestMetadata.workflow as workflow, modelId,
input.inputTokenCount as inTokens
| stats count(*) as calls,
avg(inTokens) as avgInputTokens,
sum(inTokens) as totalInputTokens
by workflow, modelId
| filter calls > 50 and avgInputTokens > 2000
| sort totalInputTokens desc
| limit 25

注意: 前述查询中的字段路径仅为示例。请对照你的调用日志 schema 进行核实,它可能因模型、API 操作和日志配置而异。

应用层优化

第三类节省(用即时检索替代塞满上下文、压缩长对话、把稳定的高流量工作流蒸馏到更小的模型上)属于应用团队而非平台。平台的职责是让这些节省变得可见: 发布按工作流的 token 排行榜,为每个模型和工作流设置 token 上限,让拥有昂贵工作流的团队准确了解自己所处的位置。

第 5 阶段: 运营闭环

前四个阶段负责产生数据，而这个阶段将其转化为决策。平台团队运行一个常设健康仪表板，监控四个信号：

  • 模型组合：哪些模型被调用以及调用频率，这是路由纪律的直接衡量指标。
  • 失败请求率：错误、限流和超时。每次重试都会增加延迟，而客户端超时的请求若在服务端仍继续执行完成，可能会被计费两次——一次是被放弃的调用，一次是重试。
  • 缓存效果：第 4 阶段的读与写比率。
  • 元数据覆盖率：带有完整元数据的生产调用百分比。每个未覆盖的调用都是一个归因盲点，会悄然降低其他所有数字的准确性。

当某个信号出现漂移时，补救措施是更改策略（路由规则、token 限制、元数据强制执行），而不是发邮件要求团队多加小心。

资金闭环

FinOps 基于同样的数据运行资金闭环。当归因清晰时，异常检测就变成一条调查流，而不是慌乱的全员会议：某个已标记团队或应用程序的支出激增，只需在第 2 阶段的排行榜中查询即可，无需组建作战室。费用分摊（Chargeback）基于 CUR 中按团队和应用程序的分组来运行。

记分卡

以下阈值是起点，而非硬性规定。在将其采纳为策略之前，请根据您自己的集群数据和定价层级进行校准。

维度 指标 绿色 黄色 红色
单位经济效益 每个成功成果的成本 ≤ 预算 预算的 1–1.5 倍 >预算的 1.5 倍
开发者人均成本 每位开发者的每日支出 <$100 $100–$300 >$300
模型路由 调用成本效益模型的比例 >50% 30–50% <30%
缓存效率 缓存读取命中率 >60% 30–60% <30%

绿色表示工作负载在其经济范围内运行。黄色表示路由或缓存纪律正在松懈。红色表示支出集中在高端模型或未缓存的上下文中，第 3 和第 4 阶段的控制措施是补救路径。请定期审查此记分卡（高流量集群每周一次，其他每两周一次），并将其视为 FinOps 加平台团队的联合决策界面。

结论

在这篇文章中，您学习了如何构建一个五阶段运营模型，将 Amazon Bedrock 的支出从失控转变为全面治理：

  1. 归因（Attribute）——使用 IAM 主体标签、会话标签和 CUR 2.0 将每一美元归因到具体责任人。
  2. 观测（Observe）——通过模型调用日志记录和标记的请求元数据观测每个请求。
  3. 执行（Enforce）——在与风险相匹配的层级执行预算：仅监控、超额时 IAM 拒绝，或同步网关阻断。
  4. 优化（Optimize）——利用智能提示路由和提示缓存优化平台默认设置，从集中层面消除浪费。
  5. 运营（Operate）——运行记分卡和审查节奏，将遥测数据转化为策略决策。

注意记分卡的第一行：是“每次成功产出的成本”，而不是“每次调用的成本”。这个区别正是本指南的交接点。这里的一切都是为了让 Amazon Bedrock 的支出可见、可归因、有上限且高效，但一个工作流即使完全高效，也可能仍不值得运行。要做出这个判断，需要将智能体与其所替代的人工流程进行对比衡量，这是产品与分析层面的工作，而非 FinOps 层面的。成本平台的贡献在于打好基础：干净的归因和按工作流的成本数据，正是成效衡量所要关联的输入。

构建好这五个阶段，你就能端到端地回答：钱是谁花的、为什么花，以及花费是否受控。这就是管理 Amazon Bedrock 成本的意义所在，也是每月账单审查与一种运营模式之间的区别。

要开始使用，请为阶段 1–3 部署 Guidance for Claude Code with Amazon Bedrock 参考架构，然后使用 成本归因最佳实践 文档来配置你的标签策略。

关于作者

来源： AWS Machine Learning Blog · aws.amazon.com

#教程/实践#Agent#部署/工程#Anthropic