【Azure入門】Application Gatewayの作成とルーティング完全ガイド｜ポータル/CLIでの作成・専用サブネット・パスベースルーティング・ヘルスプローブを解説

「Application Gatewayが何者かは分かった。じゃあ実際にどうやって作って、どうやってURLで振り分けるの？」

——概要をつかんだ次にぶつかるのが、この「作成とルーティング」の壁です。ポータルのウィザードは項目が多く、Azure CLIのコマンドは長い。おまけに「Application Gatewayは専用サブネットが必要」といった、知らないとハマる独自ルールもあります。Microsoft Learn（公式）は正確ですが、初学者が一気に読むと迷子になりがちです。

ウィザードもCLIも項目が多すぎて、どこで何を決めてるのか分からなくなる…

この記事では、Application Gatewayの「作成」と「ルーティング」だけに絞って、次の7つを順番に手を動かしながら整理します。読み終えたとき、この7つを自分の言葉で説明できて、実際に構築できるようになることをゴールにしています。

• ポータルからApplication Gatewayを作成できる
• Azure CLI（az network application-gateway create）で作成できる
• 専用サブネット要件（AGW専用・サイズ）を理解している
• リスナー（基本／マルチサイト）の違いを理解している
• パスベースルーティングを構成できる
• バックエンドプール（IP／FQDN／App Serviceなど）を設定できる
• ヘルスプローブ（既定／カスタム）を構成できる

概要（Application Gatewayとは何か・L4との違い・SKU・コンポーネント）は前回の記事で解説済みなので、ここでは軽く触れる程度にとどめます。前回の「フロントエンドIP → リスナー → ルール → バックエンドプール／HTTP設定」という流れを思い出しながら読むと、一気に腑に落ちるはずです。各セクションの最後には「【ここが説明できればOK】」という自己チェックの目安を置いていますので、学習の到達度確認にも使ってください。

ポータルからApplication Gatewayを作成する

まずは一番イメージしやすいAzureポータルのウィザードから作成してみましょう。ポータルの作成画面は5つのタブに分かれていて、これがそのまま前回学んだコンポーネントの流れに対応しています。「どのタブで何を決めているのか」を意識すると迷いません。

• 基本：リソースグループ・名前・リージョン・SKU（Standard_v2 / WAF_v2）・仮想ネットワークと専用サブネットを指定する。
• フロントエンド：フロントエンドIP（パブリック／プライベート）を指定する。玄関のIPアドレス。
• バックエンド：バックエンドプールを作る。宛先サーバー（VM・IP・FQDN・App Serviceなど）を登録する。
• 構成：ルーティング規則を作る。リスナー・バックエンドプール・HTTP設定を1本の経路として結びつける、いわば司令塔の設定。
• 確認と作成：入力内容が検証され、問題なければデプロイされる。

ポイントは、「基本」タブで専用サブネットを、「構成」タブでルーティング規則を作るという順番です。ルーティング規則を作るには先にリスナー・バックエンドプール・HTTP設定が必要なので、ウィザードはこの順に案内してくれます。前回の図（フロントエンドIP → リスナー → ルール → バックエンドプール／HTTP設定）を思い出せば、各タブの位置づけがそのまま見えてくるはずです。

「確認と作成」を押すと入力検証が走り、続けてデプロイが始まります。v2世代は作成に数分〜最大30分ほどかかることがあるので、慌てずに待ちましょう。デプロイが完了したら、必ず動作確認まで行います。

• Application GatewayのパブリックIPアドレスを「フロントエンドIP構成」から確認する。
• そのIPアドレスをブラウザのアドレスバーに貼り付けて、バックエンド（テスト用のNGINXなど）のページが表示されるか確認する。
• 「バックエンドの正常性（Backend health）」ページで、各サーバーがHealthyになっているか確認する。

ブラウザにバックエンドの応答が返ってくれば、作成は成功です。ここまでできれば、ポータルからの作成チェックはクリアです。

【ここが説明できればOK①】
「ポータルのウィザードは基本→フロントエンド→バックエンド→構成→確認と作成の5タブで進み、デプロイ完了後にパブリックIPへアクセスして動作確認する」——この流れを言えて実際に作れれば、1つ目のチェックはクリアです。

Azure CLI（az network application-gateway create）で作成する

ポータルで全体像がつかめたら、次はAzure CLIで作成してみましょう。CLIならコマンドとして構成を残せるので、再現性が高く、あとから何を作ったか一目で分かります。順番は「リソースグループ → ネットワーク（VNet・サブネット・パブリックIP）→ Application Gateway本体」です。

まずリソースグループとネットワークを用意します。ここでApplication Gateway用のサブネット（myAGSubnet）と、バックエンドサーバー用のサブネット（myBackendSubnet）を分けている点に注目してください。理由は次のセクションで詳しく解説します。

# リソースグループを作成
az group create --name myResourceGroupAG --location eastus

# 仮想ネットワークとApplication Gateway用サブネット（/24）を作成
az network vnet create \
  --name myVNet \
  --resource-group myResourceGroupAG \
  --location eastus \
  --address-prefix 10.21.0.0/16 \
  --subnet-name myAGSubnet \
  --subnet-prefix 10.21.0.0/24

# バックエンドサーバー用のサブネットを別途作成
az network vnet subnet create \
  --name myBackendSubnet \
  --resource-group myResourceGroupAG \
  --vnet-name myVNet \
  --address-prefix 10.21.1.0/24

# フロントエンド用のパブリックIP（Standard SKU / 静的）を作成
az network public-ip create \
  --resource-group myResourceGroupAG \
  --name myAGPublicIPAddress \
  --allocation-method Static \
  --sku Standard

各コマンドの役割を補足します。

• az network vnet create：仮想ネットワークと、同時にAGW用サブネットを作成。--subnet-prefix 10.21.0.0/24 で/24（256アドレス）を確保している。
• az network vnet subnet create：バックエンド用のサブネットを別に追加。AGWと同じサブネットには置かないのがポイント。
• az network public-ip create：v2 SKUのフロントエンドはStandard SKU・静的（Static）のパブリックIPが必要。

ネットワークが整ったら、いよいよ本体を作成します。バックエンドにはあらかじめ用意したVMのプライベートIPなどを --servers で指定します。

az network application-gateway create \
  --name myAppGateway \
  --location eastus \
  --resource-group myResourceGroupAG \
  --capacity 2 \
  --sku Standard_v2 \
  --public-ip-address myAGPublicIPAddress \
  --vnet-name myVNet \
  --subnet myAGSubnet \
  --servers 10.21.1.4 10.21.1.5 \
  --priority 100

• --sku Standard_v2：作成するSKU。WAFを付けたいなら WAF_v2 を指定する。
• --capacity 2：インスタンス数（キャパシティ）。
• --subnet myAGSubnet：AGW専用サブネットを指定。ここを間違えると作成に失敗する。
• --servers：バックエンドプールに入れるサーバーのプライベートIPやFQDN。
• --priority 100：v2 SKUではルーティング規則に優先度（priority）の指定が必須。

作成には最大30分ほどかかります。完了したら、プロビジョニングが成功したか（Succeeded）を確認しましょう。

# プロビジョニング状態を確認（Succeeded なら成功）
az network application-gateway show \
  --name myAppGateway \
  --resource-group myResourceGroupAG \
  --query "provisioningState" \
  --output tsv

# フロントエンドのパブリックIPを取得してブラウザで動作確認
az network public-ip show \
  --resource-group myResourceGroupAG \
  --name myAGPublicIPAddress \
  --query "ipAddress" \
  --output tsv

provisioningState が Succeeded と返れば、作成は成功です。取得したパブリックIPにブラウザからアクセスして、バックエンドの応答が返ってくることまで確認しておきましょう。

【ここが説明できればOK②】
「az network application-gateway create でSKU・キャパシティ・専用サブネット・servers・priorityを指定して作成し、provisioningState がSucceededであることを確認する」——ここまでできれば、2つ目のチェックはクリアです。

専用サブネット要件（AGW専用・サイズ）を理解する

作成時に必ずつまずくのが、この専用サブネット要件です。ここは公式ドキュメントにもはっきり書かれている重要ルールなので、しっかり押さえましょう。

Application Gatewayは、仮想ネットワーク内に「専用のサブネット」を必要とします。そのサブネットには、Application Gateway以外のリソースを配置できません。

身近な例で言うと、Application Gatewayは「専用の駐車場」をイメージすると分かりやすいでしょう。この駐車場（サブネット）にはApplication Gatewayという車しか停められません。他のVMやサービスと相乗りはできない、というルールです。同じサブネットに複数のApplication Gatewayを並べることはできますが、VMなど他の種類のリソースを混ぜることはできません。

なぜ専用が必要かというと、Application Gatewayはオートスケールで内部的にインスタンス数を増減させるため、そのぶんのIPアドレスを常に確保しておく必要があるからです。だからサイズにも推奨があります。

• v2 SKU（Standard_v2 / WAF_v2）は、最小 /24（256アドレス）を強く推奨。オートスケール拡張とメンテナンス更新に十分な余裕を持たせるため。
• Azureは各サブネットの先頭4つ＋末尾1つの計5アドレスを予約している。使えるのはその残り。
• Application Gatewayは1インスタンスにつき1つのプライベートIPを使う。プライベートフロントエンドIPを使う場合はさらに1つ必要。

「専用サブネット＋v2は/24推奨」。この2つを覚えておけば、作成時のハマりはほぼ回避できるよ！

なお、GatewaySubnet という名前のサブネットはVPN Gateway専用で予約されているため、Application Gatewayには使えません。混同しやすいので注意しましょう。

【ここが説明できればOK③】
「Application Gatewayは他のリソースと共有しない専用サブネットが必要で、v2 SKUでは/24が推奨される」——この2点を理由付きで説明できれば、3つ目のチェックはクリアです。

リスナー（基本／マルチサイト）の違いを理解する

ここからは「ルーティング」の話に入ります。まずは入口であるリスナーから。前回、リスナーは「プロトコル・ポート・ホスト名で着信リクエストを待ち受ける受付窓口」だと学びました。このリスナーには2つの種類があります。

• 基本（Basic）リスナー：1つのサイト（ホスト）だけを待ち受ける。ホスト名は見ず、指定ポートに来たリクエストをすべて受け付ける。1つのドメインだけを公開するシンプルな構成向け。
• マルチサイト（Multi-site）リスナー：ホスト名（Hostヘッダー）を見て、複数のサイトを1台のApplication Gatewayで振り分ける。contoso.com と fabrikam.com のように、ドメインごとに別々のバックエンドへ流したいときに使う。

例え話にすると、こうなります。

• 基本リスナー＝一軒家の玄関。訪ねてくる人はみんな同じ家（サイト）の用事なので、名前を確認せず全員通す。
• マルチサイトリスナー＝マンションのエントランス。「どの部屋（ホスト名）宛てですか？」と確認して、正しい部屋（サイト）へ案内する。

つまり違いは「ホスト名で振り分けるかどうか」の一点です。1つのドメインしか扱わないなら基本リスナー、1台のAGWで複数ドメインをホストしたいならマルチサイトリスナー、と使い分けます。

【ここが説明できればOK④】
「基本リスナーは1ホスト向けでホスト名を見ない。マルチサイトリスナーはホスト名で複数サイトを振り分ける」——この違いを言えれば、4つ目のチェックはクリアです。

パスベースルーティングを構成する

Application Gatewayの真骨頂が、このパスベースルーティングです。同じドメインへのリクエストでも、URLのパスを見て別々のバックエンドへ振り分けられます。前回の「/images は画像用サーバーへ、/video は動画用サーバーへ」という例が、まさにこれです。

これを実現するのがURLパスマップ（url-path-map）です。パスマップは「このパスパターンなら、このバックエンドプールへ」というルールの一覧で、どれにも当てはまらないリクエストは既定（default）のバックエンドプールへ流れます。

  https://example.com/images/logo.png
        │
        ▼  URLパスマップで照合
 ┌─────────────────────────────────────────────┐
 │  /images/*  →  imagesBackendPool（画像用）    │
 │  /video/*   →  videoBackendPool（動画用）     │
 │  それ以外   →  appGatewayBackendPool（既定）   │
 └─────────────────────────────────────────────┘

Azure CLIで構成する流れは、①振り分け先のバックエンドプールを作る → ②URLパスマップを作る → ③パスごとのルールを追加する → ④パスベースのルーティング規則としてリスナーに紐づける、の4ステップです。

# ① 振り分け先となるバックエンドプールを作成
az network application-gateway address-pool create \
  --gateway-name myAppGateway \
  --resource-group myResourceGroupAG \
  --name imagesBackendPool

az network application-gateway address-pool create \
  --gateway-name myAppGateway \
  --resource-group myResourceGroupAG \
  --name videoBackendPool

# ② URLパスマップを作成（/images/* を imagesBackendPool へ）
az network application-gateway url-path-map create \
  --gateway-name myAppGateway \
  --resource-group myResourceGroupAG \
  --name myPathMap \
  --paths /images/* \
  --address-pool imagesBackendPool \
  --http-settings appGatewayBackendHttpSettings \
  --default-address-pool appGatewayBackendPool \
  --default-http-settings appGatewayBackendHttpSettings \
  --rule-name imagePathRule

# ③ パスマップにルールを追加（/video/* を videoBackendPool へ）
az network application-gateway url-path-map rule create \
  --gateway-name myAppGateway \
  --resource-group myResourceGroupAG \
  --path-map-name myPathMap \
  --name videoPathRule \
  --paths /video/* \
  --address-pool videoBackendPool \
  --http-settings appGatewayBackendHttpSettings

# ④ パスベースのルーティング規則としてリスナーに紐づけ
az network application-gateway rule create \
  --gateway-name myAppGateway \
  --resource-group myResourceGroupAG \
  --name pathRule \
  --http-listener myListener \
  --rule-type PathBasedRouting \
  --url-path-map myPathMap \
  --address-pool appGatewayBackendPool \
  --priority 200

• --paths /images/*：照合するパスパターン。末尾の * で「/images/ 以下すべて」を表す。
• --default-address-pool：どのパスにも一致しなかったときの既定の振り分け先。
• --rule-type PathBasedRouting：ルーティング規則をパスベースにする指定。ここが Basic だとパスを見ない単純転送になる。
• --url-path-map myPathMap：規則に紐づけるパスマップ。これでリスナー・パスマップ・バックエンドが1本につながる。

構成できたら、/images/test.htm や /video/test.htm にアクセスして、パスごとに違うバックエンドの応答が返ってくるかを確認しましょう。狙ったサーバーに振り分けられていれば成功です。

【ここが説明できればOK⑤】
「URLパスマップで /images/* などのパスごとに別のバックエンドプールへ振り分け、どれにも一致しないものは既定プールへ流す構成を作れる」——ここまでできれば、5つ目のチェックはクリアです。

バックエンドプール（IP／FQDN／App Serviceなど）を設定する

振り分けの「宛先」となるのがバックエンドプールです。前回学んだとおり、実際にリクエストを処理するサーバーの集まりですが、登録できる宛先にはいくつかの種類があります。

• NIC（VMのネットワークインターフェイス）：仮想マシンを直接登録する。
• 仮想マシンスケールセット（VMSS）：スケールするVM群をまとめて登録する。
• IPアドレス：VMのプライベートIPや、到達可能なIPを直接指定する。
• FQDN（完全修飾ドメイン名）：backend.contoso.com のようなドメイン名で指定する。
• App Serviceなどのマルチテナントバックエンド：PaaSのWebアプリを宛先にできる。

つまり、「IISやNGINXを載せたVM」だけでなく、PaaSのApp Serviceまで宛先にできるのがポイントです。CLIでプライベートIPを登録する場合は、次のように --servers にIPやFQDNを並べます。

# 既存のバックエンドプールにサーバー（プライベートIP / FQDN）を登録
az network application-gateway address-pool update \
  --gateway-name myAppGateway \
  --resource-group myResourceGroupAG \
  --name imagesBackendPool \
  --servers 10.21.1.4 10.21.1.5 backend.contoso.com

登録したら、必ず到達確認をします。次のセクションで扱う「バックエンドの正常性」ページで、登録したサーバーが Healthy になっていれば、Application Gatewayからそのサーバーへ到達できている証拠です。

【ここが説明できればOK⑥】
「バックエンドプールにはVMのプライベートIP・FQDN・App Serviceなどを登録でき、登録後はバックエンドの正常性で到達（Healthy）を確認する」——ここまでできれば、6つ目のチェックはクリアです。

ヘルスプローブ（既定／カスタム）を構成する

最後はヘルスプローブ（正常性プローブ）です。前回「バックエンドの健康診断」と紹介したこの仕組みは、各サーバーが正常かを定期的にチェックし、異常なサーバーには振り分けないようにしてくれます。プローブには既定（デフォルト）とカスタムの2種類があります。

既定のプローブ

カスタムプローブを設定しない場合、Application Gatewayは既定のプローブを自動で構成します。これはバックエンドに対して <protocol>://127.0.0.1:<port>/（＝ルートパス /）へHTTP GETを送り、応答をチェックするものです。既定値は次のとおりです。

• 正常とみなす応答：ステータスコード 200〜399
• 間隔（Interval）：30秒
• タイムアウト（Time-out）：30秒
• 異常しきい値（Unhealthy threshold）：3回連続失敗でダウン扱い

既定プローブはルートパス / しか見られないのが弱点です。「アプリの入口は / ではなく /health にある」「正常時に 200 ではなく 403 が返る（認証必須のため）」といったケースでは、既定のままだと正常なサーバーまでUnhealthyと判定されてしまいます。

カスタムプローブ

そこで使うのがカスタムプローブです。パス・ホスト名・間隔・タイムアウト・異常しきい値・正常とみなすステータスコードなどを自由に設定できます。たとえば「/health に対して 200-399 が返れば正常」といったチェックに変更できます。

# カスタムヘルスプローブを作成（/health を監視）
az network application-gateway probe create \
  --gateway-name myAppGateway \
  --resource-group myResourceGroupAG \
  --name myHealthProbe \
  --protocol Http \
  --host-name-from-http-settings true \
  --path /health \
  --interval 30 \
  --timeout 30 \
  --threshold 3

# 作成したプローブをHTTP設定（Backend Setting）に紐づける
az network application-gateway http-settings update \
  --gateway-name myAppGateway \
  --resource-group myResourceGroupAG \
  --name appGatewayBackendHttpSettings \
  --probe myHealthProbe

• --path /health：監視するパス。アプリのヘルスチェック用エンドポイントを指定するのが定石。
• --interval / --timeout / --threshold：それぞれ間隔・タイムアウト・異常しきい値。
• プローブはHTTP設定（Backend Setting）に紐づけて初めて有効になる。作りっぱなしでは効かない点に注意。

正常応答コードを細かく指定したい場合（例：認証必須で 403 を正常扱いにしたい）は、ポータルのプローブ設定にある「正常時のHTTP応答コード（match）」で 200-399,403 のように範囲を指定します。設定後はバックエンドの正常性ページで Healthy になったことを必ず確認しましょう。

【ここが説明できればOK⑦】
「既定プローブは / へGETしてコード200〜399を正常とみなす。カスタムプローブではパスや正常応答コードを指定し、HTTP設定に紐づけてHealthy判定を確認できる」——ここまで言えれば、7つ目のチェックはクリアです。

まとめ

今回のポイントを振り返りましょう。この7つを自分の言葉で説明できて、実際に手を動かせれば、Application Gatewayの「作成とルーティング」はバッチリです。

• ポータルは基本→フロントエンド→バックエンド→構成→確認と作成の5タブ。デプロイ後にパブリックIPへアクセスして動作確認する
• Azure CLIは az network application-gateway create で作成し、provisioningState がSucceededかを確認する
• 専用サブネットが必須。他リソースと共有せず、v2 SKUは/24を推奨
• リスナーは基本（1ホスト）とマルチサイト（ホスト名で複数サイト振り分け）の2種類
• パスベースルーティングはURLパスマップで /images/* などパスごとに別バックエンドへ振り分ける
• バックエンドプールにはIP・FQDN・App Serviceなどを登録し、正常性で到達を確認する
• ヘルスプローブは既定（/・200〜399）とカスタム（パス・応答コードを指定）。カスタムはHTTP設定に紐づけてHealthyを確認する

ここまでできれば、Application Gatewayを「作って、URLで振り分けて、健康チェックする」という一連の流れが自分の手で再現できるはずです。次は、Web公開時に欠かせないWAF（Webアプリケーションファイアウォール）やTLS終端といったセキュリティ面に進んでいきましょう。

あわせて読みたい

• 【前回】Application Gatewayとは？L7ロードバランサーの基本（概要・L4との違い・SKU・コンポーネント）
• WAF（Webアプリケーションファイアウォール）の仕組みとルール設定 ※別記事で解説予定
• Application GatewayのTLS終端・エンドツーエンドTLSの設定 ※別記事で解説予定
• Azure VNetとサブネットの基礎（Application Gatewayを配置するネットワークの土台）