AWS发布基于ECS与Bedrock部署OpenAI Codex网关的完整方案
AWS博客介绍了如何在Amazon ECS上部署LiteLLM网关，将OpenAI Codex的模型请求路由到Amazon Bedrock，并提供预算、速率限制与审计能力。
AI解读：企业规模化采用AI编程代理时，最头疼的是如何统一管控模型访问和成本。AWS这篇博客提供了一套可实操的答案：在自家的AWS账户里用LiteLLM搭一个网关，放在Codex和Amazon Bedrock之间。Codex继续在开发者电脑上执行代码和工具，但每一次模型请求都先经过网关——网关负责认证、路由、预算、速率限制，并把使用记录写进日志。对系统管理员来说，这意味着不用把模型主密钥发给每个开发者，按人发带预算上限的独立密钥，比如示例里 50 美元/30 天；还能限流，比如每分钟最多 1000 请求。运维团队要自己承担网关的可用性、数据库升级和容量规划。代码和部署脚本都已开源在GitHub，验证过的区域是us-east-1，但模型可用性因账户和区域而异。普通开发者暂时不用做任何事；真正需要行动的是那些准备把Codex从个人试用推向团队使用的平台团队。
AWS机器学习博客于 2025 年发布了一篇技术文章，介绍如何在Amazon ECS上部署由客户自运维的LiteLLM网关，将OpenAI ChatGPT Codex的模型推理请求路由至Amazon Bedrock，并为生成式AI编程代理提供集中式企业管控。该方案在开发者工作站与Amazon Bedrock之间插入LiteLLM，作为模型认证、路由、预算、速率限制与遥测的统一控制点，而Codex仍负责本地的任务与工具执行循环。完整实现代码已发布在GitHub的guidance-codex仓库中。
架构与请求流程
该方案的请求流程分为五个步骤：Codex将当前任务上下文和可用工具定义发送到网关的 /v1/responses端点；Application Load Balancer与AWS WAF实施网络层防护后转发至运行在AWS Fargate上的LiteLLM；LiteLLM认证调用者、检查模型与消费策略，并通过其ECS任务角色调用Amazon Bedrock上的已批准模型；Bedrock返回文本或函数调用；若模型请求工具，Codex在本地沙箱中执行并再次通过网关发送结果。
参考部署还使用了Amazon RDS for PostgreSQL存储LiteLLM状态与预算数据，AWS Secrets Manager与AWS KMS管理密钥，CloudWatch记录日志与告警，以及Amazon ECR存放不可变镜像。文章特别强调，网关在AWS账户中并未获得通用shell，也未取代Codex的本地审批机制，它只管控每一次模型调用。
部署与配置步骤
部署过程要求具备AWS账户及相关资源权限、对Amazon Bedrock上选定OpenAI模型的访问权限、AWS CLI v2、Docker with Buildx、Codex CLI与Python 3；若启用HTTPS，还需Route 53托管区或同区域的ACM证书。该方案在us-east-1区域验证通过，使用网关别名openai.gpt-5.5，映射到LiteLLM配置中的bedrock_mantle/openai.gpt-5.5。
部署通过make命令完成：先运行litellm-check执行只读预检，再构建镜像并推送到Amazon ECR（使用digest-pinned基础镜像，CloudFormation接收不可变digest），创建不执行的CloudFormation change set，审阅后执行litellm-deploy部署网络与网关栈。ECS服务启用了deployment circuit-breaker回滚与ALB健康检查，模板还配置了target-tracking自动扩缩、加密日志与数据、RDS备份、ALB访问日志与运维告警。
文章强调不要向开发者分发LiteLLM主密钥，而是为每个用户或团队创建带独立策略的网关密钥。示例中为开发者alice配置了CODEX_KEY_MODELS=gpt-5.5、CODEX_KEY_MAX_BUDGET=50（30 天）、CODEX_KEY_TPM_LIMIT=100000、CODEX_KEY_RPM_LIMIT=1000。provision-key命令在子进程中解析主凭据，调用 /key/generate API生成密钥并直接写入KMS加密的Secrets Manager密钥，不会将凭据写入命令行或打印到终端。
Codex通过 ~/.codex/config.toml配置模型提供商，认证命令由辅助脚本从Secrets Manager拉取密钥，不存储在配置文件中。测试命令codex exec --sandbox read-only --ephemeral可执行冒烟测试与真实代理任务，LiteLLM管理界面的Request Logs可验证成功状态、密钥识别、模型映射、token数与成本数据。
验证、运营与备选方案
文章特别指出，单纯的文本响应成功不能证明代理工作流兼容。因此提供了严格验证脚本（litellm-validate），检查Responses API必填字段、semantic continuation的previous_response_id、server-sent event流式响应和函数调用。文章报告称，实际部署通过了全部验证，CloudFormation成功、ECS服务达到目标任务数、PostgreSQL数据库加密且未公开暴露。该脚本是兼容性门禁而非压力测试，生产环境还需测试并发会话、长流、请求取消、密钥吊销、故障恢复与峰值流量。
在运维层面，文章建议仅发布企业批准的模型别名，并将上游映射固定为不可变Amazon ECR digest；为每个用户/团队发放独立scoped key，通过LiteLLM记录保留身份归因；实际测试预算与速率限制策略，而非仅确认设置生效。同时要监控基础设施健康与LiteLLM使用数据。
文章也提供了备选方案对比：当原生AWS IAM、CloudTrail日志能满足需求时，直接访问Amazon Bedrock是最低复杂度选择；当系统团队需要跨开发者/团队/模型提供商的额外且一致的控制时，LiteLLM这类自运维网关才更合适。若需要托管网关，Portkey是备选。文章还提到，当AWS IAM Identity Center直接访问或托管网关（如Portkey）更合适时，应优先考虑那些方案。