はじめに
この記事はJapan AWS Ambassadors Advent Calendar 2025 の 12 日目の記事です。
re:Invent開催前の怒涛のアップデート発表期間に、VPCからのEgress通信に関わる大き目のアップデートが2つ発表されました。
1つ目はAWS NAT Gatewayの新しい提供形態として「Regional NAT Gateway」が登場したというもの、2つ目はAWSマネージドのForward Proxyである「AWS Network Firewall Proxy」（現在はPreview段階）の発表です。
本ブログでは2つのアップデートの内容の概要と、実際に触ってみて分かったことについて共有していきたいと思います。
こう書くとRegional NAT GatewayとNetwork Firewall Proxyを組み合わせられそうに見えますが、後述の通り、Network Firewall Proxyと組み合わせられるのは現状、Zonal NAT Gatewayのみとなっているためご注意ください。
アップデート内容概要
Regional NAT Gateway
AWS NAT Gatewayが「Regional NAT Gateway」に対応しました。
リリース記事：
公式ブログ：
このアップデートにより、ユーザーが各AZのPublic SubnetにNAT Gatewayを立てることなく、NAT Gatewayを利用することが可能になりました。
また、Public Subnetが不要となるため、セキュリティ面でもメリットのあるアップデートです。
本件もそうですが、昨年発表されたCloudFrontのVPC Originや先日発表されたAPI Gatewayのプライベート統合でALBが利用可能になったアップデートなど、Public Subnetが不要になるケースがかなり増えているのではないでしょうか。
AWS Network Firewall Proxy
恐らく、かなり多くの人が望んでいたと思われる、マネージドなForward Proxyがついに発表されました（現在はまだPreview段階）。
リリース記事：
公式ブログ：
Network Firewall Proxyという名称ですが、これまでのNetwork FirewallのEndpointを利用する形ではなく、NAT Gatewayと統合する形で構成されるProxyです。
これまでNetwrok FirewallではFQDNレベルでのアクセス制御を行うことはできたものの、仕組みとしてHTTP通信の場合はHost Header、HTTPS通信の場合はSNIの値を見て制御が行われていたため、偽装の懸念等から厳格に制御したい環境ではsquid等のForward Proxyを導入するケースがありました。
今回のアップデートでAWSマネージドなProxyが登場し、喜んでいる人は多そうです。
実際に触ってみた
得られた知見
最初に、得られた知見を書いておくと以下2つです。
- Regional NAT Gateway + Network Firewall Proxyの組み合わせは今のことろできなさそう。Zonal NAT Gatewayの利用が必要。
- Network Firewall Proxyで「TLS interception」を利用しないケースにおいて、プロキシ設定のデフォルトアクションの「PreREQUEST」、「PostResponse」を"拒否"にしてしまうと、通信時、TLS connect errorがエラーが発生する。
詳細については以下の「触ってみた内容」と合わせて記載していきます。
触ってみた内容
Regional NAT Gateway
こちらは設定を行うだけであれば、特に困難なく進みました。
上記のようにNAT Gateway作成時にRegional/Zonalの2つの選択肢が出てくるため、Regionalを選択すればOKです。
また、図の通りEIPの割り当ても行われます。
1点注意点としては、公式ブログの図にあるようにRegional NAT Gateway利用時もInternet Gatewayは必要になる点です。
Internet Gatewayを紐づけていない場合は、NAT Gatewayの設定画面の"VPC"の選択肢としても現れませんでした。
上記でRegional NAT Gatewayのデプロイが完了した後に、NAT Gatewayを利用してEgress通信を行いたいSubnetのルートテーブルに0.0.0.0/0向けの通信をNAT Gatewayに向けるルーティング設定を追加してあげれば準備は完了です。
これまでのZonal NAT Gatewayとは異なり、AZを意識してNAT Gatewayを指定する必要はなく、どのAZからも同一のターゲットを指定する形となります。
設定完了後、Private Subnet上のEC2から無事にインターネット向けの通信を行うことができました。
AWS Network Firewall Proxy
つづいてNetwork Firewall Proxyの設定です。今回は、ホワイトリスト形式で、許可したドメインのみに疎通が行えるように設定していきます。
Network Firewall Proxyの設定を進める上では大きく
- プロキシルールグループ
- プロキシ設定
- プロキシ
の3つの設定を進めていく必要があります。
プロキシグループ
まずは「プロキシルールグループ」の設定です。
ここでは主に許可/拒否する具体的なルールを設定していきます。
ルールのタイプとしてはフェーズの選択が必要で、以下のいずれかと、そのルールのアクション（許可/拒否）を選択します。
- preDNS
- ドメイン名解決前に評価される
- PreRequest
- DNS解決後、HTTP/sリクエストを送信する前に評価される
- PostResponse
- HTTP/sレスポンスを受信した後に評価される
また、条件キーには以下が利用可能です。
request:SourceAccount request:SourceVpc request:SourceVpce request:Time request:SourceIp request:DestinationIp request:SourcePort request:DestinationPort request:Protocol request:DestinationDomain request:Http:Uri request:Http:Method request:Http:UserAgent request:Http:ContentType request:Http:Header/CustomHeaderName response:Http:StatusCode response:Http:ContentType response:Http:Header/CustomHeaderName
ただし、フェーズとしてPreRequest/PostResponseを選択する場合は、プロキシ作成時に「TLS interception」を有効化する必要があります。
「TLS interception」については上述の公式ブログに詳細が記載されていますが、ざっくりいうと、クライアントとProxy間でTLS Sessionを確立し、一度Proxy上で暗号化を解いて中身を確認の上、Proxyと本来の宛先間でTLS Sessionを確立する形になります。この場合、ProxyにクライアントとのTLS Sessionの確立のために必要な証明書をセットすることや、クライアント側に該当の証明書のルート証明書をImportするなどの対応が必要になります。
今回はドメインレベルでの検査ができればよいので、「TLS interception」を有効にする予定はなく、PreRequest/PostResponseフェーズのルールは作成しない方針としています。
プロキシ設定
プロキシグループの設定が完了したら、続いては「プロキシ設定」です。
ここでは主にデフォルトのアクションと紐付けるルールグループの設定を行います。
まずデフォルトのアクションですが、先ほど出てきた、「preDNS」、「PreRequest」、「PostResponse」の3つの段階でのデフォルトアクション（許可/拒否）を定義する形となります。
で、ここが1つ嵌ったポイントだったのですが（理解不足で勝手に嵌っただけですが．．．）、今回ホワイトリスト形式を考えていたため、何も考えずすべて「拒否」にしていたのですが、
どうもPreRequest/PostResponseを「拒否」にしているとHTTPリクエスト/レスポンスの中身を見ようとする動作になるのか、この後行った動作確認の際にTLS Connection Errorが発生しました。
そのため、以下のように設定を変更しています。
（preDNSの設定をデフォルト拒否としているので、その時点で許可していないFQDNへの疎通は行えず、やりたいことはできる。）
プロキシ
最後にプロキシ自体の作成を進めていきます。
ここでは紐付けるNAT GatewayやTLS interception、ポート番号などの設定を行います。
このNAT Gateway IDの選択の際に、Regional NAt GatewayのIDが選べたので、これはいけるのか？と思ったのですが、残念ながら作成ボタン押下後に以下のエラーが発生しました。
というわけで、気を取り直して、Public SubnetとZonal NAT Gatewayを作成し、上記の画面からZonal NAT Gatewayを指定することで、無事作成が完了しました。
疎通確認
プロキシの作成が完了すると、以下のようにプライベートDNS名が表示されるので、こちらをクライアントで利用するProxyとして指定します。
Private SubnetのEC2上から以下のように動作確認し、無事に想定動作となることが確認できしました。
許可した宛先へProxy経由でCurl ⇒ 200 OKが返る
許可していない宛先へProxyを経由させずCurl ⇒ 200 OKが返る
許可していない宛先へProxy経由でCurl ⇒ CONNECTに対しProxyから403が返っており疎通NG
おわりに
Egress通信周りのアップデートに触れてみるということで、「Regional NAT Gateway」、「Network Firewall Proxy」を触ってみて分かったことをまとめてみました。
Network Firewall ProxyはまだPreview版なものの、双方ネットワーク構成のベストプラクティスに影響するレベルのアップデートかと思いますので、今後のアーキテクチャ検討の際には、是非取り入れていきたいと思います。