© 2026 Classmethod, Inc. 2026/3/24 AWS re:Invent 2025 新機能「やってみた」報告会 〜ネットワーク‧運⽤編〜 Network Firewall Proxyで ⾃前プロキシを消し去ることができるのか 

© 2026 Classmethod, Inc. 本⽇のテーマ 2 閉域ネットワークのアウトバウンド制御、⾃前プロキシで頑張っていませんか？ 先⽇パブリックプレビューとして発表のあったAWS Network Firewall Proxy で ⾃前プロキシ運⽤を消し去れるのか？を検討してみました。 ⼤前提としてパブリックプレビュー段階のサービスです。 今後⼤幅な変更がある可能性もありますのでその点ご認識ください。 

© 2026 Classmethod, Inc. 結論 : 消し去ることができる未来は近い。でも今はまだ早い。 3 消し去れそうな理由 ● ドメインベースのアウトバウンド制御がマネージドで実現できる ● HTTP メソッド‧ヘッダー‧URI 等の細かな制御にも対応している ● Windows Update レベルの実通信でも問題なく動作する まだ早い理由 ● プレビュー段階（us-east-2 のみ、東京未対応） ● 料⾦体系が未確定 ● HTTP/1.1 のみサポート（HTTP/2, HTTP/3 は⾮サポート） ● アカウントあたり設定可能な Proxy 数 は 1つまで（プレビュー時点での制限） ● Regional NAT Gateway には⾮対応（Zonal のみ） 

© 2026 Classmethod, Inc. そもそもなぜプロキシが必要なのか？ 4 

© 2026 Classmethod, Inc. 閉域ネットワークの課題 5 ● セキュリティ上、プライベートサブネットのリソースから直接インターネットには出られない ● でも OS アップデートや API 連携など外に出たい通信はある ● 「必要な通信だけ許可して、それ以外は遮断する」 仕組みが必要 →この仕組みを実現するのがプロキシ（厳密にはフォワードプロキシ） 

© 2026 Classmethod, Inc. プロキシの種類を整理する 6 →Network Firewall Proxy はフォワードプロキシに該当するサービス 種類 方向 主な目的 フォワードプロキシ 内部 → 外部 アウトバウンド通信の制御・中継 リバースプロキシ 外部 → 内部 負荷分散・SSL 終端 キャッシュプロキシ どちらも コンテンツキャッシュで帯域節約 主な種類と⽤途 

© 2026 Classmethod, Inc. Squidという定番ツール 7 ● Squid ができること（プロキシ機能の全般を設定可能） ○ フォワードプロキシ（ACL でドメイン制御） ○ リバースプロキシ（アクセラレータモード） ○ キャッシュプロキシ（コンテンツキャッシュ） ○ 透過型プロキシ（intercept モード） ■ クライアントにプロキシの存在を意識させず、ネットワーク側のルーティングで実現 ● 実際のアウトバウンド制御でよく使われているもの ○ フォワードプロキシ + キャッシュ の組み合わせ 

© 2026 Classmethod, Inc. 今回のスコープ：フォワードプロキシ 8 ● 許可した通信先だけにアクセスさせたい ● ドメインで許可 / 拒否を判断したい ● 通信内容をログに残したい 上記の⽤途であれば Network Firewall Proxy で代替可能な想定。 キャッシュ等が必要なら別途検討が必要（今回のスコープ外）。 

© 2026 Classmethod, Inc. ⾃前フォワードプロキシのよくある構成例 9 ※上記に限らず、ECSなどのコンテナでProxy運⽤していることもあると思います。 ※本番ワークロードではProxy⽤のVPCが別途存在することもよくあります。 

© 2026 Classmethod, Inc. ⾃前プロキシの「つらみ」 10 課題 内容 構築コスト ソフトウェア選定、セットアップ、設定ファイル管理 運用負荷 OS パッチ、ミドルウェア更新、ログローテーション 可用性 冗長化の設計・実装が必要（ Multi-AZ、ECS タスク数等） スケーラビリティ トラフィック増加への対応（ EC2 スケール / Fargate タスク増） 障害対応 プロキシ障害 = 全アウトバウンド通信断 → やりたいのはドメイン制御だけなのに、やることが多すぎる 

© 2026 Classmethod, Inc. Network Firewall Proxy とは 11 

© 2026 Classmethod, Inc. Network Firewall Proxy 概要 12 ● NAT Gateway にアタッチするマネージドフォワードプロキシ ○ VPC からのアウトバウンド通信（HTTP/HTTPS）を検査‧フィルタリング ○ パブリックプレビュー段階（変更の可能性あり） ○ 現在オハイオリージョンのみでサービス提供 ● 主要コンポーネント コンポーネント 役割 Proxy Configuration 監視・保護の動作を定義 Proxy Rule Group フィルタリングルールの集合（再利用可能） Proxy Endpoint クライアントが接続するエンドポイント Proxy Configuration を NAT Gateway にアタッチ 

© 2026 Classmethod, Inc. プロキシ接続コンポーネントの図解 13 出典: Securing Egress Architectures with Network Firewall Proxy - AWS Blog https://aws.amazon.com/jp/blogs/networking-and-content-delivery/securing-egress-architectures-with-network-firewall-proxy/ 

© 2026 Classmethod, Inc. 3つの処理フェーズ 14 ● 各フェーズで Allow / Deny / Alert のアクションを設定可能 ● 各フェーズ内で設定するルールは Insert Position（優先度）で評価順を制御可能 ● 評価は全フェーズを通して⾏われるが、フェーズ毎のデフォルトアクションを Allowに設定す ることで細かい検査をせずに許可することも可能 フェーズ タイミング 主な用途 Pre-DNS DNS 解決前 ドメインベースの許可・拒否 Pre-request DNS 解決後、リクエスト送信前 HTTP メソッド・ヘッダー・リクエストパス の制御 Post-response レスポンス受信後 Content-Type・Content-Length 等の制御 

© 2026 Classmethod, Inc. 3つの処理フェーズについてのざっくりとした通信の流れ 15 

© 2026 Classmethod, Inc. Network Firewall Proxy の機能⼀覧 16 機能 内容 TLS Interception設定 ドメイン制御 Allowlist / Denylist によるアクセス制御 不要 Proxy経由の通信でのDNS Tunneling 防止 Allowlist 運用により非許可ドメインへの DNSクエリを抑制 不要 SNI Spoofing 対策 ドメイン検証による SNI 偽装の防止（構造的に防げる） 不要 ソース制御 VPC ID / VPC Endpoint ID / Account ID / IP CIDR での送信元制 御 不要 HTTP フィルタリング メソッド・ヘッダー・URI 等（HTTPS 通信時） 必要 レスポンス検査 Content-Type・ステータスコード等（ HTTPS 通信時） 必要 ● TLS Interception （オプション設定）の注意点 ○ HTTPS 通信の中⾝（HTTP ヘッダー等）を検査するには TLS Interception が必要 ○ TLS Interception には AWS Private CA（PCA）の構築が必要 ○ PCA のルート証明書をクライアントのトラストストアに追加する必要あり → ドメイン制御のみの⽤途なら不要、HTTP レベルの細かな制御が必要なら要検討 

© 2026 Classmethod, Inc. なぜ SNI Spoofing を構造的に防げるのか 17 従来（ルーティング型 FW） Network Firewall Proxy DNS 解決 クライアント Proxy 接続先 IP の決定 クライアント Proxy SNI Spoofing 成立しうる 構造的に不可能 → Proxy が DNS 解決と接続先を制御しているため、クライアントが接続先を偽装できない ※ただし、外部アクセスが必ず Proxy 経由になるようなネットワーク設計（SG‧ルートテーブル）が前提 従来のNetwork Firewallのホワイトリストを使⽤したパターンでSNI Spoofingが⾏われる場合の簡単な図解 

© 2026 Classmethod, Inc. 設定⽅法は？簡単な検証をしてみた 18 

© 2026 Classmethod, Inc. 検証：Windows Update は通るのか 19 ● 最低限な構成でNetwork Firewall Proxy経由のWindows Updateを試してみました。 

© 2026 Classmethod, Inc. 設定 (1-1) ルールグループ - ルール定義例 20 ホワイトリスト⽤のルールを定義 

© 2026 Classmethod, Inc. 設定 (1-2) ルールグループ - ドメイン制御条件設定例 21 ● Pre-DNSフェーズでホワイトリスト⽅式を実現 ○ ホワイトリスト⽤ルールのアクション ■ 許可 ○ 条件キー ■ 「request:DestinationDomain」 ○ 演算⼦ ■ 「StringLike（ワイルドカード対 応）」 ● 許可したドメイン例 ○ 「windowsupdate.microsoft.com」 ○ 「*.delivery.mp.microsoft.com」 ○ 「*.download.windowsupdate.com」等 ■ 参考 ：https://learn.microsoft.com/ja-jp/ windows-server/administration/wind ows-server-update-services/deploy/2 -configure-wsus 

© 2026 Classmethod, Inc. 設定 (2) Proxy Configuration 22 プロキシ設定でPreDNSのデフォルトアクションを「拒否」に設定（他フェーズは許可）し、 オプションで作成済みのルールグループをアタッチします。 

© 2026 Classmethod, Inc. 設定 (3) プロキシ作成 23 プロキシ本体の作成です。どのProxy Configuration‧NATゲートウェイに紐づけるか指定し、オ プションでTLS検査やログ記録の有効化ができます。今回はログ記録のみ有効化しています。 

© 2026 Classmethod, Inc. 設定 (4) Nat Gatewayへのアタッチ確認 24 プロキシを作成すると、指定したNat Gatewayにアタッチされます。 検証時は約10分で完了しました。Nat Gateway側でAttachments設定を⾒るとNetwork Firewall Proxy⽤のVPCエンドポイントが出来ていました。 

© 2026 Classmethod, Inc. 設定 (5) Windows Server側のプロキシ設定 25 ● 補⾜ ○ Network Firewall Proxyの作成完了後、コンソールからProxy EndpointのDNS名とポート 番号を取得できるので控えておきます。 ○ Network Firewall Proxy⽤のVPC エンドポイントにはデフォルトのセキュリティグループ が紐づいていました。必要に応じて設定済みの専⽤セキュリティグループを紐づけるか、 インバウンドルールにEC2からのアクセス許可設定を⼊れます。 ● Windows Serverでの設定 ネットワークとインターネットの設定から、通常のプロキシを設定するのと 同じようにGUIで設定し、設定からWindows Updateを実⾏しました。 ○ アドレス：Proxy のDNS名（「xxx.proxy.nfw.us-east-2.amazonaws.com」のような名 前） ○ ポート：1080 

© 2026 Classmethod, Inc. 検証結果 26 

© 2026 Classmethod, Inc. 検証結果：Allow ログ（Windows Update 成功） 27 { "event_timestamp": 1764497623, "proxy_name": "test-nfw-proxy", "client_src_ip": "10.0.100.210", "final_action": "allow", "src_vpc": "vpc-xxxxxxxxxxxxxxxxx", "dest_domain": "au.download.windowsupdate.com.", "http_method": "GET", "dest_ip": "146.75.78.172", "http_status_code": 206, "final_rule_name": "default", "final_rule_group_name": "" } Windows Update⾃体は無事成功したためNetwork Firewall Proxyのログを⾒てみます。 宛先IPが記載されているためDNS 名前解決済み、ステータスコード 206 で 巨⼤ファイルの分割ダウンロード成功とみられる。 

© 2026 Classmethod, Inc. 検証結果：Deny ログ（bing.com を拒否） 28 { "event_timestamp": 1764498850, "proxy_name": "test-nfw-proxy", "client_src_ip": "10.0.100.210", "final_action": "deny", "src_vpc": "vpc-xxxxxxxxxxxxxxxxx", "dest_domain": "www.bing.com.", "http_method": "", "dest_ip": "", "http_status_code": -1, "final_rule_name": "default", "final_rule_group_name": "" } 通信拒否されたログを⾒てみます。「www.bing.com」はホワイトリストで許可していないた め、名前解決さえされずに拒否されています。（dest_ipがとなっている部分） Pre-DNSの段階で拒否されたことがよくわかります。 

© 2026 Classmethod, Inc. 改めて結論 29 

© 2026 Classmethod, Inc. 消し去れるかどうか？ → 条件付きで YES 30 ● 今すぐ消し去れるケース ○ 検証‧開発環境でのアウトバウンド制御を試したい ○ ドメイン制御（ホワイトリスト運⽤）が主⽬的 ○ us-east-2 リージョンでの利⽤ ● もう少し待つべきケース ○ 本番ワークロード（GA 待ち） ○ 東京リージョンでの利⽤ ○ HTTP/2, HTTP/3 を利⽤する環境 ○ 複数 Proxy が必要な構成（プレビュー時点では 1 アカウント 1 Proxy） ○ Regional NAT Gateway を利⽤中の環境 ● そもそも⽤途としての⽐較対象が異なるケース ○ キャッシュプロキシとしての⽤途 → Network Firewall Proxyの守備範囲外 

© 2026 Classmethod, Inc. 参考サイト 31 ● AWS Network Firewall Developer Guide https://docs.aws.amazon.com/network-firewall/latest/developerguide/network-firewall-p roxy-developer-guide.html ● Securing Egress Architectures with Network Firewall Proxy - AWS Blog https://aws.amazon.com/jp/blogs/networking-and-content-delivery/securing-egress-archi tectures-with-network-firewall-proxy/ ● AWS Network Firewall Developer Guide (PDF) https://docs.aws.amazon.com/pdfs/network-firewall/latest/developerguide/network-fire wall-developer-guide.pdf 

© 2026 Classmethod, Inc.