AWS Network Firewallの設計入門｜インライン配置とルートテーブルでVPC境界を守る構成パターン

この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）

ＨＯＭＥ＞ Linux技術リナックスマスター.JP（Linuxマスター.JP）＞ AWS(Amazon Linux) ＞ AWS Network Firewallの設計入門｜インライン配置とルートテーブルでVPC境界を守る構成パターン

「アウトバウンド通信でマルウェアのC2サーバーへの通信を遮断したい」「許可したドメイン以外へのHTTPS通信を一括でブロックしたい」——セキュリティグループとNACLだけでは、こうした要件を実装するのは難しいです。

セキュリティグループはステートフルなL4フィルタ、NACLはステートレスなL4フィルタです。どちらもIPアドレスとポート番号で制御しますが、ドメイン名（FQDN）やSNIを見たフィルタリング、Suricataルールによる侵入検知はできません。

この記事では、AWS Network FirewallをVPCにインライン配置するアーキテクチャを解説します。Firewall Subnetの設計からルートテーブルの変更、マルチAZ配置、ルールグループの設計まで、現場で使える構成パターンを体系的にまとめています。Amazon Linux 2023を使ったEC2環境での実践を想定しています。

この記事のポイント

・Network FirewallはFirewall Subnetを作り、ルートテーブルを変更してインライン配置する
・マルチAZ構成ではAZごとに1つのFirewall Endpointが必要（Traffic Asymmetry防止のため）
・ルールグループはステートレス（5-tuple）とステートフル（Suricata互換）の2層に分かれる
・ドメインリストルールでアウトバウンドのHTTPS通信をFQDN単位で許可リスト管理できる

「このままじゃマズい」と感じていませんか？

参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。

姓・名・メールの3つだけ／30秒／解除は3秒／詳細はこちら

AWS Network Firewallとは何か

AWS Network Firewallは、VPC内のサブネット境界に置くフルマネージドのネットワーク型IPS/IDSファイアウォールです。2020年11月に一般提供が開始され、Suricata（スリカータ）ルール互換のステートフル検査と、ドメインリストによるFQDNフィルタリングを提供します。

従来のEC2上のiptablesや、サードパーティのソフトウェアアプライアンス（Palo Alto VM-Series等）とは異なり、マネージドサービスとして以下を自動的に行います。

・スケーリング：トラフィック量に応じてキャパシティが自動拡張される
・高可用性：Firewall EndpointはAWS側で冗長構成が取られており、単一障害点にならない
・アップデート：Suricataエンジンのバージョン管理はAWSが行う

一方、Network Firewallが追加コストなしで使えるわけではない点は設計前に把握しておく必要があります（後述のコスト欄を参照）。

セキュリティグループ・NACLとの違い｜なぜ3つ目の防御層が必要か

AWSのネットワークセキュリティには、すでにセキュリティグループとNACLという2つのフィルタリング機構があります。Network Firewallはこれらの置き換えではなく、別レイヤーの防御として追加するものです。

項目	セキュリティグループ	NACL	Network Firewall
適用場所	EC2のENI	サブネット境界	Firewall Endpoint（専用サブネット）
フィルタ対象	IPアドレス・ポート	IPアドレス・ポート	IP・ポート・ドメイン・プロトコル・パケット内容
ステート管理	ステートフル	ステートレス	両方（ルールグループ単位で選択）
IDS/IPS機能	なし	なし	あり（Suricata互換ルール）
FQDNフィルタ	なし	なし	あり（ドメインリスト型ルール）
追加コスト	なし	なし	あり（時間課金＋通信量課金）

Network Firewallが特に有効なのは次のユースケースです。

・アウトバウンド通信の許可リスト管理：EC2から外部への通信を特定ドメインだけ許可する（例：ソフトウェアアップデートサイトのみ許可）
・C2通信のブロック：マルウェアが外部の攻撃者サーバーと通信するパターンをSuricataルールで検知・遮断する
・コンプライアンス要件の対応：PCI DSSやISMAPで求められるネットワーク層の侵入検知ログを取得する

インライン配置の基本アーキテクチャ

AWS Network Firewallは、VPCにトランスペアレント（透過型）で挿入してインライン配置します。トランスペアレント挿入とは、アプリケーションやEC2側の設定を変えずに、ネットワーク経路の途中にファイアウォールを挟む方式です。

基本的なアーキテクチャの構成要素は次の3つです。

・Firewall Subnet：Firewall Endpointを置く専用のサブネット。EC2は置かない
・Firewall Endpoint：実際にトラフィックを検査するエンドポイント（VPCエンドポイントとして作成される）
・ルートテーブルの変更：トラフィックをFirewall Endpoint経由で通過させるためのルーティング設定変更

1. Firewall Subnetをどこに置くか

Firewall Subnetは、パブリックサブネット（IGWが紐付くサブネット）とプライベートサブネット（EC2が動くサブネット）の間に挟む形で設計します。インターネット向けのアウトバウンド検査の場合、よく使われる構成は次のとおりです。

・Firewall Subnet（/28程度・Firewall Endpointのみ）
・NAT Gateway Subnet（パブリック・NAT GWを置く）
・Private Subnet（EC2が動作）

アウトバウンド方向のトラフィック経路は次のとおりです。

# アウトバウンド通信の経路（EC2 → インターネット） EC2（Private Subnet） → Firewall Endpoint（Firewall Subnet） ← ここでルール検査 → NAT Gateway（Public Subnet） → Internet Gateway → インターネット

2. ルートテーブルの変更（3か所）

Network Firewallをインライン配置するには、3か所のルートテーブルを変更する必要があります。 変更1：Private SubnetのルートテーブルにFirewall Endpointを向ける

デフォルトでEC2のアウトバウンドはNAT Gatewayに向いています。これをFirewall Endpointに向け替えます。

# 変更前（NAT Gatewayへ直接） 0.0.0.0/0 → nat-0abc123...（NAT Gateway） # 変更後（Firewall Endpoint経由） 0.0.0.0/0 → vpce-0xyz789...（Firewall Endpoint）

変更2：Firewall SubnetのルートテーブルにNAT Gatewayを向ける

Firewall Subnetを通過したトラフィックは次にNAT Gatewayへ向かう必要があります。

# Firewall Subnetのルートテーブル 0.0.0.0/0 → nat-0abc123...（NAT Gateway）

変更3：IGW IngressルートテーブルでFirewall Endpointへ返す（インバウンド検査時）

インバウンド方向（インターネット→EC2）もFirewallで検査する場合は、IGWに「Edge association」で結びつけた特別なルートテーブルを使い、宛先（Private SubnetのCIDR）をFirewall Endpointに向けます。

# IGW Ingressルートテーブル（Edge associationで使用） 10.0.1.0/24（Private SubnetのCIDR） → vpce-0xyz789...（Firewall Endpoint）

マルチAZ構成でのFirewall Endpoint配置

高可用性が必要な本番環境では、マルチAZ構成でNetwork Firewallを設計します。ここで重要な原則が1つあります。

「AZをまたいでFirewall Endpointにルーティングしてはならない」

これを守らないと、往路と復路でAZをまたぐ「Traffic Asymmetry（非対称ルーティング）」が発生し、ステートフル検査が正しく機能しなくなります。

1. AZごとに1つのFirewall Endpointを配置する

マルチAZ構成の基本は、各AZに独立したFirewall Subnetを作り、それぞれに1つのFirewall Endpointを置くことです。

# マルチAZ構成の例（東京リージョン ap-northeast-1a / 1c） AZ-a: Firewall Subnet-a（10.0.10.0/28）→ Firewall Endpoint-a（vpce-aaa...） Private Subnet-a（10.0.1.0/24） NAT GW Subnet-a（10.0.100.0/24） AZ-c: Firewall Subnet-c（10.0.11.0/28）→ Firewall Endpoint-c（vpce-ccc...） Private Subnet-c（10.0.2.0/24） NAT GW Subnet-c（10.0.101.0/24）

2. Traffic Asymmetryを防ぐルーティング設計

AZ-aのEC2からのアウトバウンド通信は、必ずAZ-aのFirewall Endpointを経由させます。AZ-cのエンドポイントに誘導してしまうと、復路のパケットがAZ-aのエンドポイントを通り、セッションテーブルに一致するエントリがない状態になります（ステートフル検査でドロップの原因になります）。

# AZ-a Private Subnetのルートテーブル（AZ-aのEndpointのみ指定する） 0.0.0.0/0 → vpce-aaa...（AZ-aのFirewall Endpoint） # AZ-c Private Subnetのルートテーブル（AZ-cのEndpointのみ指定する） 0.0.0.0/0 → vpce-ccc...（AZ-cのFirewall Endpoint）

Network FirewallのEndpointはVPCエンドポイントとして作成されるため、EndpointIdはAWS CLIで確認できます。

# aws network-firewall describe-firewall でFirewall EndpointのIDを確認する aws network-firewall describe-firewall \ --firewall-name my-vpc-firewall \ --region ap-northeast-1 # 出力結果（SyncStates → AZごとのAttachment → EndpointId） { "FirewallStatus": { "SyncStates": { "ap-northeast-1a": { "Attachment": { "SubnetId": "subnet-0aaa...", "EndpointId": "vpce-aaa..." } }, "ap-northeast-1c": { "Attachment": { "SubnetId": "subnet-0ccc...", "EndpointId": "vpce-ccc..." } } } } }

このEndpointIdをルートテーブルのターゲットとして指定します。Amazon Linux 2023でEC2を構築してAWSのネットワーク設計を実践したい方は、Amazon LinuxでLinuxサーバーを使い始める方法も合わせてご参照ください。

ルールグループの設計｜ステートレスとステートフルの使い分け

Network Firewallのルールは「ルールグループ」という単位で管理し、それをFirewall Policyに束ねて適用します。ルールグループには「ステートレス」と「ステートフル」の2種類があります。

1. ステートレスルールグループ（5-tupleフィルタ）

ステートレスルールグループは、NACLに近い動作をするIPアドレス・ポート・プロトコルの5-tupleフィルタです。NACLとの違いはルールの優先順位が数値で管理でき、ヒットしたパケットをステートフル検査に渡す（forward to stateful）という特殊なアクションが取れる点です。

実務での使い方の例：

・優先度100（最高）：信頼済み管理IP（踏み台EC2のEIPなど）からの通信を「pass」で許可し、ステートフル検査をスキップ
・優先度1000：その他の通信は「forward」でステートフルルールグループへ渡す

ステートレスで「pass」にしてしまうとステートフル検査を受けないため、重要なアクセスパターンについては慎重に判断します。

2. ステートフルルールグループ（Suricata互換ルール）

ステートフルルールグループは、TCP/UDPのセッションを追跡した上でパケット内容を検査します。Network FirewallはSuricata IDS/IPSと互換性のあるルール記法をサポートしており、プロトコルのシグネチャ検査が可能です。

Suricata互換ルールの記述例（不審なUser-Agentを含むHTTP通信をブロック）：


# ステートフルルールグループの例（Suricata互換記法）
# 不審なUser-Agentを含むHTTPアウトバウンド通信をブロックする
drop http $HOME_NET any -> $EXTERNAL_NET any (
  msg:"Blocked suspicious User-Agent Go-http-client";
  http.user_agent; content:"Go-http-client"; nocase;
  sid:1000001; rev:1;
)

3. ドメインリストルールによるアウトバウンド制御

Network Firewallの特に便利な機能が「ドメインリストルールグループ」です。FQDNを列挙した許可リスト（または拒否リスト）を作成し、SNI（Server Name Indication）をもとにHTTPS通信をフィルタリングできます。

・許可リスト型：指定ドメイン以外への通信を全部ブロック（最も堅牢）
・拒否リスト型：特定の既知悪性ドメインをブロック（運用は楽だが網羅性が低い）

# ドメインリストルール（許可リスト型）の設定例 # 下記以外のドメインへのアウトバウンドTLS/HTTP通信はDropになる .amazonaws.com # AWSサービスへのアクセス .amazonlinux.us # Amazon Linuxリポジトリ updates.redhat.com # RHEL/RockyLinux更新（必要な場合） .github.com # GitHub（CI/CD連携が必要な場合）

注意点として、ドメインリストルールはSNIが暗号化されるTLS ECH（Encrypted Client Hello）を使う通信では機能しない場合があります。EC2のシステム通信（dnf/apt更新など）では問題になりにくいですが、設計時に把握しておきます。

ルーティング設定の問題を切り分ける｜トラブルシュート

Network Firewallを設定した後、EC2からの通信が到達しなくなるケースが多くあります。その多くはルートテーブルの設定ミスです。

1. EC2からインターネットへ通信が届かない場合

まずFirewallのステータスを確認します。`READY`でなければルートテーブルの変更前に問題があります。

# aws network-firewall list-firewalls でFirewallの一覧とステータスを確認する aws network-firewall list-firewalls --region ap-northeast-1 # 出力結果（Statusが "READY" であることを確認） { "Firewalls": [ { "FirewallName": "my-vpc-firewall", "FirewallArn": "arn:aws:network-firewall:ap-northeast-1:123456789012:firewall/my-vpc-firewall" } ] }

ステータスが`READY`であれば、ルートテーブルを確認します。典型的な設定ミスは次のとおりです。

・ミス1：Private Subnetのルートテーブルがまだ旧NAT GW向き（Firewall Endpointに変更し忘れ）
・ミス2：Firewall SubnetのルートテーブルにNAT GWへのルートがない（デフォルトルートが欠落）
・ミス3：AZ-aのEC2がAZ-cのFirewall Endpointへルーティングされている（Traffic Asymmetry）

2. ドメインリストルールで意図しない通信がブロックされる場合

Alertログに対象トラフィックが記録されているか確認します。CloudWatch Logsに送っている場合は次のようなクエリで絞り込めます。

# CloudWatch Logs Insights のクエリ例（Dropされたドメインを確認する） fields @timestamp, event.tls.sni, event.dest_ip | filter event.event_type = "alert" | filter event.alert.action = "blocked" | sort @timestamp desc | limit 50

SNIに表示されたドメインを許可リストに追加するか、接続先を変更することで解消できます。

ログ設計とコストの注意点

Network Firewallは2種類のログを出力します。

・Flowログ：5-tupleとアクション（pass/drop）のログ。通信量の多い環境では大量になる
・Alertログ：ステートフルルールにhitしたパケットのログ。IDS/IPS検知結果

送り先はS3またはCloudWatch Logsを選択できます。S3はストレージコストを抑えられますが、リアルタイム分析がしにくくなります。CloudWatch Logsはログインサイトでクエリが使えますが、データ取り込み量に応じた課金が発生します。

コストの目安（東京リージョン・参考値）：

・エンドポイント時間課金：約$0.395/時間 × AZ数。東京2AZ構成だと月額約$570（エンドポイント費用のみ）
・通信量課金：$0.065/GB（Network Firewallで処理したデータ量）

Network Firewallはコストが高いため、全VPCに一律適用するのではなく、コンプライアンス要件があるVPCや本番環境に絞って適用するのが現実的な設計です。開発環境ではセキュリティグループとNACLの組み合わせで代替し、コストを抑える判断もあります。

AWSのネットワーク設計を「なぜそう設計するか」まで理解して進めていますか？

Network Firewallのルートテーブル変更手順は調べれば分かります。でも「どのAZにFirewall Endpointを置くか」「ステートレスとステートフルをどう組み合わせるか」を自分で判断できますか？
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。

今すぐ無料でダウンロード（登録10秒）＞＞図解60P『Linux入門マニュアル』を受け取る

※ 「独学の時間がもったいない」「AWSを含む現場の技術を最短で体系的に学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

本記事のまとめ

AWS Network Firewallの設計ポイントをまとめます。

設計項目	ポイント
Firewall Subnetの設計	AZごとに/28程度のサブネットを専用に作成。EC2は置かない
ルートテーブルの変更	Private Subnet→Firewall Endpoint→NAT GW→IGWの経路を3か所のルートテーブルで構成する
マルチAZ配置	AZごとに1つのFirewall Endpointを配置。AZをまたぐルーティングはTraffic Asymmetryの原因になる
ステートレスルール	信頼済みIPのpass・その他のforward to statefulを優先度で管理する
ステートフルルール	Suricata互換ルールで侵入検知。ドメインリストでFQDNフィルタが可能
トラブルシュート	通信不能の多くはルートテーブル設定ミス。aws network-firewall list-firewalls でステータスを最初に確認する
コスト	エンドポイント課金が高い（2AZで月約$570～）。コンプライアンス要件のある環境に絞って適用する

セキュリティグループとNACLの2層に加えて、Network Firewallをインライン配置することで、ドメインフィルタリングや侵入検知というセキュリティグループでは実現できない防御が追加できます。ルートテーブルを3か所変更するアーキテクチャを最初に理解しておくと、設計・実装・トラブルシュートのすべてがスムーズになります。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。