技術課の山本です。
近所の南アルプスでも紅葉が始まっていました。

Transit Gateway を使用して、AWS Network Firewall Endpoint の集約を考えてみる。

AWS Network Firewall を使用して、VPC内の通信を監査することが増えてきたように感じます。
そこでよく考慮に挙がるのが、Endpoint の集約です。
Endpoint は従量課金になるため、Endpointの母数を減らし、いろいろなサービスが１つの Endpoint を使うように構成しよう、と皆さん考えられます。
Endpoint を集約するためのネットワークを構成する際に、よく用いるサービスが Transit Gateway です。
本記事では、Transit Gateway を使用した、AWS Network Firewall Endpoint の集約を考えてみました。
VPC内からインターネットへのアウトバウンド通信、その逆のインバウンド通信について、２パターンを考えてみました。

参考資料

AWSさん公式の資料では、以下が参考になります。

AWS Network Firewallのデプロイモデル

AWS Network Firewall 応⽤編1　新機能︓MSRの活⽤/トラフィックを集約して監査する

２つ目の資料について特筆しますと、これまで Network Firewall Endpoint のログに残る送信元 IPアドレスが全て、NAT ゲートウェイになっていた問題を解決しています。
VPC の More Specific Routing 機能を使って解決しています。

１．VPC内からインターネットへのアウトバウンド通信時に利用するAWS Network Firewall Endpoint を集約する

まず、集約しない場合は、AWS Network Firewall 応⽤編1　新機能︓MSRの活⽤/トラフィックを集約して監査するにある以下の構成になります。

集約を考えると、以下の構成が候補になります。
上がFirewall Endpoint を集約するAWSアカウントです。
VPC2 が増えた場合は、Firewall Endpoint を集約するAWSアカウントの「Transit Gateway のルートテーブル 2」を VPC1と同様に追加していけば大丈夫です。

補足：前提として、Transit Gateway を図のように利用する際のルーティングは以下のようになります。

VPC内のノードから Transit Gateway Attachment に通信がきた場合は、Transit Gateway のルートテーブル (Transit Gateway Route Tables) を参照する
Transit Gateway のルートテーブル (Transit Gateway Route Tables) から Transit Gateway Attachment に通信がきた場合は、Transit Gateway Attachment のあるサブネットのルートテーブルを参照する

しかし、「AWSマネージドルールのHOME_NET 変数は、Firewall Endpoint のあるVPCの CIDR になる」という制約から、この構成ではAWSマネージドルールを使えません。
詳細は以下記事の「AWS マネージドルールグループの注意点 (重要)」を参照ください。
AWS Network Firewall のルールグループと評価の流れを詳細に理解する ※ハマりポイントも解説しています - サーバーワークスエンジニアブログ
なお、シグネチャルールに関しては、既存のAWSマネージドルールの中身をコピーして、カスタムルールを作るという手もあります。（更新は SNS で受け取り可能。）
こちらについては、またブログを書こうと思います。
AWSマネージドルールを直接使う場合は、以下のようにFirewall Endpoint への送信元を NAT ゲートウェイにする方法があります。
HOME_NET 変数は同じVPC内からの通信を監査するため、NATゲートウェイからの通信は AWS Network Firewall が検査します。

ただし、Network Firewall のログに出る送信元 IP アドレスが、NATゲートウェイの IP アドレスになるため、送信元ノードを特定するのが難しくなります。
VPCフローログと Firewall のログの突き合わせ等が発生します。

２．インターネットからVPC内へのインバウンド通信時に利用するAWS Network Firewall Endpoint を集約する

インターネットからVPC内へのインバウンド通信時には、基本的には、AWS WAF などウェブアプリケーションファイアーウォールを導入して検査するのが良いかと思います。
ただし、ウェブアプリケーション以外の場合は、AWS WAF も使えないため、AWS Network Firewall も検討には入るかなと思います。
その上で、集約までするか、は事前に考慮すると良いと思います・・・。
まず、集約しない場合は、以下の構成になります。

次に結論を書きますと、集約は難しそうでした。

初めに、以下の構成を考えました。
VPC2 が増えた場合に、Firewall Endpoint を集約するAWSアカウントの「Transit Gateway のルートテーブル 2」を VPC1と同様に追加する想定の構成です。
しかし、「Transit Gateway のルートテーブル 2」の宛先が 0.0.0.0/0 となっており、0.0.0.0/0 を VPC2 に向けるルートは書けません。重複してしまいます。
よって集約構成にできません。

次に、以下の構成を考えました。

しかし、仕様上、VPC内にあるEIPなどのパブリックIPアドレスを持つリソースは、同一のVPCに紐づくインターネットゲートウェイを使ってインターネットと通信します。
図内の "NAT" と書いている処理は、インターネットゲートウェイが EC2 のパブリック IP とプライベート IP アドレスを変換する処理です。参考：IP アドレスおよび NAT
そのため、集約用AWSアカウントのインターネットゲートウェイを使って、インターネットと通信できません。
参考2：インターネットへの一元的な発信ルーティング
よってこの案も実装不可でした。

他には、EC2 に EIP を付けずに、Network Load Balancer (NLB) を使って通信を受け、EC2 と NLB 間の通信に Network Firewall を通す通信も考えられます。
しかし、「１．VPC内からインターネットへのアウトバウンド通信時に利用するAWS Network Firewall Endpoint を集約する」で既に Transit Gateway を使っている場合、Transit Gateway をもう一つ作る必要があります。
また、NLBに対応可能なアプリケーションも限られてくると思います。ネットワーク構成も複雑になるため、現実性がなく、本記事では一旦記載を割愛します。

まとめ

１．VPC内からインターネットへのアウトバウンド通信時に利用するAWS Network Firewall Endpoint を集約する
- AWSさんの公式等にも情報があり、実装もある程度は容易
２．インターネットからVPC内へのインバウンド通信時に利用するAWS Network Firewall Endpoint を集約する
- AWSさんの公式にも情報がなく、実装も難しい

以下の２つを同時に行う VPC1 の図を書いてみます。