インターネットのアウトバウンド通信の集約用途のNAT GatewayとAWS Network Firewallを組み合わせる場合の構成パターンを整理してみた
インターネットのアウトバウンド通信の集約用途のNAT Gatewayがある場合、AWS Network Firewallをどのように配置すれば良いのかな
こんにちは、のんピ(@non____97)です。
皆さんはインターネットのアウトバウンド通信の集約用途のNAT Gatewayがある場合、AWS Network Firewallをどのように配置すれば良いのかなと気になったことはありますか? 私はあります。
2025年はAWS Network FirewallとAWS Transit Gatewayの統合機能やRegional NAT Gatewayなど新しい機能が出てきました。
これに伴い、インターネットへのアウトバウンド通信の集約や、Network Firewallを用いた通信の制御の構成が変わってきたように感じます。
現時点でどのような構成パターンがあり、どんな時に取るべきなのか整理します。
いきなりまとめ
- インターネットアウトバウンド通信を集約する際の、NAT GatewayとAWS Network Firewallの配置パターンは大きく2つ
- NAT GatewayとNetwork Firewallを同一VPC内に作成する
- NAT GatewayとNetwork Firewallを別VPCにする
- 前者が推奨
- 後者を選ぶのは主にRegional NAT Gatewayを使いたいとき
- 同一VPCでもRegional NAT Gatewayは採用できるが、AZごとにサブネットのCIDRと同一AZのFirewall Endpointを対応付ける必要があり、運用負荷が高く非推奨
- Regional NAT GatewayはCloud WANと非対応 (2026/6/30時点でTransit Gatewayのみ)。Cloud WANで集約する場合は後者を選択できない
- East-West用とNorth-South用でNetwork Firewallを分けるハイブリッド方式は、Network Firewallの料金が二重になり非現実的
- 可用性は別途考慮が必要
- 別VPCでRegional NAT Gatewayを使えても、間のNetwork FirewallはAZ単位の冗長性しかないため、AZ障害を気にしなくてよくなるわけではない
- Firewall Endpointが不調なときのフェイルオーバーは自動では行われず、検知と切り替えを手組みする必要がある
- Firewall EndpointをMulti-AZでデプロイするだけでは十分とは言えない
- 一方、Transit GatewayやCloud WANのみのAZ障害はHyperplaneにより基本的に考慮不要
- アプライアンスモードを有効化しても、どのAZのTransit Gateway attachment ENIから抜けていくのかランダムだったところ、送信元および送信先AZのを考慮してくれるようになっていた
パターンの整理
NAT GatewayとNetwork Firewallを同一VPC内に作成する
一つ目のパターンが「NAT GatewayとNetwork Firewallを同一のVPC内に作成する」です。
図示するとこのようになります。
通信経路としてはこのような形になります。
East-Westの通信
North-Southの通信
現在はEast-Westの通信もできるようにしていますが、もし、East-Westの通信は行わせたくないのであれば以下のようにBlackholeルートを追加することで対応可能です。
詳細は以下記事をご覧ください。
コンポーネントがまとまっていて非常にシンプルです。基本的には私はこの方式を推したいです。
Cloud WANの場合も同様の構成になります。
「Regional NAT Gatewayは使わないの? 推していただろ」と思われた方もいるかもしれません。この構成の辛いところはRegional NAT Gatewayの採用が難しいところです。
Regional NAT Gatewayを採用する場合は、以下のようにAZごとにルートを設定する必要があります。
これはNetwork FirewallのエンドポイントがNetwork Firewallが存在しているVPCに一つ存在しているのではなく、AZ単位で存在しているためです。要するにリージョンレベルでの可用性はありません。
その結果、アウトバウンド集約元の全VPCの全サブネットのCIDRブロックをAZごとに整理し、整理したサブネットCIDRブロックごとにサブネットと同一AZのFirewall Endpointを指定することになります。こちらの対応をしなければRegional NAT Gatewayからの戻りのトラフィックで非対称ルーティングとなるものが発生します。
サブネット数が多い場合、プレフィックスリストを使ったとしても非常に運用負荷が高い作業でしょう。個人的には全くお勧めしません。
また、勘の良い方は「Inspection VPCでアプライアンスモードを有効化する場合、Inspection VPC内でどちらのAZのFirewall Endpointにルーティングされるのか分からないとブログを書いていただろ! その結果、Inspection VPC内でNAT Gatewayからの戻りのトラフィックで非対称ルーティングが発生してしまうのでは?」と思われるかもしれません
これは以下AWS Blogsに投稿されている記事のとおり、解消されています。
これまでは、VPC アタッチメントにおいてアプライアンスモードが有効になっている場合、Transit Gateway および AWS Cloud WAN CNE における対称ルーティングではフローハッシュアルゴリズムに基づいてトラフィックの AZ を判断していました。このアルゴリズムは IP パケットにおける 4 タプルに基づいており、トラフィックフローの送信元および宛先の AZ については考慮されていなかったため、トラフィックが異なる AZ を経由する遠回りな経路となってしまう場合がありました。
この問題に対して、今回の AZ 認識の強化により、Transit Gateway と AWS Cloud WAN CNE はトラフィックパスの選択において、トラフィクフローの送信元と宛先の両方の AZ を考慮するようになり、フローの送信元と宛先が同じ AZ にある場合には、トラフィックはインスペクション VPC を経由する場合であっても同じ AZ 内に留まるようになりました。これにより、より効率的なルーティングとなり、レイテンシーを低減できる可能性があります。
AWS Transit Gateway および AWS Cloud WAN におけるパフォーマンスとメトリクスに関する機能強化 | Amazon Web Services ブログ
つまりはトラフィックフローの最初にトラフィックについて、Transit Gatewayに入ってきたトラフィックががどのAZのTransit Gateway attachment ENIから抜けていくのかランダムだったところ、送信元および送信先AZのを考慮してくれるようになりました。
実際に試してみましょう。先述の記事と同じ構成を作成します。
NAT GatewayごとのAZは以下のとおりです。
> aws ec2 describe-nat-gateways \
--query 'NatGateways[].{NatGatewayPublicIp : NatGatewayAddresses[].PublicIp, SubnetId : SubnetId}'
[
{
"NatGatewayPublicIp": [
"52.207.102.10"
],
"SubnetId": "subnet-0ccb75936488ee920"
},
{
"NatGatewayPublicIp": [
"32.198.209.252"
],
"SubnetId": "subnet-0844604ef66dae435"
}
]
> aws ec2 describe-subnets \
--subnet-ids subnet-0ccb75936488ee920 subnet-0844604ef66dae435 \
--query 'Subnets[].{AvailabilityZone : AvailabilityZone, SubnetId : SubnetId}'
[
{
"AvailabilityZone": "us-east-1a",
"SubnetId": "subnet-0844604ef66dae435"
},
{
"AvailabilityZone": "us-east-1b",
"SubnetId": "subnet-0ccb75936488ee920"
}
]
この時、各AZのEC2インスタンスからhttp://checkip.amazonaws.com/にアクセスします。
$ for i in {0..15}; do
curl http://checkip.amazonaws.com/
done
32.198.209.252
32.198.209.252
32.198.209.252
32.198.209.252
32.198.209.252
32.198.209.252
32.198.209.252
32.198.209.252
32.198.209.252
32.198.209.252
32.198.209.252
32.198.209.252
32.198.209.252
32.198.209.252
32.198.209.252
32.198.209.252
$ for i in {0..15}; do
curl http://checkip.amazonaws.com/
done
52.207.102.10
52.207.102.10
52.207.102.10
52.207.102.10
52.207.102.10
52.207.102.10
52.207.102.10
52.207.102.10
52.207.102.10
52.207.102.10
52.207.102.10
52.207.102.10
52.207.102.10
52.207.102.10
52.207.102.10
52.207.102.10
はい、送信元のEC2インスタンスと同一AZのNAT Gatewayに関連付けられているEIPのみが返ってきました。数十分ほど時間をおいて再度トライをしたり、Zonal NAT Gatewayだけではなく、Regional NAT Gatewayの場合も同様の結果になりました。
Regional NAT Gatewayで確認した際の検証検証結果は以下のとおりです。
$ for i in {0..15}; do
curl http://checkip.amazonaws.com/
done
32.199.57.138
32.199.57.138
32.199.57.138
32.199.57.138
32.199.57.138
32.199.57.138
32.199.57.138
32.199.57.138
32.199.57.138
32.199.57.138
32.199.57.138
32.199.57.138
32.199.57.138
32.199.57.138
32.199.57.138
32.199.57.138
$ for i in {0..15}; do
curl http://checkip.amazonaws.com/
done
35.168.100.223
35.168.100.223
35.168.100.223
35.168.100.223
35.168.100.223
35.168.100.223
35.168.100.223
35.168.100.223
35.168.100.223
35.168.100.223
35.168.100.223
35.168.100.223
35.168.100.223
35.168.100.223
35.168.100.223
35.168.100.223
ということで、アプライアンスモードの有効化による副作用は気にする必要はありません。
NAT GatewayとNetwork Firewallを別VPCにする
続いて、NAT GatewayとNetwork Firewallを別VPCにするパターンです。
図示すると以下のとおりです。
通信経路としてはこのような形になります。
East-Westの通信
North-Southの通信
Transit GatewayとNetwork Firewallの統合機能によってVPCの管理コストが減るのが嬉しいポイントです。
また、こちらの構成の場合、Egress VPCでZonal NAT GatewayではなくRegional NAT Gatewayを選択することができます。
というよりもRegional NAT Gatewayを使いたいがためにこの構成を採用するレベルです。
ただし、Regional NAT GatewayとCloud WANの相性は悪いと言えます。以下アップデートでRegional NAT GatewayとTransit Gatewayの連携はサポートされましたが、2026/6/29時点でCloud WANとの連携はできません。
先述のとおりNetwork FirewallとRegional NAT Gatewayが同一VPCの場合は、運用負荷が非常に高くなってしまいます。そのため、Transit Gatewayではなく、Cloud WANを採用してインターネットのアウトバウンド通信の集約を行う場合はRegional NAT Gatewayを採用することは現実的ではありません。
Cloud WAN繋がりで言うと、send-viaを通した先にsend-toを使用することはできません。その逆も然りです。これをやろうとすると、Inspection VPCとEgress VPCとで別のNFGに属する必要がありますが、一連のトラフィックフローの中で複数のNFGを経由させることはできません。
同じコアネットワークで複数の NFG を設定できます。ただし、同じセグメントまたはセグメントペアに複数の NFG を挿入することはできません。
AWS Cloud WAN Service Insertion を使用したグローバルセキュリティ検査の簡素化 | Amazon Web Services ブログ
「Network FirewallがあるInspection VPCにsend-via で通した後、static routeでNAT GatewayがあるEgress VPCにルーティングすれば良いのでは?」と思われるかもしれませんが、「send-viaで経由するのはセグメントではなく、NFGのみ」かつ「NFGからのstatic routeは定義できない」という制約があるため、このようなも設定を行うことはできません。
create-routeparameters. If the action iscreate-route, the following are the required and optional parameters.
segment— The name of the segment created in thesegmentssection, which must be a static route. If you need to duplicate the static route in multiple segments, use multiplecreate-routestatements.destination-cidr-blocks— The static route to create. A segment should have the same routing behavior for a certain destination. This means if one Region has a route to a destination, other Regions should also have that route, but with potentially different paths. You can define the IPv4 and IPv6 CIDR notation for each AWS Region. For example,10.1.0.0/16or2001:db8::/56. This is an array of CIDR notation strings.destinations— Defines the list of attachments to send the traffic to, with up to oneattachment-idper Region. Because a segment is a global object, you should design your routing so that every AWS Region has an attachment in the destinations list. Regions that do not have attachments in this list will receive a propagated version of this route through cross-Region peering connections, and will use the static route of another Region. This is the same case for multiple attachments that are defined across multiple remote Regions. Instead of an array of attachments, you can also provide ablackhole, which drops all traffic to thedestination-cidr-blocks.
つまりNAT Gatewayを介してインターネットに出るトラフィックについて、別VPCのNetwork Firewallを通す構成を取ろうとするとsend-viaやsend-toを使用せず、static routeを逐次追加していく運用になります。
ルート管理の楽にしようとすると、VPC間のEast-Westで検査するNetwork FirewallをInspection VPCと、VPCとインターネット間のNorth-Southで検査するNetwork FirewallをEgress VPCにと2つの用途のNetwork Firewallを配置することになります。これではコスト増となってしまいます。
Pros/Consの整理
各パターンのPros/Consを整理してみましょう。
なお、East-West用とNorth-South用のNetwork Firewallを分離させるハイブリッド方式も紹介しましたが、Network Firewallの料金が二重でかかる分、採用は現実的ではないため、ここでは主に「同一VPC」と「別VPC」の2つでPros/Consの整理をします。
整理すると以下のようになります。
| 観点 | 同一VPC | 別VPC |
|---|---|---|
| 構成のシンプルさ | ○ コンポーネントが1つのVPCに集約 | ○ Inspection VPCは統合機能を用いることで管理不要 |
| コスト | ○ Transit Gatewayを経由する回数が少ないため、データ処理量にかかるコストを低減 | △ Transit Gatewayを経由する回数が増える分、インターネットとの通信で発生するTransit Gatewayのデータ処理量の課金が同一VPCのパターンと比べて倍 |
| Regional NAT Gateway | × 運用負荷が高く非推奨 | ○ 採用可能 |
| Cloud WANとの組み合わせ | ○ Service Insertionを使用してルート管理負荷を低減 | × 強みのRegional NAT Gatewayとの統合は非対応、かつ send-viaとsend-toを効果的に使用できないことからルート管理の難易度が増大 |
| East-West / North-South | ○ 対応可能 | ○ 対応可能 |
個人的には同一VPCパターンをまず採用するのが良いでしょう。コスト的にも運用負荷的にもバランスが取れていると考えます。
逆に別VPCパターンを採用するのは以下シチュエーションかと思います。
- Regional NAT Gatewayによる高い可用性を重要視したい場合
- Regional NAT Gatewayの自動拡張機能を使用したい場合
- = 同時接続数に応じて自動的に割り当てるEIPを動的に変更させたい
- 一度割り当てられたIPアドレスを永続化するためにはIPAMによるケアが必要
一方で、別VPCパターンがRegional NAT Gatewayを使用できるといっても、その間のコンポーネントであるNetwork FirewallがAZレベルの冗長性しかないため、コストを払ったことによってネットワークトポロジー内でAZレベルの障害を全く気にする必要がなくなった訳ではないのは理解しておきましょう。Regional NAT Gatewayが登場してしばらく経った2026/6/30現在でもSLAは99.9%のままなのも気に留めておく必要があるでしょう。
Firewall Endpointが不調な場合にHealthyなFirewall Endpointにルーティングする仕組みについては。現状では自動でフェイルオーバーする機能もなく、ヘルスチェックに適したCloudWatchメトリクスもないため、手組みで検知および対応のプロセスを確立する必要があります。例えば、1分間隔で信頼できるいくつかのリソースに対してTCPコネクションを張り、いずれの宛先へも複数回失敗する場合はTransit Gateway attachmentやCloud WAN attachmentが存在するサブネットのルートテーブルにて、デフォルトルートのターゲットを切り替えるなどです。
つまりは、Firewall EndpointをMulti-AZでデプロイするだけでは高い可用性を実現する仕組みとして十分とは言えないのです。
これはZonal NAT Gatewayが不調な場合も同様のプロセスで対応をします。NAT Gatewayの場合はPacketsDropCountメトリクスも判断材料に入れるとより精度が高くなるでしょう。
送信元ポートを割り当てられなかった回数を示すErrorPortAllocationメトリクスをトリガーに対応をするのはオススメしません。この状態はNAT Gatewayが大量の接続を捌いていることに起因するものであるため、1つのAZのNAT Gatewayに片寄する形をとると、今まで正常に行えていた通信も巻き込まれてしまう可能性があります。
Transit GatewayやCloud WANのみに影響を与えるAZ障害が発生した場合
「Transit GatewayやCloud WANのみに影響を与えるAZ障害が発生した場合」というのも気になるところですが、これは基本的に考えなくとも良い認識です。
Transit GatewayではHyperplaneを用いており、ユーザー側でTransit Gateway自体の可用性は気にする必要ないとされています。
抜粋 : AWS Transit Gateway deep dive | AWS Black Belt Online Seminar
まず、Transit Gateway は AWS が管理しているため、 顧客はオペレーティングシステム、インフラストラクチャ、プラットフォームを心配すること無く、 エンドポイントにトラフィックを送信する構成のみに集中できます。 また、Transit Gateway はリージョン内で冗長性があります。
顧客の責任について説明するために、サンプルシナリオを考えてみます。 3つの AZ を持つ VPC があり、別の VPC にあるアプリケーションにアクセスする必要がある EC2 インスタンスがいくつかある場合、 VPC 間のルーティングを実行したいとします。 そこで、Transit Gateway をデプロイし、それをサブネットにアタッチします。 また、アクティブな各 AZ にアタッチすることで、 異常なイベントが発生しても他の AZ のリソースは問題なく Transit Gateway にアクセスできます。
よくある質問として、「レジリエンスを高めるために複数の Transit Gateway を導入する必要がありますか？」というものがありますが、答えはノーです。 なぜなら、Transit Gateway は Hyperplane 上に構築されており、AZ 内での可用性が高く、リージョン内でのフォールトトレラントと信頼性が高まるからです。 つまり、データプレーンのレジリエンスを高めるために複数の Transit Gateway をデプロイする必要はなく、単一のTransit Gatewayで対応できます。
Cloud WANについてもHyperplaneが使用されています。
Although the Cloud WAN Core Network Edge (CNE) is represented by a single endpoint per subnet/Availability Zone (AZ) in our diagrams, it is highly available and based on AWS Hyperplane. The same is true for the Transit Gateway.
基本的にAZレベルでTransit GatewayやCloud WANのみがダウンしているシナリオは考えにくく、そのようなレベルのAZ障害では送信元/送信先のリソース諸共ダウンしているのではと考えています。
仮に、一部AZにおいてTransit GatewayやCloud WANのENIのみが不調である場合は、以下のようにHealthyなENIにトラフィックをルーティングするといった動作は行われません。
もし、こちらの事象に対して対策が必要なのであれば送信元と送信先のペア自体をAZレベルで二重にし、1つのAZのペアで通信に失敗した場合はもう片方のAZのペアで再度トライするといった仕組みが必要です。
これは非常に難易度が高いです。
Active/Activeで動作させても問題ないアーキテクチャであり、
- 失敗した処理は別のノードから再度トライをする
- 片系がダウンしたとしても求められる性能を満たすことができる
- 常に二重で同じ情報を送信し裏側で突合している
のであればまだ良いのですが、Active/Standbyの場合はフェイルオーバーの条件やフェイルオーバー完了までに失敗した処理の扱い方などの考慮点が多くあります。
無理やり片寄するために障害が発生しているENIをデタッチしてしまうと、以下のような前提条件があるため、そもそもTransit Gatewayに到達すること自体ができなくなります。
VPC を Transit Gateway にアタッチしても、Transit Gateway のアタッチメントが存在しないアベイラビリティーゾーンのリソースは、Transit Gateway に到達できません。
結果として送信元と送信先ペア自体をAZレベルで冗長化する必要があります。
Regional NAT Gatewayをどうしても使いたい訳ではないのであればNetwork FirewallとNAT Gatewayを同一VPCにする構成から検討しよう
インターネットのアウトバウンド通信の集約用途のNAT GatewayとAWS Network Firewallを組み合わせる場合の構成パターンを整理してみました。
Regional NAT Gatewayをどうしても使いたい訳ではないのであればNetwork FirewallとNAT Gatewayを同一VPCにする構成から検討しましょう。
個人的にはNetwork FirewallがRegional NAT Gatewayのようにリージョンレベルの可用性をもったサービスになってくれることを期待しています。もし、そうなってくれるとRegional NAT Gatewayとの相性問題も解決できるでしょう。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!
