8.0
热点
AI SCORE
技术实践2026-09-02 00:03
Jamf如何在Amazon Bedrock上实现实时成本管控
AWS ML Blog#AWS Bedrock#成本管控#AI工程化
Editor brief · 编辑速览
Jamf用IAM策略+Athen视图+Lambda循环在不离线情况下对每个用户按模型层级实时限费。
生成式 AI 的费用行为与以往任何成本行项都不同。传统计算随预置容量扩展，而 AI 费用随行为扩展：一名工程师在高级模型上运行代理式编码循环，几个小时消耗的 token 可能比一个团队一周消耗的还多。这就是 Tokenomics 问题：使用量在账单到来之前是不可见的，这使得成本控制和投资回报率（ROI）都难以证明。在扩大 AI 访问权限之前，领导层希望得到三个答案：每个人花费多少？能否在不减缓工程师速度的情况下设置上限？生产力提升是否足以证明成本合理？
Jamf 为超过 76,000 家组织管理并保护大规模 Apple 设备，面对这一挑战也不例外。为了加速 AI 辅助开发，Jamf 向其工程组织提供了对 Amazon Bedrock 的广泛访问。生产力提升了，但对 AI FinOps 的需求也随之增加：需要按人可见的费用和成本问责。
Jamf 构建了一个在个人层面解决这一问题的生产系统。在这篇文章中，你将学习如何使用 AWS Identity and Access Management（IAM）客户托管策略（Customer Managed Policies，CMP）、基于 Amazon Athena 的成本视图，以及无服务器 AWS Lambda 强制执行循环来构建这个架构。到最后，你将拥有一个经过生产验证的模式，可以在不影响活跃会话的情况下近乎实时地强制执行分层消费限额。这是一种 AI 成本治理能力。
Jamf 的解决方案追踪每位工程师每日 Amazon Bedrock 消费，然后在他们接近预算时应用分层模型限制。例如，当达到日预算的 80% 时，拒绝 Anthropic Claude Opus 访问；当达到 100% 时，拒绝 Anthropic Claude Sonnet 访问。它不会阻止 Anthropic Claude Haiku，因此工程师保留一个低成本模型以继续工作。限制在几分钟内生效，无需重新认证，并在下一个每日重置时自动恢复。对于确实需要更多配额的工程师，有文档化的异常流程来授予有时限的更高限额。
该架构解决了三个问题：计量消费、决定限制谁并通知他们、以及强制执行限制。每一个都由专用无服务器组件处理。
端到端流程如下：
调用和日志记录 — 当工程师通过其 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 发布适当策略的新版本。策略通过 saml:sub 条件键定向到特定用户。
实时评估 — CMP 附加到 IAM 权限集。在工程师下一次调用 Amazon Bedrock 时，IAM 评估更新后的策略并相应地允许或拒绝请求，无需重新认证。
要部署此解决方案，你需要：
你可以通过 https://github.com/aws-samples/sample-bedrock-spend-enforcement 访问这篇文章的代码。高级别来说，部署步骤可总结如下：
Amazon Bedrock 调用日志以 JSON 格式落在 Amazon S3 上。首先在日志位置创建一个 Athena 表，然后创建一个将 token 计数转换为美元的视图。该视图将输入和输出 token 乘以每个模型公布的每 token 费率，按用户身份和当前日期分组。
将费率常量替换为你所在区域的当前 Amazon Bedrock 定价。每个模型系列需要一个明确的定价分支。未映射的模型以最高层级定价作为故障安全（不是 $0），因此未识别的模型无法绕过强制执行。注意随附的警报并及时添加模型的真实费率。
创建拒绝特定用户集（通过其 saml:sub 值标识）访问某个模型系列的强制策略。从空用户列表开始。Lambda 在运行时通过发布新策略版本填充该列表。将策略附加到 IAM 权限集。当你使用 iam:CreatePolicyVersion 更新这些客户托管策略时，你的更改会立即生效，无需重新配置。
部署强制处理程序并使用 Amazon EventBridge 安排其每 15 分钟运行一次。每次运行时，处理程序查询 Athena 视图、读取 DynamoDB 异常表、计算每个层级的受限用户列表，并发布更新的 CMP 版本。
这个设计本质上是幂等的：每次运行都从当天的累积消费重新计算完整的受限用户列表，而不是应用增量更改。连续运行处理程序两次，或完全错过一次运行，一旦赶上会产生相同的结果。没有什么需要双重应用的，也没有什么需要回滚的。每日重置也是隐式的。Athena 视图将消费范围限定在滚动每日窗口（你选择的参考时区的 00:00）。一旦该窗口滚动，下一次运行的重新计算列表会省略不再超阈的用户，他们的 CMP 限制会在下一次 iam:CreatePolicyVersion 调用时自动解除。没有单独的解除阻塞代码路径需要维护或可能失去同步。
有些工程师确实需要更高的限制，用于大型迁移、客户升级或模型评估。不要手动编辑策略，而是公开一个 Slack 斜杠命令（/bedrock-limit），供管理员用来授予有时限的自定义限制。该命令向 DynamoDB 异常表写入一条条目，包含工程师身份、抬高的限制和过期时间戳。它还记录了审计跟踪，记录谁授予的、何时授予的，以及可选地哪个工单授权了。在过期时间戳上设置 DynamoDB 生存时间（TTL）属性，以便异常自动清理。在下一次运行时，强制 Lambda 读取活跃异常并相应调整每位工程师的阈值。
在生产环境中运行这个系统 surfac surfaced 了一些值得分享的经验教训。
成本：对于这个用例，AWS Lambda、DynamoDB 和 S3 为数百名工程师产生的成本远低于 $10/月。Amazon Athena 是需要仔细调整的一项：账单随扫描范围和运行频率缩放，因此保持调用日志 schema 精简（仅 token 计数和身份/模型元数据），并在每次运行时查询预聚合成本视图一次，而不是反复扫描原始日志。
JSON 日志意味着每次查询都会扫描每个字节，无论选择了哪些列。Athena 必须在应用任何过滤器之前反序列化每一行，因此对同一视图的四个不同过滤查询各自扫描了相同的约 11 GB。列修剪和谓词下推对面向行的 JSON 没有帮助。通过将派生查询合并为一个 SELECT ... GROUP BY 并在应用代码中分割结果来修复它，或者更进一步，将日志转换为 Parquet 等列式格式。
治理加速采用而非限制采用。战略洞察是反直觉的：实施硬性每人上限反而让领导层放心扩大访问权限，而不是收缩访问权限。因为消费现在是可观察的，Jamf 可以自信地增加启用 AI 的工程师数量。
始终可用的模型。保持低成本模型始终可用是一个深思熟虑的选择。达到预算 100% 的工程师仍然可以完成工作，因此强制执行不会完全停止生产力。
新模型需要明确的定价分支。将定价图作为一等运营工件，并在启用新模型的时刻添加它们。
IAM 策略版本限制。托管策略最多保留五个版本。强制 Lambda 必须在创建新版本之前删除最旧的非默认版本，否则 iam:CreatePolicyVersion 将失败。
考虑 Amazon Athena 的异步查询模型。Athena 查询是提交和轮询的，不是同步返回的。Lambda 处理程序必须启动查询、等待完成，然后读取结果。相应地设置函数超时。
为避免持续产生费用并移除强制控制，请删除你创建的资源。
在这篇文章中，你学习了 Jamf 如何使用客户托管策略、Amazon Athena 成本视图和无服务器 AWS Lambda 循环为 Amazon Bedrock 构建实时、每人消费强制执行。随着生成式 AI 采用规模的扩大，将会获胜的组织是那些能够自信地回答 Tokenomics 问题的组织：我们知道每个人花费多少，我们可以不减缓任何人地设置上限，并且我们可以证明价值。成本治理使安全地对更多 AI 说"是"成为可能，而不是更少。
现在，轮到你去开始探索了。我们在这里提供帮助，如果你需要进一步协助，请联系 AWS Support 和你的 AWS 账户团队。