正文 · AI 翻译
生成式 AI 支出很难归属。在组织扩大 AI 使用权限之前，首席财务官和首席技术官通常希望弄清 3 个问题：每个人或每个团队花费多少，能否设置支出上限，以及实现这些目标需要多少工作。在上一篇文章《Tokenomics at Scale: How Jamf Built Real-Time Spend Enforcement for Amazon Bedrock》中，我们介绍了一个基于 AWS IAM Identity Center、通过 Amazon Athena 查询 Amazon Bedrock 模型调用日志，以及 AWS Lambda 构建的自定义管控闭环。这种方法提供近实时控制，但需要编写代码，并由你负责后续维护和运行。本文介绍如何仅使用 AWS 原生功能，实现按身份查看 Amazon Bedrock 成本并强制执行支出限额；对于常见场景，无需编写应用程序代码。该方法依赖 3 项功能：Amazon Bedrock 自动记录的 IAM 主体归属信息；用于报表的 AWS Cost and Usage Reports（CUR）2.0 或 AWS Cost Explorer；以及用于强制执行限制的 AWS Budgets 及其预算操作。完成后，你将拥有按身份统计的成本报告，以及在支出超过阈值时限制 Amazon Bedrock 访问权限的自动防护措施。方案概览 该方案分为 3 个部分：归属、报告和强制执行。归属。Amazon Bedrock 会自动记录每个推理请求对应的 AWS Identity and Access Management（IAM）主体身份，即 IAM 用户或角色，无需更改 Amazon Bedrock 模型推理调用。如果多个人共用一个角色，可以在代入角色时传递会话标签，补充用户级明细。如果每个人或每个应用程序都有自己的角色，角色上的主体标签就足够了。报告。将这些标签激活为成本分配标签，然后在 Cost Explorer 中查看控制台报表，或通过 CUR 2.0 数据导出进行详细的明细分析和 SQL 查询。强制执行。创建一个范围限定为 Amazon Bedrock、并按某个身份或标签值筛选的 AWS Budget，然后附加一个预算操作，在支出超过阈值时应用拒绝访问的 IAM 策略。以下各节结合实施步骤，详细介绍每个部分。前提条件 要部署此方案，你需要：一个已启用 Amazon Bedrock 模型访问权限的 AWS 账户。具有为 IAM 主体添加标签、激活成本分配标签、创建数据导出以及创建预算和预算操作的权限。通过 IAM 角色或 IAM 用户访问 Amazon Bedrock。已配置适当凭证的 AWS Command Line Interface（AWS CLI）。CUR 2.0 数据导出和用于接收导出数据的 Amazon Simple Storage Service（Amazon S3）存储桶。（可选，用于详细的明细分析。）Amazon Athena。（可选，用于查询导出数据。）AWS Billing Console 的访问权限与大多数 IAM 权限分开管理。开始前请确认你拥有该权限。操作步骤 在进行任何配置之前，先检查现有设置。Amazon Bedrock 会自动记录每个推理请求的调用者身份。打开 Cost Explorer，将 Service 筛选为 Amazon Bedrock，并按可用的身份或标签维度分组。对于每个应用程序或每个人已经使用不同 IAM 角色的账户，这可能已经提供了你所需的全部可见性。若要配置更多可见性：步骤 1 提供身份级可见性。步骤 2 至 4 添加标签维度和详细报告。步骤 5 添加强制执行措施。步骤 1：确定身份如何对应到用户 标签的设置方式取决于 IAM 主体的组织方式。每个人或每个应用程序使用一个角色。直接为每个 IAM 角色或用户附加主体标签。这些标签是静态的，适用于该主体发出的每个请求。使用 IAM 控制台或 AWS CLI：aws iam tag-role \ --role-name BedrockDeveloperRole-alice \ --tags Key=user,Value=alice@example.com Key=team,Value=platform Key=CostCenter,Value=CC-1001 多个人共用一个角色，或使用网关。主体标签无法区分共用角色的用户，因为每个会话都带有相同的标签。 改用会话标签，在代入角色时传入。会话标签是动态的，每个会话都可能不同。如果会话标签和主体标签使用相同的键，则该会话以会话标签为准。角色的信任策略必须允许 sts:TagSession。会话标签可以通过 3 种方式传入：对于按用户或租户代入角色的网关，使用带有 --tags 参数的 sts:AssumeRole；使用 AssumeRoleWithWebIdentity，在 OpenID Connect (OIDC) ID 令牌的 https://aws.amazon.com/tags 声明中携带标签（这是声明名称，不是供浏览的 URL）；使用 AssumeRoleWithSAML，在身份提供商的安全断言标记语言 (SAML) 断言中映射 PrincipalTag:* 属性。如果您的组织已为其他用途采集了 saml:sub 之类的声明，仅凭这一点并不能让它在这里可用。身份提供商必须另行将该属性映射为 PrincipalTag:* SAML 属性语句，并且角色的信任策略必须允许 sts:TagSession，它才能作为会话标签传递。这两项集成从同一个 SAML 断言中获取数据，但需要分别配置。常见的标签键包括 user、team、Department、CostCenter 和 Environment。每个 IAM 用户或角色最多可以应用 50 个主体标签或会话标签。图 1：使用主体标签与使用会话标签进行归因的比较。步骤 2：激活成本分配标签。在激活标签之前，它们不会出现在账单数据中。打开 AWS Billing and Cost Management Console。选择 Cost allocation tags。按 IAM principal 类型筛选。选择您的标签键，然后选择 Activate。在 AWS Organization 中，应在管理账户（付款账户）中激活 IAM 主体成本分配标签。成员账户无法自行激活。需要注意 2 点：只有主体至少发起过 1 次 Amazon Bedrock 调用后，标签键才会出现在此列表中；如果列表为空，请先进行一次测试调用。新应用的标签键可能需要最多 24 小时才会显示为可激活；激活后，可能还需要最多 24 小时才会开始填充到账单数据中。默认情况下，激活不会追溯应用，因此请在需要数据之前激活标签。步骤 3：创建包含调用者身份的 CUR 2.0 数据导出。如果 Cost Explorer 已足以满足您的报告需求，请跳过此步骤。在 Billing and Cost Management 控制台中，选择 Data Exports。选择 Create，并创建 CUR 2.0 (Standard) 导出。在 Additional export content 下，选择 Include caller identity (IAM principal) allocation data。在 Time granularity 下，选择 Hourly。在 Report data integration 下，选择 Amazon Athena。这会将文件格式设为 Parquet，更重要的是，还会将设置脚本与导出数据一同交付到您的 S3 存储桶。选择目标 Amazon S3 存储桶。运行交付的设置脚本（或该脚本定义的 Glue 爬网程序/DDL）1 次。这个步骤才会实际创建您将在步骤 4 中查询的 Glue Data Catalog 表。上述控制台操作流程不会自动为您创建该表。如果您已有在启用身份归因之前创建的 CUR 2.0 导出，它不会追溯包含身份数据。请创建一个选中调用者身份选项的新导出。在导出数据中，主体标签和会话标签显示为带有 iamPrincipal/ 前缀的列，资源标签则显示为带有 resourceTags/ 前缀的列。例如，标签键 team 显示为 iamPrincipal/team。AWS 在 aws-samples/sample-cur-iam-principal-bedrock-tracking 中发布了针对这一具体模式的现成查询集。步骤 4：读取数据。下图比较了读取数据的 2 种方式：通过 Cost Explorer 的纯控制台路径，以及使用 Amazon Athena 查询 CUR 2.0 导出数据的 SQL 路径。图 2：使用 Cost Explorer 与使用 CUR 2.0 和 Amazon Athena 进行报告的比较。控制台路径，无需自定义代码。将 Cost Explorer 筛选为 Amazon Bedrock，并按您的标签键分组，即可通过图表和表格查看各团队或各用户的支出。这能满足大多数定期报告需求，而且无需编写查询。SQL 路径，少量代码。 将 Amazon Athena 指向 CUR 2.0 导出数据，按 iamPrincipal/team 和使用类型汇总支出：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 注意事项：服务代码：Amazon Bedrock 支出可能记录在多个 product_servicecode 值下，例如 AmazonBedrock 和 AmazonBedrockService。表名：表名（cur2_view）取决于步骤 3 中的设置脚本创建 Glue 表时所用的名称。如果名称不同，请检查该脚本或 Glue 目录。无论表名是什么，列名都与 CUR 2.0 Parquet 架构一致。账单周期列：确认导出数据如何表示账单周期。有些导出数据使用 billing_period（YYYY-MM），另一些则按开始日期列或年/月列分区。编写任何查询时，都要记住以下两点。统计所有令牌类型：Amazon Bedrock 对 4 种令牌类型分别按不同费率计费：输入、输出、缓存读取和缓存写入。每种类型都是单独的账单明细项，有各自的使用类型和单价，因此只汇总输入和输出会低估费用。对于大量使用提示词缓存的工作负载，差额最大。有关最新信息，请参阅 AWS 文档《Understanding Amazon Bedrock pricing in CUR》。按账单明细项而非模型匹配费率：CUR 中的 Amazon Bedrock 定价取决于 3 个因素：令牌类型、服务层级，以及请求是否通过跨区域推理路由。区域内请求与跨区域请求的定价不同，使用类型也会反映服务层级。使用类型带有表示跨区域路由和服务层级的后缀，因此如果工作负载混用这些方式，应为每个账单明细项匹配相应费率，而不是对每个模型统一使用一种费率。相关示例请参阅 CUR 使用类型示例。步骤 5：使用 AWS Budgets 和预算操作添加强制限制。附加操作由 AWS Budgets 执行，因此此工作流程无需自定义代码。预算操作附加到特定的 IAM 用户、组或角色。只有当某人已经拥有自己的角色时，才能借此仅限制该人的访问权限。如果 Amazon Bedrock 流量通过多人共用的角色运行，那么附加到该角色的 Deny 操作会阻止使用该角色的所有人，而不只是超出阈值的人。下图说明了强制限制工作流程。图 3：使用 AWS Budgets 和预算操作实施强制限制。达到阈值时，AWS Budgets 可以执行操作。可用操作包括应用自定义 IAM 策略、应用服务控制策略（SCP），以及针对 Amazon Elastic Compute Cloud（Amazon EC2）或 Amazon Relational Database Service（Amazon RDS）实例执行操作。对于此用例，相关的是 IAM 策略操作。首先，创建该操作将附加的 Deny 策略。此示例拒绝使用成本较高的模型，同时保留成本较低的模型供用户继续工作：{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ], "Resource": [ "arn:aws:bedrock:*::foundation-model/[HIGHER-COST-MODEL-ID]" ] } ] } 将 [HIGHER-COST-MODEL-ID] 替换为您希望在自己的环境中拒绝使用的模型 ID。然后设置权限和预算本身。这里有 2 个不同的角色，而 AWS 托管策略只涵盖其中 1 个：您自己的用户或角色（配置预算的身份）需要 AWS 托管策略 AWSBudgetsActionsWithAWSResourceControlAccess。该策略授予预算相关权限，以及将预算操作角色交给 AWS Budgets 所需、受条件限制的 iam:PassRole 权限。对于此用例，AWS Budgets 为执行操作而代入的 IAM 角色没有单一的具名托管策略可覆盖。 创建该角色时，配置允许服务主体 budgets.amazonaws.com 代入该角色的信任策略，并使用 aws:SourceArn 和 aws:SourceAccount 条件限定范围；再配置授予 iam:AttachRolePolicy 和 iam:DetachRolePolicy 权限的权限策略（如果还使用 SCP，则也授予 organizations:AttachPolicy 和 organizations:DetachPolicy 权限）。有关可授予的权限，请参阅《为 AWS Budgets 设置用于执行预算操作的角色》。创建前文所述的预算操作角色。创建限定于 Amazon Bedrock 的成本预算，并按您希望限制的身份或标签值进行筛选。在“配置提醒”中，添加提醒阈值。选择“实际”，以便根据已发生的支出采取操作；或选择“预测”，以便在支出实际发生前采取操作。在“附加操作”下，选择“添加操作”，选择预算操作角色，然后选择 IAM 策略操作。选择“拒绝”策略，以及要将其附加到的 IAM 用户、组或角色。若要自动执行，选择“是”，使操作自动运行。选择“否”则要求人工在“提醒详情”页面批准每次操作。至少配置一项通知，让受影响的用户知道访问权限为何发生变化。您可以为单个阈值附加多个操作，也可以为一个预算设置多个阈值。这样就能构建分级限制：例如，在达到 80% 时拒绝访问高端模型，在达到 100% 时拒绝访问中档模型，而始终不拒绝访问低成本模型。只有管理账户可以应用 SCP，您可以从管理账户向其他账户应用 SCP。注意事项：AWS Budgets 并非近乎实时：预算数据每天最多刷新 3 次，因此在操作运行前，支出可能超过阈值。成本分配标签不会追溯生效：新应用的标签键最多需要 24 小时才会出现；激活后，还可能需要最多 24 小时才会开始填充账单数据。CUR 不包含逐请求明细：传统 CUR 和 CUR 2.0 都会按使用类型、操作以及定价和资源属性，在 1 小时或 1 天的时间范围内汇总 Amazon Bedrock 成本。IAM 主体字段需要 CUR 2.0：旧版 CUR 格式不包含这些字段。两种格式均提供按 token 划分的成本明细。会话标签在 AssumeRole 时确定，而不是按请求确定。使用该会话凭证发起的每次调用，其标签值都保持不变，而且这些值只会出现在汇总的账单数据中。会话标签不会写入模型调用日志。日志会记录调用方的 identity.arn。若要在请求级别区分共享会话中的用户，请为每位用户使用不同的 RoleSessionName，或在每次调用的请求元数据中设置用户信息。预算操作可附加到 IAM 用户、组和角色。如果用户通过联合身份登录，且没有固定的 IAM 身份，操作就需要以某个角色为目标。因此，每个人或应用程序都有自己的角色时，这种模式效果最好。如果用户共享一个角色，或通过联合身份登录但没有自己的角色，请参阅我们之前的文章，了解按用户执行限制的方法。默认情况下，共享网关角色会使身份归属合并。使用大型语言模型（LLM）网关时，记录到的身份是网关的执行角色。新模型需要留意。使用类型因模型而异。启用新模型时，应确认它按预期出现在查询结果和预算筛选条件中，而不要假定它已被涵盖。决策框架：需求／建议路径——快速生成报表：在 Cost Explorer 中按身份分组；按团队生成报表：使用已激活标签的 Cost Explorer（步骤 1、2 和 4）；详细的账单明细分析：CUR 2.0 导出（步骤 1 至 4）；执行限制：使用预算操作的 AWS Budgets（步骤 1 和 5）。清理：为避免持续产生费用，请删除您创建的所有资源。结论：本文介绍了如何仅使用 AWS 原生功能实现按身份查看 Amazon Bedrock 成本并执行支出限额；对于常见场景，无需编写应用程序代码。 随着生成式 AI 的采用规模不断扩大，最终胜出的组织将是那些能够自信地回答 token 经济性问题的组织：我们每人或每个团队花费多少，能否设定上限，以及实现这一目标需要投入多少工作。现在，轮到您开始探索了。我们随时提供帮助；如果您需要进一步协助，请联系 AWS Support 和您的 AWS 客户团队。关于作者 Arun Chandapillai Arun 是一名高级云架构师，热衷于通过以业务为先的云采用策略，帮助客户加快 IT 现代化进程。他专注于在 AWS 上构建和部署 AI 与生成式 AI 解决方案，涵盖从智能体工作流到可投入生产的应用程序。Arun 是一名汽车爱好者，也热衷于演讲；他热心回馈他人，并相信“付出多少，就会收获多少”。Cami Persson Cami 是 AWS 的首席客户经理，与独立软件供应商合作，通过云采用和 AI 集成创造价值。她致力于推动合作伙伴的收入增长，并帮助其平台实现规模化现代化。Cami 居住在明尼阿波利斯，与丈夫共同生活。Aditya Mettu Aditya 是 AWS 的技术客户经理，为独立软件供应商（ISV）客户提供支持。他帮助工程团队在 AWS 上可靠且经济高效地运行生成式 AI，重点关注 AI FinOps：针对 Amazon Bedrock 等服务的成本可见性、治理和优化。他乐于将云支出数据转化为切实可行的约束机制，让团队在扩大 AI 采用规模的同时避免成本失控。Andre Bernardo Andre 致力于云基础设施、FinOps 和 AI 设计的交叉领域，专门构建能够顺畅扩展、又不会妨碍工程师工作的系统。他打造的云自动化和生成式 AI 平台，使 Jamf 能够安全地采用 AI，同时不拖慢团队的工作进度。Andrew Dunham Andrew 是一名 FinOps 工程师，专注于云成本优化、自动化和财务治理。他将金融、经济学和数据科学背景与云工程专长相结合，帮助团队了解、控制并优化 AWS 和生成式 AI 工作负载的成本。Levi McCormick Levi 是工程总监，在科技领域拥有 25 年以上经验，涉及电话支持、培训与指导、架构、应用设计和客户沟通。他热衷于改善开发者体验，并利用云平台让每位工程师都能成为效率提升 10 倍的工程师。