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

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

生成式 AI 的成本管理，是构建应用的团队与对云支出负责的团队之间的共同责任。许多团队从比较各模型的每令牌费率开始，并要求应用团队缩短提示。这些步骤有帮助，但它们回答不了财务和工程负责人在用量扩大时会问的问题：哪个团队花了这笔钱，花在哪个工作负载上，这笔支出是否在已批准的预算之内？

智能体工作负载使这些问题更紧迫。对话式助手通常每个用户回合发起一次模型调用。智能体工作流，例如一个会规划变更、读取文件、调用工具并迭代的 AI 编码助手，每个任务会发起许多次调用，并且每一次都携带更大的上下文。因此令牌消耗随你授予工作流的自主程度以及它所携带的上下文大小而扩展，而不是随用户交互次数扩展。因为消耗是工作负载如何被设计与运行的函数，生成式 AI 的成本管理是一门架构与运维学科。公布的平均值不能很好地替代你自己的数字：用 AWS Pricing Calculator 和 Amazon Bedrock 定价页来为费率建模，并用本文的步骤 2 来测量你的工作负载实际消耗了什么。

解决办法不是更便宜的模型或更短的提示。它是一种运营模型：一个可重复的循环，把每一美元归属到一个所有者，使每个请求可观测，在超支复合之前对预算发出警报并强制执行，优化驱动大部分浪费的平台默认值，并按节奏复核整个系统。

在本文中，你将学习如何用五个步骤管理 Amazon Bedrock 成本。你把每一美元归属到一个所有者，使每个请求可观测，用预算和强制执行来控制支出，优化驱动大部分可避免支出的平台默认值，并运行一套把数据变成决策的复核节奏。这种方法由 AWS 构件搭建，你可以定制它并应用到自己的环境。本文为两类读者而写：负责归属、费用分摊、预算和异常复核的 FinOps 从业者，以及负责日志、请求元数据、强制执行和路由默认值的平台工程团队。

一张图里的运营模型

五个阶段，作为一个循环来运行。归属：每一美元 Amazon Bedrock 支出都落到计费流水线中的一个身份、团队和应用上。观测：每个请求都被记录足够的元数据，以解释是什么产生了这笔支出。强制执行：预算要有约束力，至少有警报，并在风险要求的地方有硬阻断。优化：平台默认值（模型路由、缓存、令牌上限）在中心去掉浪费，而不是要求每个团队都小心。运营：一张小记分卡和一套复核节奏把数据变成决策。FinOps 主导第一和第五阶段。平台工程主导第二到第四阶段。复核是联合的。这些阶段是有意排序的。每一阶段都依赖它前面的阶段，直接跳到优化、却没有归属和可观测性的团队是在猜测。

[图：五阶段 Amazon Bedrock 成本运营模型循环：归属、观测、强制执行、优化、运营]

图 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 密钥。

设置是四步：

• 在你的 CUR 2.0 数据导出中打开 IAM 主体数据。

• 用团队、应用和成本中心等业务维度为 IAM 主体打标签。对于联合访问，配置你的身份提供者，通过 OIDC 或 SAML 声明传递会话名称和标签。

• 在 AWS Billing 中把这些标签激活为成本分配标签（控制台或 UpdateCostAllocationTagsStatus API）。

• 分析这些标签：它们在 CUR 2.0 中以 iamPrincipal/ 前缀出现（例如 iamPrincipal/team），并在激活后 24–48 小时内出现在 AWS Cost Explorer 的 IAM 类别下，可以按团队、应用或成本中心筛选和分组。

这是账单级的、按身份的归属，不需要自定义基础设施。

共享角色问题

最值得注意的模式是共享角色问题，因为大多数平台在这里悄无声息地失去归属。一个通过单个 IAM 角色调用 Amazon Bedrock 的大语言模型（large language model，LLM）网关，会把每一美元都归属到那一个角色，完全消除按用户的可见性。修复办法是按用户的会话管理。网关为每个用户代入一次 Amazon Bedrock 调用角色，把用户身份作为角色会话名称传入，把他们的属性作为会话标签传入，然后把这些凭据缓存最多一小时（每个用户每小时一次 AWS Security Token Service（AWS STS）调用，而不是每个请求一次）。

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

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 还提供另外两种归属机制，各自适合不同模式。应用推理配置文件（application inference profiles）是在 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 工作负载，使用 projects。

阶段 2：使每个请求可观测

CUR 告诉你谁花了钱。调用日志告诉你发生了什么。Amazon Bedrock 支持把请求数据、响应数据和元数据的模型调用日志记录到 Amazon CloudWatch Logs、Amazon Simple Storage Service（Amazon S3），或两者。用 Amazon CloudWatch 做快速的运维查询，用 S3 加 Amazon Athena 做长期商业智能（business intelligence，BI）访问。把日志当作基础设施，而不是手工开关：通过代码置备日志组或存储桶，定义保留和加密策略，并在环境设置期间验证投递。如果日志只存在于开发环境或只存在于一个区域，用量一增长，你的成本计划就会变得支离破碎。

日志也补上了延迟缺口：CUR 归属大约滞后 24 小时，但 CloudWatch 加 OpenTelemetry 可以支撑近实时仪表板，在几分钟内显示每位开发者的支出（Analyzing Claude Code usage with CloudWatch and OpenTelemetry 端到端演示了这一点）。

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

原始日志回答身份级问题。要回答工作负载级问题（哪个功能、工作流或租户产生了这些令牌），就在每次调用上盖上请求元数据。Amazon Bedrock 在调用日志中捕获这些元数据，供稍后分析：

下面的示例通过美国跨区域推理配置文件，在 Amazon Bedrock 上使用 Anthropic Claude Sonnet 5.5。模型完整列表见 Supported foundation models in Amazon Bedrock。各区域可用性见 Model support by AWS Region in 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 并不强制请求元数据，而当每个应用各行其是时，团队会很快漂移到不一致的模式。平台团队应在共享 SDK 包装或网关中集中注入强制元数据，规范化键集合，并把元数据覆盖率当作平台健康指标。

诊断查询

有了日志和元数据，CloudWatch Logs Insights 可以回答那些常设问题。谁消耗的令牌最多：

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 的工具。没有东西能硬停支出，因此你是在问题发生之后才看到它。它适合早期采用，此时警报加上人工干预就够了。两份构建者指南演练了它：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 中累计每位用户的令牌和美元计数器。当用户突破其阈值时，该函数把其身份加入一条共享 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 机群，面向 AWS 的 Claude apps gateway 是官方建议。它随 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 定价，对缓存写入按基础输入费率的 1.25 倍计费，存活时间（time-to-live，TTL）为 5 分钟（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 操作和日志配置而不同。

应用级优化

第三类节省（即时检索而不是塞满的上下文、长对话的压缩、把稳定的高量工作流蒸馏到更小的模型上）属于应用团队，而不是平台。平台的工作是让这些节省可见：发布按工作流的令牌排行榜，按模型和工作流设置令牌上限，并让拥有昂贵工作流的团队准确看到自己站在哪里。

阶段 5：运营这个循环

前四个阶段产出数据。这一阶段把它变成决策。平台团队运行一块常设健康仪表板，带四个信号：

• 模型组合：哪些模型被调用以及调用频率，这是路由纪律的直接度量。

• 失败请求率：错误、限流和超时。每一次重试都增加延迟，而服务端仍会完成的请求上的客户端超时可能被计费两次，一次是被放弃的调用，一次是重试。

• 缓存有效性：来自阶段 4 的读取相对写入之比。

• 元数据覆盖率：带有完整元数据的生产调用百分比。每一次未覆盖的调用都是一个归属盲点，会悄悄劣化其他每一个数字。

当一个信号漂移时，补救是一次策略变更（路由规则、令牌上限、元数据强制执行），而不是一封要求团队小心的电子邮件。

资金循环

FinOps 在同一数据上运行资金循环。当归属干净时，异常检测变成一条调查流，而不是一场惊慌的全员动员：被标记的团队或应用中的一次尖峰，会触发在阶段 2 排行榜中的查找，而不是一间作战室。费用分摊按团队和应用对 CUR 分组来运行。

记分卡

下面的阈值是起点，不是处方。在把它们采纳为策略之前，对照你自己的机群数据和定价层级校准它们。

绿色意味着工作负载在其经济包络内运行。黄色意味着路由或缓存纪律正在下滑。红色意味着支出集中在高价模型或未缓存的上下文上，阶段 3 和阶段 4 的控制是补救路径。按固定节奏复核这张记分卡（高速机群每周，否则每两周），并把它当作 FinOps 与平台的联合决策面。

结论

在本文中，你学习了如何构建一个五阶段运营模型，把 Amazon Bedrock 支出从不受控带到完全受治理：

• 使用 IAM 主体标签、会话标签和 CUR 2.0，把每一美元归属到一个所有者。

• 通过模型调用日志和盖上的请求元数据，观测每个请求。

• 在与你的风险相匹配的层级上强制执行预算：仅监控、违约时 IAM 拒绝，或同步网关阻断。

• 用智能提示路由和提示缓存优化平台默认值，在中心去掉浪费。

• 运营记分卡和复核节奏，把遥测变成策略决策。

注意那张记分卡的第一行：每次成功结果的成本，而不是每次调用的成本。这个区分是本实操手册交棒的地方。这里的一切使 Amazon Bedrock 支出可见、可归属、有上限且有效率，但一个工作流可以完全有效率，却仍然不值得运行。做出那个决定需要对照它所替代的人工流程来测量智能体，这是产品和分析学科，而不是 FinOps 学科。成本平台贡献的是基础：干净的归属和按工作流的成本数据，正是结果测量要去连接的输入。

构建这五个阶段，你就可以端到端回答：谁花的，为什么花，以及它是否受控。这就是管理 Amazon Bedrock 成本的含义，也是月度账单复核与一套运营模型之间的差别。

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

PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/managing-amazon-bedrock-costs-end-to-end-a-playbook-for-finops-and-platform-teams