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

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

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

解决办法不是更便宜的模型或更短的提示词，而是一种运营模式：一个可重复的循环，将每一美元归因到负责人，让每个请求都可观测，在超支累积之前发出告警并强制执行预算，优化驱动大部分浪费的平台默认设置，并按节奏审查整个系统。

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

运营模式一览

五个阶段，以循环方式运行。归因：在账单管道中，每一美元 Amazon Bedrock 支出都落到某个身份、团队和应用上。观测：每个请求都被记录，并带有足够的元数据来解释是什么产生了这笔支出。强制执行：预算要有约束力，至少要有告警，在风险要求的地方要有硬性阻断。优化：平台默认设置（模型路由、缓存、token 限制）集中消除浪费，而不是要求每个团队小心谨慎。运营：一个小型记分卡和审查节奏将数据转化为决策。FinOps 主导第一和第五阶段。平台工程主导第二至第四阶段。审查是联合进行的。各阶段的排序是刻意安排的。每个阶段都依赖前面的阶段，而那些跳过归因和可观测性直接进行优化的团队是在猜测。

图 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. 分析这些标签：它们会以 iamPrincipal/ 前缀出现在 CUR 2.0 中（例如 iamPrincipal/team），并在激活后 24–48 小时内出现在 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 使用并控制成本，以及深入探讨在 Claude Code 中通过 AWS Budgets 和标签管理 Bedrock。

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

一个聚合器 AWS Lambda 函数根据调用日志数据，在 Amazon DynamoDB 中统计每用户的令牌和美元计数器。当用户超过其阈值时，该函数将其身份添加到共享的 IAM 拒绝策略中（拒绝 bedrock:*），直到每月重置或管理员覆盖。此强制执行完全依赖 IAM 和 Amazon Bedrock 日志记录，推理路径中无第三方组件，且适用于直接调用 Amazon Bedrock 的工具。AWS 解决方案库中的适用于 Amazon Bedrock 的 Claude Code 指南提供了一个可部署的变体。它在颁发凭证时根据每用户和每团队的限制检查每个用户的使用情况，并在用户超过限制后扣留凭证。由于该检查使用客户端发出的使用遥测数据，其数字可能与 CUR 不同。无论哪种形式，强制执行都是异步的。对于 IAM 策略更新，阻止在违规调用后数秒到数分钟生效；对于凭证检查，则在下次凭证刷新时生效。你的平台团队负责该管道。此层适合需要真正强制执行、能容忍该延迟，并希望将第三方软件排除在数据路径之外的团队。

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

网关位于推理数据路径中，同步执行预算，在用户或团队超过限制时立即返回 HTTP 429。你获得亚秒级阻止、每用户模型允许列表、令牌速率限制和集中强制路由规则。权衡之处：数据路径中的组件必须部署、扩展并进行安全审查。客户端必须配置为通过网关发送请求。

对于 Claude Code 和 Claude Desktop 集群，适用于 AWS 的 Claude 应用网关是官方推荐。它随 CLI 二进制文件一起提供，作为由 PostgreSQL 支持的单个无状态容器运行。它开箱即提供 OIDC 身份、集中管理策略、OpenTelemetry 遥测、多区域 Amazon Bedrock 路由以及每用户/组/组织的支出上限。对于跨多个提供商的混合模型工作负载，通用网关仍是正确选择：通过 AWS Fargate 上的 Amazon Elastic Container Service (Amazon ECS) 参考架构使用 LiteLLM，或 为 Amazon Bedrock 构建主动式 AI 成本管理系统，第 2 部分中描述的无服务器替代方案。

选择层级

两个因素占主导。

连接性：如果开发者直接调用 Amazon Bedrock 且无代理，则只有第 1 层和第 2 层可行。

支出速度：如果每月支出已达数百万美元，现在就建立强制执行机制。如果告警还能再撑一个季度，先投入阶段 1 和阶段 2，等数据要求时再增加强制执行。

大多数组织应分阶段推进：在层级 1 观察，然后逐步升级。将这三个阶段都视为桥梁而非终点：Well-Architected Agentic AI Lens 已将智能体成本治理确立为一等架构关注点，而阶段 1 建立的归因基础正是任何托管强制执行机制所依赖的根基。

阶段 4：优化默认值

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

模型路由

并非每项任务都需要前沿模型。常规补全（样板代码、lint 建议、小型重构）可运行在更小、更便宜的模型上，将质量保留给复杂推理，通过模型家族内的智能提示路由或网关上的路由规则实现（完整演练见使用 Amazon Bedrock Intelligent Prompt Routing 和提示缓存降低成本和延迟）。哪些工作流可以降级是一个实证问题：从阶段 2 拉取工作负载排行榜，对排名靠前的条目在更便宜的模型上运行质量评估，并路由通过评估的部分。对于智能体编码集群，样板代码主导调用量，超过一半的调用落在更便宜的模型上是一个可实现的目标。

提示缓存

提示缓存奖励稳定的重复前缀。截至 2026 年 10 月，美国东部（弗吉尼亚北部）Anthropic Claude 模型的已发布 Amazon Bedrock 定价对缓存写入按基础输入费率的 1.25 倍计费（5 分钟生存时间 TTL），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

注意：上述查询中显示的字段路径仅为示例。请根据您的调用日志模式进行验证，该模式可能因模型、API 操作和日志配置而异。

应用层优化

第三类节省（即时检索而非填充上下文、压缩长对话、将稳定的高流量工作流蒸馏到更小的模型上）属于应用团队而非平台。平台的工作是让这些节省可见：发布按工作流的 token 排行榜，为每个模型和工作流设置 token 限制，并让拥有昂贵工作流的团队清楚看到自己的位置。

阶段 5：运营闭环

前四个阶段产生数据。这一阶段将数据转化为决策。平台团队运行一个常设的健康仪表盘，包含四个信号：

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

当某个信号发生漂移时，补救措施是策略变更（路由规则、令牌限制、元数据强制），而不是发邮件请各团队多加小心。

资金闭环

FinOps 基于同一数据运行资金闭环。当归因清晰时，异常检测就变成一条调查流，而不是一场惊慌的全员会议：某个已标记团队或应用的花费激增会触发在阶段 2 排行榜中的查询，而不是召开战情室会议。费用分摊通过 CUR 按团队和应用分组来运行。

记分卡

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

绿色表示工作负载在其经济包络内运行。黄色表示路由或缓存纪律正在松懈。红色表示支出正集中在高级模型或未缓存的上下文上，而阶段 3 和阶段 4 的控制措施是补救路径。请按固定节奏审查此记分卡（高节奏机群每周一次，其他情况每两周一次），并将其视为 FinOps 与平台联合的决策界面。

结论

在本文中，你了解了如何构建一个五阶段运营模型，将 Amazon Bedrock 支出从失控转变为完全受治理：

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

注意那张记分卡的第一行：每个成功结果的成本，而不是每次调用的成本。这一区别正是本手册的交接点。这里的一切都让 Amazon Bedrock 支出可见、可归因、有上限且高效，但一个工作流可以完全高效，却仍然不值得运行。要做出这一判断，需要将智能体与其所取代的人工流程进行衡量，这属于产品和数据分析范畴，而非 FinOps 范畴。成本平台所贡献的是基础：清晰的归因和按工作流的成本数据，正是结果衡量所要对接的输入。

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

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

关于作者

Aswath Ram A Srinivasan

Aswath 是 Amazon Bedrock 的高级专家解决方案架构师，专注于核心模型、功能以及成本优化与归因。他帮助 ISV 和战略客户在 Amazon Bedrock 上解决他们的挑战。他与企业团队合作，负责任地设计兼顾性能、成本和运营简便性的推理架构。业余时间，他是一名摄影师，喜欢阅读关于神经符号 AI 和负责任 AI 的科学期刊论文。

Aamna Najmi

Aamna 是生成式 AI 的高级专家解决方案架构师，专注于 Anthropic 模型以及在 Amazon Bedrock 上大规模运营和治理生成式 AI 系统。她帮助 ISV 解决挑战、拥抱创新，并借助 Amazon Bedrock 创造新的业务机会。业余时间，她热衷于尝试美食和探索新地方。

Ajit Mahareddy

Ajit 是一位经验丰富的产品和上市（GTM）领导者，在产品管理、工程和上市方面拥有超过 20 年的经验。在担任当前职位之前，Ajit 曾在 Uber、Turing 和 eHealth 等领先科技公司领导 AI/ML 产品的产品管理工作。他热衷于推进生成式 AI 技术，并借助生成式 AI 推动现实世界的影响。

Benedict Augustine

Benedict 是一位资深产品 GTM 领导者，一直与顶级 ISV 合作开展 Amazon Bedrock 的使用。