在 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 這類託管網關，把基礎設施運維交給服務商。最終選擇取決於企業對控制粒度、運維能力和託管成本的綜合考量。