Azure Application Gatewayとは？L7負荷分散・WAF・料金とv2の構築手順【2026年版】

Azure Application Gatewayは、HTTP(S)のリクエストをURLパスやホスト名で振り分ける、Azureのリージョン単位のレイヤー7（L7）ロードバランサーです。TLSの終端とWeb Application Firewall（WAF）も同じリソースで担います。旧世代のv1 SKUは2026年4月28日に廃止され、新しく使えるのはv2系（Standard_v2・WAF_v2と、プレビューのBasic）だけです。

この記事では、Microsoft Learnの公式ドキュメントとAzure Retail Prices APIの単価をもとに、使い分け・料金・構築条件・502エラーの切り分けまでを整理します。

まとめ：Azure Application Gatewayの要点（2026年10月時点）

• 役割：1つのリージョン内で、仮想ネットワーク内のWebサーバーへHTTP(S)を振り分けるL7プロキシです。複数リージョンにまたがる負荷分散はAzure Front Doorの担当です。
• SKU：本番はStandard_v2、WAFが必要ならWAF_v2を選びます。Basicはプレビューで、SLAは99.9%、mTLS・Private Link・AKS連携に対応していません。
• 料金：固定料金と容量ユニット（CU）の合計です。東日本のStandard_v2は固定料金だけで月約33,400円、最小インスタンス数2なら月約51,800円です。
• 構築の前提：専用サブネット（v2は/24推奨）が必要です。標準デプロイではNSGでGatewayManagerからのTCP 65200〜65535を許可し、0.0.0.0/0を仮想アプライアンスへ向けられません。ネットワーク分離（プライベートデプロイ）を有効にすると、この2つの制約が外れます。
• 502エラー：最初にポータルの「バックエンド正常性」を見て、次にアクセスログの ErrorInfo で原因を絞ります。多いのはNSG・UDR・DNSによる到達不能、プローブの失敗、バックエンド証明書の不一致です。

Application Gatewayの役割とリクエストが流れる仕組み

Microsoftのアーキテクチャガイドは、Application Gatewayを「アプリケーション配信コントローラー（ADC）の機能をマネージドサービスとして提供するプロキシ型ロードバランサー」と位置付けています。クライアントとの接続をいったんゲートウェイで終端し、バックエンドへは別の接続を張り直す方式です。このため、URLパスやHTTPヘッダーを見て転送先を決めたり、リクエスト本文をWAFで検査したりできます。IPアドレスとポートだけで振り分けるAzure Load Balancer（L4）との違いはここにあります。

リスナー・ルールなどの5つの構成要素

設定の中心は次の要素です。どのリクエストを、どの条件で、どこへ送るかを分担しています。

• フロントエンドIP：クライアントが接続する入口。v2は静的なパブリックIPとプライベートIPを持てます。
• リスナー：IP・ポート・プロトコル・ホスト名の組み合わせで受け付ける要求を定義し、HTTPSならサーバー証明書を割り当てます。
• ルーティング規則：リスナーとバックエンドを結び付けます。パスベースルーティングやHTTPからHTTPSへのリダイレクトもここで設定します。
• バックエンドプール：転送先のNIC、仮想マシンスケールセット、IPアドレス、FQDN、App Serviceなどを登録します。
• バックエンド設定：転送時のポート・プロトコル・要求タイムアウト（既定20秒）・セッションアフィニティを決めます。

複数ドメインを1台で受けるマルチサイトホスティングは、ホスト名を指定したリスナーを複数作って実現します。Standard_v2の上限は、リスナー100、バックエンドプール100、プールあたりのサーバー1,200、ルール400です。

一般用語の「アプリケーションゲートウェイ（ALG）」との違い

「アプリケーションゲートウェイ」「アプリケーションレイヤーゲートウェイ」という言葉は、Azureの製品名とは別に、ネットワークの用語として2つの意味で使われます。

• ファイアウォールの方式：NIST SP 800-41 Rev.1は、クライアントとプロキシ、プロキシと宛先の2本の接続に分け、両者を直接つながせない方式を「application-proxy gateway」と説明しています。パケットフィルタリング型と対比される、いわゆるプロキシ型ファイアウォールです。
• NATの補助機能：RFC 2663の2.9節は、ペイロード内にIPアドレスやポートを含むアプリケーション（FTPなど）をNAT越しに通すための翻訳エージェントを「Application Level Gateway（ALG）」と定義しています。家庭用ルーターの「SIP ALG」はこの意味です。

Azure Application Gatewayは、接続を終端して張り直す点では前者に近いものの、主目的はHTTP(S)の負荷分散とTLS終端です。WAF_v2を選ぶとWebアプリケーションへの攻撃の検査が加わり、「セキュアなアプリケーションゲートウェイ」として外部から自社のWebアプリへ入る通信を守ります。社内ユーザーのWeb閲覧を制御するセキュアWebゲートウェイ（SWG）とは守る向きが逆です。方式ごとのファイアウォールの違いはファイアウォールの仕組みと種類で整理しています。

Load Balancer・Front Door・Traffic Managerとの使い分け

Azureの負荷分散サービスは「グローバルかリージョンか」と「HTTP(S)か否か」の2軸で整理できます。Microsoft Learnのアーキテクチャガイドの分類は次のとおりです。表は推奨用途を示しており、Load BalancerとTraffic ManagerもHTTP(S)を振り分けられますが、L7の処理は行いません。

インターネットに公開するWebアプリを1リージョンで動かすなら、Application Gatewayが第一候補です。複数リージョンに配置してエッジで振り分けたい、または静的コンテンツをキャッシュしたい場合はAzure Front DoorのCDN・グローバル負荷分散を使い、リージョン内のパス振り分けやWAFも要るときだけ背後にApplication Gatewayを置きます。Traffic ManagerのDNSベース負荷分散は通信を中継しないため、フェイルオーバーがDNSキャッシュの分だけ遅れます。L4とL7の一般論はロードバランサーの仕組みと種類で確認できます。

Application Gateway for Containersは名前が似た別製品で、AKSのIngressやGateway APIの実装として動きます。仮想マシンやApp Serviceが相手なら、従来のApplication Gatewayを選びます。

SKUの選び方：Standard_v2・WAF_v2・Basicとv1の廃止

v2系のSKUは3つです。機能差はBasicとそれ以外の間に集中しています。

最大接続数はRSA 2048ビットのTLS証明書を使った場合の推定値で、WAF_v2の値は公式の比較表に載っていません。WAF_v2でもTCP/TLSプロキシのリスナーを通る通信はWAFの検査対象外です（Microsoft Learn「TCP/TLSプロキシの概要」）。Basicは2026年10月時点でもプレビューのままで、サブスクリプションごとに機能 AllowApplicationGatewayBasicSku の登録が要ります（Microsoft Learn「Application Gateway v2とは」）。SLAも下がるため、本番ではStandard_v2から検討するのが妥当です。

v1（Standard・WAF）の2026年4月28日廃止とv2への移行

v1 SKUの廃止は2023年4月28日に告知され、2026年4月28日に廃止されました。Microsoftはv1リソースをサポートしておらずSLAも適用されず、移行していないv1は基盤ハードウェアの廃止に伴ってトラフィックが止まるおそれがあります（Microsoft Learn「Application Gateway V1の廃止」）。PowerShellの移行スクリプトで設定はv2へコピーできますが、トラフィックの切り替えは利用者側の作業です。移行時は、v2がパスをデコードしてから振り分ける（/abc%2Fdef と /abc/def を同一視する）点に注意します。

料金の仕組み：固定料金と容量ユニットの計算（東日本の単価）

v2の料金は「固定料金＋容量ユニット（CU）料金」で、どちらも1時間単位です。1時間未満の利用も1時間として課金されます。固定料金は、ゲートウェイがプロビジョニングされて要求を処理できる状態の間、インスタンス数に関係なくかかり、パブリックIPアドレスの料金は含みません。

2026年10月26日にAzure Retail Prices APIで取得した、東日本（japaneast）の単価は次のとおりです。

ドル建てがAPIの小売価格で、括弧内の円はAPIが返す予算見積もり用の参考価格です。円の値は為替で動くため、見積もりの前にApplication Gatewayの価格ページで最新値を確認してください。

容量ユニットの数え方と最小インスタンス数の影響

1CUは「持続的接続2,500」「スループット2.22Mbps（1時間あたり1GB）」「コンピューティングユニット1」のうち、最も使用率が高い項目で数えます。Standard_v2のコンピューティングユニット1つは、RSA 2048ビット証明書で1秒あたり約50接続を処理できます。

見落としやすいのが最小インスタンス数です。オートスケールの最小インスタンス数は0〜100、上限は125（最大値を省略すると10）で設定します。この最小値や手動のインスタンス数は、1インスタンスにつき10CUを予約扱いにし、トラフィックがゼロでも課金されます。東日本のStandard_v2を月730時間稼働させ、最小インスタンス数を2、使用量を予約分の20CU以内とすると、固定料金33,353円に20CU分の18,402円が加わり、月約51,755円です。同じ条件のWAF_v2は60,036円＋33,123円で月約93,159円になります。最小インスタンス数を0にしても固定料金は残るので、検証環境で使わない時間帯の課金を止めたいなら、Azure CLIの az network application-gateway stop かPowerShellでゲートウェイを停止します（Microsoft Learn「Application Gatewayの価格について」）。

WAF_v2でAzure DDoS Network Protectionを有効にしている場合は、WAFの追加料金がかからず、Standard_v2と同じ単価で課金されます。価格APIでも WAF v2 - Discounted として、Standard_v2と同額の単価が別に登録されています。

WAF_v2でできること：マネージドルール・例外・レート制限

DRS 2.2へ上げるときの注意と旧WAF構成の廃止

WAF_v2では、ルールの設定を「WAFポリシー」という独立したリソースに持たせてゲートウェイに関連付けます。マネージドルールセットは、Default Rule Set（DRS）の最新版である2.2を使うよう案内されています。CRS 3.0〜3.2やDRS 2.1から上げるときは、次の2点で挙動が変わります（Microsoft Learn「CRSまたはDRSのルールセットバージョンをアップグレードする」）。

• パラノイアレベル：DRS 2.2は既定でパラノイアレベル1（PL1）で動き、PL2のルールは既定で無効です。CRS 3.2とDRS 2.1ではPL2も有効だったため、PL2のルールを調整していた場合は明示的に有効化し直します。
• 消えたルールの上書き設定：DRS 2.2に存在しないルールIDの上書きや除外を持ち越すと、ポリシーの更新が The override Rule '<id>' is unknown のエラーで失敗します。

DRS 2.2で新しく有効になるPL1のルールは、防止モードのWAFならまずログモードにして、誤検知がないかを確認してから遮断に切り替えます。ゲートウェイの設定内に直接WAFを書く旧来の「WAF構成」は、2025年3月15日に新規作成が止まり、2027年3月15日に廃止されます。既存のWAF_v2はダウンタイムなしでWAFポリシーへ移行できます。SQLインジェクションなどWAFが防ぐ攻撃の一般論はWAFの仕組みとファイアウォールとの違いで解説しています。

誤検知を通す例外リストとHTTP DDoSルールセット

正当なリクエストがWAFに止められたとき、従来の手段はリクエストの一部（特定のCookieやヘッダー）を検査から外す「除外」でした。これに加えて、条件に一致したリクエストを特定のルール・ルールグループ・ルールセット全体の評価から外す「例外リスト」がプレビューとして提供されています。条件に使えるのはリクエストURI、送信元IPアドレス、リクエストヘッダーの3種類で、次世代WAFエンジンかつCRS 3.2・DRS 2.1以降が前提です。上限は1ポリシー60件、1ゲートウェイ合計60件です（Microsoft Learn「WAF例外リスト」）。次のAzure CLI例は、rg-appgw内にDRS 2.2を設定した既存のWAFポリシーwaf-policy-webがある前提です。検証用の例としてルールセット全体を対象にしていますが、本番では誤検知したルールだけに範囲を絞ってください。

az network application-gateway waf-policy managed-rule exception add \
  --resource-group rg-appgw \
  --policy-name waf-policy-web \
  --match-variable RequestURI \
  --value-operator Equals \
  --values "/login" \
  --rule-sets "[{rule-set-type:Microsoft_DefaultRuleSet,rule-set-version:2.2}]"

Learnも例外はできるだけ狭く作るよう勧めています。誤検知の原因になったルールIDをWAFログで特定し、rule-groups でそのルールに絞るのが基本です。

カスタムルールの「Allow」アクションは、DRS・CRS・ボット保護の検査をすべて飛ばします。ただし、プレビュー中のHTTP DDoSルールセットだけはカスタムルールより先に評価されるため、Allowでも飛ばせません。このルールセットは割り当て後に最低24時間トラフィックを学習し、その間は検知も遮断もしません。

レート制限の集計単位とインスタンス別カウンターの制約

レート制限はWAFポリシーのカスタムルールとして設定します。しきい値と適用条件を指定し、集計単位はクライアントIP（既定）、地域、全体、X-Forwarded-Forヘッダー内のIP・地域から選びます。判定はスライディングウィンドウ方式で、超過した最初のウィンドウは一致する通信をすべて破棄し、次からはしきい値までを通します。

厳密な流量制御には使えません。カウンターがインスタンスごとに独立しているためです。公式の例では、クライアントIPあたり毎分400のしきい値で、2インスタンスが同じIPから270件と230件を受けても遮断されません。用途はログイン画面への総当たりなど異常な流量の抑制に限定し、APIの利用プランごとの呼び出し上限はAzure API Managementのクォータで管理するほうが設計に合います。

TLS終端と証明書：Key Vault連携とTLSポリシー

HTTPSリスナーでTLSを終端すると、証明書の管理をバックエンドの各サーバーからゲートウェイ1か所に集約できます。バックエンドまで暗号化を保つ場合は、バックエンド設定のプロトコルをHTTPSにしたエンドツーエンドTLSにします。このとき、バックエンド証明書の名前がホスト名と一致しないと502の原因になります。

TLSポリシーは、APIバージョン2023-02-01以降で作成したゲートウェイでは AppGwSslPolicy20220101 が既定で、最小TLS 1.2・最大TLS 1.3です。TLS 1.0と1.1のサポートは2025年8月31日に終了しているため、古いゲートウェイで旧ポリシーが残っていないか確認します。

サーバー証明書はAzure Key Vaultに置いて参照させる運用が一般的です。Key Vault連携はv2限定で、各インスタンスが4時間間隔でKey Vaultを確認します。自動更新するにはバージョンを含まないシークレット識別子を参照させ、新しい証明書バージョンを取得できるようにします。クライアント証明書で接続元を認証するmTLSもv2で設定できますが、Basicは非対応です。

構築手順：専用サブネットの設計からaz CLIでの作成まで

専用サブネットの推奨サイズと同居制限

Application Gatewayには専用サブネットが必要で、同じサブネットに置けるのはApplication Gatewayだけです。v1とv2を同じサブネットに混在させることもできません。v2は1インスタンスにつきプライベートIPを1つ使い、最大125インスタンスまで増えるため、公式のインフラストラクチャ構成ガイドは/24以上を強く推奨しています。計算は「インスタンス数の上限＋プライベートフロントエンドIP 1＋Azureの予約5」です。/24なら256から予約の5を引いた251アドレスを、同じサブネット内の複数ゲートウェイで分け合えます。オートスケールやメンテナンス時の更新でアドレスが一時的に多く必要になるので、最初から/24で切ります。

標準デプロイのNSG要件とUDR制約

ネットワーク分離を有効にしていない標準デプロイでサブネットにNSGを付ける場合、次の受信3項目と送信1項目を許可します。

送信のインターネット向け通信を拒否するルールは作れません。UDRにも制約があり、0.0.0.0/0を仮想アプライアンスへ向けるルートテーブルはサブネットに関連付けられません。ExpressRouteやVPNからBGPで0.0.0.0/0が広報されると強制トンネリングとして働き、管理プレーンの通信が壊れます。この場合はルートテーブルで「ゲートウェイのルート伝達」を無効にしてサブネットに関連付けます。

プライベートデプロイ（ネットワーク分離）で外れる制約

社内規程で「送信は全拒否」「0.0.0.0/0はファイアウォール経由」が決まっている環境では、プライベートデプロイを使います。サブスクリプションで機能 EnableApplicationGatewayNetworkIsolation を登録した後に作ったv2で、次の制約が外れます。ポータルの登録画面には「プレビュー」と表示されますが、Learnは一般提供で本番に使え、SLAの対象だと明記しています（Microsoft Learn「プライベートApplication Gatewayのデプロイ」）。

• NSG：GatewayManagerからの受信もInternet宛ての送信も不要になります。基盤側の必須ルールはAzureLoadBalancerからの受信許可です。送信の全拒否ルールも作れますが、クライアントからリスナーへの受信と、バックエンドなどへの必要な送信は別途許可します。
• UDR：0.0.0.0/0の次ホップを仮想アプライアンスにでき、ハブのAzure Firewall経由で外へ出す構成が組めます。
• フロントエンド：パブリックIPを持たない、プライベートIPだけの構成にできます。

代わりに注意点が3つあります。2025年5月5日以降、サブネットを Microsoft.Network/applicationGateways へ委任することが必須です。プライベートIPだけの構成ではインターネット宛ての送信ができないため、インターネット上のバックエンドや、プライベートエンドポイントもサービスエンドポイントも使わないKey Vault、インターネット上のCRL・OCSPに届けるにはNAT Gatewayか仮想アプライアンスが要ります。機能の登録前に作ったゲートウェイと同じサブネットでは、新しいゲートウェイでもNSGとルートテーブルの制御が使えません。既存のゲートウェイを作り直すか、別のサブネットに分けます。

az CLIでStandard_v2を作成するコマンド

Microsoft LearnのCLIクイックスタートのコマンドを、東日本リージョン向けにリソース名を置き換えたものです。この例はゲートウェイ作成部分のみで、バックエンド用サブネットやVMは作成しません。疎通確認には、vnet-appgw内の別サブネットにHTTPポート80で応答するVMを用意するか、到達可能な既存バックエンドを準備し、10.21.1.4と10.21.1.5を実際のIPへ置き換えます。

az group create --name rg-appgw --location japaneast

az network vnet create \
  --name vnet-appgw \
  --resource-group rg-appgw \
  --location japaneast \
  --address-prefix 10.21.0.0/16 \
  --subnet-name snet-appgw \
  --subnet-prefix 10.21.0.0/24

az network public-ip create \
  --resource-group rg-appgw \
  --name pip-appgw \
  --allocation-method Static \
  --sku Standard

az network application-gateway create \
  --name appgw-web \
  --location japaneast \
  --resource-group rg-appgw \
  --capacity 2 \
  --sku Standard_v2 \
  --public-ip-address pip-appgw \
  --vnet-name vnet-appgw \
  --subnet snet-appgw \
  --servers 10.21.1.4 10.21.1.5 \
  --priority 100

--sku は省略しないでください。az CLI 2.91.0のヘルプでは既定値が Standard_Medium（廃止済みのv1）のままで、指定できる値にBasicもありません。--priority はルーティング規則の優先度で、Standard_v2とWAF_v2で指定します。作成には最大30分かかり、バックエンドプール・ポート80のHTTP設定・リスナー・規則 rule1 が既定名で作られます。可用性ゾーンのあるリージョンでゾーンを指定しなければ、自動でゾーン冗長になります。

502 Bad Gateway（microsoft-azure-application-gateway/v2）の原因と切り分け

ブラウザに「502 Bad Gateway」と「microsoft-azure-application-gateway/v2」が並んで表示されたら、応答を返したのはバックエンドのWebサーバーではなく、v2のApplication Gatewayです。ゲートウェイがバックエンドから正しい応答を受け取れなかったことを意味します。

502エラーの主な原因と504になるタイムアウト

公式のトラブルシューティングが挙げる原因を、確認しやすい順に並べると次のとおりです。

1. NSG・UDR・カスタムDNS：ゲートウェイやバックエンドのサブネットで通信が遮断されている、UDRが通信をアプライアンスへ曲げている、カスタムDNSがバックエンドのFQDNを解決できない。
2. 既定の正常性プローブの失敗：プローブは30秒間隔・タイムアウト30秒で送られ、3回連続で失敗すると異常と判定されます。プロトコルとポートはバックエンド設定を継承し、Hostを指定しなければ 127.0.0.1、パスは「/」です。このHostとパスに応答できないバックエンドは失敗します。
3. カスタムプローブの設定誤り：パスやホスト名の誤り、正常と判定するステータスコードの範囲（既定は200〜399）を返さないURLの指定。v2のHTTPSプローブはホスト名をSNIとしても送るため、バックエンド証明書のSANと一致させます。
4. 要求タイムアウト超過：既定は20秒で、プライベートバックエンドでは1〜86,400秒、外部バックエンドでは1〜240秒の範囲で変更できます。v1は502を返していましたが、v2は別のバックエンドに再試行し、それも失敗すると504を返します。
5. バックエンドプールが空、または全台が異常：プールにサーバーが登録されていない、アプリが配置されていない、HTTPSバックエンドの証明書の期限切れや信頼されたルート証明書の不一致。

最初に見るのはポータルの「バックエンド正常性」です。ゲートウェイのサブネットにUDRがあると、正常性が「不明」と表示されログも取れないことがあります。要求タイムアウトを延ばすのは最後の手段で、原因がバックエンドのCPU不足や遅いクエリなら症状を隠すだけです。

アクセスログのErrorInfoで原因を絞るKQL

バックエンド正常性が「正常」なのに502が出るときは、アクセスログを見ます。診断設定で「アクセスログ」をLog Analyticsへ送り、送信先テーブルを「リソース固有」（既定）にすると、AGWAccessLogs テーブルに60秒ごとに記録されます。次のクエリで、502がどのプール・どのサーバー・どの理由で出ているかを集計できます。

AGWAccessLogs
| where TimeGenerated > ago(1h)
| where HttpStatus == 502
| summarize count() by BackendPoolName, ServerRouted, ServerStatus, ErrorInfo
| order by count_ desc

HttpStatus はゲートウェイがクライアントに返した値、ServerStatus はバックエンドが返した値です。HttpStatus が502で ServerStatus も502なら、バックエンド側のプロキシやアプリが502を返しています。ErrorInfo の値と原因の対応は次のとおりです（Microsoft Learn「Application Gatewayの監視データリファレンス」）。

特定のインスタンスだけで5xxが出ているかは、InstanceId 列でまとめると分かります。テーブルプランの選び方や保存コストはLog Analyticsのワークスペース設計とKQLを参照してください。

Application Gatewayを選ばないほうがよいケース

次の条件に当てはまるなら、別のサービスを選びます。

• 複数リージョンで冗長化する：単一リージョンのApplication Gatewayだけを入口にすると、そのリージョンが単一障害点になります。グローバルな入口にはFront Doorを選び、リージョンごとのApplication Gatewayはその背後に置きます。
• UDPを分散する：TCP/TLSプロキシはありますがUDPは扱えません。パススルー型のAzure Load Balancerが適しています。
• App ServiceやContainer Appsの単一アプリにWAFだけを付けたい：WAF_v2は割引を適用しない場合、固定料金だけで月約6万円です。インターネット公開のPaaSなら、Front DoorのWAFで足りるかを先に比較します。

逆に、1リージョンの仮想ネットワーク内に複数のWebアプリがあり、パスやホスト名で振り分けつつTLS終端とWAFを1か所にまとめたい場合は、Application Gatewayが最も素直な選択です。サブネット・NSG・ハブ経由の経路まで含めたAzureのネットワーク設計を外部に任せたい場合は、一創のインフラ構築（AWS・Google Cloud・Azure）で相談を受けています。

よくある質問

Azure Application Gatewayとは簡単に言うと何ですか？

Azureの仮想ネットワーク内のWebサーバーの前に置く、L7のロードバランサー兼リバースプロキシです。URLパスやホスト名で転送先を振り分け、TLSの終端と、WAF_v2では攻撃の検査も行います。範囲は1つのリージョンで、複数リージョンにまたがる振り分けはAzure Front Doorが担当します。

Application Gatewayの料金はいくらですか？

東日本のStandard_v2は固定料金が1時間0.29ドル（2026年10月26日の参考価格で月約33,353円）、容量ユニットが1時間0.008ドルです。最小インスタンス数2なら月約51,755円、WAF_v2は固定料金が1.8倍です。

Application Gateway v1はいつ終了しましたか？

v1（StandardとWAF）は2023年4月28日に廃止が告知され、2026年4月28日に廃止されました。サポートとSLAの対象外で、残っているv1は基盤ハードウェアの廃止に伴ってトラフィックが止まるおそれがあります。PowerShellの移行スクリプトで設定をv2にコピーし、トラフィックを切り替えてください。

Azure Front DoorとApplication Gatewayの違いは何ですか？

Front DoorはMicrosoftのエッジで動くグローバルなL7負荷分散とCDNで、複数リージョンのバックエンドへ振り分けます。Application Gatewayは1リージョンの仮想ネットワーク内で動き、プライベートなバックエンドへの振り分けや、TCP/TLSのプロキシ、mTLSを担います。グローバルに公開するアプリでは、Front Doorの背後にApplication Gatewayを置く併用構成もあります。

microsoft-azure-application-gateway/v2の502エラーはどういう意味ですか？

v2のApplication Gatewayが、バックエンドから有効な応答を受け取れなかったことを示します。主な原因はNSGやUDRによる遮断、正常性プローブの失敗、空のバックエンドプール、HTTPSバックエンドの証明書不一致です。ポータルの「バックエンド正常性」で異常の理由を確認し、正常なのに502が出るならアクセスログの ErrorInfo を見ます。

関連記事

• Azure Front Doorとは？CDN・グローバル負荷分散・WAFの仕組みとStandard／Premiumの違い・料金・採用判断を実装者目線で解説
• Azure Traffic Managerとは？DNSベース負荷分散の仕組みと6つのルーティング方式・Front Doorとの使い分けを実装目線で解説
• ロードバランサーとは？仕組み・種類・振り分け方式を実装目線で解説【2026年版】
• WAFとは？仕組み・ファイアウォール／IPS・IDSとの違いと企業の選び方を解説
• Azure Firewallの料金を円で試算｜Basic・Standard・Premiumの違いとSKUの選び方