「Application Gatewayを作ろうとしたら、専用サブネットが必要って言われた。おまけにNSGで 65200-65535 とか GatewayManager とか、見慣れない設定が出てきて手が止まった…」
——Application Gateway（AGW）は、単体のリソースではなく「仮想ネットワーク（VNet）の中に住む」サービスです。そのため、置き場所となるサブネットや、通信を制御するNSG（ネットワークセキュリティグループ）の作法を知らないと、作った瞬間に動かなかったり、原因不明のエラーに悩まされたりします。特にNSGは、初学者が最もハマるポイントです。
NSGでガチガチに絞ったら、AGWのバックエンドが全部「異常」になって焦った…なんで？
この記事では、Application Gatewayを支えるネットワークとセキュリティに絞って、次の2つを整理します。読み終えたときに、この2つを自分の言葉で説明できるようになることをゴールにしています。
- 専用サブネットとNSGの必要ルール（GatewayManagerからの
65200-65535受信許可）を理解している - バックエンドへのプライベート接続（プライベートIP／Private Link）を構成できる
特に1つ目のNSGのつまずきポイントは厚めに解説します。「NSGでうっかりこのルールを塞いでAGWが壊れる」というのは、現場でも本当によくある事故だからです。各セクションの最後に「これが説明できればOK」という自己チェックの目安を置いていますので、学習の到達度確認にも使ってください。
専用サブネットとNSGの必要ルール（GatewayManager・65200-65535受信）
まず「専用サブネット」が必要な理由
Application Gatewayは、VNet内の「専用サブネット」に配置する必要があります。そのサブネットには、Application Gateway以外のリソースを置くことはできません。
Application Gatewayは、内部的に複数のインスタンス（実体となる仮想マシン群）を動かしてオートスケールします。そのインスタンスひとつひとつが、サブネットのプライベートIPアドレスを1つずつ消費します。だから、他のリソースと相部屋にすると、IPアドレスが足りなくなったりスケールの邪魔になったりするため、丸ごと1つのサブネットを専有する決まりになっています。
身近な例で言うと、専用の駐車場をイメージすると分かりやすいでしょう。AGWは「混雑したら車（インスタンス）を増やす」ため、いつでも空きスペースが必要です。他の人の車が停まっていると増車できないので、区画ごと借り切っておく——それが専用サブネットです。
サイズについては、公式は v2 SKU（Standard_v2 / WAF_v2）で /24 を強く推奨しています。オートスケールの拡張やメンテナンス更新のために、十分な余白が必要だからです。加えて、Azureは各サブネットの先頭4つ＋末尾1つ、合計5つのIPを内部予約する点も覚えておきましょう。狭いサブネットだと、実質使えるIPがすぐ枯渇します。
- サブネットは Application Gateway専用（他リソースの相部屋NG、v1とv2の混在もNG）
- v2はサイズ
/24推奨（オートスケールの余白のため） GatewaySubnetという名前のサブネットはVPN Gateway用の予約名なので、AGWには使わない
NSGの必要ルール ——「GatewayManagerからの65200-65535受信」が主役
専用サブネットにはNSG（ネットワークセキュリティグループ）を付けて通信を制御できますが、ここに絶対に塞いではいけないルールがあります。それが、本記事の一番の山場である 「GatewayManager からの 65200-65535 受信許可」 です。
v2のApplication Gatewayは、GatewayManagerサービスタグを送信元とする TCP
65200-65535の受信（インバウンド）を許可しておく必要があります。この通信を塞ぐと、Application Gatewayが正常に動作しません。
「これは一体なんの通信なの？」というのが最大の疑問だと思うので、そこから噛み砕きます。
前回の記事で触れたとおり、Application Gatewayは自分で意識せずともインスタンスを自動で増減（オートスケール）させ、バックエンドの正常性（ヘルス）を監視し、構成の更新を受け取ります。この「AGWを管理・運用するための裏方の通信」を担っているのが、Azure側の管理基盤である GatewayManager です。
つまり 65200-65535 は、あなたのユーザー（ブラウザ）が使う 80 / 443 のような「表の通信」ではなく、Azureのコントロールプレーンがインスタンスと会話するための「裏口（インフラ通信ポート）」なのです。ここが遮断されると、Azureは自分のAGWインスタンスと連絡が取れなくなり、状態管理やヘルスチェックが破綻します。
80/443＝お客さん用の玄関、65200-65535＝Azureスタッフ専用の裏口。裏口を塞ぐと、AGW自体がメンテ不能になるイメージだよ！
なお「勝手に開けて大丈夫なの？」と不安になるかもしれませんが、この 65200-65535 のエンドポイントはAzureの証明書で保護（ロックダウン）されています。正しい証明書を持たない外部が、このポート経由でAGWに変更を仕掛けることはできない仕組みなので、許可しても安全です。
ここで登場した 「GatewayManager」 は、Azureのサービスタグです。サービスタグとは、Azureが管理するIPアドレスの集合に付けられた名札のこと。IPは変わってもタグ名は不変なので、NSGでは生のIPではなく GatewayManager と書くだけで、その通信を狙って許可できます。
最低限そろえるNSGのインバウンドルール
AGWのサブネットにNSGを付けるなら、次のインバウンドルールをこの優先順位で用意します（DenyAllより上に置くのがポイント）。
【インバウンド（受信）ルール】
① クライアント通信
ソース: Any（または想定クライアントのIP範囲）
宛先ポート: 80, 443 （＝リスナーで待ち受けるポート）
プロトコル: TCP → 許可
② インフラ通信 ★これが今回の主役★
ソース: GatewayManager （サービスタグ）
宛先ポート: 65200-65535 （v2の場合）
プロトコル: TCP → 許可
③ Azure Load Balancerのプローブ
ソース: AzureLoadBalancer （サービスタグ）
宛先ポート: Any
→ 許可（既定で入っている。Denyで上書きしない）
④ それ以外
→ DenyAll でまとめて拒否してOK- ①クライアント通信：あなたのサイトを見に来る利用者の
80/443。リスナーで使うポートに合わせる。 - ②インフラ通信：
GatewayManager→65200-65535（TCP）。v1では65503-65534とポート範囲が異なる点に注意。 - ③ロードバランサープローブ：
AzureLoadBalancerタグからの受信。既定ルールで許可されているので、手動のDenyで潰さないこと。 - アウトバウンド（送信）は、インターネット向けの送信を拒否しないこと。AGWは外部への送信通信も必要とします。
【つまずきポイント】NSGでAGWを壊す典型パターン
ここが本記事で一番伝えたいところです。初学者が「セキュリティのために」と善意でNSGを絞った結果、AGWを壊してしまう典型的な事故パターンを挙げます。
- 「DenyAll」を最優先で置いてしまう：良かれと思って全拒否を上位に置くと、
GatewayManagerの65200-65535まで巻き込んで遮断してしまう。必要な許可ルールを、DenyAllより高い優先度に置くのが鉄則。 - AzureLoadBalancerの既定許可を上書きしてしまう：既定で入っている
AzureLoadBalancer許可を、自作のDenyで潰すとヘルスプローブが届かなくなる。 - アウトバウンドをインターネット向けまで全拒否する：AGWの管理通信・ログ・メトリック・証明書失効チェック（CRL）などが外部へ出られなくなり、動作が不安定になる。
症状として分かりやすいのが、「バックエンドの正常性（Backend health）が Unknown や Unhealthy になる」状態です。バックエンド自体は元気なのに一斉に異常表示になったら、まずNSGで 65200-65535 や AzureLoadBalancer を塞いでいないかを疑う——この当たりの付け方を覚えておくと、原因不明のトラブルで消耗せずに済みます。
ちなみに、UDR（ユーザー定義ルート）でAGWの通信を仮想アプライアンス（ファイアウォール等）へ強制的に迂回させるのも、v2では非対応のシナリオがあり、ヘルスやログが壊れる原因になります。「管理・コントロールプレーンの通信は、まっすぐインターネットへ」——これが基本方針です。
【ここが説明できればOK①】
「Application Gatewayは専用サブネットに置く。v2ではNSGでGatewayManagerからの65200-65535（TCP）受信を許可する必要があり、これはインスタンスを管理するインフラ通信なので塞ぐとAGWが動かなくなる」——これを説明できれば、1つ目のチェックはクリアです。
バックエンドへのプライベート接続（Private Endpoint／内部IP）
次は「閉域（プライベート）で通信する」構成です。ここで大事なのは、Application Gatewayには「入口側」と「出口側」の2つのプライベート化ポイントがあると理解することです。混同しやすいので、まず整理しましょう。
- 出口側（バックエンド接続）：AGWからバックエンドへの通信をプライベートIPで閉じる。＝サーバーをインターネットに晒さない。
- 入口側（クライアント接続）：クライアントがAGW自体にプライベートに到達する。＝AGWのフロントを閉域公開する（Private Link／プライベートフロントエンドIP）。
出口側：バックエンドをプライベートIPで閉じる
もっとも基本的な閉域構成がこれです。前回整理したバックエンドプールには、公開IPやFQDNだけでなく、VNet内のプライベートIPアドレスを宛先として登録できます。
つまり、バックエンドのVM／VMSS／App ServiceなどをプライベートIPだけで待ち受けるように構成し、AGWのバックエンドプールにそのプライベートIP（または内部DNS名）を登録すれば、インターネットからは直接触れないサーバーに、AGW経由でだけアクセスさせる——という閉域構成が作れます。
インターネット
│ ① https://example.com へアクセス
▼
【Application Gateway】（フロントエンド＝パブリックIP）
│ ② 同じVNet内でプライベートに転送
▼
【バックエンド】プライベートIP（例: 10.0.2.4）
・パブリックIPを持たない
・インターネットからは直接アクセス不可
・AGW経由の通信だけを受け付けるポイントは、公開する窓口をAGW1点に集約できることです。バックエンドのサーバーはパブリックIPを持たず、攻撃対象領域（アタックサーフェス）を最小化できます。同じVNet内はもちろん、VNetピアリングでつないだ別VNetのプライベートIPをバックエンドにする構成も可能です。
- バックエンドサーバーはパブリックIPを外し、プライベートIPのみで運用する
- バックエンドプールに、そのプライベートIP／内部FQDNを登録する
- バックエンド側のNSGは、AGWサブネットからの通信を許可しておく（正常性プローブ含む）
入口側：Private Linkで「AGWへの到達」も閉域化する
「出口（バックエンド）だけでなく、AGWに入ってくる通信もインターネットを通したくない」——そんな要件に応えるのが Application Gateway Private Link です。
Application Gateway Private Linkを使うと、別のVNetやサブスクリプションのクライアントから、インターネットを経由せずにプライベート接続でApplication Gatewayへ到達できます。
仕組みはこうです。AGW側に Private Link構成 を作り、クライアント側のVNetに Private Endpoint（プライベートエンドポイント） を作成します。Private EndpointはクライアントVNet内のプライベートIPを持つネットワークインターフェースで、クライアントはそのプライベートIP宛にアクセスするだけで、閉じたトンネル経由でAGWのフロントエンドへ届きます。
クライアント（別VNet／別サブスク）
│ Private Endpoint のプライベートIP宛にアクセス
▼
【Private Endpoint】（クライアント側VNet内のNIC）
│ 閉域トンネル（インターネットを経由しない）
▼
【Application Gateway】（Private Link構成＋フロントエンドIP）
│
▼
バックエンド（プライベートIP）構成上の注意点として、Private Link用の専用サブネットが必要です（AGWのサブネットとは別に用意する）。そのサブネットでは Private Link Service のネットワークポリシーを無効化しておく必要があります。ポータルから作ると自動で無効化されますが、CLIやPowerShellで作る場合は自分で無効化する手順が要るので、ここは忘れやすいポイントです。
- 出口の閉域化だけなら → バックエンドをプライベートIPで構成するだけでOK（Private Linkは不要）
- 入口も閉域化したい（クライアントもインターネットを通さない） → Private Link＋Private Endpoint を使う
- Private Linkには専用サブネット＋ネットワークポリシー無効化が必要。CLI/PowerShellでは無効化を明示的に行う
「出口＝バックエンドをプライベートIPに」「入口＝Private Linkで到達を閉域に」。この2方向で覚えると混乱しないよ！
閉域構成ができたら、動作確認も忘れずに。バックエンドをプライベート化したら「インターネットから直接バックエンドIPを叩けないこと（＝閉じていること）」を、Private Linkを組んだら「Private EndpointのプライベートIP経由でAGWにアクセスできること」を、それぞれ確かめて完了です。
【ここが説明できればOK②】
「バックエンドをプライベートIPでバックエンドプールに登録すれば、サーバーをインターネットに晒さず閉域アクセスにできる。さらにクライアント側もPrivate Link／Private Endpointで、インターネットを経由せずAGWへ到達させられる」——ここまで言えれば、2つ目のチェックはクリアです。
まとめ
今回のポイントを振り返りましょう。この2つを自分の言葉で説明できれば、Application Gatewayの「ネットワーク・セキュリティ」の基礎はバッチリです。
- AGWは専用サブネット（v2は
/24推奨）に置く。NSGではGatewayManagerからの65200-65535（TCP）受信を必ず許可する。これはインスタンスを管理するインフラ通信の裏口なので、塞ぐとAGWが動かない - バックエンドが一斉にUnknown／Unhealthyになったら、まずNSGで
65200-65535やAzureLoadBalancerを潰していないかを疑う - 閉域化は「出口」と「入口」の2方向。出口＝バックエンドをプライベートIPで登録、入口＝Private Link／Private EndpointでAGW到達を閉域化する
ネットワークとセキュリティの土台が固まれば、Application Gatewayを「作ったのに動かない」で消耗することはグッと減ります。特にNSGの 65200-65535 は、知っているかどうかだけで結果が変わる典型の”ハマりどころ”なので、しっかり自分のものにしておきましょう。
あわせて読みたい
- Application Gatewayとは？ L7ロードバランサーの概要（本シリーズ第1回）
- Application Gatewayの作成手順（リスナー・ルール・書き換えの設定）※別記事で解説予定
- WAF（Webアプリケーションファイアウォール）の仕組みとルール設定 ※別記事で解説予定
- Azure VNetとサブネット・NSGの基礎（Application Gatewayを配置するネットワークの土台）
