Amazon Bedrock、Codexの推論先に LiteLLM経由の5ステップ構成
- Codexの推論をAmazon Bedrockへ中継します。
- LiteLLMをAmazon ECS上のゲートウェイにします。
- 予算、レート制限、テレメトリを集約します。
AWS Machine Learning Blogは、OpenAI CodexをLiteLLM経由でAmazon Bedrockに接続する構成を示しました。顧客が運用するLiteLLMゲートウェイをAmazon ECSにデプロイし、Amazon Bedrock上のOpenAIモデルへ接続します。
この構成では、LiteLLMがモデル認証、ルーティング、予算、レート制限、ゲートウェイのテレメトリの共有制御点になります。Codexは開発者のワークステーション上でローカルのタスク処理とツール実行ループを担います。
リクエストの流れは5ステップです。Codexが/v1/responsesエンドポイントに文脈とツール定義を送り、Application Load BalancerとAWS WAFを通過します。LiteLLMは呼び出し元を認証し、ECSタスクロールでAmazon Bedrock上の承認済みモデルを呼び出します。
参照デプロイでは、LiteLLMの状態、利用量、予算データにAmazon RDS for PostgreSQLを使います。AWS Secrets Manager、AWS KMS、Amazon CloudWatch、Amazon ECR、任意のAWS WAF保護も使います。検証はus-east-1で、ゲートウェイ別名openai.gpt-5.5を使っています。
つまり、社員それぞれが好き勝手にAIへ問い合わせていたのを、社内に受付窓口を一つ置いて必ずそこを通す形にする、という話です。AI本体はAWSの中にあり、窓口が誰の依頼かを確かめ、使いすぎを止め、利用量を記録します。手元のパソコンでコードを読んだり試しに動かしたりするのは、これまで通りCodexの担当です。
AWSの解説で目を引いたのは、性能の話がほとんど出てこないことです。予算、上限、記録。並んでいるのは管理の言葉ばかりで、開発を速くする道具の紹介という雰囲気ではありません。
ただ、これは企業がAIコーディングを本気で配り始めた証拠だと筆者は見ています。個人が試している段階では、誰も予算管理の話をしません。部署単位で配る段になって、はじめて「誰がどれだけ使ったか」が問題になります。
一方で、この構成は自前で抱える荷物がかなり増えます。データベース、ロードバランサ、ログ、バージョン更新。少人数の会社なら、Amazon Bedrockへ直接つなぐ形で十分だと思います。窓口を置くのは、部署をまたいで配り始めてからでも遅くないはずです。
検証はus-east-1で行われています。東京リージョンで同じOpenAIモデルを同じやり方で選べるようになるかを見たいです。
開発者ごとやチームごとに生成AIコーディングエージェントの利用制御を集約したい企業に関係します。
