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

端到端管理 Amazon Bedrock 成本：FinOps 与平台团队的操作指南 | 人工智能

端到端管理 Amazon Bedrock 成本：FinOps 与平台团队的操作指南

生成式 AI 的成本管理是构建应用程序的团队与负责云支出的团队之间的共同责任。许多团队最初会通过比较每种模型的每 token 价格，并要求应用团队缩短提示词来控制成本。这些措施有一定帮助，但当使用规模扩大时，财务和工程领导者会提出更关键的问题：这笔支出属于哪个团队？用于哪个工作负载？该支出是否在批准的预算范围内？

智能代理工作负载使这些问题更加紧迫。典型的对话助手通常每个用户交互只调用一次模型。而像能够规划更改、读取文件、调用工具并迭代的 AI 编码助手这样的智能代理工作流，每个任务会触发多次模型调用，并且每次调用都携带更大的上下文。因此，token 消耗量取决于工作流的自主程度和上下文规模，而非用户交互次数。由于消耗量取决于工作负载的设计和运行方式，生成式 AI 的成本管理已成为架构和运营层面的学科。公开的平均数据无法替代实际数据：使用 AWS 定价计算器和 Amazon Bedrock 定价页面来建模费率，并使用本文第 2 步来测量工作负载的实际消耗。

解决方案不是选择更便宜的模型或缩短提示词，而是建立一个运营模型：一个可重复的闭环，将每一美元支出归因到负责人，使每次请求都可观察，提前预警并强制执行预算以防止超支累积，优化驱动大多数浪费的平台默认设置，并定期审查整个系统。

在本文中，您将学习如何通过五个步骤管理 Amazon Bedrock 成本。您将实现每一美元支出的归因，使每次请求都可观察，通过预算和强制执行控制支出，优化导致大多数可避免支出的平台默认设置，并通过定期审查机制将数据转化为决策。该方法基于 AWS 的构建模块，您可以根据需要进行定制并应用到自己的环境中。本文面向两类读者：负责归因、分摊、预算和异常审查的 FinOps 实践者，以及负责日志记录、请求元数据、强制执行和路由默认设置的平台工程团队。

一图概览运营模型

五个阶段，以循环方式运行。归因：在计费流程中，每一美元 Amazon Bedrock 支出都会关联到某个身份、团队和应用。观察：每次请求都会记录足够的元数据以解释支出来源。强制执行：预算具有约束力，最低触发预警，高风险场景下设置硬性限制。优化：平台默认设置（模型路由、缓存、token 限制）从中心层面消除浪费，而非要求每个团队自行注意。运营：通过小型仪表板和定期审查机制将数据转化为决策。FinOps 负责第一和第五阶段。平台工程团队负责第二至第四阶段。审查由双方联合进行。各阶段的顺序经过精心设计。每个阶段都依赖于前序阶段，跳过归因和可观测性直接进行优化的团队实际上是在猜测。

图 1：五阶段运营模型，以持续循环方式运行

第一阶段：归因每一美元支出

你无法管理无法归因的事物，而所有下游流程（费用回退、预算、执行、异常检测）都依赖于这一阶段。基础是 Amazon Bedrock 的细粒度成本归因（参见《Amazon Bedrock 的细粒度成本归因介绍》）：Amazon Bedrock 自动将推理成本归因到发起调用的 AWS 身份和访问管理（IAM）主体，无需任何资源管理。调用者的 ARN 会出现在 AWS 成本和使用报告（CUR）2.0 的 line_item_iam_principal 列中，覆盖范围包括 IAM 用户、角色、联合身份和 API 密钥。

设置过程分为四个步骤：

• 在 CUR 2.0 数据导出中启用 IAM 主体数据。
• 使用团队、应用和成本中心等业务维度对 IAM 主体进行标记。对于联合访问，配置你的身份提供商通过 OIDC 或 SAML 声明传递会话名称和标签。
• 在 AWS 计费中将这些标签激活为成本分配标签（控制台或 UpdateCostAllocationTagsStatus API）。
• 分析这些标签：它们会在 CUR 2.0 中以 iamPrincipal/ 前缀显示（例如 iamPrincipal/team），并在激活后 24-48 小时内出现在 AWS 成本分析器的 IAM 类别中，可按团队、应用或成本中心进行过滤和分组。

这是无需自定义基础设施即可实现的发票级、按身份归因的解决方案。

共享角色问题

最需要关注的模式是共享角色问题，因为这是大多数平台静默丢失归因的地方。通过单个 IAM 角色调用 Amazon Bedrock 的大型语言模型（LLM）网关会将所有费用归因到该角色，完全消除按用户可见性。解决方案是按用户会话管理。网关按用户一次假设 Amazon Bedrock 调用角色，将用户身份作为角色会话名称，将用户属性作为会话标签传递，然后缓存这些凭证最多一小时（每用户每小时一次 AWS 安全令牌服务（AWS STS）调用，而非每次请求）。

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

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"}
    ]
)

关于应用推理配置文件和项目的说明

Amazon Bedrock 提供了另外两种归因机制，分别适用于不同的使用场景。应用推理配置文件是预先创建的、按应用划分的 bedrock-runtime 端点资源，包含成本分配标签。您需要为每个应用、每个模型、每个 AWS 区域创建一个配置文件，调用方通过引用该配置文件的 ARN 进行关联，这种模式适合应用和模型组合较少且稳定的团队。项目和工作区则用于 bedrock-mantle 端点（响应 API、聊天补全 API）。项目不绑定特定模型，因此一个项目 ID 可跨多个模型复用，这种模式适合模型使用频繁变化的团队。您在客户端初始化时传递项目 ID，其标签会同步至 CUR 2.0 和 Cost Explorer（参见《使用 Amazon Bedrock 项目管理 AI 成本》）。对于兼容 OpenAI 的工作负载，项目是 Amazon Bedrock 的归因路径。

对于 bedrock-runtime 工作负载，我们建议通过 IAM 主体归因（会话标签）作为主要机制。该方案可随身份系统扩展，无需预先创建资源，且覆盖所有模型和 API 操作。当少量稳定业务单元需要发票级计费隔离且无需调整身份设计时，应用推理配置文件表现更佳。对于使用响应 API 或聊天补全 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 使用情况》完整演示了这一流程）。

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

原始日志可回答身份级问题。要回答工作负载级问题（哪些功能、工作流或租户生成了令牌），请在每次调用时添加请求元数据。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 可回答常见问题。谁消耗了最多的令牌：

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 的工具。无法硬性阻止支出，因此只能在问题发生后发现。适合早期采用者，警报加人工干预已足够。两个构建者指南逐步演示：限制 Bedrock 使用和控制成本，以及使用 AWS Budgets 和标签在 Claude Code 中管理 Bedrock 的深度解析。

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

一个聚合的 AWS Lambda 函数从调用日志数据中在 Amazon DynamoDB 中统计每个用户的令牌和美元计数器。当用户超出阈值时，该函数会将其身份添加到共享的 IAM 拒绝策略（拒绝 bedrock:*）中，直到每月重置或管理员覆盖。此执行完全基于 IAM 和 Amazon Bedrock 日志，推理路径中没有第三方组件，且适用于直接调用 Amazon Bedrock 的工具。AWS Solutions Library 中的 Claude Code 与 Amazon Bedrock 指南提供了可部署的变体。在颁发凭证时，它会检查每个用户的使用情况是否超出个人或团队限制，一旦用户超出限制即扣留凭证。由于该检查使用客户端发出的使用遥测数据，其统计结果可能与 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成本管理系统，第二部分》中描述的无服务器替代方案。

选择层级

两个因素最为关键。

连接性：如果开发人员直接调用Amazon Bedrock且不使用代理，仅Tier 1和Tier 2可行。

支出速度：如果月支出已达到数百万美元，应立即构建控制机制。如果警报还能维持一个季度，应优先投资Tier 1和Tier 2，待数据需求出现时再添加控制。

大多数组织应分阶段实施：从Tier 1观察开始，然后逐步升级。将三个层级都视为桥梁而非终点：Well-Architected Agentic AI Lens已将代理成本治理作为首等架构问题进行规范化，而Stage 1的归因基础将是任何托管控制机制的底层支撑。

Stage 4：优化默认配置

大多数Amazon Bedrock资源浪费并非源于个人疏忽，而是平台默认配置未被设置所致。影响最大的两个杠杆均由平台控制。

模型路由

并非所有任务都需要前沿模型。常规任务（模板生成、代码检查建议、小规模重构）可通过智能提示路由在模型家族内部运行，或通过网关路由规则使用更小、更便宜的模型，同时将高质量保留给复杂推理（完整操作指南请参见《通过Amazon Bedrock智能提示路由和提示缓存降低成本和延迟》）。哪些工作流可以降级使用低成本模型是一个实证问题：从Stage 2获取工作负载排行榜，对前几项任务在低成本模型上运行质量评估，将通过评估的流程进行路由。对于以模板生成为主的代理编码舰队，超过一半的调用转向低成本模型是一个可实现的目标。

提示缓存

提示缓存奖励稳定的重复前缀。截至2026年10月，Amazon Bedrock在美国东部（北弗吉尼亚）发布的Anthropic Claude模型定价中，缓存写入操作按基准输入费率的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

应用层优化

第三类节省（即时检索替代填充上下文、长对话压缩、将稳定高流量工作流提炼到小模型）属于应用团队而非平台。平台的职责是使这些节省可见：发布按工作流划分的每令牌排行榜，按模型和工作流设置令牌限制，并让拥有高成本工作流的团队清楚了解自身位置。

第5阶段：运行循环

前四个阶段生成数据。这一阶段将其转化为决策。平台团队运行一个持续健康仪表板，包含四个信号：

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

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

• 缓存效率：第4阶段的读写比例。

• 元数据覆盖率：生产调用中具有完整元数据的比例。每个未覆盖的调用都是归因盲点，会悄无声息地降低所有其他指标。

当信号偏离时，补救措施是政策变更（路由规则、令牌限制、元数据强制执行），而不是通过邮件提醒团队小心。

资金循环

FinOps在相同数据上运行资金循环。当归因清晰时，异常检测会转化为调查流程而非恐慌式全员会议：标记团队或应用的激增会触发第2阶段排行榜的查询，而非作战室会议。按团队和应用的CUR分组进行费用回溯。

评分卡

以下阈值是起点而非处方。在采用为政策前，请根据您自己的舰队数据和定价层级进行校准。

维度 | 指标 | 绿色 | 黄色 | 红色 | 单位经济 ---|---|---|---|---|--- 成功结果的单位成本 | ≤预算 | 1–1.5倍预算 | | |

1.5倍预算

每开发者成本

开发者每日支出

<100美元

100–300美元

300美元

模型路由

调用成本效益模型的占比

50%

30–50%

<30%

缓存效率

缓存读取命中率

60%

30–60%

绿色表示工作负载在其经济范围内运行。黄色表示路由或缓存纪律有所松懈。红色表示支出集中在高端模型或未缓存的上下文中，此时Stage 3和Stage 4的控制措施是补救路径。定期审查该评分表（高速舰队每周审查一次，其他情况每两周审查一次），并将其视为联合FinOps加平台决策界面。

结论

在本文中，你学习了如何构建一个五阶段运营模型，将Amazon Bedrock支出从无控制状态转变为完全受控状态：

• 使用IAM主体标签、会话标签和CUR 2.0，将每一美元归因于所有者。
• 通过模型调用日志和带有时间戳的请求元数据观察每一次请求。
• 在与风险匹配的层级执行预算：仅监控、IAM违规阻止或同步网关阻断。
• 通过智能提示路由和提示缓存优化平台默认设置，从中心消除浪费。
• 运营一个评分表和定期审查机制，将遥测数据转化为策略决策。

注意该评分表的第一行：是每成功结果的成本，而非每调用的成本。这一区别标志着该操作手册的交接点。此处所有内容使Amazon Bedrock支出变得可见、可归因、有上限且高效，但一个工作流可能完美高效却仍不值得运行。判断这一点需要将代理与它取代的人工流程进行对比，这属于产品和分析领域而非FinOps范畴。成本平台的贡献在于奠定基础：清晰的归因和每工作流成本数据正是结果度量所需的输入。

构建这五个阶段后，你可以从端到端回答：是谁支出的、原因是什么、以及是否受控。这就是管理Amazon Bedrock成本的含义，也是月度账单审查与运营模型之间的区别。

要开始操作，请部署Claude代码的Guidance与Amazon Bedrock参考架构（适用于Stage 1–3），然后使用成本归因最佳实践文档配置您的标签策略。

作者简介

'\"