【Azure】従来のAppGWとPrivate-only AppGW（ネットワーク分離）の違いを完全解説
AzureのLayer 7ロードバランサーであるAzure Application Gateway（AppGW）v2は、長らく「パブリックIPアドレス（Public IP）の保持」が必須仕様となっていました。
しかし、機能の一般提供（GA）に伴い、パブリックIPを一切保持しない完全なプライベート構成が可能となる「Private-only AppGW（Network Isolation / ネットワーク分離機能）」が利用できるようになりました。
本記事では、従来のAppGWとPrivate-only AppGWの決定的な違い、アーキテクチャ上のメリット、どのようなユースケースで活用すべきかをわかりやすく解説します。
一目でわかる！機能・制約の比較表
まずは従来の構成（Public IP必須）と、Private-only構成の主な違いをまとめました。
| 項目 | 従来のAppGW (v2) | Private-only AppGW (v2) |
|---|---|---|
| パブリックIP (PIP) | 必須（フロントエンドに割り当てが必要） | 不要（プライベートIPのみでデプロイ可能） |
| GatewayManager (NSG) | インバウンド許可ルールが必須 | 規則の解放/削除が可能（Azure基盤制御が内部統合） |
| Outbound (NSG) | インターネットへの送信許可が必須 | 「Deny All Outbound」が設定可能 |
| 強制トンネリング | 非対応（0.0.0.0/0 をアプライアンス等へ向けると動作不可） |
完全対応（オンプレミスやNVAへルート変更可能） |
| データ漏洩（Exfiltration）リスク | パブリックIP経由の外部露出リスクが存在 | 閉域網内に完全に限定され、リスクを大幅低減 |
主な違いと3つの深掘りポイント
1. フロントエンドIPとパブリックIPの完全削除
-
従来の課題:
社内システム（イントラネット）用のロードバランサーとして使いたい場合でも、Azureコントロールプレーン（GatewayManager）との通信を維持するためにパブリックIPの紐付けが強制されていました。リスナーをプライベート側だけに設定する構成は可能だったものの、パブリックIPが存在すること自体が企業のセキュリティポリシーに抵触ケースが多くありました。 -
Private-onlyでの進化:
パブリックIPリソースを一切作成せず、VNet内のプライベートIPのみでAppGWをデプロイ可能になりました。「社内限定WebアプリにパブリックIPを持たせてはならない」という制約をクリアできます。
2. NSG（ネットワークセキュリティグループ）の自由度向上
-
従来の課題:
AppGWサブネットのNSGには、Azure管理トラフィック用のGatewayManagerタグからのインバウンド（65200-65535ポート）と、インターネット宛てのOutbound通信を許可するルールを必ず含める必要がありました。 -
Private-onlyでの進化:
ネットワーク分離機能により、コントロールプレーン通信が内部管理メカニズムに移行したため、GatewayManager規則の強制が不要になりました。また、アウトバウンド制御として「Deny All Outbound（全ての送信通信を拒否）」を構成できるようになり、不正なデータ外部送信を厳格に阻止できます。
💡 補足:
Private-only AppGWサブネットのNSGでは、ヘルスチェック用のAllow inbound from AzureLoadBalancerルールのみを許可しておけば動作します。
3. 強制トンネリング（Forced Tunneling）とルートテーブルのサポート
-
従来の課題:
VNetのカスタムルートテーブル（UDR）で0.0.0.0/0（デフォルトルート）をファイアウォール（Azure FirewallやサードパーティNVA）やオンプレミスへリダイレクトすると、AppGWの管理通信が切断され、メトリクス不具合やデプロイ失敗が発生していました。 -
Private-onlyでの進化:
デフォルトルート（0.0.0.0/0）の上書きに対応しました。AppGWからバックエンドや外部へ向かう全トラフィックをハブファイアウォールやオンプレミスへ強制集約・検査（強制トンネリング）するエンタープライズ構成が実現できます。
どのようなシーンで利用すべきか？
-
金融・医療・官公庁などの厳格なコンプライアンス要件
「インターネットに一切接点を持たない完全閉域ネットワーク構築」が求められる環境に最適です。 -
社内イントラネット / 社員向けポータルアプリ
VPNやExpressRoute経由でアクセスする社内システムにおいて、WAF機能（Web Application Firewall）やLayer 7ルーティングを安全に導入できます。 -
Zero Trust（ゼロトラスト）ネットワークアーキテクチャ
明示的な許可ルール以外をすべて遮断（Deny All Outbound）し、セグメンテーションを徹底するインフラ構成に対応します。
まとめ
従来のAppGW v2は「管理通信のためにパブリックIPと特定のNSGルールを強要される」点が設計上のボトルネックでした。
Private-only AppGWの登場により、「完全プライベート化」「厳格なNSG制御」「自由なルート制御（強制トンネリング）」がすべて解除され、より安全で高度なAzureネットワーク設計が可能になりました。
注意点
Private-only AppGW利用の場合、バックエンドはインターネット公開サービスの場合、
Private AppGW で発生しやすい問題
Private Only 構成では、規定ではInternet への出口を提供しないので
インターネット公開されたバックエンドへ到達できないことがあります。
つまり従来のAppGWを作成する予定ですが、間違って意識せずにネットワーク分離モードで作成した場合、
予想外でインターネット公開されたバックエンドへのProbe確認が失敗します。
公開文章：
https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-private-deployment?tabs=portal#outbound-internet-connectivity
Outbound Internet connectivity
Application Gateway deployments that contain only a private frontend IP configuration (do not have a public IP frontend configuration associated to a request routing rule) aren't able to egress traffic destined to the Internet. This configuration affects communication to backend targets that are publicly accessible via the Internet.
To enable outbound connectivity from your Application Gateway to an Internet facing backend target, you can utilize Virtual Network NAT or forward traffic to a virtual appliance that has access to the Internet.
裏技ですが、ダミーのPublic FrontEnd理由のルーティングを作成すれば、上記の注意点が回避できます。
AppGW の外部送信接続は外部 LB の SNAT 機能 (以下の 4 番) で実現しているはずなので、パブリック IP が関連付けられたルーティング規則を作成した時点で 外部 LB が作成されて暗黙の SNAT が機能するようになると思います。
https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-outbound-connections#4-use-the-frontend-ip-addresses-of-a-load-balancer-for-outbound-without-outbound-rules
LB から見たバックエンド プールは AppGW インスタンスなので、AppGW のフロントエンド IP がどのルーティング規則に対応しているかは意識せずに外部送信接続を提供すると考えます。