「Azureの構成図でよく見かけるApplication Gatewayって、結局なにをしてくれるの？」
——Azureを学習していると、ロードバランサーの仲間として Application Gateway（アプリケーションゲートウェイ、通称AGW） が必ず出てきます。ですが「Load Balancerとの違いは？」「WAFって何が違うの？」と聞かれると、うまく説明できずに止まってしまう方は多いはずです。
名前は聞くけど、Load BalancerやWAFと何が違うのか、モヤっとしたまま先に進んでる…
この記事では、Application Gatewayの「概要」だけに絞って、次の4つを順番に整理します。読み終えたときに、この4つを自分の言葉で説明できるようになることをゴールにしています。
- Application Gatewayが何か（L7ロードバランサー／リバースプロキシ）を説明できる
- L4（Load Balancer）との違いを理解している
- SKU（Standard_v2 / WAF_v2）の違いを理解している
- 主要コンポーネント（フロントエンドIP・リスナー・ルール・バックエンドプール・HTTP設定）の関係を理解している
作成手順やWAFの細かいルール設定は別記事に譲り、ここでは「そもそも何者なのか」という土台を固めます。各セクションの最後に「これが説明できればOK」という自己チェックの目安を置いていますので、学習の到達度確認にも使ってください。
Application Gatewayとは？（L7ロードバランサー／リバースプロキシ）
Azure Application Gatewayとは、HTTP/HTTPSのWebトラフィックを、アプリケーション層（OSI参照モデルのL7）で振り分けるロードバランサー兼リバースプロキシです。
ポイントは「L7（アプリケーション層）で動く」という点です。一般的なロードバランサーはIPアドレスとポート番号を見て振り分けますが、Application GatewayはそこからさらにHTTPリクエストの中身、つまり URLのパス や ホスト名（Hostヘッダー） まで見て、どのサーバーへ流すかを判断できます。
身近な例で言うと、大きな受付カウンター をイメージすると分かりやすいでしょう。訪問者（リクエスト）が来たときに、単に空いている窓口へ流すのではなく、「用件（URL）」を聞いてから適切な担当部署（サーバー）へ案内してくれる——それがApplication Gatewayの役割です。
たとえば、次のようなパスベースの振り分けができます。
/imagesへのリクエスト → 画像配信に最適化したサーバー群へ/videoへのリクエスト → 動画配信に最適化したサーバー群へcontoso.comとfabrikam.com→ ホスト名ごとに別々のサーバー群へ（マルチサイト）
また、リバースプロキシ でもある、というのも重要な性質です。リバースプロキシとは、クライアントとバックエンドサーバーの「間」に立って、クライアントからの唯一の接続先（窓口）になる仕組みです。クライアントはApplication GatewayのIPアドレスにアクセスし、実際にどのサーバーが処理しているかは意識しません。
この「間に立つ」位置にいるおかげで、Application Gatewayは以下のような付加機能も提供できます。
- SSL/TLS終端（暗号化・復号をAGW側で肩代わりし、バックエンドの負荷を軽くする）
- URLパス／ホスト名によるルーティング
- HTTP → HTTPSへのリダイレクト、ヘッダー／URLの書き換え
- オートスケール・ゾーン冗長、そして後述する WAF（Webアプリケーションファイアウォール） との統合
【ここが説明できればOK①】
「Application Gatewayは、HTTP/HTTPSのL7でURLパスやホスト名に基づいてルーティングするリバースプロキシである」——これを自分の言葉で言えれば、1つ目のチェックはクリアです。
L4（Load Balancer）との違い
Application Gatewayを理解するうえで、一番つまずきやすいのが Azure Load Balancer との違い です。どちらも「トラフィックを分散する」役割は同じですが、見ている情報の層（レイヤー）が違います。
- Azure Load Balancer：L4（トランスポート層） で動作。IPアドレスとポート番号を見て振り分ける。中身（HTTP）は見ない。
- Application Gateway：L7（アプリケーション層） で動作。URLパス・ホスト名・ヘッダーなどHTTPの中身を見て振り分ける。
例え話にすると、こうなります。
- L4のLoad Balancer＝郵便の仕分け係。封筒の「宛先住所（IPとポート）」だけを見て、中身は開けずに次の集配所へ流す。速くて効率的だが、中身によって出し分けはできない。
- L7のApplication Gateway＝封筒を開けて内容を読む担当者。「この用件は経理へ、この用件は総務へ」と、中身（URLやヘッダー）を見て賢く振り分けられる。
「中身を見ない＝L4」「中身を見る＝L7」。この一言で覚えると忘れないよ！
どちらが優れているという話ではなく、用途が違うという点が大切です。TCP/UDPレベルで高速に分散したいならLoad Balancer、URLベースの振り分けやSSL終端・WAFといったWeb向けの高度な制御がしたいならApplication Gateway、という使い分けになります。実際の構成では、この2つを組み合わせて使うことも珍しくありません。
なお、Azureには他にも Traffic Manager（DNSベースのグローバル振り分け）や Front Door（グローバルなL7ロードバランサー＋CDN）といったサービスもありますが、まずは「L4＝Load Balancer / L7（リージョン内）＝Application Gateway」という対比を軸に押さえておけば十分です。
【ここが説明できればOK②】
「Load BalancerはL4でIP／ポートを見て分散、Application GatewayはL7でURLやヘッダーを見て分散する」——この違いを言えれば、2つ目のチェックはクリアです。
SKU（Standard_v2 / WAF_v2）の違い
Application Gatewayを作成するときには SKU（stock keeping unit＝製品の種類） を選びます。現在の主流は v2世代 で、選択肢は大きく次の2つです。
- Standard_v2：ロードバランサー／リバースプロキシとしての基本機能一式（L7ルーティング、SSL終端、オートスケール、ゾーン冗長など）を備えたSKU。
- WAF_v2：Standard_v2の機能をすべて含んだうえに、さらにWAF（Webアプリケーションファイアウォール）による防御が加わったSKU。
つまり両者の関係は「WAF_v2 ＝ Standard_v2 ＋ WAF」とイメージすると分かりやすいです。ベースの機能は同じで、WAF_v2はセキュリティ機能が上乗せされた上位版という位置づけです。
ここで加わる WAF は、OWASP（オワスプ）のコアルールセット をベースに、SQLインジェクションやクロスサイトスクリプティング（XSS）といった、よく知られたWeb攻撃からアプリケーションを守る仕組みです。OWASPは「Webアプリのよくある脆弱性と対策」をまとめている団体で、そのルールに沿って不正なリクエストを検知・ブロックしてくれます。
- Web公開するアプリを攻撃から守りたいなら → WAF_v2
- 内部向けなどでWAFが不要、コストを抑えたい → Standard_v2
WAFの具体的なルール設定（検知モード／防御モードの切り替えや除外ルールなど）は奥が深いため、詳しくは別記事で解説します。ここでは「WAF_v2はStandard_v2にOWASPベースのWAF防御が加わったもの」という関係だけ押さえておけばOKです。
【ここが説明できればOK③】
「WAF_v2は、Standard_v2の機能にOWASPベースのWAF防御が加わったSKUである」——これを説明できれば、3つ目のチェックはクリアです。
主要コンポーネントの関係（フロントエンドIP→リスナー→ルール→バックエンドプール／HTTP設定）
最後に、Application Gatewayが実際にどうやってリクエストを処理しているのか、主要コンポーネントの関係で見ていきましょう。ここが理解できると、後の作成手順が一気に腑に落ちます。
登場人物（コンポーネント）は次の5つ＋αです。それぞれの役割を先に押さえます。
それぞれの役割
- フロントエンドIP（Frontend IP）：Application Gatewayの「玄関」となるIPアドレス。パブリックIP／プライベートIP、またはその両方を持てる。クライアントはここ宛にアクセスする。
- リスナー（Listener）：受付窓口。特定の プロトコル（HTTP/HTTPS）・ポート・ホスト名・IP の組み合わせで着信リクエストを待ち受ける。条件が一致したリクエストだけを受け付ける。
- ルーティングルール（Request routing rule）：交通整理役。「リスナー」「バックエンドプール」「HTTP設定」の3つを結びつける、いわば司令塔。リスナーが受けたリクエストを、どのバックエンドへ・どの設定で流すかを決める。
- バックエンドプール（Backend pool）：実際に処理する宛先サーバーの集まり。VM・仮想マシンスケールセット・App Service・IP／FQDN指定のサーバーなどをまとめて登録する。
- HTTP設定（HTTP settings）：バックエンドへの「渡し方」の設定。バックエンドと通信するときのポート番号・プロトコル（HTTP/HTTPS）、Cookieベースのセッション維持、後述の正常性プローブの紐づけなどを定義する。
- （＋）正常性プローブ（Health probe）：バックエンドの健康診断。各サーバーが正常かを定期的にチェックし、異常なサーバーには振り分けない。
リクエストが流れる順番（図解）
これらがどうつながるのか、クライアントのリクエストが到着してからバックエンドに届くまでの流れを図にすると、次のようになります。
クライアント（ブラウザ等）
│ ① https://example.com/images へアクセス
▼
┌───────────────────────────────────────────────┐
│ Application Gateway │
│ │
│ 【フロントエンドIP】 ← 玄関（例: パブリックIP） │
│ │ ② │
│ ▼ │
│ 【リスナー】 ← プロトコル/ポート/ホスト名で受付 │
│ │ ③ 条件が一致したら │
│ ▼ │
│ 【ルーティングルール】 ← 3つを束ねる司令塔 │
│ ├─④ どのバックエンドへ？→【バックエンドプール】│
│ └─⑤ どう渡す？ →【HTTP設定】 │
│ │ │
└────────────────────┼───────────────────────────┘
▼ ⑥
バックエンドサーバー群
（VM / VMSS / App Service など）
▲ 正常性プローブが健康チェック言葉でたどると、こうなります。
- クライアントが フロントエンドIP 宛にリクエストを送る。
- そのIPに紐づく リスナー が、プロトコル・ポート・ホスト名の条件でリクエストを受け付ける。
- リスナーに結びついた ルーティングルール が発動し、URLパスなどを見て振り分け先を決定する。
- ルールが指定する バックエンドプール（宛先サーバー群）へ、
- 同じくルールが指定する HTTP設定（ポート・プロトコルなどの渡し方）に従って転送される。
- 裏では 正常性プローブ が各サーバーを監視し、異常なサーバーは自動的に振り分け対象から外れる。
ここで一番の要は、「ルーティングルールがリスナー・バックエンドプール・HTTP設定の3つを束ねている」という点です。リスナーが「入口」、バックエンドプールが「出口の宛先」、HTTP設定が「渡し方」、そしてルールがそれらを1本の経路として結びつける——この関係が頭に入れば、Application Gatewayの設定画面で迷子になりません。
【ここが説明できればOK④】
「フロントエンドIP → リスナー → ルール → バックエンドプール／HTTP設定、という流れを図示して説明できる」——ここまで言えれば、4つ目のチェックはクリアです。
まとめ
今回のポイントを振り返りましょう。この4つを自分の言葉で説明できれば、Application Gatewayの「概要」はバッチリです。
- Application Gateway は、HTTP/HTTPSをL7（アプリケーション層）で扱い、URLパスやホスト名で振り分けるリバースプロキシ型のロードバランサー
- L4のLoad Balancer はIP／ポートで分散、L7のApplication Gateway はURL／ヘッダーの中身を見て分散する（見る層が違う）
- SKUは Standard_v2 と WAF_v2。WAF_v2 ＝ Standard_v2 ＋ OWASPベースのWAF防御
- 主要コンポーネントは フロントエンドIP → リスナー → ルール → バックエンドプール／HTTP設定 の流れ。ルールが3つを束ねる司令塔
概要がつかめたら、次は実際に Application Gatewayを作成する手順 や、WAFの詳しい設定 に進んでいきましょう。手を動かすと、今回整理したコンポーネントの関係が一気に「腑に落ちる」はずです。
あわせて読みたい
- Application Gatewayの作成手順（リスナー・ルール・書き換えの設定）※別記事で解説予定
- WAF（Webアプリケーションファイアウォール）の仕組みとルール設定 ※別記事で解説予定
- Azure VNetとサブネットの基礎（Application Gatewayを配置するネットワークの土台）
