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