2025.06.17 プラットフォーム

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の単価をもとに、構成要素と他の負荷分散サービスとの使い分け、東日本リージョンでの料金計算、専用サブネットとNSGの必須条件、502 Bad Gatewayの切り分けまでを整理します。

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

役割：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,700円かかり、最小インスタンス数2なら月約52,300円になります。
構築の前提：Application Gateway専用のサブネットが必要で、v2は/24が推奨です。ネットワーク分離を有効にしていない標準デプロイでは、NSGでGatewayManagerからのTCPポート65200〜65535を許可します。
502エラー：主な確認対象は、NSG・UDR・カスタムDNSによる到達不能や、正常性プローブの失敗です。まずバックエンド正常性の画面を確認します。

料金だけを知りたい場合は「料金の仕組み」、エラー対応中なら「502 Bad Gatewayの原因」の章から読めます。

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です。

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

ネットワークセキュリティでいう「アプリケーションゲートウェイ（アプリケーションレベルゲートウェイ）」は、通信をアプリケーションごとに中継して中身を検査するプロキシ型ファイアウォールの方式名で、パケットフィルタリング型と対比されます。Azure Application Gatewayは、HTTP(S)の負荷分散やTLS終端を提供するADC製品で、WAF_v2ではWebアプリケーションへの攻撃も検査します。社内ユーザーのWeb閲覧を制御するセキュアWebゲートウェイ（SWG）とは守る向きが逆で、外部から自社のWebアプリへ入る通信を守ります。

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

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

サービス	範囲	推奨トラフィック	方式
Application Gateway	リージョン	HTTP(S)・TCP・TLS	終端型プロキシ
Application Gateway for Containers	リージョン	HTTP(S)	Kubernetes向けL7
Azure Front Door	グローバル	HTTP(S)	エッジのL7・CDN
Azure Load Balancer	リージョン・グローバル	HTTP(S)以外	パススルー型L4
Traffic Manager	グローバル	HTTP(S)以外	DNSベース

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

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

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

項目	Basic（プレビュー）	Standard_v2	WAF_v2
SLA	99.9%	99.95%	99.95%
最大接続数/秒	200	62,500	－
リスナー・プール上限	5・5	100・100	100・100
mTLS・Private Link・AKS連携	非対応	対応	対応
WAF	なし	なし	あり

最大接続数はRSA 2048ビットのTLS証明書を使った場合の推定値で、WAF_v2の値は公式の比較表に載っていません。Basicはプレビュー登録が必要なうえSLAが下がるため、本番ではStandard_v2から検討するのが妥当です。

v1（Standard・WAF）は2026年4月28日に廃止済み

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

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

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

2026年9月15日にAzure Retail Prices APIで取得した、東日本（japaneast）の円建て参考単価は次のとおりです。

SKU	固定料金（1時間）	CU料金（1CU・1時間）	固定料金の月額（730時間）
Standard_v2	46.2028円	1.2746円	約33,728円
WAF_v2	83.165円	2.2942円	約60,710円
Basic（プレビュー）	3.8715円	1.2746円	約2,826円

掲載した円価格は、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で最小インスタンス数を2にすると、固定料金33,728円に20CU分の18,609円が加わり、月約52,337円です。同じ条件のWAF_v2は60,710円＋33,495円で月約94,206円になります。検証環境で最小インスタンス数を0にしても、固定料金の月約33,728円（WAF_v2は約60,710円）は残ります。使わない時間帯の課金を止めたい場合は、Azure CLIや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ポリシー」という独立したリソースに持たせてゲートウェイに関連付けます。WAFポリシーを関連付けられるSKUはWAF_v2だけです。マネージドルールセットは、2026年9月時点でDefault Rule Set（DRS）2.2が推奨されており、DRS 2.1やOWASP CRS 3.2のままのポリシーは更新対象です。

ゲートウェイの設定内に直接WAFを書く旧来の「WAF構成」は、2025年3月15日に新規作成が止まり、2027年3月15日に廃止されます。既存のWAF_v2はダウンタイムなしでWAFポリシーへ移行できるので、旧構成が残っているなら今のうちに移します。SQLインジェクションなどWAFが防ぐ攻撃の一般論はWAFの仕組みとファイアウォールとの違いで解説しています。

レート制限の数え方と「しきい値どおりに止まらない」注意点

レート制限はWAFポリシーのカスタムルールとして設定し、最新のWAFエンジン（既定ルールセットにCRS 3.2を選ぶ）が前提です。しきい値と適用条件を指定し、集計単位はクライアント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項目を許可します。

方向	ソース	宛先ポート	用途
受信	想定するクライアント	リスナーのポート（80・443など）	クライアント通信
受信	GatewayManager	65200〜65535（v2）	インフラ管理・正常性
受信	AzureLoadBalancer	すべて	Azureのプローブ
送信	すべて	Internet宛て・すべて	管理プレーン通信

送信のインターネット向け通信を拒否するルールは作れません。UDRにも制約があり、v2では0.0.0.0/0をネットワーク仮想アプライアンスやハブ仮想ネットワーク、オンプレミスへ向ける強制トンネリングはサポート外です。ExpressRouteやVPNゲートウェイから既定ルートが広報される環境では、ルートテーブルで「仮想ネットワークゲートウェイのルート伝達」を無効にしてサブネットに関連付けます。これらの制限は、ネットワーク分離を有効にしたプライベートデプロイでは緩和されます。

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

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

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

作成には最大30分かかり、バックエンドプール・ポート80のHTTP設定・リスナー・規則 rule1 が既定名で作られます。可用性ゾーンのあるリージョンでゾーンを指定しなければ、自動でゾーン冗長になります。

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

ブラウザに「502 Bad Gateway」と「microsoft-azure-application-gateway/v2」が並んで表示されたら、応答を返したのはバックエンドのWebサーバーではなく、v2のApplication Gatewayです。ゲートウェイがバックエンドから正しい応答を受け取れなかったことを意味します。公式のトラブルシューティングが挙げる原因を、確認しやすい順に並べると次のとおりです。

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

最初に見るのはポータルの「バックエンド正常性」です。全台が異常なら1〜3に加えて5の証明書やアプリ配置も確認します。正常なのに502が出る場合は、アクセスログでバックエンド接続やTLS、ホスト名、アプリの応答を調べます。v2の要求タイムアウトは通常504として切り分けます。ゲートウェイのサブネットにUDRがあると、正常性が「不明」と表示されログも取れないことがある点に注意してください。要求タイムアウトを延ばすのは最後の手段で、原因がバックエンドのCPU不足や遅いクエリなら症状を隠すだけです。

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

Application GatewayのStandard_v2は、掲載した参考単価で月730時間稼働すると固定料金だけで月3万円を超え、専用サブネットとNSGの設計も必要です。次の条件に当てはまるなら、別のサービスを選びます。

複数リージョンで冗長化する：単一リージョンのApplication Gatewayだけを入口にすると、そのリージョンが単一障害点になります。各リージョンにApplication Gatewayを配置し、グローバルな入口と組み合わせる構成は可能です。Front Doorを選びます。
UDPを分散する：TCP/TLSプロキシはありますがUDPは扱えません。パススルー型のAzure Load Balancerが適しています。
0.0.0.0/0を必ずファイアウォールへ強制トンネリングする社内規程がある：v2の標準デプロイではサポート外です。ルートテーブル制御がGAになっているプライベートデプロイ（ネットワーク分離）か、Azure Firewallを含む別の構成を検討します。
App ServiceやContainer Appsの単一アプリにWAFだけを付けたい：WAF_v2は、DDoS Network Protectionによる割引を適用せず、掲載した参考単価で月730時間稼働すると、固定料金だけで月約6万円になります。インターネット公開のPaaSなら、Front DoorのWAFで足りるかを先に比較します。

逆に、1リージョンの仮想ネットワーク内に複数のWebアプリがあり、パスやホスト名で振り分けつつTLS終端とWAFを1か所にまとめたい場合は、Application Gatewayが最も素直な選択です。

よくある質問

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

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

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

固定料金と容量ユニット料金の合計で、東日本リージョンのStandard_v2は固定料金が1時間46.2028円（月730時間で約33,728円）、1容量ユニットが1時間1.2746円です（2026年9月15日取得のAPIによる円換算の参考価格）。最小インスタンス数を2にすると20容量ユニット分が常に課金され、月約52,337円になります。WAF_v2は固定料金が約1.8倍です。

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

v1（StandardとWAF）は2023年4月28日に廃止が告知され、2026年4月28日に廃止されました。サポートとSLAの対象外で、Microsoftは残ったv1のデータパスを遮断してリソースを削除すると案内しています。PowerShellの移行スクリプトで設定をv2にコピーし、トラフィックを切り替えてください。

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

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