生成AIエージェントをAmazon Bedrock AgentCoreで本番APIエンドポイントとしてデプロイする場合、AWS WAFを使用してWebアプリケーションファイアウォールポリシー、レート制限、一般的なWeb脅威からの保護、または監査制御を適用したい場合があります。
AWS WAFは、Elastic Load Balancing Application Load Balancers（ALB）、Amazon CloudFrontディストリビューション、およびAmazon API Gateway REST APIと統合できます。Amazon CloudFrontはキャッシュとコンテンツ配信向けに設計されており、エージェント呼び出しはリアルタイムで動的であるため、キャッシュは適用されません。Amazon API Gatewayは独自の認証とリクエスト変換レイヤーを追加するため、AgentCoreの組み込みSigV4およびOAuth処理と二重認証問題を引き起こす可能性があります。そのため、インターネット向けALBが統合ポイントとして適しています。ALBはヘッダーを透過的に渡し、VPC内部ルーティングをサポートし、AWS WAF WebACLを直接接続できます。その後、VPCインターフェースエンドポイントを介してAgentCoreデータプレーンサービスにトラフィックをルーティングします。
ここで課題が発生します。ALBはバックエンドターゲットが応答していることを確認するためにヘルスチェックを必要としますが、AgentCoreランタイムはAPI呼び出し（ヘルスチェックリクエストを含む）にSigV4またはOAuth認証を要求します。標準のALBヘルスチェックは認証なしのリクエストを送信するため、デフォルトで失敗します。認証なしでヘルスチェックを機能させつつ、認証済みの本番トラフィックをAgentCoreに渡す方法が必要です。
この投稿では、この問題に対処する2つのアーキテクチャパターンを紹介します。どちらもインターネット向けALBとAWS WAFを使用し、VPCインターフェースエンドポイントを介してAgentCoreランタイムにトラフィックをルーティングします。パターン1はALBとVPCエンドポイントの間にAWS Lambdaプロキシを配置し、リクエスト変換を完全に制御できます。パターン2はVPCエンドポイントのENI IPアドレスをALBから直接ターゲットにし、Lambdaホップを完全に排除します。また、リソースポリシーを使用して直接アクセスをブロックし、トラフィックがAWS WAFのみを通過するようにする方法も学びます。両パターンとも、SigV4およびOAuth（Amazon Cognito JWT）認証を使用してエンドツーエンドでテスト済みです。
アーキテクチャの概要
2つのパターンは共通の基盤を共有しています。クライアントアプリケーションは、認証済みリクエスト（SigV4署名またはOAuthベアラートークン）をインターネット向けALBに送信します。AWS WAFがリクエストを検査した後、ALBはHTTPSポート443でVPCエンドポイントのENIに転送します。AgentCoreが認証を検証し、リクエストを内部ポート8080で実行中のランタイムコンテナにルーティングします。パターンの違いは、ALBとVPCエンドポイントの間に何が配置されるかです。
アーキテクチャは4つのコンポーネントで構成されます：
- AWS WAF：ALBに接続され、レート制限、SQLインジェクション保護、XSSフィルタリング、ボット制御を提供。
- ALB：インターネット向け、HTTPSリスナー（ポート443）、VPCエンドポイントENI IPターゲットにルーティング。
- VPCインターフェースエンドポイント：PrivateLinkを介してAgentCoreへのプライベート接続を提供。
- AgentCoreランタイム：エージェントコードを実行するマネージドコンテナ、内部ポート8080でリスン、SigV4およびOAuth認証をサポート。
注意：ランタイム呼び出しにはcom.amazonaws..bedrock-agentcore（データプレーン）を使用してください。3つの異なるエンドポイントサービスがあります：bedrock-agentcore（データプレーン、ランタイム、メモリ、ツール用）、bedrock-agentcore-control（コントロールプレーン）、bedrock-agentcore.gateway（ゲートウェイのみ）。間違ったエンドポイントを使用するとランタイムにルーティングされません。
前提条件
- Amazon Bedrock AgentCoreが有効化されたAWSアカウント。
- デプロイ済みのAgentCoreランタイム（パブリックまたはVPCモード）。
- 少なくとも2つのアベイラビリティーゾーンにパブリックおよびプライベートサブネットを持つVPC。
- ALBのHTTPSリスナー用の同一リージョンのAWS Certificate Manager証明書。
- Amazon Cognitoユーザープール（OAuthパターン用）またはAWS認証情報（SigV4パターン用）。
- ALB、VPCエンドポイント、AWS WAFに関する知識。
次のセクションでは、AWS WAFをAgentCoreと統合する2つのパターンについて説明します。リクエスト変換、カスタムログ記録、またはALBとAgentCore間の認証変換が必要な場合は、パターン1から始めてください。最もシンプルなアーキテクチャと最低レイテンシを重視する場合は、パターン2に進んでください。
パターン1：ALBとLambdaプロキシ
このパターンでは、Lambda関数がALBの背後に配置され、認証ヘッダーを含むリクエストをVPCエンドポイント経由でAgentCoreに転送します。Lambda関数は計算レイヤーを提供し、リクエストの変換、認証方法間の変換、またはAgentCoreにリクエストが到達する前のカスタムログ記録を実行できます。
パターン1を選択する条件：
- リクエスト変換、ヘッダー操作、ペイロード変更、またはプロトコル変換が必要。
- プロキシレイヤーでのカスタムログ記録や監査証跡が必要。
- 複数の認証方法間の変換が必要。
- ALBとバックエンド間に明示的な計算レイヤーが必要（一部のセキュリティポリシーで要求）。
VPCエンドポイントの作成：プライベートサブネットにAgentCoreデータプレーンサービスのVPCインターフェースエンドポイントを作成します。
VPCエンドポイントのセキュリティグループの設定：ALBのセキュリティグループからのインバウンドHTTPS（ポート443）のみを許可します。
Lambdaプロキシの作成：Lambda関数はALBからのリクエストを受信し、VPCエンドポイント経由でAgentCoreに転送します。OAuthの場合は、Authorizationヘッダー（ベアラートークン）をそのまま、元のリクエストパスとボディとともに渡し、JWTがそのままAgentCoreに到達するようにします。SigV4の場合、署名は元のリクエストホストにバインドされており、リクエストがVPCエンドポイントに転送されると無効になるため、プロキシは自身の実行ロール資格情報を使用してリクエストに再署名します。
ALBとLambdaターゲットグループの設定：Lambdaターゲットグループを作成し、プロキシ関数を登録し、ALBにHTTPSリスナーを作成します。ALBはTLS終端を処理し、復号されたリクエストをLambda関数に転送します。
AWS WAFの接続：AWS WAF WebACLをALBに関連付けます。典型的な初期設定には、AWSManagedRulesCommonRuleSet（一般的なWeb脅威からの保護）、レートベースのルール（送信元IPあたりのリクエストを制限）、およびAWSManagedRulesBotControlRuleSet（エージェントがブラウザベースのクライアントに公開されている場合）が含まれます。
パターン1のトレードオフ：
- レイテンシ：リクエストあたり50〜200ミリ秒追加（Lambdaコールドスタート）。プロビジョンド並列処理で緩和可能。
- コスト：リクエストあたりのLambda呼び出しコスト。
- 複雑さ：デプロイ、監視、保守が必要な追加コンポーネント。
- 柔軟性：リクエスト/レスポンス変換とカスタムログ記録を完全に制御。
パターン2：ALBからVPCエンドポイントへ直接
このパターンでは、ALBはVPCエンドポイントのENI IPアドレスをHTTPSポート443で直接ターゲットにします。Lambda関数やNetwork Load Balancerはありません。ALBは認証ヘッダーをAgentCoreに透過的に渡します。このアーキテクチャはコンポーネントが少なく、Lambdaプロキシホップを排除します。
パターン2を選択する条件：
- よりシンプルなアーキテクチャ、コンポーネントが少ない。
- ALBとAgentCore間のリクエスト変換が不要。
- 追加ホップなしで最小レイテンシが必要。
- クライアントアプリケーションがSigV4またはOAuth署名を直接処理。
VPCエンドポイントの作成：パターン1のステップ1と同じ。
VPCエンドポイントENI IPアドレスの取得：VPCエンドポイントによって作成されたENIのプライベートIPアドレスを取得します。これらのIPがALBターゲットグループのターゲットになります。
IPターゲットグループとヘルスチェックの作成：IPタイプのターゲットグループをHTTPSポート443で作成し、ヘルスチェックパスを"/"、マッチャーを200-499に設定します。AgentCoreは"/"に対して404を返しますが、ALBは200-499の範囲を正常と見なします。目標はVPCエンドポイントが応答していることを確認することであり、特定のステータスコードは重要ではありません。ヘルスチェックは認証を必要としません。
ターゲットの登録とALBリスナーの作成：VPCエンドポイントENI IPをターゲットグループに登録します。ALBにHTTPSリスナーを作成し、このターゲットグループにトラフィックをルーティングし、AWS WAF WebACLを接続します。
リソースポリシーでバックドアを閉じる：VPCエンドポイントのリソースポリシーを更新し、ALBのセキュリティグループからのトラフィックのみを許可して直接アクセスをブロックします。
パターン2のトレードオフ：
- レイテンシ：最小限、追加ホップなし。
- コスト：ALBとVPCエンドポイントのみの費用、Lambda費用なし。
- 複雑さ：低い、コンポーネントが少ない。
- 柔軟性：リクエスト変換機能なし。
まとめ
両方のパターンにより、AWS WAFを介してAgentCoreランタイムを保護できます。パターン1は柔軟性を提供しますがレイテンシが増加し、パターン2は低レイテンシですが柔軟性が低くなります。リソースポリシーを使用してトラフィックがAWS WAFのみを通過するようにし、直接アクセスを防止します。