AWSが公開した技術検証により、Amazon Bedrockのエージェント実行基盤「AgentCore Runtime」をインターネット経由で安全に公開する2つの構成が明らかになった。Application Load BalancerとAWS WAFを前置し、VPCインターフェースエンドポイント経由でトラフィックを流すこの設計は、Lambdaを挟む完全制御型と、Lambdaを排除した直接接続型に分岐する。生成AIエージェントを外部APIとして提供する際の必須パターンとして、設計選択の基準が浮き彫りになっている。
AgentCore Runtimeが開いたAPI公開の裏口とその閉鎖手法
Bedrockのエージェント機能を動かすAgentCore Runtimeは、直接的なインターネット公開を想定していない。しかし社外アプリケーションや別アカウントと連携する場合、隔離されたVPCの外へAPIを露出させる必要が生じる。今回の技術記事は、多くの開発者が見落とす「ベースURLを直接叩けばWAFを迂回できてしまう」という裏口の存在を指摘し、リソースポリシーで特定のVPCエンドポイントからの呼び出しだけを許可することで、トラフィックを必ずWAF経由に強制する実装を示している。これは単なる設定例ではなく、共有責任モデルにおける顧客側の防御策の不足を埋める設計パターンだ。
Lambdaプロキシがもたらす完全制御と運用コストのトレードオフ
パターン1では、ALBとVPCインターフェースエンドポイントの間にLambda関数を配置し、リクエストの変換やヘッダーの付与をプロキシに任せる。これにより、Bedrockが期待するSigV4署名やOAuthトークンの検証・注入をアプリケーションから完全に隠蔽でき、既存クライアントの改修を最小化できる利点がある。一方で、エージェント呼び出しのたびにLambdaの実行待ち時間とコストが上乗せされる。同期的な会話応答が求められる生成AIワークロードでは、この追加レイテンシを許容できるかが採用の分かれ目となる。
ENI直結が生むLambda排除の効率性と設計上の制約
パターン2は、ALBのターゲットグループにVPCエンドポイントのENIのプライベートIPアドレスを直接登録する。これによりLambdaのホップが不要となり、単純なリクエスト転送ではレイテンシとコストの両面で優位に立つ。ただしALBから届くリクエストのパスやヘッダーをAgentCore Runtimeが期待する形式に整形する責務はクライアント側に残る。またENIのIPアドレスが変更された場合に自動追随する仕組みを別途用意する必要があり、可用性をどこまで自動化するかが運用設計の焦点となる。
SigV4とJWT認証が試すエージェントAPIの企業間境界
両パターンとも、Amazon Cognitoが発行するJWTを用いたOAuth認証と、AWSの内部署名プロトコルであるSigV4をエンドツーエンドで検証している。これはBedrockエージェントを単なる社内ツールではなく、対外API製品として提供するシナリオを想定している証左だ。WAFでボット制御やレート制限をかけた上で、さらにアプリケーション層でJWTクレームを検証する多層防御は、生成AIエージェントが外部から悪用されるリスクを抑える設計の雛形として機能する。
編集視点：AI実行基盤のセキュリティ統合が生む次の競争軸
この記事は技術ハウツーに留まらず、クラウド事業者間の競争軸がモデル性能から「安全な実行基盤の統合度」へと拡大していることを映し出す。Bedrockはエージェント機能をマネージドサービスとして提供するが、その外部公開パターンを利用者が自力で組み立てなければならない点は、今後の差別化余地でもある。WAFやVPCエンドポイントとの統合がより簡素化され、ポリシー定義ひとつでエージェントAPIを安全に公開できるプラットフォームが登場すれば、企業の生成AI導入速度はさらに加速するだろう。
