规模化Token经济学：Jamf如何为Amazon Bedrock实现实时费用管控
生成式 AI 的支出形态，和以往任何一项成本都不一样。传统计算成本随预置容量伸缩，而 AI 支出随使用行为变化：一个工程师跑着高级模型做智能体编码循环（agentic coding loop），几小时烧掉的 token，可能比一个团队一周用的还多。这就是 tokenomics（token 成本经济学）问题的核心——账单没到之前，用量完全不可见，成本控制和投资回报率（ROI）都难以证明。
在放开 AI 访问权限之前，管理层需要三个答案：每个人的花费是多少？能不能设上限，同时又不拖慢工程师？生产力提升是否值回成本？
Jamf 为超过 7.6 万家组织提供大规模 Apple 设备管理与安全服务，也正面遇到了这个问题。为了加速 AI 辅助开发，Jamf 向工程团队开放了 Amazon Bedrock 的广泛访问权限。生产力确实上去了，但对 AI FinOps（云财务运营）的需求也随之而来——需要按用户维度的用量可见性和成本问责。
Jamf 构建了一套生产级系统，把成本管控落实到了个人粒度。本文将介绍如何利用 AWS 身份与访问管理（IAM）的客户托管策略（CMPs）、基于 Amazon Athena 的成本视图，以及无服务器 AWS Lambda 的强制执行循环，搭建这套架构。读完本文，你会得到一个经过生产环境验证的可运行方案，它能近实时地强制分级消费限额，同时不会打断正在进行的会话。这是一项 AI 成本治理能力。
解决方案概览
Jamf 的方案会跟踪每位工程师每日的 Amazon Bedrock 消费，并在接近预算时逐级收紧可用模型。比如，当日预算用到 80%，就禁止访问 Anthropic Claude Opus；用到 100%，再禁止 Anthropic Claude Sonnet。但 Anthropic Claude Haiku 始终可用，工程师仍能保留一个低成本模型继续工作。限制在几分钟内生效，无需重新认证，次日自动重置恢复。对于确实需要更多额度的工程师，还有文档化的例外审批流程，可临时授予时限更高的限额。
该架构图展示了三个关注点：衡量花费、决定限制对象并通知他们，以及执行限制。每个关注点都由一个专门的无服务器组件处理。
图 1：Amazon Bedrock 实时花费控制
端到端流程如下：
衡量：调用与日志记录——当工程师通过其 AWS IAM Identity Center 单点登录（SSO）会话调用 Amazon Bedrock（bedrock:InvokeModel）时，Amazon Bedrock 会将调用记录（包括模型 ID、输入和输出 token 数量以及用户身份）记录到你配置的 Amazon Simple Storage Service（Amazon S3）存储桶中。
决定与通知：成本衡量——一个 Amazon Athena 视图（bedrock_cost_today）读取这些日志，通过将 token 数量乘以已发布的模型费率，计算每个用户当日的花费。Athena 直接在原始日志上查询，无需单独的数据管道。
执行决策——一个 AWS Lambda 执行处理器每 15 分钟运行一次，由 Amazon EventBridge 定时任务触发。它从 Athena 视图中读取当前花费，并与 Amazon DynamoDB 中的例外表进行交叉比对，该表保存着授予个别工程师的定制限时额度。
通知——同一个执行处理器从 Amazon DynamoDB 状态表中读取每个用户之前的状态，当花费超过新阈值时，向工程师发送一条针对该档位的 Slack 私信，这样限制不会让人措手不及。
执行：执行操作——对于每个超过阈值的工程师，Lambda 通过使用 iam:CreatePolicyVersion 发布相应 CMP 的新版本。该策略通过 saml:sub 条件键针对特定用户。
实时评估——这些 CMP 附加到 IAM permission set（权限集）上。在工程师下一次调用 Amazon Bedrock 时，IAM 会评估更新后的策略，并相应地允许或拒绝请求，无需重新认证。
前提条件
要部署此解决方案，你需要：
- 一个 AWS 账户，并具有创建 IAM 角色、客户托管策略（Customer Managed Policies）、AWS Lambda 函数、Amazon Athena 工作组、Amazon S3 存储桶和 Amazon DynamoDB 表的权限。
大规模 Token 成本治理：Jamf 如何为 Amazon Bedrock 构建实时支出管控
你需要一个配置好权限集（permission set）并分配给用户的 AWS IAM Identity Center；为 Amazon Bedrock 开启模型调用日志，让日志投递到你的 Amazon S3 存储桶；AWS 命令行界面（AWS CLI）配置好相应的凭证；Slack 工作区里有一个应用，配置好了斜杠命令、交互功能和机器人消息。
部署步骤
本文用到的代码可以从 https://github.com/aws-samples/sample-bedrock-spend-enforcement 获取。整体来看，部署过程可以概括为以下三个步骤。
步骤 1：创建 Amazon Athena 成本视图
Amazon Bedrock 的调用日志会以 JSON 格式落入 Amazon S3。先在日志所在的位置建一张 Athena 表，再创建一个视图（view），把 token 数量换算成美元金额。这个视图按用户身份和当前日期分组，将输入、输出 token 数量分别乘以对应模型公开的每 token 单价。你需要把视图里的单价常量替换成你所在区域的 Amazon Bedrock 最新价格。
每个模型家族都要有明确的价格分支。没有映射到的模型按最高档单价计费（而不是按 0 计费），这样未识别的模型就无法绕过管控。记得留意配套的告警，及时补上该模型的真实单价。
步骤 2：创建客户托管策略（Customer Managed Policy）
创建管控策略，用 saml:sub 标识一组特定用户，拒绝他们调用某个模型家族。用户列表初始为空，由 Lambda 在运行时通过发布新的策略版本动态填充。把这些策略附加到 IAM 权限集上。通过 iam:CreatePolicyVersion 更新这类客户托管策略时，改动会立即生效，不需要重新预置。
步骤 3：部署管控 Lambda 并设置调度
部署管控处理器，并用 Amazon EventBridge 调度它每 15 分钟运行一次。每次运行时，处理器会查询 Athena 视图、读取 DynamoDB 中的例外名单表，算出每个档位对应的受限用户列表，然后发布更新后的 CMP 版本。这个设计天然具备幂等性：每次运行都会根据当天累计花费重新计算完整的受限用户列表，而不是做增量更新。
连续运行两次 handler，或者完全漏跑一次，一旦追上进度，最终结果都一样。不存在重复生效的东西，每日重置也是隐式的。Athena 视图将花费限定在一个滚动的每日窗口内（以你选择的参考时区的 00:00 为界）。窗口滚动后，下一次运行重新计算出的列表会省略那些不再超限的用户，他们的 CMP 限制会在随后的 iam:CreatePolicyVersion 调用中自动解除。不需要单独维护一套解锁代码路径，也不会出现不同步的问题。
第 4 步：添加例外工作流
有些工程师确实需要更高的限额，用于大规模迁移、客户升级或模型评估。与其手动编辑策略，不如提供一个 Slack 斜杠命令（/bedrock-limit），让管理员可以授予有时限的自定义限额。该命令会向 DynamoDB 例外表写入一条记录，包含工程师身份、提升后的限额和过期时间戳。它还会记录审计追踪：谁授予的、何时授予的，以及（可选）由哪个工单授权。在过期时间戳上设置 DynamoDB 的 Time to Live (TTL) 属性，例外就会自动清理。在下次运行时，执行 Lambda 会读取活跃的例外，并相应调整每位工程师的阈值。
经验教训
在生产环境中运行这套系统后，我们总结了一些值得分享的经验。
成本：对于这个用例，AWS Lambda、DynamoDB 和 S3 在一百多位工程师的情况下，每月成本远低于 10 美元。Amazon Athena 是需要仔细控制的一项：账单随扫描范围和运行频率增长，因此要保持调用日志结构精简（只包含 token 计数和身份/模型元数据），并且每次运行只查询一次预聚合的成本视图，而不是反复扫描原始日志。JSON 日志意味着每次查询都会扫描每一个字节，无论选择哪些列。Athena 必须先反序列化每一行，然后才能应用任何过滤器，因此针对同一视图的四次不同过滤查询，每次都会扫描相同的约 11 GB。列裁剪和谓词下推对面向行的 JSON 没有帮助。解决办法是将派生查询合并到一个 SELECT ...
在应用代码里用 GROUP BY 拆分查询结果，或者更进一步，把日志转成 Parquet 这类列式存储格式。
治理不是限制使用，反而会加速采用。这里有一个反直觉的战略洞察：正因为设置了严格的单用户上限，管理层才放心扩大 AI 的开放范围，而不是收紧。支出变得可见可查之后，Jamf 才有底气扩大能用 AI 的工程师规模。
常驻低成本模型。 故意保留一个低成本模型始终可用，是经过深思熟虑的设计。即使工程师的预算额度已经用满，他仍然能继续完成工作，管控不会让生产力完全停摆。
新模型要有明确的定价分支。 把定价映射当作运维中的一等资产来维护，每启用一个新模型，就同步把它加入映射。
IAM 策略版本数量限制。 托管策略最多保留五个版本。执行管控的 Lambda 在创建新版本之前，必须先删除最旧的非默认版本，否则 iam:CreatePolicyVersion 调用会失败。
注意 Amazon Athena 的异步查询模型。 Athena 查询是提交后轮询获取结果，不会同步返回。Lambda 处理器需要先发起查询，等待完成后再读取结果，因此要相应调整函数的超时时间。
清理资源。 为避免持续产生费用并解除管控，请删除你创建的资源。
结语
这篇文章介绍了 Jamf 如何借助客户托管策略（Customer Managed Policies）、Amazon Athena 成本视图和无服务器 AWS Lambda 循环，为 Amazon Bedrock 构建实时、按用户维度的支出管控。
随着生成式 AI 的采用规模不断变大，最终胜出的组织，是那些能自信回答 Token 成本问题的组织：我们知道每个人花了多少钱，能在不拖慢任何人的前提下设好上限，并且能证明投入的价值。成本治理让我们敢于对更多 AI 说「是」，而不是说「不」。
现在轮到你去探索了。如果需要进一步帮助，可以联系 AWS Support 和你的 AWS 客户团队。
关于作者
Arun Chandapillai，资深云架构师，热衷于通过「业务优先」的云采用策略，帮助客户加速 IT 现代化。
Arun 专注于在 AWS 上构建和部署人工智能与生成式 AI（Generative AI）解决方案，覆盖从智能体工作流到生产级应用。Arun 是一名汽车爱好者和活跃的演讲者，热衷于回馈社区，相信“付出终有回报”。
Cami Persson 是 AWS 的首席客户经理，与独立软件开发商（ISV）合作，通过云采用和 AI 集成推动价值创造。她专注于加快合作伙伴的收入增长，并在规模化层面推进平台现代化。Cami 与丈夫住在明尼阿波利斯。
Aditya Mettu 是 AWS 的技术客户经理，负责支持独立软件开发商（ISV）客户。他帮助工程团队在 AWS 上可靠、经济地运行生成式 AI，重点关注 AI FinOps——即针对 Amazon Bedrock 等服务的成本可见性、治理与优化。他乐于把云支出数据转化为实用的“护栏”，让团队既能扩大 AI 采用规模，又不会让成本失控。
Andre Bernardo 是云基础设施、FinOps 和 AI 设计交叉领域的一名构建者，擅长打造可干净扩展、又不给工程师添麻烦的系统。他构建了云自动化和生成式 AI 平台，让 Jamf 能够安全地采用 AI，同时不拖慢团队节奏。
Andrew Dunham 是一名 FinOps 工程师，专注于云成本优化、自动化和财务治理。他把金融、经济学和数据科学背景与云工程专长结合起来，帮助团队理解、控制并优化 AWS 与生成式 AI 工作负载的成本。
Levi McCormick 是工程总监，技术经验超过 25 年，涵盖电话支持、培训与指导、架构设计、应用开发和客户沟通。他热衷于开发者体验，善于利用云平台，让每位工程师都能成为“10 倍工程师”。