【初心者】AWS Network Firewall を使ってみる

Posted at 2025-08-23

1. はじめに

以下の2点をモチベーションとしてAWS Network Firewallを初めて検証した。

AWS資格(Advanced Networking - Specialty)の学習をしているが、机上だといまいちピンとこないので、出題対象のAWSサービスについて実機で動作確認したい。
自システムにSquidがあり、内部サーバからのインターネットアクセスに対して、アクセス先ドメインをホワイトリスト登録して接続の管理をしているが、Squid用EC2インスタンスの管理が面倒なため、Network Firewallに置換できるか知りたい。

2. AWS Network Firewall とは（自分の理解）

VPCへのインバウンド/VPCからのアウトバウンドの通信を一括して監視・制御できるマネージド型サービス。VPCの入口に設置して内部全体を保護するという意味では、オンプレ時代の物理Firewallに近いかなという気もする。

3. やったこと

自システムのSquidの置換をすることを想定ユースケースとして、プライベートサブネットにあるEC2インスタンスから、特定のドメイン（.google.com）にだけアウトバウンド通信ができるように設定する（ドメインベースの制御）。
Network Firewall をアウトバウント通信制御に使う場合、複数の構成例が見られたため、実際に作ってみてメリデメを確認する。

4. 構成例の比較

VPCからのアウトバウンド通信の制御を行いたい場合、以下の2パターンのネットワーク構成例が見られた。
- パターン1: EC2インスタンス --> Network Firewall --> NATGW --> Internet --> Google
- パターン2: EC2インスタンス --> NATGW --> NetworkFirewall --> Internet --> Google
どちらがいいのか？は、有識者のいろいろな記事があった。
自分としてはパターン1のほうがよいと判断した（先にNetwork Firewallを通して不要な通信を落としたほうがよいため）。ただ学習のため、一応両方の構成を練習することとした。
パターン1の場合の構成図

パターン2の場合の構成図

5. 手順

5.1 事前準備

構成図のVPC、サブネット、EC2インスタンスを作成する。
- VPC: 10.0.0.0/16
- Public Subnet(NATGWを配置): 10.0.0.0/24
- Private Subnet(EC2インスタンスを配置): 10.0.1.0/24
- Private Subnet(Network Firewallを配置): 10.0.10.0/24
接続試験用に、Public SubnetにNATGW、Private SubnetにEC2インスタンスを作成する。
Network Firewall 導入前の状態として、クライアントのEC2インスタンスから、NATGWを経由して、インターネット接続(curl http://www.google.comなど)が可能なことを確認する。
後で各サブネットのルートテーブルを変更することでパターン1,2の構成に変更する。

5.2 Network Firewallの作成と設定

「Getting started with AWS Network Firewall」などを見ながらNetwork Firewall自体及び関連の設定を行う。
Network Firewallの作成にはファイアウォールポリシーが必要、ファイアウォールポリシーの作成にはルールグループが必要なため、ルールグループ->ファイアウォールポリシー->Network Firewallの順に作成する。

ルールグループの作成

VPC -> ネットワークファイアウォール -> Network Firewallのルールグループ -> ルールグループの作成　を選択しルールの作成を開始する。

グループタイプをステートフル、形式をドメインリストにする。

グループ名およびキャパシティを設定する。今回はキャパシティ値は適当（まじめにやる場合は「AWS Network FirewallのRule Group Capacityの計算方法まとめ」などを参照。

「.google.com」だけを許可する。

以後はデフォルト設定で、ルールグループを作成する。

ファイアウォールポリシーの作成

VPC -> ネットワークファイアウォール -> ファイアウォールポリシー -> ファイアウォールポリシーの作成　を選択しポリシーの作成を開始する。

ポリシー名を設定する。ストリーム除外ポリシーはデフォルトの「拒否」のまま。

「ステートフルルールグループ」に、前の手順で作成したルールグループ「mksamba-rulegroup」を追加する。

以後はデフォルト設定で、ファイアウォールポリシーを作成する。

ファイアウォールの作成

VPC -> ネットワークファイアウォール -> ファイアウォールの作成　を選択しファイアウォールの作成を開始する。

ファイアウォール名を設定する。

ファイアウォールを配置するVPCとサブネットを選択する。(2025/6に、Network FirewallをTransit Gatewayにアタッチする機能が追加されたようだが、今回は従来のVPCにNetwork Firewallを作成する方法を選択)

せっかくなのでいろいろ機能を有効にする。「トラフィック分析モード」を有効化。

Alert, Flow, TLS の3種類のログを有効化し、CloudWatch Logsのそれぞれ別グループへ保存。

「ファイアウォールモニタリングダッシュボード」を有効化。

前の手順で作成したファイアウォールポリシーを関連付ける。

以後はデフォルト設定で、ファイアウォールを作成する。

5.3 ルーティング設定と動作確認

パターン1 (NetworkFirewallが内側にある構成)

前段の手順(4.項目)の構成図内に記載した通りに各サブネットにルートテーブルを設定する。
注意点として、10.0.0.0/24 のサブネットに、「10.0.1.0/24 NWFW」の行が必要（戻りのパケットのルーティングのため）。
クライアントのEC2インスタンスから、「curl http://www.google.com」は接続可、「curl http://www.yahoo.co.jp」は接続不可であることを確認する。
「curl http://www.google.com」実施時（許可）のフローログは以下（行きと帰り）。

flowlog1.json

{
    "firewall_name": "mksamba-nwfw",
    "availability_zone": "ap-northeast-3a",
    "event_timestamp": "1755926480",
    "event": {
        "tcp": {
            "tcp_flags": "1b",
            "syn": true,
            "fin": true,
            "psh": true,
            "ack": true
        },
        "app_proto": "http",
        "src_ip": "10.0.1.223",
        "src_port": 38248,
        "netflow": {
            "pkts": 10,
            "bytes": 605,
            "start": "2025-08-23T05:20:19.895950+0000",
            "end": "2025-08-23T05:20:19.982450+0000",
            "age": 0,
            "min_ttl": 126,
            "max_ttl": 126,
            "state": "closed",
            "reason": "timeout",
            "alerted": false
        },
        "event_type": "netflow",
        "flow_id": 1033327125216370,
        "dest_ip": "172.217.25.164",
        "proto": "TCP",
        "dest_port": 80,
        "timestamp": "2025-08-23T05:21:20.895681+0000"
    }
}

flowlog2.json

{
    "firewall_name": "mksamba-nwfw",
    "availability_zone": "ap-northeast-3a",
    "event_timestamp": "1755926480",
    "event": {
        "tcp": {
            "tcp_flags": "1b",
            "syn": true,
            "fin": true,
            "psh": true,
            "ack": true
        },
        "app_proto": "http",
        "src_ip": "172.217.25.164",
        "src_port": 80,
        "netflow": {
            "pkts": 19,
            "bytes": 20403,
            "start": "2025-08-23T05:20:19.895950+0000",
            "end": "2025-08-23T05:20:19.982450+0000",
            "age": 0,
            "min_ttl": 114,
            "max_ttl": 114
        },
        "event_type": "netflow",
        "flow_id": 1033327125216370,
        "dest_ip": "10.0.1.223",
        "proto": "TCP",
        "dest_port": 38248,
        "timestamp": "2025-08-23T05:21:20.895814+0000"
    }
}

-　「curl http://www.yahoo.co.jp」を実施時（拒否）のalertログは以下。

alertlog.json

{
    "firewall_name": "mksamba-nwfw",
    "availability_zone": "ap-northeast-3a",
    "event_timestamp": "1755932483",
    "event": {
        "tx_guessed": true,
        "tx_id": 0,
        "app_proto": "http",
        "src_ip": "10.0.1.223",
        "src_port": 35496,
        "event_type": "alert",
        "alert": {
            "severity": 3,
            "signature_id": 4,
            "rev": 0,
            "signature": "aws:alert_established action",
            "action": "blocked",
            "category": ""
        },
        "flow_id": 953179431955692,
        "dest_ip": "124.83.185.252",
        "proto": "TCP",
        "verdict": {
            "action": "drop"
        },
        "http": {
            "hostname": "www.yahoo.co.jp",
            "url": "/",
            "http_user_agent": "curl/8.5.0",
            "http_method": "GET",
            "protocol": "HTTP/1.1",
            "length": 0
        },
        "dest_port": 80,
        "pkt_src": "geneve encapsulation",
        "timestamp": "2025-08-23T07:01:23.160444+0000",
        "direction": "to_server"
    }
}

Squidでは許可/拒否に関わらず、処理対象通信の宛先URLがログ保存できるが、今回のNetwork Firewallの設定では、通信拒否時はAlertログにURLが保存されるが、許可時に宛先URLの保存ができなかった。（もう少しルールグループを追加設定すればできるかもだが未検証）

パターン2 (NATGWが内側にある構成)

前段の手順(4.項目)の構成図内の記載の通りに各サブネットにルートテーブルを設定する。
注意点として、3つのサブネットのルートテーブルをそれぞれ設定することに加えて、Internet Gatewayに対してもルートテーブルを設定する必要がある(「VPC Ingress Routing」という機能）。手順としては、専用のルートテーブル(mksamba-nwfw-edge)を作成した上で、「Edgeの関連付け」で、Internet Gatewayを関連付ける。

クライアントのEC2インスタンスから、「curl http://www.google.com」は接続可、「curl http://www.yahoo.co.jp」は接続不可であることを確認する（ログは省略）。

6. その他の機能確認

モニタリングダッシュボード

Network Firewallのログを集計し（※ログを出力する設定になっていることが前提）、ダッシュボードに表示してくれる機能。
「Network Firewall -> モニタリングとオブザーバビリティ」から参照可能。今回の検証ではcurlで http://www.google.com と http://www.yahoo.co.jp にしかアクセスしていないため、ダッシュボードの表示は以下の感じ。

この機能についてはこちらの記事「[アップデート] AWS Network Firewall でファイアウォールモニタリングダッシュボードが利用できるようになりました」が詳しい。

ドメインレポート

30日分のアクセス先URLを集計してくれる機能。
「Network Firewall -> モニタリングとオブザーバビリティ」からレポートの作成及び参照が可能。今回の検証時の結果は以下。ここではログと異なり、www.google.com(許可ドメイン)も表示されているが、このレポートだけでは許可なのか拒否なのかは分からない。

この機能についてはこちらの記事「【新機能】AWS Network Firewallのトラフィック分析モードを試してみた」が詳しい。

7. 所感

通信経路の間にNetworkFirewallを挟んでチェックするという概念的なところが理解できたので、資格試験の際も一応脳内に構成図が浮かびそう。
初めてVPC Ingress Routing の機能を使ってInternet Gateway にルートテーブルをアタッチした(今までそんな機能があることを知らなかった…)ので勉強になった。
このサービスでSquidを代替することも可能そうだが、ログが十分か、料金が許容範囲かなどいろいろ確認することがあるため、単純置換というわけにはいかなさそう。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up