在 Amazon ECS 和 Amazon Bedrock 上使用 LiteLLM 设置 OpenAI ChatGPT Codex

随着生成式 AI 编程助手从个人实验走向企业规模化应用，团队需要在模型访问、成本归属和可观测性方面建立统一控制。OpenAI Codex 可以在开发者的工作站上运行任务循环，在本地沙箱和审批策略的约束下读取文件、执行工具，但模型推理请求可以路由到客户 AWS 账户中的基础设施。LiteLLM 作为开源 AI 网关，正好可以充当集中控制层，帮助企业以 API 兼容的方式管理模型路由、虚拟密钥、预算、速率限制以及使用遥测。

本文描述的方案将 LiteLLM 部署在 Amazon ECS 上并使用 AWS Fargate 运行，与 Amazon Bedrock 上的 OpenAI 模型连接，再配置 Codex 使用网关的 Responses API。其整体架构将 LiteLLM 放在 Codex 和 Amazon Bedrock 之间，Codex 仍然负责本地的任务和工具执行，而模型推理流量则经过网关控制。一次完整的模型请求会经历五个步骤：Codex 将当前任务上下文和工具定义发送到网关的 /v1/responses 端点；Application Load Balancer 和 AWS WAF 先完成网络层与应用层防护，再把请求转发给运行在 Fargate 上的 LiteLLM；LiteLLM 验证调用者身份，检查模型和消费策略，然后使用 ECS 任务角色调用 Amazon Bedrock 上已批准的模型；Amazon Bedrock 将文本或函数调用结果返回给 LiteLLM；如果需要调用工具，Codex 会在本地沙箱中执行该工具，并在下一轮 Responses 请求中把结果通过 LiteLLM 再次发送给模型，如此循环。这种设计不会在 AWS 账户中为网关开放通用 shell，也没有取代 Codex 本地的审批机制，它只管控每一轮模型请求。

该参考部署还包含多个配套 AWS 服务：Amazon RDS for PostgreSQL 用于保存 LiteLLM 状态、用量和预算数据；AWS Secrets Manager 与 AWS KMS 用于保存网关主密钥和作用域密钥；CloudWatch Logs、Container Insights、告警和部署健康检查提供可观测性；Amazon ECR 保存不可变的网关镜像；可选配置包括 AWS WAF 托管防护和基于源 IP 的速率限制。

为什么选择 LiteLLM？直接访问 Amazon Bedrock 是复杂度最低的方案，前提是 AWS IAM 策略和 CloudTrail 日志已经能够满足企业的治理要求。当系统团队需要在多个开发者、团队或模型提供商之间保持一致的控制策略时，网关的价值就体现出来。LiteLLM 特别适合以下场景：只允许使用已批准的模型别名；为不同用户或团队签发作用域密钥；设置硬性预算以及每分钟请求数、每分钟 token 数限制；集中管理路由和故障转移策略；在上游模型使用共享 ECS 任务角色时保留网关级身份；并且在客户自己的 AWS 账户内运营网关、数据库、网络、日志和升级流程。其代价是运维责任完全由客户承担，包括可用性、数据库生命周期、版本升级、事件响应和容量规划。

部署过程从 GitHub 上的 guidance-codex 仓库开始。先使用 git clone 获取仓库，并切到 feat/enterprise-gateway-readiness 分支，再复制 .env.deploy.example 为 .env.deploy，然后在其中配置 AWS Profile、区域、来源 CIDR、DNS 或证书信息。部署入口由 Make 命令和辅助脚本组成：make litellm-check 执行只读的预检，验证 AWS CLI、身份、Docker、不可变镜像引用、区域一致性、CIDR 限制、TLS 输入和 CloudFormation 语法；CONFIRM_AWS_WRITE=1 make litellm-build 会构建 LiteLLM 镜像并推送到 Amazon ECR，镜像使用 digest 固定的基础镜像，CloudFormation 使用不可变的摘要而不是易变的 tag；make litellm-plan 创建不自动执行的 CloudFormation 变更集，方便先评审；最后运行 CONFIRM_AWS_WRITE=1 make litellm-deploy 和 make litellm-status 完成部署并查看状态。整个 ECS 服务启用了部署断路器回滚和 ALB 健康检查，模板还配置了目标跟踪自动扩缩、加密日志和数据、RDS 备份、ALB 访问日志以及运维告警。在生产环境中，应保持 TLS 开启，使用受信任的 DNS 名称和 ACM 证书，将 ALB 限制在公司或 VPN 的 CIDR 范围内，并把 ECS 任务和 RDS 放在私有子网中，不要公开暴露 ECS 任务的 4000 端口或 PostgreSQL 的 5432 端口。

对于开发者身份，不应向开发者分发 LiteLLM 主密钥。部署环境文件可以配置一个作用域密钥的 Secret ID、别名、用户 ID、允许的模型、最大预算、预算周期、每分钟 token 数和每分钟请求数。运行 CONFIRM_AWS_WRITE=1 make litellm-provision-key 后，辅助脚本会通过 LiteLLM 的 /key/generate API 创建密钥，并把生成的密钥直接写入由 KMS 加密的 Secrets Manager 密文中，不会把主凭证或生成的密钥显示在命令行或终端里。企业推广时，可以为每个开发者配置独立的 IAM 策略，使其只能读取并解密自己被分配的密钥密文。

Codex 的配置可以通过 make litellm-codex-config 生成。辅助脚本从 CloudFormation 输出中读取网关端点，并打印出 model_provider 配置片段，但不会自动修改用户配置。把该配置添加到用户级的 ~/.codex/config.toml 中。需要特别注意的是，provider 和认证设置属于用户级配置，Codex 会忽略项目本地 .codex/config.toml 中的这些设置。生成的配置使用 model = "gpt-5.5"、model_provider = "litellm-gateway"，以及 wire_api = "responses"；认证部分通过调用部署脚本中的 aws-secret-auth.py，使用指定 AWS Profile 从 Secrets Manager 读取当前密钥并输出为 bearer token。Codex 会无标准输入地运行这个认证命令，并从标准输出读取令牌，因此令牌不会写入 config.toml。

在 LiteLLM 管理界面中，Models + Endpoints 可以显示开发者可用的稳定别名以及对应的 Amazon Bedrock 上游模型映射。除本文介绍的自运营路径外，企业还可以评估两种替代方案：一种是直接让 Codex 使用 AWS IAM Identity Center 访问 Amazon Bedrock，这种方式在身份和审计需求可以满足时最为简单；另一种是使用 Portkey 这类托管网关，把基础设施运维交给服务商。最终选择取决于企业对控制粒度、运维能力和托管成本的综合考量。