この記事は、ラクスパートナーズ Advent Calendar 2025 24日目の記事です。
概要（TL;DR）
- IGWやVGWから入ってくる通信をNetwork Firewallで検査したい場合、ルートテーブルのEdge関連付けが必要
- Network Firewallエンドポイントは「ゲートウェイロードバランサー型」のVPCエンドポイント
はじめに
現場でAWS Network Firewallを使うことになったが、一般的なファイアウォールの知識もない状態で設計を行い苦労したので、備忘録としてまとめておく。この記事では主にNetwork Firewallを用いた構成のルーティング及びエンドポイントに着目するが、ファイアウォールの具体的なルールの書き方については対象外とする。
また、分散型構成を前提に、NATなしでインターネット向け通信と、その戻り通信（IGW経由）をNetwork Firewallに通して検査するためのルーティング設計に絞って説明する。集約型／複合型で用いるTransit Gatewayを使った構成は扱わない。
Network Firewallの概要
AWS Network Firewallは、VPCのトラフィックを脅威検知・防御（IPS/IDS）できるフルマネージドなファイアウォールであり、セキュリティグループやNACLがL3/L4のアクセス制御中心なのに対して、Network Firewallはより検査寄りで、シグネチャベースの検知やアプリ層のような条件も扱えるのが特徴である。
Network Firewallを作成すると、指定したサブネットにファイアウォールのエンドポイント（検査ポイント）が自動で作られる。このエンドポイントはルートテーブルで宛先として指定することが可能で、AZごとにエンドポイントが必要になる。このエンドポイントを置くサブネット（いわゆるfirewall用サブネット）内のトラフィックは、Network Firewallで検査がされないため、基本的に他のリソースを置かないことが推奨されている。
検査方式としてはステートレスとステートフルの両方を持つ。ステートフルルールではSuricata互換の文字列を用いて複雑な検査を行うことができる。
設定の粒度は、まず各ルールをルールグループとして作る（ステートレス/ステートフル、ドメインリストやSuricata互換など）。次にそれらを束ねてファイアウォールポリシーにまとめ、最後にポリシー1つをNetwork Firewall本体に紐付ける。
運用的には「ルールグループ→ポリシー→Firewallへ反映」という流れで管理するイメージになる。
代表的な構成パターン（分散型 / 集約型 / 複合型）
AWS公式では、Network Firewallの代表的な構成パターンを次の3つに整理している。
-
分散型（Distributed）
保護したい各VPCにNetwork Firewallを配置するモデル。VPCごとに独立して完結し、他VPCへの接続やTransit Gatewayの使用を前提としない。
-
集約型（Centralized）
Network Firewallを集約VPC（Inspection VPC）に置き、VPC間（East-West）やインターネット／オンプレ（North-South）のトラフィックを集約して検査するモデル。集約のためにTransit Gatewayを使う前提になる。
-
複合型（Combined）
East-Westと一部（オンプレ／Egress など）のNorth-Southを集約VPC側で検査しつつ、インターネットIngressは要るVPCに分散配置する分散型と集約型の折衷モデル。これもTransit Gatewayを前提にした設計となる。
以降はNATなしの分散型に限定して説明する。今回のスコープは「各VPC内でインターネット向けおよびインターネットからの戻りトラフィックをNetwork Firewallに通して検査する」までで、Transit Gatewayは不要とする。分散型は各VPCが他のVPCやTransit Gatewayを必要としないことが公式に明記されている。
（逆に、集約型／複合型はTransit Gatewayが必要になる。）1
仮想プライベートゲートウェイ（VGW）を用いたオンプレとの通信も基本的には同じ考え方となる。
分散型（NATなし）でのルーティング設計
対称ルーティングが必要
AWS Network Firewallを用いた構成では、トラフィックを必ず対称（往復が同じ経路）でファイアウォールエンドポイントに通す前提で設計する。
たとえば、EIPを付与したEC2からの通信を考えたときに、下図のように行きの通信はNetwork Firewallのエンドポイントを経由するが、戻りの通信はインターネットゲートウェイから直接EC2に到達するといった行きと戻りで非対称な設計にしてはいけない（その逆もしかり）。
Network Firewallでステートフル検査を成立させるには、同じフローの往復パケットが同じ検査ポイントを通る必要があるため、行きと戻りで経路が分かれると期待した検査ができなくなる。
そのため、トラフィックの対称性を確保するために、下記2種類の方法で検査したいトラフィックを制御する必要がある。
-
サブネットのルートテーブルで、検査したいトラフィックをfirewall endpointに送る
-
インターネットゲートウェイ（IGW）にルートテーブルのEdge関連付け（Ingress routing） を行う
ルートテーブル設計
各ルートテーブルの具体的なルーティングは
EC2が存在するサブネット: 0.0.0.0/0 → 同一AZのfirewall endpoint宛に
firewallサブネット: 0.0.0.0/0 → IGW宛に
IGW: EC2（のサブネットCIDR） → 対応するAZのfirewall endpoint宛に
これにより 戻り経路も同じAZのendpointを通るようにし、対称ルーティングを成立させてステートフル検査を維持する。
Edge関連付け（Ingress routing）の設定ポイント
また、IGW（VGW）にルートテーブルを関連付けるには、マネジメントコンソール上ではサブネットへの関連付けと若干やり方が異なるため注意が必要。
VPCのダッシュボードにてメニューのルートテーブルを選択し、対象のルートテーブルにチェックが入っている状態から「アクション」→「Edgeの関連付けを編集」を選択することで関連付けの画面に行くことができる
Network Firewall エンドポイントとは
Network Firewallを作成すると、作成時に指定したサブネットに自動でNetwork Firewallエンドポイントが作成される。
この作成されるエンドポイントとは、サブネットCIDR範囲の中から割り当てられたIPを持つENI（このIPは指定不可）であり、作成されるエンドポイントID「vpce-...」（実態はENI）をルートテーブルの宛先として設定することができるようになる。
このエンドポイントであるが、詳しい解説がある記事等が見当たらず、詳細設計書上このエンドポイントの扱いに困ることがあったので簡単に調査してまとめた。
endpoint = Gateway Load Balancer endpoint
結論から言うと、仕様としては次のような扱いとなる。
- Network Firewall endpointはGateway Load Balancer(型の)エンドポイント
- Gateway Load Balancer endpointはVPCエンドポイントの一種
- Gateway Load Balancer型のVPCエンドポイントはネクストホップとして機能する点で他二種（ゲートウェイ型・インターフェイス型）のVPCのエンドポイントと異なる
まず、Network Firewall endpointはGateway Load Balancer(型の)エンドポイントという点についてだが、こちらはAWS公式ブログ上でNetwork Firewallのデプロイモデルを解説する記事に下記のような記載がある。
Once AWS Network Firewall is deployed, you will see a firewall endpoint in each firewall subnet. As mentioned earlier, firewall endpoint is similar to interface endpoint and it shows up as vpce-id in your VPC route table target selection. Firewall endpoint capability is powered by AWS Gateway Load Balancer and therefore elastic network interface (ENI) of the endpoint is “gateway_load_balancer_endpoint” type.
Gateway Load Balancer endpoint = VPCエンドポイント
次に、Gateway Load Balancerエンドポイントの扱いだが、こちらもELBの公式ドキュメント上に記載があり、VPCエンドポイントの一種であることが明言されている。
Gateway Load Balancers use Gateway Load Balancer endpoints to securely exchange traffic across VPC boundaries. A Gateway Load Balancer endpoint is a VPC endpoint that provides private connectivity between virtual appliances in the service provider VPC and application servers in the service consumer VPC.
https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html
実際にマネジメントコンソール上でも、Network Firewallを作成すると、VPCのエンドポイントの欄に「Gateway Load Balancer」としてタイプが表示される。
Gateway Load Balancer型の性質（他2種との違い）
では、このGateway Load Balancer型のVPCエンドポイントとは何なのかというと、ネクストホップとして機能するエンドポイントである。他のVPCエンドポイントと決定的に違うのがこの点で、アプリケーションが宛先としてアクセスする対象ではなく、ルートテーブル上の次ホップ（ネクストホップ）として機能することができる
- ゲートウェイ型：S3/DynamoDB等のプレフィックスリスト宛の通信が、ルートで吸い込まれる
- インターフェイス型：DNS名（Private DNS等）を通して、アプリがエンドポイントENIへ到達する
- Gateway Load Balancer型：任意の宛先プレフィックスに対して次ホップとして指定でき、経路上に中継点を挿入する
この経路上に挿入できる性質が、Network Firewallの検査ポイントとして使われている理由になる。
つまり、Network Firewall endpointに送られた通信がGateway Load Balancerにより検査基盤となるアプライアンスに転送され検査が行われる仕組みとなる。(Ingressの通信のみ図示、線が汚いのは許して)
GENEVE（UDP/6081）とデータプレーンのイメージ
では、Network Firewall endpointを通過した後の裏側のデータプレーンはどうなっているのかというと、Gateway Load BalancerはL3で動作し、ターゲットであるアプライアンスへはGENEVEプロトコル(UDP/6081)で転送している。
https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/gateway-load-balancers.html
つまり、Gateway Load Balancer配下のアプライアンスは元のパケットをそのまま受け取るのではなく、GENEVEでカプセル化された形で受け取って復元・検査するため、透過型のインライン挿入が可能という設計になっている。
※アプライアンスという表現を使っているのは、AWSでNetwork FirewallがGENEVEでアプライアンスとやり取りすると明示しているわけではないため。一方でNetwork Firewall endpointがGateway Load Balancerによって実現されていることと、Gateway Load BalancerがGENEVEを使うことはそれぞれ公式に書かれている。したがって、Network FirewallのデータプレーンもGateway Load Balancerの仕組み（GENEVEによる転送）を土台にしている、と理解してよいはず。
まとめ
本記事では、分散型構成を前提に、NATなしでインターネット向け通信とその戻り通信をAWS Network Firewallで検査するためのルーティング設計を整理した。Network Firewallでステートフル検査を成立させるには、同一フローの往復トラフィックが同じ検査ポイントを通る必要があるため、行きと戻りの経路が分かれる非対称ルーティングは避ける必要がある。
対称性を担保するための要点は2つである。1つ目は、サブネットのルートテーブルで検査対象トラフィックの次ホップとして各AZのNetwork Firewallエンドポイントを指定すること。2つ目は、IGW（VGW）に対してルートテーブルのEdge関連付け（Ingress routing）を行い、戻りトラフィックも対応するAZのエンドポイントへ誘導することである。これにより、往復ともに同一AZのエンドポイントを通す設計とし、検査の前提を崩さない。
また、Network FirewallのエンドポイントはGateway Load Balancerにより実現されており、VPCエンドポイント（Gateway Load Balancer型）としてルートテーブルのターゲットに指定できる。Gateway Load BalancerはGENEVE（UDP/6081）でターゲットへ転送するため、検査ポイントを経路上に透過的に挿入できる。詳細設計上は、Network FirewallエンドポイントをGateway Load Balancer型のVPCエンドポイントとして扱うのが整理しやすい。
終わり
-
再三主張するのはインターネットにTransit GatewayとNATGatewayを使用した構成図ばかり溢れていて、それを見たプロジェクトメンバーや他部門のAWSチームに、今回構築するシステムにはどちらも不要だと納得させるのに苦労したからである。 ↩