AWS、WAFを活用してAmazon Bedrock AgentCore Runtimeのセキュリティを強化する2つの構成案を提示

要点

• Amazon Bedrock AgentCoreで構築された生成AIエージェントのAPIエンドポイントを、AWS WAFで保護する設計手法が公開された。
• 統合の接続点には、認証ヘッダーを透過的に渡し、仮想ネットワーク内のルーティングに対応する「Application Load Balancer」を採用している。
• AgentCoreがヘルスチェック要求に対しても認証を求めるため、標準のロードバランサーによる死活監視が失敗する課題を解決する必要がある。
• 解決策として、中継用のAWS Lambdaプロキシを配置する構成と、VPCエンドポイントのIPアドレスを直接指定する構成の2パターンが提示された。
• いずれのパターンも、認証処理を維持したまま、AWS WAFを迂回する直接アクセスをリソースポリシーで遮断する対策が施されている。

リード文

Amazon Web Services（AWS）は2026年7月8日、自社の公式ブログ「AWS ML Blog」において、生成AIエージェントの構築フレームワークである「Amazon Bedrock AgentCore」の実行環境（Runtime）を、Webアプリケーションファイアウォール「AWS WAF」で保護するための2つのアーキテクチャパターンを公開した。本番環境にデプロイされたAIエージェントに対し、Web上の脅威からの保護やアクセス制限を適用する際の具体的な技術的アプローチを解説している。

本文

Amazon Bedrock AgentCoreで開発されたAIエージェントを、本番環境のAPIエンドポイントとしてデプロイする際、システムの安全性や信頼性を高めるためにAWS WAFを導入したいというニーズがある。AWS WAFは、Webアプリケーションに対するサイバー攻撃を検知・遮断するセキュリティサービスであり、通常はロードバランサーである「Application Load Balancer（ALB）」や、コンテンツ配信ネットワークの「Amazon CloudFront」、API管理サービスの「Amazon API Gateway」と統合して利用される。

しかし、AIエージェントの呼び出しはリアルタイムかつ動的な処理であるため、キャッシュを主目的とするCloudFrontは適合しない。また、API Gatewayを仲介させた場合は独自の認証やリクエスト変換層が追加されるため、AgentCoreが標準で備えるSigV4（AWSのリクエスト署名プロセス）やOAuth（認可フレームワーク）による認証処理と重複し、二重認証の問題が発生してしまう。そのため、元のリクエストヘッダーを透過的に後ろへ渡し、VPC（仮想プライベートクラウド）内部へのルーティングをサポートする「インターネット公開型のALB」が、AWS WAFとの最適な統合ポイントとなる。

この構成では、ALBからVPC Interface Endpoint（AWS PrivateLinkを通じてAWSサービスにプライベート接続するための窓口）を経由してAgentCoreデータプレーンサービスにトラフィックを送信する。しかし、ここでバックエンドのヘルスチェック（死活監視）に関する課題が生じる。ALBが背後のターゲットが稼働しているかを判断するためにはヘルスチェックが必要だが、AgentCore Runtimeはヘルスチェック要求を含むすべてのAPI呼び出しに対してSigV4またはOAuthによる認証を要求する。一方で、標準のALBヘルスチェックは認証情報を含まない未認証のリクエストを送信するため、初期設定のままでは接続が拒否されてエラーとなってしまう。

このヘルスチェックの認証問題を回避しつつ、正規の認証トラフィックを正常に通すため、AWSは以下の2つのアーキテクチャパターンを提案している。

パターン1：AWS Lambdaプロキシを配置する構成
1つ目のパターンは、ALBとVPCエンドポイントの間に、サーバーレスでコードを実行できるサービスである「AWS Lambda」をプロキシ（代理）として配置する手法である。Lambdaを挟むことにより、リクエストの変換やヘルスチェックへの応答を開発者が詳細に制御できるようになる。

パターン2：VPCエンドポイントのIPアドレスを直接ターゲットにする構成
2つ目のパターンは、ALBの転送先ターゲットとして、VPCエンドポイントに関連付けられている「ENI（Elastic Network Interface、仮想ネットワークカード）」のIPアドレスを直接指定する手法である。このアプローチでは、パターン1のようにLambdaを中継する処理工程（ホップ）が発生しないため、よりシンプルな接続構成が可能となる。

また、いずれのパターンにおいても、WAFを通らない「直接アクセスのバックドア（裏口）」を閉じるための対策が解説されている。リソースポリシーを設定し、WAFがアタッチされたALBからの通信のみを受け入れるようにアクセス制限を行うことで、すべてのトラフィックが必ずWAFによる検証を通過するように強制できるという。

補足

なお、今回示された2つのアーキテクチャパターンは、SigV4署名による認証、およびAmazon CognitoのJWT（JSON Web Token）を用いたOAuth Bearerトークン認証の双方で、エンドツーエンドでの正常な動作が検証されている。