按 IAM 身份追踪并限制 Bedrock 开支

AWS ML Blog#AWS#成本控制#权限管理

Editor brief · 编辑速览

通过 IAM 主体标签归属费用，再用 CUR 2.0 或 Cost Explorer 查看各身份的 Bedrock 支出。AWS Budgets 可在达到阈值后触发拒绝策略，常见场景无需修改应用代码。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

Amazon Bedrock 的费用账单能告诉你花了多少钱，却未必能直接回答「谁花的、哪个团队该承担、超预算后怎么处理」。AWS 给出的方案，是把 IAM 身份、成本报表和预算动作串起来，用原生能力完成费用归属与访问限制，常见场景无需编写应用代码。

但它有两个关键前提：账单能区分用户，不代表权限也能按用户切断；预算触发限制，也不代表费用会停在阈值上。对正在接入模型的团队，这两条边界比配置步骤更值得先弄清。

想按人算账，先看请求用了谁的身份

方案分为三步：归属、报表、执行。Amazon Bedrock 会自动记录每次推理请求的 IAM principal，也就是发起调用的 IAM 用户或角色，不需要修改模型推理调用。

如果每个人或应用都有独立角色，先到 Cost Explorer，把 Service 筛选为 Amazon Bedrock，再按可用身份或标签维度分组，可能已经够用。需要补充团队、部门、成本中心时，再添加标签。

独立角色适合使用 principal tags，即直接挂在 IAM 用户或角色上的静态标签。原文通过 aws iam tag-role，给 --role-name BedrockDeveloperRole-alice 设置 --tags Key=user,Value=alice@example.com Key=team,Value=platform Key=CostCenter,Value=CC-1001。

共享角色则需要 session tags：在获取临时角色凭证时，为这次会话带上用户信息。同名标签同时存在时，会话标签覆盖角色标签。可通过三条路径传入：

sts:AssumeRole 使用 --tags，适合网关按用户或租户获取凭证。
AssumeRoleWithWebIdentity 使用 OIDC ID token 中的 https://aws.amazon.com/tags claim。
AssumeRoleWithSAML 将身份提供方属性映射到 PrincipalTag:*。

角色信任策略必须允许 sts:TagSession。已有 saml:sub 不代表它自动成为计费标签，还要单独配置映射。每个 IAM 用户或角色最多可应用 50 个主体或会话标签。

费用归属能细到什么程度，首先取决于应用如何使用 IAM 身份。

尤其是统一 LLM 网关：默认记录的是网关执行角色。没有额外身份设计，所有调用都会记在网关名下。

报表可以很轻，但标签不会立即进入账单

标签设置后，还要到 Billing and Cost Management 的 Cost allocation tags 页面，按 IAM principal 类型选择并激活。在 AWS Organization 中，这一步只能由管理账户，也就是付款账户完成。Billing Console 的访问权限也独立于多数 IAM 权限，需要提前确认。

这里有一段容易误判为配置失败的等待时间：主体至少调用一次 Amazon Bedrock 后，标签键才可能出现在激活列表；新标签出现最多需要 24 小时，激活后进入账单还可能再等 24 小时。默认不会追溯历史数据。

日常看团队或个人费用，Cost Explorer 的图表和表格通常就够了。需要 SQL、明细分析时，再配置 CUR 2.0。

创建 CUR 2.0 (Standard) 导出时，要勾选 Include caller identity (IAM principal) allocation data，时间粒度选 Hourly，报表集成选 Amazon Athena。这会使用 Parquet，并向目标 S3 桶交付建表脚本。脚本或其中的 Glue crawler/DDL 仍需执行一次，控制台配置不会自动替你建好 Glue 表。

原文用下面的查询，按团队和用量类型汇总费用：

SELECT
    tags['iamPrincipal/team'] AS team,
    line_item_usage_type,
    SUM(line_item_unblended_cost) AS cost
FROM cur2_view
WHERE product_servicecode IN ('AmazonBedrock', 'AmazonBedrockService')
AND billing_period = '2026-09'
GROUP BY 1, 2
ORDER BY 3 DESC

重点看 product_servicecode IN (...)：Bedrock 费用可能落在 AmazonBedrock 和 AmazonBedrockService 等不同值下，只筛一个可能漏算。cur2_view 要核对实际表名，billing_period 也可能被导出中的起始日期或年、月分区字段替代。

主体和会话标签使用 iamPrincipal/ 前缀，资源标签使用 resourceTags/。旧导出不会自动补齐历史身份数据，应创建启用调用者身份选项的新导出；传统 CUR 则不包含这些 IAM principal 字段。

费用口径也不能只盯输入和输出。原文列出四种 token：input、output、cache read、cache write，各有独立用量类型和单价。缓存用得越多，只算前两项的偏差可能越大。价格还受 service tier 和跨 Region 推理影响，应匹配每条账单记录，不能给一个模型统一套单价。

另外，CUR 2.0 的「明细」仍是按小时或天聚合的数据，不是逐请求流水。

超预算后可以自动降级，但不能承诺实时封顶

AWS Budgets 的执行方式，是在阈值触发后给指定 IAM 用户、组或角色附加策略。原文示例通过 Deny 限制高价模型，同时保留低价模型，让用户还能继续工作：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:*::foundation-model/[HIGHER-COST-MODEL-ID]"
      ]
    }
  ]
}

要注意 Resource 中的 [HIGHER-COST-MODEL-ID]，需要替换成实际限制的模型 ID；这份示例策略的范围由具体模型 ARN 决定。

权限配置涉及两个身份。配置预算的人需要 AWSBudgetsActionsWithAWSResourceControlAccess，其中包含预算权限和带条件的 iam:PassRole。AWS Budgets 真正执行动作时，还需要另一个角色：信任 budgets.amazonaws.com，用 aws:SourceArn、aws:SourceAccount 限定来源，并授予 iam:AttachRolePolicy、iam:DetachRolePolicy。如果使用 SCP，还涉及 organizations:AttachPolicy、organizations:DetachPolicy；只有管理账户能应用 SCP。

接着创建限定 Amazon Bedrock、按身份或标签筛选的成本预算。阈值可选 Actual，依据已发生费用触发；也可选 Forecasted，依据预测触发。动作选自动执行 Yes，或选 No，由人在 Alert details 页面批准，并至少配置一项通知解释访问变化。

一个预算可以配置多个阈值，一个阈值也能绑定多个动作。例如达到 80% 禁用高价模型，达到 100% 再禁用中档模型，始终保留低价模型。

这是一套延迟生效的预算护栏，不能当成精确的实时额度系统。

AWS Budgets 的数据每天最多刷新三次，动作执行前可能已经超支。另一个限制更直接：给共享角色附加 Deny，会影响使用该角色的所有人，即使预算是按某个用户标签统计的，也不会自动只拦这个用户。

我的判断

这套方案最有价值的地方，是把「看见费用」和「改变权限」接了起来。对于已经按人或应用分配独立 IAM 角色、能够接受账单延迟的团队，它能减少维护自定义计费与权限执行代码的工作。

但标题中的「cap」容易让人期待过高。原文没有给出部署耗时、实际超支幅度，也没有对比原生方案与自建方案的维护成本，因此「省多少工作」仍是架构层面的判断，不是经过对照实验的结论。

原文提到的另一条路线，是 IAM Identity Center、基于模型调用日志的 Athena 查询和 Lambda 执行循环，可以提供接近实时的控制，代价是团队要维护代码。若业务必须按共享网关里的终端用户限制用量，原生预算动作的角色粒度就未必够用。

会话标签也不能补上所有缺口：它在 AssumeRole 时绑定，同一套会话凭证的后续请求使用相同值；它不会写入模型调用日志，日志记录的是 identity.arn。需要请求级区分时，原文建议使用每用户独立的 RoleSessionName，或在每次调用的 request metadata 中设置用户信息。

能拿来做什么

给 Node 服务或 AI 编程工具接入 Bedrock 前，先确认调用身份是独立角色还是共享角色。独立角色可以直接评估预算动作，共享网关则要同时设计用户归属和执行粒度。
先用 Cost Explorer 验证标签是否进入账单，再决定是否引入 S3、CUR 2.0 和 Athena。需要 SQL 分析时，把四种 token、服务代码和实际账期字段一起核对。
将预算限制设计成分级降级，例如 80% 和 100% 分别限制不同档位模型，并通知受影响用户；业务预算还应考虑账单刷新期间继续发生的费用。
每次启用新模型，都检查查询和预算过滤条件是否覆盖对应用量类型。演练结束后，清理为验证方案创建且不再需要的资源，避免继续产生费用。