【検証】VPCからBrave Searchを使う：Network Firewallで api.search.brave.com だけ穴を開けて、Web検索・AI回答が通るか試す

• URL: https://dev.classmethod.jp/articles/aws-nfw-brave-search-api-verification/
• 日付: 2026-06-04
• Tier: Tier 3
• 要旨: FargateやAgentCore上のAIエージェントにWeb検索を組み込む際、AWS Network Firewallでapi.search.brave.comの1ドメインだけ許可すればWeb検索・AI回答（Summarizer）が全て通ることをCDK構成で実証。ステートフルなSNIフィルタの使い方と、戻りトラフィックもNetwork Firewallを通す必要がある設計上の理由を詳述した。

詳細

検証の目的

• AIエージェントにWeb検索を足すために、ファイアウォールに開けるべき穴の数を確認
• Brave Search APIのエンドポイントは全て api.search.brave.com のサブパスに集約 → 1ドメインで全機能通るはずという仮説を検証

構成

• 単一VPC・単一AZ（検証用に最小構成）
• 3層サブネット: workload（EC2）/ public（NAT Gateway）/ firewall（Network Firewallエンドポイント）
• Network Firewallのデフォルト: 全egress遮断（aws:drop_established）
• CDK1ファイルでデプロイし、ドメイン許可だけCLIで後から追加する設計

重要な設計ポイント

• 戻りトラフィックもNetwork Firewallを通す必要がある: ステートフルなSNI（ドメイン）フィルタは1通信の行きと戻りを同じ経路で見る → Internet GatewayにEdge Route Tableを設定して戻りをNetwork Firewallへ迂回
• セキュリティグループは外向きをTCP443 to 0.0.0.0/0のみ（宛先IPは絞らずドメイン制御はNetwork Firewallに任せる）
• Brave APIキーはSecrets Managerにインターフェースエンドポイント経由で保存（インターネット不要）

検証結果

• api.search.brave.com の1ドメインだけ許可した状態で、curl・Python・AI回答（Summarizer）の全て通信成功を確認（東京リージョン, 2026年6月）

本番向け推奨構成

• 複数アプリVPCをTransit Gatewayで集約し、中央のegress VPCのNetwork Firewallでまとめて検査するアーキテクチャが一般的