この記事は「2025 Japan AWS Jr. Champions 夏のQiitaリレー 」の26日目の記事です。
過去の投稿（リンク集）はこちらからご覧ください！
目次
はじめに
こんにちは、Hibikiです。
Network FirewallがTransit Gatewayとネイティブ統合したとの発表が2025年6月にあり、2025年7月から全リージョンで利用可能になった(それまでは東京リージョンで利用できなかった)ので調査・検証を行いました。
話すこと・話さないこと
まず、本記事でご説明することと、ご説明しないことの整理です。
話すこと
- アップデート情報
- アップデートによる構成の変化
- 検証
話さないこと
- Transit Gatewayの説明
- アタッチメント、ルートテーブルといった機能についての説明
- Network Firewallの説明
- Network Firewallのフィルタリングルールの作成方法
アップデートについて
概要
本アップデートによって、Network Firewallを作成する際、作成済みのTransit Gatewayを指定することによって、Transit Gatewayと統合できるようになりました。
Transit Gatewayと統合されたことにより、複数VPCを使用する場合、Transit Gatewayのルートテーブルを使用した直感的なルーティングが可能となりました。
構成の変化
検証を始める前に、アップデートによってどのような変化があるのか、アップデート前後の構成を比較して確認してみようと思います。
Network Firewallの構成図としては、AWSの公開しているNetwork Firewallのデプロイモデルの記事に様々なパターンがあるので、Transit Gatewayを利用した構成図を引用して比較していきます。
アップデート前の構成
こちらの図がアップデート前の構成です。
(原文は引用元のサイトを確認いただきたいですが、構成図からだけでもイメージが湧きやすいようにオレンジ色で補足情報を追記しています。)
アップデート前は、Network Firewall専用のVPCを作成し、そのVPC内にNetwork Firewallを作成する構成がありました。
この場合、システム用VPCからインターネットに接続するためには、
システム用VPC → Network Firewall用VPC → アウトバウンド用VPC
という経路を通りフィルタリングをかけた通信を行います。(帰りの経路も同じルート)
Network Firewallの配置場所には複数の選択肢があります。
アウトバウンド用VPC内に直接配置することも可能ですが、以下のような要件がある場合はNetwork Firewall専用のVPCを作成する場合があります
Network Firewall専用VPC を作成するケース
- 複数のWorkload VPCからの通信を集約してフィルタリングしたい
- 特定のVPCだけNetwork Firewallを経由させたくない（独自のFirewall製品を使用するVPCなど）
本記事では、このような要件に対応できる汎用性の高いアーキテクチャパターンとして、Network Firewall専用VPCを用意する構成を紹介しています。
アップデート後の構成
こちらが本アップデートによる変化です。
アップデートによって、Network FirewallをTransit Gatewayに統合できるようになり、Network Firewall専用のVPCが不要になりました。
実際の構成パターンについては、次の「検証する構成」セクションでご紹介します。
Network Firewall専用のTransit Gatewayアタッチメントが作成されることとなるため、アップデート前の説明に記載していた特定のVPCからはNetwork Firewallを経由させたくないというパターンに対してもこちらの構成で対応可能です。
個人的にはVPC設計・構築の手間が減ったことは大きな変化であると感じています。
VPCを構築する（サブネット、ルートテーブル等の作成を含む）作業は運用負荷が高く、
CIDRの割り振りや管理の手間が減ったというのは嬉しいポイントだと思います。
検証
検証する構成
今回は上記の構成で検証します。
- WorkloadアカウントとNetworkアカウントを使用するクロスアカウント構成
- Workloadアカウント
- システムを構築するためのアカウント
- インターネットへの接続は全てNetworkアカウントを経由する
- プライベートサブネットにEC2を構築
- Networkアカウント
- 複数アカウントのインターネットへの経路を集約・管理するためのアカウント
- Transit Gateway、Network Firewall、Internet Gateway等を構築
検証の流れ
以下の流れで検証します。
- Network Firewallの作成
- Transit Gatewayアタッチメントの作成
- Transit Gatewayルートテーブルの作成
- 通信を発生させて検証
なお、アカウント、VPC、サブネット、EC2やTransit Gateway本体等はすでに作成してあり、Transit Gatewayのアカウント間共有も既に済んでいるものとします。また、各リソースに設定されているセキュリティグループやNACLについても通信が可能な設定になっているものとします。
1. Network Firewallの作成
Network Firewallを作成します。
作成画面に進むと、アタッチメントタイプとしてTransit Gatewayが選択できるようになっています。
アタッチメントでTransit Gatewayを選択し、統合対象のTransit Gateway、AZを選択します。
こちらでNetwork Firewallの作成は以上になります。
ファイアーウォールポリシーやルールグループの作成方法は割愛しています。
フィルタリング条件として、ホワイトリスト形式でctc-g.co.jpというドメインを許可し他の通信は全て破棄するような条件を指定しています。
2.Transit Gatewayアタッチメントの作成
Transit Gatewayから各VPCやNetwork Firewallへ生やすTransit Gatewayアタッチメントを作成します。
アタッチメントの作成方法はアタッチメントのタイプによって異なります。
- VPCアタッチメントタイプ
- Network Firewall用のアタッチメントタイプ
VPCアタッチメントタイプの作成
VPCに作成するアタッチメントは従来通り、アタッチメントタイプとしてVPCを選択し作成するVPC、サブネットを設定します。
こちらの設定はVPCの存在する各アカウントで実施します。
Network Firewall用アタッチメントタイプの作成
手順1.の通りNetwork Firewallを作成すると、自動的にNetwork Functionというリソースタイプ名(アタッチメントタイプ名)でアタッチメントが作成されます。
リソースIDはNetwork Firewallとなります。
※ルートテーブルが関連付けされていますが、実際のアタッチメント作成後には何も設定されていません。こちらはルートテーブル紐づけ後のキャプチャになります。
3.Transit Gatewayルートテーブルの作成
アタッチメントへ設定するルートテーブルを作成します。
インターネットへの行きの通信(オレンジ)とインターネットからの帰りの通信(青)が成立するために、以下のようにルートテーブルを作成しました。
- WorkloadアカウントVPC用アタッチメントのルートテーブル
| Destination | Target |
|---|---|
| 0.0.0.0/0 | Network Firewall用アタッチメント |
- Network Firewall用アタッチメントのルートテーブル
| Destination | Target |
|---|---|
| 0.0.0.0/0 | Networkアカウント用アタッチメント |
| WorkloadアカウントVPCのCIDR | Workloadアカウント用アタッチメント |
- NetworkアカウントVPC用アタッチメントのルートテーブル
| Destination | Target |
|---|---|
| 0.0.0.0/0 | Network Firewall用アタッチメント |
本構成の場合、WorkloadアカウントVPC用アタッチメントとNetworkアカウントVPC用アタッチメントのルートテーブルへ同じものを設定しても通信は成り立ちますが、別の通信経路である点と拡張性の観点からルートテーブルを分けております。
4.通信を発生させて検証
Workloadアカウント上のEC2からcurlコマンドを使用して、インターネットへ接続してみます。
- ホワイトリスト宛の通信
ホワイトリストに記載のドメインに接続できることが確認できました。
- ホワイトリスト外宛の通信
ホワイトリストに記載していないドメインは接続できていないことも確認できました。
こちらで、想定通りNetwork Firewallを経由したフィルタリングが行えていることが確認できました。
まとめ
- Network Firewallを作成する際、Transit Gatewayを直接指定できるようになりました
- 専用VPCを作成する必要がなくなり、VPC設計・構築の手間を減らすことが可能になりました