Amazon Bedrock と LiteLLM による OpenAI ChatGPT Codex の予算・レート制限管理

本ブログは 2026 年 9 月 3 日に公開された AWS Blog “Set up OpenAI ChatGPT Codex with LiteLLM on Amazon ECS and Amazon Bedrock” を翻訳したものです。

OpenAI ChatGPT Codex と LiteLLM を組み合わせることで、生成 AI コーディングエージェントに対してエンタープライズ向けの一元的な制御を実現できます。これらのエージェントは、開発者によるリポジトリの理解、コードの記述、テストの実行、複数のステップからなるエンジニアリングタスクの完了を支援します。組織が個人による試験的な利用から、管理体制のもとでの導入へと移行するにつれて、チームにはモデルへのアクセスを制御し、使用量の帰属先を明確にするための一貫した方法が必要になります。また、予算とレート制限を適用し、モデルアクセス経路を監視する必要もあります。

OpenAI Codex (Codex) は、タスクループを開発者のワークステーション上で実行します。ローカルファイルを読み取り、ローカルのサンドボックスと承認設定の範囲内で、承認済みのツールを実行します。その場合でも、モデル推論は、お客様の AWS アカウント内のインフラストラクチャを経由するようにルーティングできます。

この記事では、お客様が運用する LiteLLM ゲートウェイを Amazon Elastic Container Service (Amazon ECS) にデプロイする手順を説明します。ゲートウェイを Amazon Bedrock 上の OpenAI モデルに接続し、ゲートウェイの Responses API を使用するように Codex を設定する方法を紹介します。また、セマンティックな継続 (semantic continuation)、ストリーミング、関数呼び出し (function calling) を検証する方法も紹介します。最後に、AWS IAM Identity Center による直接アクセスや、Portkey のようなマネージドゲートウェイの方が適しているケースについて説明します。

完全な実装は guidance-codex リポジトリで公開されています。この記事で主に取り上げる構成については、「LiteLLM on AWS quickstart」の手順に従ってください。

ソリューションの概要

次のアーキテクチャでは、Codex と Amazon Bedrock の間に LiteLLM を配置します。LiteLLM は、モデル認証、ルーティング、予算、レート制限、ゲートウェイテレメトリを共通で管理するコントロールポイントになります。ローカルのタスクとツール実行のループは、引き続き Codex が担当します。

次の図は、開発者のワークステーションからゲートウェイを経由して Amazon Bedrock に到達し、再び戻ってくるまでのエンドツーエンドのリクエストフローを示しています。番号付きの 5 つのステップで、1 回のモデルターンがインフラストラクチャをどのように通過するかを確認してください。

Codex request flow through LiteLLM on AWS

図 1: Codex はモデルリクエストを LiteLLM 経由で送信し、ローカルのツール実行は引き続き開発者のワークステーション上で行われます

リクエストフローは次の 5 つのステップで進みます。

Codex は、現在のタスクコンテキストと利用可能なツール定義を、ゲートウェイの /v1/responses エンドポイントに送信します。
Application Load Balancer と AWS WAF がネットワーク層とウェブ層の制御を適用したうえで、AWS Fargate 上の LiteLLM にリクエストを転送します。
LiteLLM は呼び出し元を認証し、設定されたモデルと利用量ポリシーを確認したうえで、ECS タスクロールを使用して Amazon Bedrock 上の承認済みモデルを呼び出します。
Amazon Bedrock は、テキストまたは関数呼び出しを LiteLLM 経由で返します。
モデルがツールの実行を要求した場合、Codex はサンドボックスと承認ポリシーの範囲内でそのツールをローカルで実行します。Codex は次の Responses リクエストでツールの実行結果を LiteLLM 経由で送信し、ループが続きます。

リファレンスデプロイでは、次のサービスも使用します。

LiteLLM の状態、使用状況、予算データを保存する Amazon Relational Database Service (Amazon RDS) for PostgreSQL
ゲートウェイとスコープ付きキーのシークレットを保存する AWS Secrets Manager と、それらのシークレットを暗号化する AWS Key Management Service (AWS KMS)
Amazon CloudWatch のログ、CloudWatch Container Insights、アラーム、デプロイのヘルス監視
イミュータブルなゲートウェイイメージを格納する Amazon Elastic Container Registry (Amazon ECR)
オプションで利用できる AWS WAF のマネージド保護と、送信元 IP に基づくレート制限

この役割分担が重要です。ゲートウェイに AWS アカウント内の汎用シェルが与えられるわけではなく、Codex のローカル承認を置き換えるものでもありません。ゲートウェイが制御するのは、個々のモデルターンです。

このパターンで LiteLLM を使用する理由

LiteLLM は、API 互換のエンドポイントを通じて、モデルルーティング、仮想キー、予算、レート制限、使用状況テレメトリを提供するオープンソースの AI ゲートウェイです。このパターンでは、お客様が自身の AWS アカウント内で LiteLLM とそれを支えるインフラストラクチャを運用します。

ネイティブの AWS アイデンティティ、AWS Identity and Access Management (IAM) ポリシー、AWS CloudTrail のログでお客様の要件を満たせる場合は、Amazon Bedrock への直接アクセスが最もシンプルな選択肢です。開発者、チーム、モデルプロバイダーをまたいで一貫した追加の制御がシステムチームに必要な場合に、ゲートウェイが役立ちます。

次のような要件がある場合、お客様が自ら運用する選択肢として LiteLLM が有効です。

承認済みのモデルエイリアスのみを許可する
ユーザー単位またはチーム単位のスコープ付きゲートウェイキーを発行する
厳格な予算上限と、1 分あたりのリクエスト数または 1 分あたりのトークン数の制限を適用する
ルーティングとフォールバックのポリシーを一元化する
アップストリームのモデルが共有の ECS タスクロールを使用する場合でも、ゲートウェイレベルでアイデンティティを保持する
ゲートウェイ、データベース、ネットワーク、ログ、アップグレードプロセスを自身の AWS アカウント内で運用する

主なトレードオフは運用責任です。ゲートウェイの可用性、データベースのライフサイクル、バージョンのアップグレード、インシデント対応、キャパシティプランニングは、お客様のチームが担います。

Amazon ECS に Codex 用の LiteLLM ゲートウェイをデプロイする

このセクションでは、LiteLLM ゲートウェイをデプロイして Amazon Bedrock に接続し、ゲートウェイ経由でリクエストを送信するように Codex を設定する手順を説明します。

前提条件

このウォークスルーには、次のものが必要です。

AWS アカウントと、仮想プライベートクラウド (VPC)、Amazon ECS、Elastic Load Balancing、Amazon RDS、Amazon ECR、AWS WAF、IAM、AWS KMS、Secrets Manager、CloudWatch の各リソースを作成する権限
デプロイ先の AWS リージョンにおける、Amazon Bedrock 上の選択した OpenAI モデルへのアクセス
認証済みプロファイルを設定した AWS コマンドラインインターフェイス (AWS CLI) バージョン 2
Buildx を含む Docker
Codex CLI
Python 3
HTTPS でデプロイする場合は、パブリックな Amazon Route 53 ホストゾーン、または同じリージョン内の既存の AWS Certificate Manager (ACM) 証明書

このウォークスルーは、米国東部 (バージニア北部) リージョン (us-east-1) で、ゲートウェイエイリアス openai.gpt-5.5 を使用して検証しました。このエイリアスは、LiteLLM の設定で bedrock_mantle/openai.gpt-5.5 にマッピングされています。利用できるモデルはアカウントとリージョンによって異なります。

コストに関する注意: このソリューションでは、Application Load Balancer、Fargate タスク、Amazon RDS、AWS WAF、ログ、モデル推論など、課金対象のリソースが作成されます。サンプルの VPC でもネットワーク料金が発生する場合があります。ご利用のリージョンの最新料金を確認し、ウォークスルーの完了後は「クリーンアップ」セクションの手順に従ってください。

Amazon ECS に LiteLLM をデプロイする

リポジトリをクローンし、ローカルのデプロイ環境ファイルを作成します。

git clone https://github.com/openai-on-aws/guidance-codex.git
cd guidance-codex
git checkout feat/enterprise-gateway-readiness

cp deployment/litellm/.env.deploy.example \
deployment/litellm/.env.deploy

実際の .env.deploy ファイルは Git の追跡対象外です。使用する AWS プロファイル、リージョン、送信元 CIDR、DNS または証明書の値を設定します。次の抜粋は、本番環境を想定した設定例です。

AWS_PROFILE=your-profile
AWS_REGION=us-east-1
BEDROCK_REGION=us-east-1

ENABLE_TLS=true
GATEWAY_DOMAIN_NAME=codex-gateway.example.com
ROUTE53_HOSTED_ZONE_ID=Z0123456789EXAMPLE
ALB_CERTIFICATE_ARN=
ALLOWED_CIDR=203.0.113.10/32

ENABLE_WAF=true
DB_MULTI_AZ=true
DESIRED_COUNT=2
MIN_TASK_COUNT=2
MAX_TASK_COUNT=10

ALB_CERTIFICATE_ARN を ROUTE53_HOSTED_ZONE_ID の代わりに設定すると、既存の証明書を使用できます。お客様のランディングゾーンにデプロイする場合は、本番デプロイガイドの説明に従って、既存の VPC と、パブリック、プライベートアプリケーション、プライベートデータベースの各サブネットを個別に指定します。

読み取り専用の事前チェック (プリフライト) を実行します。

make litellm-check
# Direct helper invocation used by Make:
# deployment/scripts/litellm-stack.sh check

事前チェックでは、AWS CLI v2、AWS アイデンティティ、Docker、イミュータブルなイメージ参照、リージョンの一貫性、CIDR の制限、TLS の入力値、ローカルドキュメントのリンクを検証します。cfn-lint が利用可能な場合は、AWS CloudFormation の構文も検証します。

レビュー済みの LiteLLM イメージをビルドし、Amazon ECR にプッシュします。

CONFIRM_AWS_WRITE=1 make litellm-build
# Direct helper invocation used by Make:
# CONFIRM_AWS_WRITE=1 deployment/scripts/litellm-stack.sh build

ビルドでは、ダイジェストで固定された LiteLLM ベースイメージを使用し、生成された ECR ダイジェストを Git の追跡対象外のローカル状態ファイルに記録します。CloudFormation には、変更可能なイメージタグではなく、イミュータブルなダイジェストが渡されます。内部的には、ヘルパーがイミュータブルな Amazon ECR リポジトリを作成または再利用し、Amazon ECR にサインインして docker buildx build --push を実行したうえで、プッシュされたイメージのダイジェストを取得します。

CloudFormation 変更セットを、実行せずに作成します。

make litellm-plan
# Direct helper invocation used by Make:
# deployment/scripts/litellm-stack.sh plan

このコマンドは、ネットワークまたはゲートウェイのテンプレートに対して aws cloudformation deploy --no-execute-changeset を呼び出します。レビュー可能な変更セットが作成されますが、実行はされません。

変更セットをレビューしてから、デプロイします。

CONFIRM_AWS_WRITE=1 make litellm-deploy
make litellm-status
# Direct helper invocations used by Make:
# CONFIRM_AWS_WRITE=1 deployment/scripts/litellm-stack.sh deploy
# deployment/scripts/litellm-stack.sh status

deploy ヘルパーは、ネットワークスタック、続いて LiteLLM ゲートウェイスタックに対して aws cloudformation deploy を実行します。status ヘルパーは aws cloudformation describe-stacks を実行し、スタックの状態と出力を表示します。

ECS サービスでは、デプロイサーキットブレーカーによるロールバックと Application Load Balancer のヘルスチェックを使用します。リファレンステンプレートでは、ターゲット追跡によるオートスケーリング、ログとデータの暗号化、RDS のバックアップ、ALB アクセスログ、運用アラームも設定されます。

お客様の環境では、ENABLE_TLS=true を維持し、信頼できる DNS 名と ACM 証明書を使用したうえで、Application Load Balancer へのアクセスを承認済みの社内ネットワークまたは VPN の CIDR に制限してください。ECS タスクと Amazon RDS はプライベートサブネットに配置します。ECS タスクのポート 4000 や PostgreSQL のポート 5432 をパブリックに公開しないでください。

スコープ付きのゲートウェイアイデンティティを作成する

LiteLLM のマスターキーを開発者に配布しないでください。代わりに、Git の追跡対象外のデプロイファイルで、ユーザーまたはチームのアイデンティティとポリシーを設定します。

CODEX_API_SECRET_ID=codex-litellm-gateway/alice-key
CODEX_KEY_ALIAS=alice@example.com
CODEX_KEY_USER_ID=alice@example.com
CODEX_KEY_MODELS=gpt-5.5
CODEX_KEY_MAX_BUDGET=50
CODEX_KEY_BUDGET_DURATION=30d
CODEX_KEY_TPM_LIMIT=100000
CODEX_KEY_RPM_LIMIT=1000

キーをプロビジョニングします。

CONFIRM_AWS_WRITE=1 make litellm-provision-key
# Direct helper invocation used by Make:
# CONFIRM_AWS_WRITE=1 deployment/scripts/litellm-stack.sh provision-key

ヘルパーは子プロセス内でマスター認証情報を取得し、設定されたモデル、予算、レートのポリシーを指定して LiteLLM の /key/generate API を呼び出します。そのうえで、生成されたキーを AWS KMS で暗号化された Secrets Manager シークレットに直接書き込みます。どちらの認証情報も、コマンド引数に含めたり、ターミナルに出力したりすることはありません。

エンタープライズ規模で展開する場合は、各開発者のプロファイルに、割り当てられたスコープ付きキーのシークレットのみを読み取り、スタックの KMS キーで復号する権限を付与します。チームや環境ごとに、個別のシークレットパスと IAM ポリシーを使用してください。

Codex を設定する

プロバイダーブロックを生成します。

make litellm-codex-config
# Direct helper invocation used by Make:
# deployment/scripts/litellm-stack.sh codex-config

ヘルパーは、デプロイされたゲートウェイのエンドポイントを CloudFormation から読み取り、次の Codex プロバイダー設定を出力します。ユーザー設定に自動で書き込むことはありません。

出力内容を、ユーザーレベルの ~/.codex/config.toml に追加します。プロバイダーと認証の設定は、ユーザーレベルの設定に記述する必要があります。プロジェクトローカルの .codex/config.toml ファイルに記述しても、Codex はこれらの設定を無視します。

生成される設定は次のような形式です。

model = "gpt-5.5"
model_provider = "litellm-gateway"
web_search = "disabled"

[model_providers.litellm-gateway]
name = "LiteLLM Gateway"
base_url = "https://codex-gateway.example.com/v1"
wire_api = "responses"

[model_providers.litellm-gateway.auth]
command = "/absolute/path/to/python3"
args = [
"/absolute/path/to/deployment/scripts/aws-secret-auth.py",
"--aws-cli", "/absolute/path/to/aws",
"--region", "us-east-1",
"--secret-id", "codex-litellm-gateway/alice-key",
"--field", "LITELLM_API_KEY",
"--profile", "developer-profile",
"print-token"
]
timeout_ms = 30000
refresh_interval_ms = 300000

Codex は標準入力なしで認証コマンドを実行し、その標準出力からベアラートークンを読み取ります。ヘルパーは名前付きの AWS プロファイルを使用して最新のシークレットを取得するため、トークンが config.toml に保存されることはありません。

LiteLLM の管理 UI の [Models + Endpoints] には、開発者が利用できる安定したエイリアスと、各エイリアスからアップストリームの Amazon Bedrock モデルへのマッピングが表示されます。これにより、開発者が Codex の設定をプロバイダー固有のモデル ID に直接結び付けるのではなく、ゲートウェイエイリアスを参照していることを、画面上ですばやく確認できます。

次の図は、2 つのモデルエイリアスが設定された [Models + Endpoints] ページを示しています。Codex の設定に進む前に、このリストにゲートウェイエイリアスが表示されていることを確認してください。

LiteLLM model aliases mapped to Amazon Bedrock models

図 2: モデル管理ビューには、gpt-5.4 と gpt-5.5 のエイリアスと、それぞれの Amazon Bedrock Mantle へのマッピングが表示されます

LiteLLM 経由で Codex をテストする

新しい対話型の Codex セッションを開始し、/status を使用して、litellm-gateway がプロバイダーとして選択されていることを確認します。再現可能な非対話型のテストとして、まず最小限のスモークリクエストを実行します。

codex exec --sandbox read-only --ephemeral \
"Reply with exactly LITELLM_GATEWAY_OK and no other text."

コマンドが正常に終了し、LITELLM_GATEWAY_OK が出力されれば成功です。次に、モデル推論とローカルツールの両方が必要なタスクで、エージェントループを動かしてみます。

codex exec --sandbox read-only --ephemeral \
"Read README.md with shell tools and summarize the deployment architecture. Do not modify files."

Codex は、タスクとツール定義を LiteLLM 経由で送信します。モデルがファイルの読み取りを要求すると、Codex はそのコマンドをローカルで実行し、同じゲートウェイを通じてツールの実行結果を返します。

LiteLLM の管理 UI で [Logs] を開き、[Request Logs] を選択して、テストを実施した時間帯で絞り込みます。次の点を確認します。

リクエストのステータスが Success であること
キーエイリアスによって、ウォークスルー専用のキーまたは開発者のキーが識別されていること
モデルが想定どおり Amazon Bedrock のモデルにマッピングされていること
トークン数、リクエストの所要時間、コストが記録されていること
Codex が後続の Responses リクエストでツールの実行結果を送信するため、ツールを使用するタスクで複数の行が作成されていること

LiteLLM に行が記録される前に 403 レスポンスが返される場合、原因の多くはアップストリームのネットワークまたは AWS WAF によるブロックです。401 レスポンスは、ゲートウェイの認証情報がないか、無効であることを示します。スクリーンショットには、プロンプト、レスポンス、生のキー、完全なリクエスト ID、実在する従業員を特定できる情報を掲載しないでください。

次の図は、複数の Codex リクエストがゲートウェイを正常に通過した後の LiteLLM の [Request Logs] ページを示しています。このページで、リクエストが Amazon Bedrock に到達していることを確認し、ステータスコードを手がかりにエラーのトラブルシューティングを行います。

Successful Codex Responses requests in LiteLLM

図 3: リクエストログには、codex-walkthrough キーエイリアスに帰属する成功した Codex の各ターンが、モデル、コスト、所要時間、最初のトークンが返されるまでの時間とともに表示されます

Responses API のコントラクトを検証する

テキストプロンプトに正常な応答が返っても、エージェントワークフローとの互換性が証明されたことにはなりません。Codex は、基本的なチャット補完のレスポンスだけでなく、より多くの機能に依存しているためです。リポジトリに含まれている厳格なプローブを実行します。

make litellm-validate
# Direct helper invocation used by Make:
# deployment/scripts/litellm-stack.sh validate

ヘルパーはスコープ付きキーを取得して子プロセスの環境に渡し、デプロイされたゲートウェイに対して deployment/scripts/validate-responses-contract.py を実行します。

プローブでは、次の項目を検証します。

Responses オブジェクトの必須フィールドと出力の形式
previous_response_id を使用したセマンティックな継続
完了状態の最終レスポンスを含む Server-Sent Events のストリーミング
呼び出し ID を伴う関数ツールの強制呼び出し

継続テストでは、最初のレスポンスに一意のテストマーカーを記録し、後続のレスポンスでそのマーカーを参照できることを検証します。これにより、previous_response_id を構文上は受け付けるものの、前のレスポンスの状態を保持しないゲートウェイを検出できます。

実際のデプロイ環境は、コントラクト全体の検証に合格しました。CloudFormation は正常に完了し、ECS サービスは必要なタスク数に到達し、デプロイのロールアウトも完了しました。また、ALB のターゲットは正常で、暗号化された PostgreSQL データベースは利用可能かつパブリックにアクセスできない状態でした。

次の図は、実際のウォークスルースタックから取得したエンドツーエンドのデプロイ検証ダッシュボードを示しています。全体の合否ステータスと、インフラストラクチャのヘルス、API コントラクトへの準拠、データ層の設定、セキュリティポスチャを確認する 4 つの詳細パネルに注目してください。

LiteLLM live deployment and Responses contract validation

図 4: 検証出力により、AWS のデプロイが正常であることと、Codex が必要とする Responses API の動作を確認できます

検証スクリプトは互換性を確認するためのゲートであり、負荷テストではありません。本番環境に移行する前に、エージェントセッションの同時実行、長時間のストリーム、リクエストのキャンセル、キーの失効、障害からの復旧、想定されるピークトラフィックについてもテストしてください。

エンタープライズ利用に向けて LiteLLM の運用を整備する

codex exec とコントラクトテストが成功したことで、Codex がゲートウェイを使用できることは確認できましたが、互換性は出発点にすぎません。開発者のオンボーディングを始める前に、ゲートウェイでモデルアクセスをどのように制御し、使用量の帰属先を明確にし、利用量ポリシーを適用し、各モデルリクエストの運用記録を残すかを定義します。

まず、開発者が使用できるモデルの範囲を決めます。組織が承認したモデルに対してのみ安定したゲートウェイエイリアスを公開し、各アップストリームのマッピングを deployment/litellm/litellm_config.yaml で固定します。ゲートウェイイメージを再ビルドし、同じ Amazon ECR ダイジェストを各環境に順次昇格させます。これにより、開発者は安定したエイリアスを使い続けることができ、その背後にある Amazon Bedrock モデルはシステムチームが管理し続けられます。

すべてのリクエストの帰属を明確にできれば、モデルポリシーはより効果を発揮します。LiteLLM のマスターキーを配布する代わりに、ユーザー、チーム、ワークロードごとに個別のスコープ付きキーを発行します。アップストリームのリクエストで Amazon Bedrock から見えるのは LiteLLM の ECS タスクロールであるため、リクエスト元のアイデンティティを、スコープ付きキー、LiteLLM のレコード、エクスポートされたテレメトリに引き継ぎます。これにより、ゲートウェイで開発者やチームへの帰属を維持でき、認証情報を記録することなく、リクエスト ID を AWS サービスのログと関連付けられます。

同じスコープ付きアイデンティティで、利用量ポリシーも適用できます。キーをプロビジョニングする際に、CODEX_KEY_MAX_BUDGET、CODEX_KEY_BUDGET_DURATION、CODEX_KEY_TPM_LIMIT、CODEX_KEY_RPM_LIMIT を設定します。検証専用の一時的なアイデンティティで設定済みのしきい値を意図的に超え、LiteLLM が次のリクエストを拒否することを確かめて、これらの制御を検証します。こうすることで、設定が受け入れられたことを確認するだけでなく、ポリシーそのものが機能するかをテストできます。

ゲートウェイを運用するには、リクエスト経路全体を可視化することも必要です。AWS インフラストラクチャのシグナルからはサービスが正常かどうかがわかり、LiteLLM のレコードからは誰がどのモデルを使用し、リクエストがどれだけのキャパシティや予算を消費したかがわかります。ECS の必要タスク数と実行中タスク数、デプロイのロールバック、Application Load Balancer のターゲットのヘルスとレイテンシー、Amazon RDS のヘルス、LiteLLM のリクエスト数と拒否数、トークン使用量、支出、シークレットへのアクセス、IAM の変更、AWS WAF によるブロックをモニタリングします。

開発者のオンボーディングを始める前に、プロンプトとレスポンスをログに記録してよいかどうかを決めておきます。このコンテンツは機密性の高いお客様のデータを含む可能性があるものとして扱い、それに応じて秘匿化、暗号化、アクセス制御、保持期間を定義します。本番環境のデプロイでは、コンテンツのフィルタリング、拒否トピックの検出、グラウンディングチェックのために、モデルアクセス経路で Amazon Bedrock Guardrails を有効にすることを推奨します。ゲートウェイレベルの制御 (予算、レート制限、ルーティング) は、モデルレイヤーで適用される責任ある AI のセーフガードを補完するものであり、その代わりになるものではありません。

次の図は LiteLLM の [Usage] ページを示しています。このページでは、ゲートウェイを使用するすべての開発者のリクエストとトークンのメトリクスが集計されます。予算やレート制限を調整する前に、このビューで導入状況をモニタリングし、コストの異常を特定し、ユーザーや期間ごとにトラフィックを切り分けます。

図 5: 使用状況ダッシュボードでは、選択した検証期間について、モデル単位のリクエスト、トークン、支出、成功率を可視化できます

図 5 の検証期間には、成功したトラフィックと失敗したリクエストの両方が含まれており、ダッシュボードで通常のアクティビティとエラーの両方を確認できることがわかります。Codex は後続の Responses リクエストでローカルツールの実行結果をモデルに返すため、ツールを使用するタスクではリクエストログに複数の行が記録されることがあります。このように、実行の境界は運用データにも表れます。LiteLLM はモデルリクエストを制御して記録し、Codex は開発者のワークステーション上でツールを実行します。

2 つの代替アクセス経路を検討する

このウォークスルーで LiteLLM を主に取り上げたのは、ゲートウェイによる追加の制御をわかりやすく示せるためです。ただし、すべてのお客様に最適というわけではありません。

IAM Identity Center による直接アクセス

AWS ネイティブのアイデンティティと監査の制御で十分な場合は、組み込みの amazon-bedrock Codex プロバイダーを使用します。

model_provider = "amazon-bedrock"
model = "openai.gpt-5.5"

[model_providers.amazon-bedrock.aws]
profile = "codex-bedrock"
region = "us-east-1"

開発者は、名前付きの IAM Identity Center プロファイルでサインインします。

aws sso login --profile codex-bedrock

この経路では、ゲートウェイ、データベース、およびそれらに関連する運用が不要になります。開発者の AWS セッションのアイデンティティは AWS CloudTrail のログに残りますが、ゲートウェイレベルで一元管理する厳格な予算上限やルーティングポリシーは追加されません。

リポジトリの「IAM Identity Center quickstart」には、分離されたグループとアクセス許可セットの作成、そのグループの AWS アカウントへの割り当て、クライアント設定の出力、サインインしたプロファイルによる Amazon Bedrock へのアクセス検証を行うための CloudFormation とヘルパーコマンドが含まれています。ゲートウェイを追加する前に、まずこの直接アクセス経路をベースラインとして使用してください。

Portkey によるマネージドアクセスまたはハイブリッドアクセス

LiteLLM のリファレンススタックを自ら運用することなく、マネージドのコントロールプレーン、一元化されたルーティングとポリシー、またはサポートが提供されるハイブリッドデータプレーンを利用したい場合は、Portkey が役立ちます。

Codex を Portkey 経由で評価するには、Portkey のワークスペースキー、Amazon Bedrock Model Catalog プロバイダー、Responses ワイヤプロトコルを設定します。

model_provider = "portkey"
model = "@bedrock-validation/<approved-model-id>"

[model_providers.portkey]
name = "Portkey"
base_url = "https://api.portkey.ai/v1"
env_key = "PORTKEY_API_KEY"
wire_api = "responses"

本番環境に昇格させる前に、同じ厳格な Responses プローブを実行します。特に、previous_response_id によるセマンティックな継続、ストリーミング、関数呼び出し、Amazon Bedrock への正確なルート、IAM ロールと外部 ID の設計を検証してください。製品ドキュメントや認証レスポンスだけでは、意図したモデル経路が Codex のコントラクト全体を満たしている根拠にはなりません。

ゲートウェイ全体を自身の AWS アカウントで運用することよりも、マネージドまたはハイブリッドの運用モデルを重視する場合は、Portkey を選択します。アーキテクチャを決定する際には、ベンダーのライセンス、データの取り扱い、リージョンごとの提供状況、障害モード、サポート範囲も確認してください。

クリーンアップ

CloudFormation によって削除されるリソースと保持されるリソースをプレビューします。

make litellm-cleanup-plan
# Direct helper invocation used by Make:
# deployment/scripts/litellm-stack.sh cleanup-plan

このコマンドはスタックを読み取り、何も削除せずに、各リソースが削除されるか保持されるかを一覧表示します。

正確なスタック名を確認したうえで、ゲートウェイを削除します。

CONFIRM_STACK_DELETE=codex-litellm-gateway \
make litellm-cleanup
# Direct helper invocation used by Make:
# CONFIRM_STACK_DELETE=codex-litellm-gateway \
# deployment/scripts/litellm-stack.sh cleanup

ヘルパーは Amazon RDS の削除保護を確認し、aws cloudformation delete-stack を呼び出して、ゲートウェイスタックの削除が完了するまで待機します。

共有されていないサンプルのネットワークスタックも削除する場合は、オプトインしたうえで個別に確認します。

CONFIRM_STACK_DELETE=codex-litellm-gateway \
DELETE_NETWORKING=1 \
CONFIRM_NETWORKING_DELETE=codex-networking \
make litellm-cleanup
# Direct helper invocation used by Make:
# CONFIRM_STACK_DELETE=codex-litellm-gateway \
# DELETE_NETWORKING=1 \
# CONFIRM_NETWORKING_DELETE=codex-networking \
# deployment/scripts/litellm-stack.sh cleanup

これにより、ゲートウェイスタックに続いて、サンプルのネットワークスタックも削除されます。共有ネットワークにはこのオプションを使用しないでください。

リファレンススタックは Amazon RDS の最終スナップショットを作成し、KMS キー、Secrets Manager のシークレット、CloudWatch のロググループ、ALB のアクセスログ用バケットを保持します。ECR イメージと、プロビジョニングしたスコープ付きキーのシークレットも、スタック削除の対象外です。データ保持ポリシーに従って、保持されたリソースを確認し、削除してください。

まとめ

Codex を LiteLLM 経由でルーティングすると、Codex がローカルでタスクとツールを実行する方式を維持しながら、お客様が運用するコントロールポイントで、モデルの選択、スコープ付きアイデンティティ、予算、レート制限、テレメトリを管理できます。本番環境への移行で重要な判断基準は、ゲートウェイがテキストを返せるかどうかではありません。エージェントワークフローに必要な Responses の動作をゲートウェイが維持できるかどうか、そしてシステムチームが追加されたインフラストラクチャを確実に運用できるかどうかです。

AWS ネイティブの制御で要件を満たせる場合は、IAM Identity Center による直接アクセスから始めてください。お客様が運用するゲートウェイのポリシーが運用負荷に見合う場合は、LiteLLM を追加します。マネージドまたはハイブリッドの運用モデルの方が組織に適している場合は Portkey を評価してください。いずれの経路でも、同じコントラクトテストを適用してください。

著者について

本ブログは Security Solutions Architect の中島章博が翻訳しました。

Amazon Web Services ブログ