プレビュー中のNetwork Firewall Proxyの導入を検討する

本記事は TechHarmony Advent Calendar 2025 12/24付の記事です。

こんにちは、SCSKでAWSの内製化支援『テクニカルエスコートサービス』を担当している貝塚です。

re:Invent2025の直前に、Network Firewall Proxyという機能のプレビューが開始されました。

リリース記事

AWS Network Firewall Proxy のプレビューのご紹介 - AWS

AWS の新機能についてさらに詳しく知るには、 AWS Network Firewall Proxy のプレビューのご紹介

aws.amazon.com

ブログ記事

Securing Egress Architectures with Network Firewall Proxy | Amazon Web Services

Note: Dec 4, 2025 – expanded with additional section on application networking integrations. Customers who control acces...

aws.amazon.com

AWS Network Firewallで機能提供していた透過型プロキシではなく、クライアント側で明示的にプロキシサーバとして指定する必要のあるタイプのプロキシです。

私の担当するお客様でも金融業を中心に過去にプロキシサーバの導入を検討された結果EC2でプロキシを構築したり、Network FirewallでのTLS検査を検討されたりしていますので、それらのお客様への導入という視点からNetwork Firewall Proxyの機能を検討してみます。

アーキテクチャ

名前にNetwork Firewallとついていますが、既存のAWS Network Firewallの一機能ではなく、独立したリソースになっているようです。NAT Gatewayとセットで動作し、クライアントは専用のVPCエンドポイント(Proxyエンドポイント)経由でプロキシを使用することになります。

シンプル(単一VPC)構成

上の図がもっともシンプルな構成ですが、実際に設定してみるとNetwork Firewall Proxyと同じサブネット(パブリックサブネット)に自動的にProxyエンドポイントが作成されることが分かります。同VPC内に既にエンドポイントがあるのに別サブネットにエンドポイントを作る必要性はイマイチ理解できませんが、構成上はどちらでも動作しました。

少し調べてみたところ、こちらのblogではProxyと同じパブリックサブネットにエンドポイントが置かれていたので、そのあたりは好きに設計すればよさそうです。

中央集約構成

他のネットワークリソース(Internet GatewayやNetwork Firewallなど)と同様に、Network Firewall Proxyも、複数のVPCのProxy機能をひとつに集約した構成を取ることができます。

そしてここが素晴らしい点なのですが、Network Firewall Proxyの機能はVPCエンドポイントとして提供されているので、通信要件がHTTP/HTTPSのみであれば、Transit GatewayやVPC PeeringなどでVPC間を接続することなく、インターネットとの通信をセキュアに実現できてしまうのです。

HTTP/HTTPS以外にも通信要件がある場合は、従来同様Transit GatewayでVPC間を接続し、HTTP/HTTPS通信はProxyエンドポイント経由、HTTP/HTTPS通信以外はTransit Gateway経由という方式が紹介されています。

上図構成だと、HTTP/HTTPSの検査・制御はNetwork Firewall Proxyで行う、HTTP/HTTPS以外の検査・制御はNetwork Firewallで行うことになります。ログの出力先もログのフォーマットも別になり、運用管理上の負荷が増えそうですが、これは現状仕方ありません。

一方で、Transit Gatewayで中央集約VPCとつながっているのであれば、Proxy エンドポイントは各VPCに持つのではなく、下図の通り中央集約VPCにひとつだけ置くというのも選択肢としてありえそうですが……HTTP/HTTPSトラフィックがNetwork FirewallとNetwork Firewall Proxy両方通ることになると無駄に高額なトラフィック料金を払わされることになり現実的ではないのかもしれません。まだNetwork Firewall Proxyの料金が発表されていないので、この部分は料金の発表を待たないとこれ以上議論できなさそうです。

プロキシのルールについて

プロキシのルール構造は下図のようになっています。

プロキシは1つのプロキシ設定を持ちます。

プロキシ設定は複数のルールグループを持つことができます。プロキシ設定内で、複数のルールグループに0～の優先度をつけることができ、値が小さいグループから順に評価されるようになっています。また、どのルール(後述)にも合致しなかった場合のデフォルトのアクション(許可/拒否)をプロキシ設定で指定します。

ルールグループは複数のルールを持つことができます。ルールグループの設定のところで各ルールを記述して行きます。ルールは検査した通信に対するアクション(許可/拒否)と条件を記したもので、0～の優先度をつけることができ、値が小さいルールから順に評価されるようになっています。

以上をまとめると、ルールはフェーズ(後述)ごとに、以下の順番で評価されていき、どのルールにも合致しなかった場合、デフォルトのアクションが実行されるということになります。

優先度0のルールグループ：優先度0のルール → 優先度0のルールグループ：優先度1のルール → 優先度0のルールグループ：優先度2のルール → … → 優先度1のルールグループ：優先度0のルール → 優先度1のルールグループ：優先度1のルール → … → 優先度2のルールグループ：優先度0のルール → … → デフォルトのアクション

フェーズ

プロキシのルールは、HTTP/HTTPSの通信の段階に応じて、PreDNS、PreREQUEST、PostRESPONSEの3つのフェーズに分けて適用されます。

• クライアントがHTTP CONNECTを出し、ProxyがDNS名前解決を行う前にルールを適用するのがPreDNSです。
• クライアントがHTTP REQUESTを出し、Proxyがあて先にHTTP REQUESTを行う前にルールを適用するのがPreRequestです。
• あて先からProxyに返ってきたHTTP RESPONSEをクライアントに返す前にルールを適用するのがPostResponseです。

アクション

アクションは、許可(allow)、アラート(alert)、拒否(deny)の3つがあります。

許可(allow)、拒否(deny)はそのままの意味ですが、アラート(alert)はアラートログに出力した上で次以降のルールの評価を継続します。許可した場合でもログを出力することができますので、許可(allow)ログは証跡としての保存用、アラート(alert)ログはCloudWatch等で捕捉してSNS連携等のアクションにつなげるという使い方が想定されているのだと考えられます。

条件

アクションの発生条件を、リクエストやレスポンスに関わる各種値を使用して指定します。現在対応しているのは以下の通りです。

• request:SourceAccount – リクエスト送信元のAWSアカウントID
• request:SourceVpc – リクエスト送信元のVPC ID
• request:SourceVpce – リクエスト送信元のVPCエンドポイントID
• request:Time – リクエストが発生した日時
• request:SourceIp – 送信元のIPアドレス
• request:DestinationIp – 送信先のIPアドレス
• request:SourcePort – 送信元のポート番号
• request:DestinationPort – 送信先のポート番号
• request:Protocol – 通信プロトコル（TCPなど）
• request:DestinationDomain – 送信先のドメイン名
• request:Http:Uri – HTTPリクエストのURI（パス）
• request:Http:Method – HTTPリクエストメソッド（GET, POSTなど）
• request:Http:UserAgent – HTTPリクエストのUser-Agentヘッダーの値
• request:Http:ContentType – HTTPリクエストのContent-Typeヘッダーの値
• request:Http:Header/CustomHeaderName – HTTPリクエスト内の指定したヘッダーの値（CustomHeaderNameを実際のヘッダー名に置き換えて使用）
• response:Http:StatusCode – HTTPレスポンスのステータスコード
• response:Http:ContentType – HTTPレスポンスのContent-Typeヘッダーの値
• response:Http:Header/CustomHeaderName – HTTPレスポンス内の指定したヘッダーの値（CustomHeaderNameを実際のヘッダー名に置き換えて使用）

設定手順

プロキシの作成は以下の手順で実施します。

1. プロキシルールグループの作成
   1. ルールの作成
2. プロキシ設定の作成 → ここで、プロキシルールグループを指定
3. (まだ作成していないなら) NATゲートウェイの作成
4. (TLS インターセプトモードを有効化するなら) プライベートCAの作成、Resource Access Manager共有設定
5. プロキシの作成 → ここで、プロキシ設定、NATゲートウェイ、プライベートCAを指定
6. Proxyエンドポイントの作成

本稿では、具体的な操作手順については説明を致しません。(公式ドキュメントなどをご参照ください)以下、注意すべき点のみを書いて行きます。

TLSインターセプトモードについて

TLS通信の中身を検査するには、プライベート証明書を発行できるプライベートCAが必要になります。公式ドキュメントの記述が不親切なのですが、プライベートCAを作成し、RAM (Resource Access Manager) で共有して、「下位CAは作成できず従属CA証明書の発行のみ許可する権限」(AWSRAMSubordinateCACertificatePathLen0IssuanceCertificateAuthority)を与えてあげてください。プライベートCAのことをよく知っている人には当然のことなのかもしれませんが、私はこれが理解できておらずハマりました。

TLS検査の仕組みや、クライアントPCでプライベート証明書を信頼する手順は、以下の記事もご参照ください。

AWS Network FirewallでアウトバウンドトラフィックをTLSインスペクションする

AWS Network Firewallで、アウトバウンド(egress)のTLSインスペクション機能を検証しました。アウトバウンドTLSインスペクションにより、クライアントPC(社内)から外部のウェブサーバへのHTTPS通信の内容を検査することができるようになります。

blog.usize-tech.com

2023.12.27

TLSインターセプトモードが有効になると、条件 request:Http:* や  response:Http:* を使用した検査が行えるようになります。

Proxyエンドポイントの作成

プロキシが作成されると、プロキシと同じサブネットにProxyエンドポイントが作成されます。Proxyエンドポイントは追加作成することができます。プロキシの詳細に「VPC エンドポイントサービス名」という項目が表示されるので、プロキシを使用したいVPCでVPCエンドポイントを作成し、タイプに「NLB と GWLB を使用するエンドポイントサービス」、サービス名に「VPC エンドポイントサービス名」の値を入れるようにしてください。なお、最初に作成されるProxyエンドポイントは不要であれば削除しても構いません。

クライアントでプロキシ設定して使用

プロキシの詳細に「プライベート DNS 名」が表示されるので、その値( xxxxxxxx.proxy.nfw.<リージョンID>.amazonaws.com )をクライアントのプロキシ設定箇所に設定して使用します。

さいごに

顧客企業への導入検討と銘打ちながら、検討らしきものはアーキテクチャ検討部分だけとなってしまいましたが、プレビューが進みGA段階になれば、プレビュー段階に存在する様々な制約も解消され、具体的に検討が進められるかなと考えています。

現段階では、インターネットアクセス要件がHTTP/HTTPSだけであればTransit GatewayやVPC Peeringを作ることなくVPCエンドポイントだけで接続できてしまう点がメリットとして大きいように感じます。

まずはプレビューで出来る範囲でいろいろ試してみたいと思います。