Bedrock AgentCore RuntimeをAWS WAF経由に限定する2構成

AWSは、AgentCore Runtimeへの通信をAWS WAFで検査するため、公開 ALBからVPCインターフェースエンドポイントへ流す二つの構成を解説しました。

要点

• 一つ目はALBとVPCエンドポイントの間にLambda proxyを置き、要求変換を制御します。
• 二つ目はALBからエンドポイントのENI IPへ直接送り、Lambdaの経路を省きます。
• Runtimeのリソースポリシーで直接アクセスを閉じ、WAFを迂回できないようにします。

今回のブログ記事で語られていること

AgentCore Runtimeを公開APIとして使う場合、認証だけでなく、悪意ある要求、既知の攻撃形式、送信元制限、流量制御を入口で扱いたい場面があります。AWS WAFはALBへ関連付けられますが、Runtimeへ直接関連付ける構成ではありません。記事は、公開ALBでWAF検査を行い、その後の通信をVPCインターフェースエンドポイントからRuntimeへ渡す道を示しています。

Lambda proxyを挟む構成は、ヘッダー、本文、署名、経路を細かく変換でき、独自の検証や監査を加えやすい反面、実行時間、費用、障害点、ペイロード上限が増えます。ENI IPへ直接送る構成は経路が短くなりますが、エンドポイントのENI変更、ターゲットグループの健全性、アドレス管理を運用する必要があります。どちらもSigV4とCognito JWTによるOAuth認証で試験されています。

最も重要なのは、ALBを追加しただけで終わらず、Runtimeのリソースポリシーで直接呼び出しを拒否することです。直接URLが生きていれば、攻撃者や誤設定したクライアントはWAFを迂回できます。許可するエンドポイント、呼び出し主体、ネットワーク条件を限定し、ALB経由の正常要求、直接要求、誤った署名、期限切れJWT、大きな本文、レート超過を試してください。

運用ではWAF、ALB、Lambdaまたはターゲットグループ、VPCエンドポイント、Runtimeのログを同じ追跡IDで結びます。WAF規則を強めた時に正当なストリーミング応答や長時間処理を遮断しないかも確認が必要です。二つの構成は利便性と制御力の比較であり、Lambdaを使う方が常に安全という意味ではありません。必要な要求変換と運用能力で選びます。

今回のブログ記事が関係する人

AgentCore Runtimeを公開するクラウド基盤担当、WAFと認証を管理するセキュリティ担当、API運用者に関係します。

結局、今回のブログ記事をどう読むべきか

入口にWAFを置く方法より、迂回経路までリソースポリシーで閉じることが核心です。構成選択時は変換要件、遅延、障害点、エンドポイント運用を合わせて比較してください。