端到端管理 Amazon Bedrock 成本：给 FinOps 与平台团队的一份实操心法

AWS ML Blog 2026-10-31T03:58:25.425204

生成式 AI 的成本管理，需要应用开发团队和负责云支出的团队共同承担。很多团队一开始会去比较各模型的 token 单价，再要求应用团队把提示词缩短。这些做法有帮助，但回答不了财务和工程负责人随用量增长而越来越关心的问题：这笔钱是哪个团队花的、花在哪个工作负载上、是否落在批准的预算之内？智能体（Agentic）工作负载让这些问题更加紧迫。一次对话式助手通常每个用户回合只发起一次模型调用。而智能体工作流——比如一个 AI 编程助手，它要规划改动、读取文件、调用工具、反复迭代——每个任务会发起多次调用，而且每次调用携带的上下文更大。因此，token 消耗取决于你给工作流多少自主权、它携带多大的上下文，而不是用户交互的次数。

既然消耗由工作负载的设计和运行方式决定，生成式 AI 的成本管理就是一项架构与运维层面的工作。公开的平均数据替代不了你自己的实际数字：用 AWS Pricing Calculator 和 Amazon Bedrock 定价页来估算费率，再用本文第 2 步来衡量你的工作负载实际消耗了多少。

解决之道不是换个更便宜的模型、或者把提示词写短一点。真正需要的是一套运营模式：一个可重复的闭环——把每一美元都归到具体负责人头上，让每一次请求都可观测，在超支累积之前对预算报警并强制执行，优化那些造成大部分浪费的平台默认配置，并按固定节奏复盘整个系统。

本文介绍分五步管理 Amazon Bedrock 成本：把每一美元归到负责人，让每一次请求可观测，用预算与强制执行来控制支出，优化那些造成大部分可避免支出的平台默认配置，并建立复盘节奏，把数据变成决策。这套方法由 AWS 的各个组件搭建而成，你可以按需定制，应用到自己的环境。

本文面向两类读者：负责成本归属、分摊、预算和异常审查的 FinOps 从业者，以及负责日志、请求元数据、执行约束和路由默认值的平台工程团队。

一张图看懂运营模型：五个阶段，循环运转

归属：在账单流水里，每一笔 Amazon Bedrock 费用都能对应到具体的身份、团队和应用。
观测：每个请求都有日志记录，元数据足够还原是什么产生了这笔开销。
约束：预算要能真正起作用，至少要有告警，风险高的场景要能硬性拦截。
优化：平台层面统一设置默认值（模型路由、缓存、Token 上限），从源头消除浪费，而不是让每个团队自己小心。
运营：一张小记分卡加上固定的复盘节奏，把数据变成决策。

这五个阶段是刻意按顺序排列的。每个阶段都依赖前面的阶段，如果跳过归属和观测直接去做优化，那就是在瞎猜。FinOps 主导第一和第五阶段，平台工程主导第二到第四阶段，复盘则共同参与。

Figure 1: The five-stage operating model, run as a continuous loop

第一阶段：让每一块钱都有归属

管不了的东西，往往是因为你不知道它属于谁。下游的一切——分摊、预算、约束、异常检测——都依赖这一步。

基础是 Amazon Bedrock 的精细化成本归属（参见 Introducing granular cost attribution for Amazon Bedrock）：Amazon Bedrock 会自动把推理成本归属到发起调用的 AWS Identity and Access Management（IAM）主体上，覆盖所有模型，无需管理任何资源。调用方的 ARN 会写入 AWS 成本和使用报告（CUR）2.0 的 line_item_iam_principal 列，覆盖范围包括 IAM 用户、角色、联合身份和 API 密钥。

设置只需四步：

在 CUR 2.0 数据导出中开启 IAM 主体数据。
给 IAM 主体打上业务维度标签，比如团队、应用、成本中心。
如果是联合访问，配置身份提供商通过 OIDC 或 SAML 声明传递会话名称和标签。

在 AWS Billing 控制台（或通过 UpdateCostAllocationTagsStatus API）把这些标签激活为成本分配标签。激活后即可分析标签数据：它们会以 iamPrincipal/ 前缀出现在 CUR 2.0 中（例如 iamPrincipal/team），并在激活后 24–48 小时内出现在 AWS Cost Explorer 的 IAM 类别下，可以直接按团队、应用或成本中心筛选和分组。这是账单级别的、按身份归属的成本核算，无需自建任何基础设施。

共享角色问题

最值得关注的是共享角色问题，因为大多数平台正是在这里悄悄丢失了成本归属。一个调用 Amazon Bedrock 的大语言模型（LLM）网关如果只通过单一 IAM 角色发起请求，那么每一美元都会被归到那个角色上，完全失去按用户区分的可见性。

解决办法是按用户管理会话。网关为每个用户单独代入一次 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")

# 每个用户调用一次，缓存返回的凭证最长 1 小时
response = sts.assume_role(
    RoleArn="arn:aws:iam::123456789012:role/BedrockRuntimeRole",
    RoleSessionName="gw-alex",  # 是用户，不是网关
    Tags=[
        {"Key": "team", "Value": "sales-ai"},
        {"Key": "application", "Value": "renewal-agent"},
        {"Key": "costCenter", "Value": "CC-2041"}
    ]
)

关于 Application Inference Profiles 和 Projects 的说明

Amazon Bedrock 还提供另外两种归因机制，各自适合不同的使用模式。

Application inference profiles 是在 bedrock-runtime 端点上预先创建、按应用划分的资源，自带成本分配标签。你需要为每个应用、每个模型、每个 AWS 区域各创建一个 profile，调用方通过 profile ARN 来引用。这种方式适合应用和模型组合数量少且稳定的团队。

Projects 和 workspaces 服务于 bedrock-mantle 端点（Responses API、Chat Completions API）。一个 project 不绑定特定模型，单个 project ID 可以覆盖多个模型，适合模型使用频繁变化的团队。在客户端初始化时传入 project ID，它的标签就会流入 CUR 2.0 和 Cost Explorer（参见 Manage AI costs with Amazon Bedrock Projects）。对于 Amazon Bedrock 上兼容 OpenAI 的工作负载，Projects 就是归因路径。

对于 bedrock-runtime 工作负载，我们建议把基于会话标签的 IAM 主体归因作为主要机制。它能随身份系统扩展，不需要预先创建资源，覆盖所有模型和 API 操作。当少量且稳定的业务部门需要发票级的账单分离，又不想改动身份设计时，application inference profiles 就很合适。使用 Responses API 或 Chat Completions API 的 bedrock-mantle 工作负载，则用 projects。

第二阶段：让每个请求都可观测

CUR 告诉你钱是谁花的，调用日志告诉你发生了什么。Amazon Bedrock 支持把请求数据、响应数据和元数据的模型调用日志发送到 Amazon CloudWatch Logs、Amazon Simple Storage Service（Amazon S3），或两者同时发送。需要快速做运维查询就用 CloudWatch，需要长期的商业智能（BI）访问就用 S3 加 Amazon Athena。

把日志当作基础设施来管，而不是手动开关：用代码创建日志组或存储桶，定义保留和加密策略，并在环境搭建阶段验证日志投递是否正常。如果日志只存在于开发环境，或只在一个区域开启，那么用量一涨，你的成本管理就会变得支离破碎。

日志还能弥补延迟差距：CUR 归因大约有 24 小时延迟，而 CloudWatch 加 OpenTelemetry 可以支撑近实时仪表板，几分钟内就显示每位开发者的支出（“用 CloudWatch 和 OpenTelemetry 分析 Claude Code 用量”一文完整演示了这一点）。

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

原始日志回答的是身份层面的问题。要回答工作负载层面的问题（哪个功能、工作流或租户产生的 token），就要在每次调用上打上请求元数据。Amazon Bedrock 会把这份元数据捕获到调用日志中，供后续分析：

下面的示例通过美国跨区域推理配置文件，在 Amazon Bedrock 上使用 Anthropic Claude Sonnet 5.5。完整模型列表见 Amazon Bedrock 支持的基座模型。各区域可用性见 Amazon Bedrock 各区域模型支持。

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 不会强制要求请求元数据。如果每个应用各搞一套，团队很快就会出现 schema 不一致的问题。平台团队应该在共享的 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 分组，而不是按调用方分组，就会得到工作负载层面的排行：一旦开始讨论成本分摊，产品和工程团队第一时间就会找 FinOps 要这个视图。注意：上面查询里展示的字段路径只是示例，请以你自己的调用日志结构为准——它会随模型、API 操作和日志配置不同而变化。

阶段 3：执行预算

有了归属划分和可观测能力之后，执行预算就不该再停留在愿望层面，而要落到架构选型上。大致有三档方案可选。具体选哪一档，取决于你的支出增速、你对超支的容忍程度，以及你的工具接入 Amazon Bedrock 的方式。

第 1 档：只监控和告警（不拦截）

Amazon Bedrock 会自动把主体身份写入计费流程。你在上面叠加 AWS Budgets 做阈值告警，再用阶段 2 的 OpenTelemetry 仪表盘补上 24 小时 CUR 延迟带来的盲区，满足日常观测需要。

不需要部署任何东西，用的就是 AWS 原生计费，推理调用也不增加延迟。
对直接调用 Amazon Bedrock 的工具都适用。
无法硬性止损，只能事后发现问题。
适合早期采用阶段：靠告警加人工介入就够了。

有两篇 Builder 指南讲这套做法：《Limiting Bedrock usage and controlling costs》和《Deep dive on managing Bedrock in Claude Code with AWS Budgets and Tags》。

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

用一个聚合器 AWS Lambda 函数，根据调用日志数据，在 Amazon DynamoDB 里按用户累计 token 数和金额计数。当某个用户触达阈值时，函数就把该用户的身份加入一份共享的 IAM 拒绝策略（拒绝 bedrock:*），直到下个月重置或管理员手动解除。

这套强制执行完全跑在 IAM 和 Amazon Bedrock 日志上，推理链路里不引入任何第三方组件，对直接调用 Amazon Bedrock 的工具同样适用。AWS Solutions Library 里的《Guidance for Claude Code with Amazon Bedrock》提供了一个可直接部署的变体。

它在发放凭证时，会核对每个用户的使用量与个人限额、团队限额，用户一旦超限就停止发放新凭证。由于这项检查用的是客户端上报的用量遥测数据，算出来的数字可能和 CUR（AWS 成本与用量报告）对不上。不过无论哪种形式，执行都是异步的：IAM 策略更新在超限调用后几秒到几分钟才生效，凭证检查则要等到下一次刷新凭证时才生效。这条流水线由平台团队自己维护。适合采用这一层的团队，是那些需要真正强制执行、能接受上述延迟、并且不想让第三方软件进入数据路径的团队。

Tier 3：网关强制执行（同步拦截）

网关部署在推理的数据路径上，同步执行预算控制，一旦用户或团队超限，立即返回 HTTP 429。你能获得亚秒级拦截、按用户设置模型白名单、Token 速率限制，以及集中执行的流量路由规则。代价是：数据路径上多了一个组件，需要部署、扩容并通过安全审查；此外，所有客户端都必须配置成把请求发给网关。对于使用 Claude Code 和 Claude Desktop 的团队，官方推荐的是 Claude apps gateway for AWS。它内置于 CLI 二进制文件中，以单个无状态容器运行，后端用 PostgreSQL。开箱即提供 OIDC 身份认证、集中管理的策略、OpenTelemetry 遥测、多区域 Amazon Bedrock 路由，以及按用户、按组、按组织的支出上限。如果负载混合了多个模型、横跨多个供应商，通用网关依然是更合适的选择：可以参考 LiteLLM 通过 Amazon ECS on AWS Fargate 的参考架构，或者《Build a proactive AI cost management system for Amazon Bedrock, Part 2》里介绍的无服务器方案。

如何选层

起决定作用的有两个因素。第一是连接方式：如果开发者直连 Amazon Bedrock、不走任何代理，那就只能选 Tier 1 和 Tier 2。第二是支出增速：如果每月支出已经到了几百万美元，现在就上强制执行；如果告警还能再撑一个季度，先把 Stage 1 和 Stage 2 做好，等数据摆在那里了再加强制执行也不迟。

大多数组织应该分阶段推进：先在 Tier 1 观察，再逐步升级。这三个阶段都是过渡手段，不是终点：Well-Architected Agentic AI Lens 已经把 agent 成本治理列为架构层面的一等关注点，而 Stage 1 建立起来的归因基础，正是任何托管式强制策略的落脚点。

Stage 4：优化默认配置

Amazon Bedrock 上的大部分浪费，不是个人不小心，而是平台默认值没人设。影响最大的两个杠杆，都掌握在平台手里。

模型路由

不是每项任务都需要前沿模型。日常补全（样板代码、lint 建议、小重构）可以交给更小、更便宜的模型，把高质量留给复杂推理。具体做法有两种：在同一个模型家族内做智能提示词路由，或者在网关层配置路由规则（完整操作流程见《用 Amazon Bedrock Intelligent Prompt Routing 和提示词缓存降低成本和延迟》）。

哪些工作流可以降级，这是个实证问题：从 Stage 2 拉出工作负载排行榜，对排名靠前的条目用便宜模型跑一次质量评估，评估过关的就切过去。对于 agentic 编码这类场景，样板代码占了绝大部分调用量，把一半以上的调用落到便宜模型上，是可以实现的目标。

提示词缓存

提示词缓存奖励的是稳定、重复的前缀。截至 2026 年 10 月，Amazon Bedrock 公布的美国东部（弗吉尼亚北部）区域 Anthropic Claude 模型定价是：缓存写入按基础输入价格的 1.25 倍计费，TTL 为 5 分钟（TTL 设为 1 小时则为 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。候选对象可以直接从调用日志里筛出来：字段 requestMetadata.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

| 限制 25

注意：上面查询中的字段路径只是示例。请对照你自己的调用日志结构核实，不同模型、API 操作和日志配置可能不一样。

应用层优化

第三类节省空间属于应用团队，不在平台侧：用即时检索代替把所有上下文一股脑塞进去、压缩长对话、把稳定且高频的工作流蒸馏到更小的模型上。平台要做的是让这些节省看得见：公布按工作流统计的 token 排行榜，给每个模型和工作流设定 token 上限，让那些负责高成本工作流的团队清楚看到自己排在哪。

阶段 5：把循环跑起来

前四个阶段产出数据，这一步把数据变成决策。

平台团队维护一个常态化的健康看板，盯四个信号：

模型组合：哪些模型被调用、调用频率如何——这是衡量路由纪律最直接的指标。
请求失败率：错误、限流和超时。每次重试都会增加延迟；如果客户端超时了，但服务端其实仍完成了请求，就可能被计费两次——一次是被放弃的调用，一次是重试。
缓存有效性：阶段 4 里的读/写比例。
元数据覆盖率：生产调用中带有完整元数据的比例。每一个没覆盖到的调用都是一个归因盲区，会悄悄拉低其他所有指标的可信度。

某个信号出现漂移时，解决办法是改策略（路由规则、token 上限、强制元数据），而不是发封邮件让团队“注意一点”。

资金循环

FinOps 用同一套数据跑资金循环。归因干净之后，异常检测就变成一条调查流水线，而不是慌慌张张的全员动员：某个打了标签的团队或应用出现用量尖峰，只需要去查阶段 2 的排行榜，不用开作战室。分摊计费（chargeback）则基于 CUR 按团队和应用分组来做。

记分卡

下面这些阈值只是起点，不是规定。在把它们定为策略之前，先用你自己的 fleet 数据和价格档位校准一遍。

| 维度 | 指标 | 绿色 | 黄色 | 红色 |

| 单位经济效益 | 每次成功产出的成本 | ≤ 预算 | 预算的 1–1.5 倍 | > 预算的 1.5 倍 |
| 人均成本 | 每位开发者每日花费 | < $100 | $100–$300 | > $300 |
| 模型路由 | 调用低成本模型的比例 | > 50% | 30–50% | < 30% |
| 缓存效率 | 缓存读取命中率 | > 60% | 30–60% | < 30% |

绿色表示工作负载在其经济承受范围之内运行。黄色表示路由或缓存纪律正在松懈。红色表示支出集中在高价模型或未缓存的上下文上，此时第 3、4 阶段的控制手段就是补救路径。请定期审查这张评分卡（高频团队每周一次，其他团队每两周一次），并把它当作 FinOps 与平台团队共同的决策面。

总结

本文中，你了解了如何构建一套五阶段运营模型，把 Amazon Bedrock 的花费从失控状态带到全面治理：

归因：用 IAM 主体标签（principal tags）、会话标签（session tags）和 CUR 2.0，把每一块钱归到具体的负责人头上。
观测：通过模型调用日志和打上标记的请求元数据，观测每一次请求。
强制：在与风险相匹配的层级上执行预算约束——只监控、违规时 IAM 拒绝，或同步网关阻断。
优化：用智能提示路由（intelligent prompt routing）和提示缓存（prompt caching）优化平台默认配置，从源头消除浪费。
运营：运行评分卡并保持审查节奏，把遥测数据转化为策略决策。

注意评分卡的第一行：是每次成功产出的成本，不是每次调用的成本。这个区别正是本手册交接之处。这里讲的一切，都是为了让 Amazon Bedrock 的花费可见、可归因、有上限、够高效；但一个工作流即使效率再高，也可能根本不值得运行。要判断这一点，需要拿智能体（agent）与它替代的人工流程作对比——这属于产品和数据分析的范畴，而非 FinOps 的范畴。成本平台贡献的是基础：干净的归因和按工作流划分的成本数据，正是产出度量所需的对照输入。把五个阶段建好，你就能端到端地回答：谁花的、为什么花、有没有被控制住。这就是管理 Amazon Bedrock 成本的含义，也是每月账单审查与一套运营模型之间的差别。

开始动手时，先部署“Amazon Bedrock 上的 Claude Code 指南”中覆盖第 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（Go-To-Market，市场推广）负责人，在产品管理、工程和市场推广领域有 20 多年经验。在担任现职之前，他曾在 Uber、Turing 和 eHealth 等领先科技公司主导 AI/ML 产品的产品管理工作。他热衷于推动生成式 AI 技术发展，并让生成式 AI 产生实实在在的影响。

Benedict Augustine

Benedict 是一位资深产品 GTM 负责人，长期与顶级 ISV 合作，推动 Amazon Bedrock 的使用。

本文给出一套五阶段运营模型，用来管理 Amazon Bedrock 成本：让每一美元都能追溯到具体负责人、让每个请求都可观测、把预算约束落到实处、优化平台的默认配置，并建立固定的复盘节奏。本文面向 FinOps 团队和平台工程团队。

查看原文