こんにちは、SCSKでAWSの内製化支援『テクニカルエスコートサービス』を担当している貝塚です。
以前、「プレビュー中のNetwork Firewall Proxyの導入を検討する」というタイトルで以下の記事を書きました。
私の担当している顧客には、Transit GatewayとNetwork Firewallを組み合わせたInspection VPCを採用している会社が何社もあります。同時に、複数のVPCから使用される共通機能を集約したShared VPCも有していることが多いです。
このような顧客環境に導入することを念頭に置いて前述記事を書いたのですが、その時は「HTTP/HTTPSトラフィックがNetwork FirewallとNetwork Firewall Proxy両方通ることになり料金が跳ね上がる」という課題に答えられていませんでした。(下図)
今回、この状態から歩を進めて妥当性のありそうなアーキテクチャを作ることができたので、本記事ではそれを解説いたします。
Network Firewall/Network Firewall Proxy両対応構成
アーキテクチャは下図の通りです。（記載の仕方が今までのアーキテクチャ図と若干異なりますがご容赦ください）
Network Firewall Proxyのエンドポイントは複数のVPCに作成するのではなく、集約してShared VPCに一組配置します。ただし、インターネットゲートウェイのあるVPCや、他の集約されたエンドポイントのあるVPCではなく、Network Firewall Proxyエンドポイント専用のVPCを作成して配置します。本アーキテクチャ図ではVPCエンドポイントが集約されたShared VPCは記載せず、Network Firewall Proxyエンドポイントのみが存在するVPCをShared VPCという名前で記載しています。
この構成にすることで、Network Firewall Proxyエンドポイントへ向かうトラフィックはNetwork Firewallを経由しないようにすることができます。
Transit Gatewayのルートテーブル設計
Network Firewall ProxyがないときのTransit Gatewayルートテーブル
通常、Inspection VPCを持つTransit Gatewayでは大きく2つのルートテーブルを運用します。
(1) Inspection VPCにひもづけるルートテーブル
Network Firewallで検査が終わった後に参照されるルートテーブルなので、各VPC CIDRへのトラフィックを各VPCのアタッチメントに向けます。要するに”普通の”ルートテーブルです。
(2) Inspection VPC以外にひもづけるルートテーブル
すべてのトラフィックがNetwork Firewallで検査されるようにする必要がありますから、すべて(0.0.0.0/0)をInspection VPCに向けます。
Network Firewall ProxyがあるときのTransit Gatewayルートテーブル
本アーキテクチャのルートテーブル構成は以下の通りです。
(1) Inspection VPCにひもづけるルートテーブル
通常アーキテクチャと同じです。Network Firewallで検査が終わった後に参照されるルートテーブルなので、各VPC CIDRへのトラフィックを各VPCアタッチメントに向けます。Shared VPC宛はそもそもInspection VPCを通らないようにするのであまり意味はありませんが、万一来た時には一応ルーティングしてあげるようにしています。
(2) ワークロードのあるVPC(VPC1, VPC5)にひもづけるルートテーブル
HTTP/HTTPSトラフィックは明示的にブラウザ等で指定するNetwork Firewall Proxyエンドポイントに、Inspection VPCを経由せずに直接向かわせたいので、Shared VPC CIDRへのトラフィックはShared VPCアタッチメントに向けます。それ以外のトラフィックはNetwork Firewallで検査されるようにする必要がありますから、すべて(0.0.0.0/0)をInspection VPCに向けます。ルートテーブルにはロンゲストマッチのルール(宛先IPアドレスとマッチする経路が複数ある場合、最も長くビットが一致する(＝サブネットマスクが長い)経路を優先するルール)があるので、結果的にShared VPC以外が宛先となるすべてのトラフィックがInspection VPCに向くことになります。
(3) Shared VPCにひもづけるルートテーブル
ワークロードのあるVPCからNetwork Firewall Proxyエンドポイントに向かう通信の戻りのときに参照されるルートテーブルです。Network Firewallで検査したくないので各VPCに直接向けてやります。
(4) Internet VPCにひもづけるルートテーブル
インターネットからの戻りに適用されるルートテーブルです。Network Firewallの検査対象にしたいので、すべて(0.0.0.0/0)をInspection VPCに向けます。
このようなルートテーブルを運用することで、Shared VPCへ向かう/Shared VPCから来るトラフィックはNetwork Firewallを通らないようにできます。
TLSインターセプト
Network Firewall ProxyにはTLS(HTTPS)通信の中身を検査するTLSインターセプト機能が搭載されています。使用するにはAWS Private Certificate Authorityの汎用モード認証機関が必要です。(有効期間の短い証明書モードの認証機関では機能しませんでした)
Network Firewall Proxyは、Network Firewallでは実現できなかったECH(TLSハンドシェイク時に送信されるSNI(ホスト名)を暗号化する機能。TLS1.3で採用されている)が有効化された通信の検査を可能にするなど、一部機能においてNetwork Firewallに対する優位性があります。
現時点(2026年3月16日)ではNetwork Firewall Proxyの料金が発表されていません。Network FirewallのTLSインスペクション機能は非常に高価だったので、Network Firewall Proxyでどうなるか注目です。
[補足]インターネットゲートウェイの構成について
本アーキテクチャでは、Network Firewall ProxyエンドポイントとひもづくNetwork FirewallをProxy VPCという名前のTransit Gatewayに接続していない独立したVPCに配置しています。このVPCにNAT GatewayとInternet Gatewayを配置しインターネットに接続できるようになっています。
これは主に、Network Firewall Proxyがまだプレビュー中だからなのか、1つしかNetwork Firewall Proxyを作成できず、Regional NAT Gatewayにアタッチすることもできなかったためです。そのため通常の(非HTTP/HTTPS用の)リソースと統合できるか判断できず、一旦VPCごと独立させました。Network Firewall ProxyがGAした際にはRegional NAT Gatewayへのアタッチか、少なくとも複数のNetwork Firewall Proxyデプロイに対応すると思われますので、その時この部分の構成は見直す必要があります。
トラフィック分析
こうしてHTTP/HTTPSと非HTTP/HTTPSの経路を分けたわけですが、Network Firewall Proxy経由になったHTTP/HTTPSトラフィックについて考えてみます。
ログの粒度
まず、Network Firewall Proxyに出力されるログを確認してみます。下図は出力可能なフィールドをすべて出力するようにしたときの、成功したHTTPSリクエストのログです。
- HTTP/HTTPSに特化しているだけあって、Network FirewallログのようにTCPフラグやパケット数など下位層の詳細な情報は含まれていません。
- 各リクエストフェイズ(PRE_DNS, PRE_REQUEST, POST_RESPONSE)のどこで通信が拒否されたか分かるようになっているのが特徴的です。PRE_DNS, PRE_REQUEST, POST_RESPONSEなどのリクエストフェイズについては、冒頭にリンクを載せた過去記事を参照してください。
- 送信元VPCエンドポイント(src_vpce)があるので、どこのProxy VPCエンドポイントが使われたか分かるようになっています。
ネットワークのトラブルシュートという観点ではTCP/IP層の情報がない分やや心許ないですが、VPCフローログである程度補えますし、監査という観点では必要な情報が含まれていると言えそうです。
エンドポイント設置ポイントによる比較
次に、今はエンドポイントをShared VPC、すなわちTransit Gatewayの先に設置していますが、EC2インスタンスのあるVPCに作成することにメリットはあるでしょうか。料金面を措いて考えると…トラフィックがユーザの作成したネットワーク(Transit Gateway等)を通るのではなくAWS管理のネットワークを通るのでもしかするとレスポインスタイムなどに違いがあるでしょうか？
直観的に違いはなさそうですが、念のため確認しました。以下は、 https://www.scsk.jp へのリクエスト応答時間を、(a) ProxyエンドポイントがTransit Gatewayの先(Shared VPC)にあるとき、(b) Proxyエンドポイントがクライアントと同じVPCにあるとき、(c) Proxy経由しない(Network Firewall経由)とき、で比較したものです。
| Proxyエンドポイントが… | 平均(秒) |
| Transit Gatewayの先にある | 0.97 |
| クライアントと同じVPCにある | 0.97 |
| Proxyを使用しない | 0.95 |
Proxyエンドポイントの場所によるレスポンス差はないと言ってよさそうです。もっともほとんど負荷がかかっていない状態のテストなので、大量のトラフィックが発生しているときならまた違ってくるのかもしれません。
また、Network Firewall ProxyとNetwork Firewallを比較すると若干Network Firewallの方が応答が速いという結果でしたが、この結果だけを見れば問題になるような差ではなさそうです。
まとめ
Transit Gateway + Network FirewallによるInspection機能を有したネットワークにNetwork Firewall Proxyを導入するケースを想定し、検討してみましたが、おおむね問題なく導入できそうだということが分かりましたので、Network Firewall ProxyのGA後に本格的に導入検討を進めたいところです。
なお、本記事で説明した構成についてのデプロイ手順を解説した記事を別記事として公開予定です。