このアクセス、本当にブロックできてるのかな？
そんな不安がよぎったとき、どうしていますか？
AWSでVPCを使っている場合、セキュリティグループやNACLだけでは防ぎきれないトラフィックが存在します。
そこで心強い味方になってくれるのが AWS Network Firewall です。
2026年8月、このサービスに実用的な新機能が2つ追加されました。
今回はNetwork Firewallの基本からおさらいしつつ、最新アップデートを詳しく解説します。
AWS Network Firewallとは VPC全体のトラフィックを守るマネージド型サービス
AWS Network Firewallは、Amazon VPC内のネットワークトラフィックを細かく制御できる、AWSが提供するマネージド型のファイアウォールサービスです。
「マネージド」というのは、AWSがインフラの維持・パッチ適用・スケーリングをすべて担当してくれるという意味。
自分でEC2インスタンス上にファイアウォールソフトウェアをインストールして管理する必要はありません。
AWSのVPCには「セキュリティグループ」と「ネットワークACL（NACL）」というアクセス制御機能が既に備わっています。
ただし、これらはポートやIPアドレスによるフィルタリングが中心で、
といった高度な制御は苦手だったりします。
Network Firewallはそこを補ってくれます。
具体的には以下のような制御が可能です。
- ドメイン・URLフィルタリング：特定のドメインやURLカテゴリへの通信を許可・拒否
- ステートフルインスペクション：通信の文脈（「このパケットは正規のセッションの一部か」）を理解した上でフィルタリング
- 侵入検知・防御（IDS/IPS）：既知の攻撃パターンを検知してブロック
- 地理的IPフィルタリング：特定の国からの通信を制限
- アクティブ脅威防御：マネージドルールを使ったリアルタイム脅威ブロック
透過型ファイアウォールとフォワードプロキシの違い
Network Firewallは「透過型（トランスペアレント）」モードで動作します。
透過型とは、クライアントもサーバーも「間にファイアウォールが存在する」ことを意識しない形でトラフィックを検査する方式。その名の通り、透明な存在。
通信経路に透明な存在として割り込みながら、内容を確認してフィルタリングします。
一方、今回プレビューが始まった「フォワードプロキシ」は少し異なります。
クライアントがプロキシの存在を知っており、意図的にプロキシ経由で通信する方式です。
特にHTTPSの暗号化通信の中身（URLや通信先ドメイン）を把握しやすく、よりきめ細かい制御が可能になります。
セキュリティグループとの役割の違い
「セキュリティグループがあるのになぜNetwork Firewallが必要なの？」という疑問がもしかしたら出てくるかもしれません。
整理すると次のようになります。
| 機能 | セキュリティグループ | Network Firewall |
|---|---|---|
| フィルタリング対象 | IPアドレス・ポート | ドメイン・URL・通信内容 |
| ステートフル検査 | 基本的なもの | 深いパケット検査（DPI）対応 |
| IDS/IPS | なし | あり |
| 管理範囲 | リソース単位 | VPC・サブネット単位 |
そんなイメージです。両方を組み合わせることで、多層防御が実現します。
新機能① ステートフルルールのヒットカウントでルールの動作状況を数値で確認
新たに加わった機能を見ていきましょう。
1つ目の新機能は「ステートフルルール ヒットカウント」です。
2026年8月に一般提供が開始されました（ほぼ全リージョン対応）。
これは、ファイアウォールポリシー内の各ステートフルルールが、実際のネットワークトラフィックに何回マッチしたかをカウントして記録する機能です。
これまでは「このブロックルール、本当に機能しているの？」という疑問に答えるためには、ログを地道に解析するしかありませんでした。これが結構苦行だったりする。
ところがヒットカウントを使えば、ルールごとの「命中回数」が数値として直接確認できるようになります。
ヒットカウントで解決する3つの運用課題
死んでいるルールの発見
カウントが長期間0のルールは、実際には存在しているだけで何もブロックしていない可能性があります。
古くなったルールや誤設定のルールが一目でわかり、クリーンアップの判断材料になります。
ルールが増えるほど管理が煩雑になるNetwork Firewallにとって、これは嬉しい大きな改善です。
新しいルールの動作確認
追加したばかりのルールが正しく機能しているかどうかを、ログを掘らずに数値で確認できます。
「デプロイしたけど本当に効いてる？」という確認作業を格段に楽にしてくれます。
インシデント対応の初動を速くする
「どのルールが大量にトリガーされているか」が一目でわかるため、攻撃を受けている場合の初動調査の心強い味方に。
特定のルールのカウントが急増していれば、それが攻撃の手がかりになります。
なお、メトリクスは最短5分間隔で更新され、追加料金なしで利用できます。
カスタムルールにもAWSが提供するマネージドルールにも対応しており、新規・既存のファイアウォールポリシー両方で自動的に有効化されます。
新機能② フォワードプロキシ統合でHTTPS通信の制御がNetwork Firewallに一本化（プレビュー中）
2つ目の新機能は「明示的フォワードプロキシ」のNetwork Firewallへの統合です。
「明示的フォワードプロキシ」とは、クライアントがプロキシの存在を知った上で、意図的に中継経由で通信する方式のこと。
Network Firewallがもともと使っていた「透過型」はクライアントが意識しないまま経路上で検査されますが、明示的プロキシはクライアントが接続先URLをプロキシに直接伝えるため、HTTPSの暗号化通信でもURLの中身まで見てフィルタリングできます。
現在、米国東部（オハイオ）リージョンでパブリックプレビュー中。プレビュー期間中は無料で試せます。
AWSは2025年11月に、フォワードプロキシを独立したスタンドアロン製品として提供していました。
今回の変更では、そのプロキシ機能がNetwork Firewallの内部に組み込まれました形になります。
統合によって変わること 管理ポイントが1つになる
最大のメリットは「管理の一元化」ではないでしょうか。
これまでは透過型ファイアウォールの設定と、プロキシの設定を別々に管理する必要がありました。
統合後は、1つのセキュリティポリシーの中で、透過型モードとプロキシモードの両方をまとめて管理できます。
また、Network Firewallが持つすべての機能が、プロキシモードでもそのまま利用できるようになりました。
フォワードプロキシ統合が役立つ具体的なシーン
VPC内のリソースがインターネットに出ていく通信を細かく制御したい場合に特に有効です。
従来は透過型ファイアウォールでは対応しにくかったHTTPS通信内容の精密な制御が、Network Firewallの統合UIで完結するようになります。
AWS Network Firewallが必要かどうか 判断の目安
最後に「自分のシステムにNetwork Firewallが必要か？」という判断の目安を見ていきましょう。
費用対効果大事。
セキュリティグループとNACLで十分なケース
Network Firewallが必要になるケース
今回の2つのアップデートは、Network Firewallをすでに使っているユーザーにとって運用効率を大きく改善するものです。
ヒットカウントは追加料金なしで自動有効化されているので、すぐにAWSコンソールで確認ができます。
フォワードプロキシ統合については、プレビューの段階でオハイオリージョンで試すのが良さそうです。
