AWS社はこのほど、プロキシの管理と展開を担うマネージドサービス「AWS Network Firewall proxy」のプレビュー版を開始した。AWS社によると、このサービスは、顧客が自社のVPCからのアウトバウンドアクセスを統制するセキュリティポリシーに、より注力できるようにするものだ。
Network Firewall proxyは、VPC内で稼働し、送信トラフィックのIPアドレス変換を担うNAT Gatewayサービスと統合されている。利用者のアプリケーションは、AWS PrivateLink上に構築されたプロキシ専用のVPCインターフェースエンドポイントを通じて、ローカルおよびリモートのVPCの双方から、このプロキシに接続できる。
/filters:no_upscale()/news/2025/12/aws-network-firewall-proxy/en/resources/1Proxy%20components-1767023784724.jpg)
（出典：AWS Network & Connectivity Blog）
このプロキシは、従来の透過型ファイアウオールとは異なり、HTTP CONNECTリクエストを処理し、アプリケーションに代わって接続を確立することでネットワークトラフィックを検査する。トラフィックの評価は、次の3段階の段階的評価モデルで行われる。
-
PreDNS: プロキシが宛先ドメインを解決する前に評価される。
-
PreRequest: プロキシが宛先にリクエストを送信する前に評価される。
-
PostResponse: プロキシがサーバーからレスポンスを受信した後に評価される。
アクセス規則は各段階で適用される; 早い段階で通信が遮断された場合、その後の段階は作動せず、処理効率の最適化につながる。
利用者は、Network Firewall proxyについて、TLSインスペクション（復号して内容を検査する）設定と、TLS通信をそのまま通過させる設定のいずれかを選択できる。TLSの中継が有効な場合、プロキシは実際の接続先に対する証明書を生成し、HTTPレイヤーの内容を検査してポリシーを適用する。この場合、ワークロードはプロキシの認証局を信頼する必要がある。 一方、TLSの中継を無効にした場合、ワークロードと接続先の間でエンドツーエンドの暗号化トンネルが直接確立される。このため、プロキシはペイロードを復号できず、ポリシーの適用はDNS、IPアドレス、SNIなど、暗号化されていないメタデータに限定される。
アーキテクチャ上、このサービスは分散型（VPCごと）と集中型の両モデルをサポートする。集中型アーキテクチャでは、エンジニアはTransit GatewayやCloud WANを活用し、複数のVPCからの外向き通信を単一のプロキシエンドポイントに集約できる。これにより、従来の自社運用型Squidフリートにおけるパッチ適用やスケール対応に伴う管理負担を大幅に軽減できる。 ただし、Ivo Pinto氏がLinkedInへの投稿で指摘している:プロキシはHTTPおよびHTTPS通信に限定されており、汎用的なネットワークファイアウォールではなく、特化型のツールであるという制約が残る。
Network Firewall Proxyは、ローカルVPC、リモートVPC、さらにはオンプレミス環境からのトラフィックを保護する用途で利用できます。ワークロードがプロキシエンドポイントへの接続性を確保していれば、プロキシサービスを利用できます。 ただし、トラフィックがプロキシに到達できるのはエンドポイント経由に限られます。単にトラフィックをNAT Gatewayにルーティングしただけでは、プロキシのポリシーは適用されません。
現在、このサービスはAWSのUS East (Ohio) リージョンで利用可能で、プレビュー段階にある。Kayesee氏はRedditのスレッドで次のようにコメントしている:
試してみるのがよいでしょう。パブリックプレビュー期間中は無料で利用できます。実質的には、マネージド型の明示的フォワードプロキシです。VPC、アカウント、CIDRといった特定の場所からのトラフィックについて、特定のウェブサイトを対象に許可や遮断のルールを設定できます。ワークロードは、プロキシを明示的に利用する前提の設計である必要があるとしています。
最後に、詳細についてはドキュメントページで確認できる。