LiteLLMでCodexをAmazon Bedrockに接続するECS構成

構成の背景と目的

AWSは、OpenAI CodexをLiteLLMゲートウェイ経由でAmazon Bedrockに接続するリファレンス構成を公開しました。この構成は、開発者が利用する生成AIコーディングエージェントに対して、企業レベルでの統制を提供することを目的としています。具体的には、モデルアクセスの管理や利用量の把握、予算・レート制限の適用、監視などを一元的に行えるようにします。

Codexは、開発者のワークステーション上でリポジトリの理解、コード作成、テスト実行などのマルチステップのタスクを実行します。モデル推論のリクエストのみがAWSアカウント内のインフラを通るため、Codexのローカルな動作には影響を与えずに、アクセス経路を管理できます。

アーキテクチャの仕組み

アーキテクチャは、CodexとAmazon Bedrockの間にLiteLLMを配置する構成です。LiteLLMはモデルの認証、ルーティング、予算、レート制限、利用状況のテレメトリを集約し、Codexはタスク実行とツールのローカル処理を担当します。AWS Fargate上のECSで稼働するLiteLLMには、Application Load BalancerとAWS WAFが前面に配置されます。

リクエストは5段階のフローで処理されます。CodexはゲートウェイのResponses APIにタスクコンテキストを送信し、ALBとWAFがネットワーク制御を行います。次にLiteLLMが呼び出し元の認証とポリシーチェックを行い、ECSタスクロールを使用してAmazon Bedrockのモデルを呼び出します。モデルがツールの実行を要求した場合は、Codexがローカルで処理し、次のリクエストで結果を返します。

LiteLLM導入の効果

Amazon Bedrockへの直接アクセスでは、IAMポリシーとCloudTrailでアクセス制御と監査が可能です。しかし、複数の開発者やチームが異なるモデルを利用する場合、より細かな制御が求められます。LiteLLMは、ユーザーやチーム単位の仮想キー、承認済みモデルエイリアスの制限、ハードバジェット、毎分のリクエスト数・トークン数（RPM/TPM）の制限を提供します。

LiteLLMはオープンソースのため、顧客は自身のAWSアカウント内で運用し、既存の監視やセキュリティ基盤と統合できます。一方で、ゲートウェイの可用性、データベース管理、バージョンアップ、インシデント対応といった運用責任が伴います。このトレードオフを理解した上で採用を検討する必要があります。

デプロイと設定の流れ

デプロイ手順は、GitHubの『guidance-codex』リポジトリにまとめられています。Makefileのターゲットを使って、事前チェック、LiteLLMイメージのビルドとECRへのプッシュ、CloudFormationのチェンジセット作成、デプロイを実行します。環境変数ファイルで、AWSプロファイルやリージョン、TLS、ドメイン、アクセス元CIDRなどを設定します。

本番導入では、TLSを有効にし、ロードバランサーを承認済みCIDRに制限することが推奨されています。開発者には、マスターキーの代わりにLiteLLMで生成したスコープ付きキーを発行し、KMSで暗号化したSecrets Managerに保管します。Codexは、設定ファイルの認証コマンドを通じてシークレットを取得し、ゲートウェイにアクセスします。

注意点と比較

このソリューションは、複数のAWSサービスを組み合わせるため、ランニングコストが発生します。記事では、ALB、Fargate、RDS、WAF、ログ、モデル推論が課金対象であることが明記されています。また、モデルの利用可能性はリージョンやアカウントにより異なるため、事前確認が必要です。

記事では、AWS IAM Identity Centerやマネージドゲートウェイ（例：Portkey）が適しているシナリオにも言及しています。また、ゲートウェイを挟まない直接アクセスが適するケースもあります。組織の規模や運用体制に応じて、最適な選択肢は異なると考えられます。