AWS Bedrock 密钥现在由一个内部 LLM 网关进行保护，这使得金融科技公司的每个团队都能调用模型，同时每个请求都与每个团队的 token 预算挂钩。这一变化制止了将 IAM 凭据散落在代码仓库和 notebook 中的做法，这种习惯此前已威胁到公司，可能在短短一个下午内就耗尽其 AI 预算。

为什么分发 AWS 密钥会迅速演变成一场混乱

组织内的非技术团队请求直接访问公司的语言模型。从理论上讲，最简单的办法是在 AWS 中启用这些模型，并为每个团队授予 IAM 权限。只需十分钟的工作，修改几项策略，任务就完成了——至少在理论上是这样。

但在实践中，分发 IAM 凭据会产生三种隐藏成本：

  • 凭据蔓延 (Credential sprawl) – 密钥最终会出现在 .env 文件、CI 流水线、Jupyter notebook 和临时脚本中。当需要进行密钥轮换时，每一份副本都可能成为故障点。
  • 零可见性 (Zero visibility) – 单个共享密钥无法提供任何线索，说明是哪个团队或哪段代码正在产生使用量。当出现失控的循环调用时，可能在任何人察觉之前就耗尽整个预算。
  • 运维开销 (Operational overhead) – 追踪谁拥有什么权限、撤销访问权限以及审计使用情况，很快就会变成一个手动且易出错的过程。

这家金融科技团队意识到，这种“权宜之计”很快就会演变成安全和成本的噩梦。

转而构建一个反向代理网关

解决方案是在每个内部应用程序和 AWS Bedrock 之间插入一个轻量级的反向代理。该代理将真实的 AWS 凭据保存在一个受 Vault 保护的单一位置，并向调用者发放短期且易读的 token（例如 lllkey_9f3c）。

关键设计点：

  • AWS 凭据不会离开网关 – 开发人员和服务永远不会看到实际的 IAM 密钥。
  • 基于 token 的策略执行 – 每个 token 都可以被限制在特定的模型系列或最大 token 数量内。
  • 完整的审计追踪 – 每个请求都会记录名称。

网关如何处理请求

  1. 接收 token – 客户端在 HTTP 请求头中包含其 llmkey_… token。
  2. 验证 token – 网关检查 token 的状态（是否活跃、是否过期）以及请求是否在分配的预算范围内。
  3. 模型白名单 – 确认所请求的模型是该 token 允许使用的。
  4. 转发至 Bedrock – 使用存储的 IAM 凭据将请求发送至 AWS。
  5. 日志记录与计费 – token 使用量、模型名称和成本估算将被写入中央数据库以供报告。

由于金融科技公司必须将所有数据保留在自有网络内，因此无法采用第三方 SaaS 方案。

公司获得了什么

  • 模型控制 – 仅需要低成本模型的团队可以被限制在该模型上，防止误用昂贵的高容量变体。
  • 预算保护 – token 设有硬性的 token 限制。当达到限制时，网关会返回错误，而不是静默地消耗更多额度。
  • 财务归因 – 基于使用日志构建的仪表板可以准确显示哪个团队或服务在 AI 上花费了多少钱，将模糊的电子表格变成了透明的报告。

运维工作流也发生了变化。不再需要新的 IAM 策略，不再需要密钥轮换，也不再有密钥泄露到版本控制系统中的风险。

反方观点：为什么不使用托管服务

一个常见的反对意见是，构建自定义网关会增加工程投入和维护成本。但在该金融科技公司的案例中，将所有 AI 流量和使用数据保留在公司防火墙后的需求，超过了使用第三方解决方案带来的便利。这个内部代理仅需一个周末的开发时间，但它消除了由于采用天真的密钥分发方式而可能导致的数月凭据清理工作和预算超支。

总结

分发 AWS Bedrock 密钥是一种捷径，但很快就会演变成安全和预算的噩梦。一个在周末就能构建完成的轻量级反向代理网关，可以实现凭据集中管理，执行按团队限制，并提供财务所需的审计追踪。对于任何希望让多个团队在不丧失控制权的情况下尝试 LLM 的组织来说，通过避免安全事件和提高支出透明度，这种网关方案所带来的收益将远超其投入。