application gateway の概要を初心者向けに徹底解説！

AzureでWebアプリケーションを公開する際、必ずと言っていいほど名前が挙がるのが「Azure Application Gateway（アプリケーション ゲートウェイ）」です。

「Webサイトの負荷分散ができるサービス」ということは知っていても、

と悩んでいるエンジニアの方も多いのではないでしょうか。

Application Gatewayは、単にアクセスを振り分けるだけの「ロードバランサー」ではありません。URLパスに応じた高度なルーティング、WAFによるセキュリティ防御、さらにはクライアント証明書を用いた強固な認証（mTLS）までを1台でこなす、Webシステムの「万能な玄関口」です。

この記事では、Application Gatewayの基本概念から、具体的な機能、複雑に見える構成要素、他のサービスとの違い、そして気になる料金システムまで、図解を交えてわかりやすく徹底解説します！

この記事を読めば、Application Gatewayで「できること」が明確になり、自信を持ってWebシステムのインフラ設計・構築ができるようになります。

application gateway とは？

Application Gatewayとは、L7（アプリケーション層）のロードバランサーをベースとしながら、Webサイトを

『安全に（WAF/mTLS）』

『効率よく（SSLオフロード）』

『柔軟に（パスルーティング）』

公開するための機能をすべて詰め込んだ、Web専用の管理・制御リソースです。

Azure Application Gateway（アプリケーション ゲートウェイ）とは、Webアプリケーションへのトラフィック（HTTP/HTTPS通信）を管理・分散するための、高度なロードバランサーサービスです。

「L4」と「L7」の違いとは？2つのロードバランサーを徹底比較！

ロードバランサーにはネットワーク層で動くものとアプリケーション層で動くものの2種類が存在します。

これらの2つの違いについて簡潔に解説します。

階層	名称	役割を一言でいうと	代表的なプロトコルや機器
L7	アプリケーション層	人間が理解できる「データの中身」	HTTP, HTTPS, SSH, SMTP
L6	プレゼンテーション層	データの「表現形式（文字コード、暗号化）」	SSL/TLS, JPEG, ASCII
L5	セッション層	通信の「始まりから終わりまでの管理」	TLS（セッション管理機能）
L4	トランスポート層	データを「エラーなく正確に届ける制御」	TCP, UDP
L3	ネットワーク層	目的地までの「道案内（ルーティング）」	IP, ルーター
L2	データリンク層	隣り合う機器同士の「ローカルな通信」	Ethernet（イーサネット）, L2スイッチ
L1	物理層	データを「電気信号や光に変換する物理線」	LANケーブル, 光ファイバー

通常のネットワークロードバランサー（L4）

通常のネットワークロードバランサーは、OSI参照モデルの「レイヤー4（トランスポート層）」で動作します。

L4層のロードバランサーがチェックするのは、封筒の表面に書かれた情報だけ。

具体的には「送信元・宛先のIPアドレス」と「ポート番号」だけを見て、機械的にトラフィックを裏側のサーバーへ振り分けます。

アプリケーション層のロードバランサー（L7）

一方で、今回の主役であるAzure Application Gatewayなどは、最上層の「レイヤー7（アプリケーション層）」で動作します。

こちらは、通信の暗号を一度解除して、封筒の中にある手紙の本文（HTTP/HTTPSリクエストの中身）をしっかりと読み解いてから、どう処理するかを判断します。

ユーザーが使っているWebブラウザの言葉（HTTPプロトコル）を直接理解できるため、高度なルーティングが可能になります。

application gateway ができることは？

Application Gatewayは、一般的なロードバランサーとは異なり、HTTP/HTTPS通信の中身（L7層）をインテリジェントに識別できる点が最大の強みです。

Webサイトの公開や運用に欠かせない、application gatewayがもつ4つの主要機能を見ていきましょう。

1. L7層でのロードバランサーの役割・高度なルーティング

Application Gatewayの最も重要な機能とも言えるのが、通信の中身である「URLの文字列」を読み解いて、アクセス先を賢く振り分けるロードバランサーとしての機能です。

例えば、1つのWebシステムの中に「通常のホームページ画面」と「システム用のAPI」が同居しているケースを想像してみてください。

通常のロードバランサー（L4）では、URLの中身が読めないため、すべてのアクセスを同じサーバー群に均等に送るしかありませんでした。

しかし、Application Gatewayであれば、URLの「後ろにある文字列（パス）」を見て、裏側で自動的に交通整理ができます。

• example.com/web/*（画面へのアクセス）⇨ 通常のWebサーバーへ
• example.com/api/*（データ処理のアクセス）⇨ 高性能なAPI専用サーバーやコンテナへ

この機能によって「ユーザーから見える公開窓口（パブリックIPアドレスやドメイン）は完全に1つだけ」になります。

もしこの機能がない場合、画面用（web.example.com）とAPI用（api.example.com）で別々のロードバランサーやIPアドレスを用意しなければならず、インフラ費用もドメイン管理の手間も2倍になってしまいます。

2. マルチサイト（複数ドメイン）のホスティング

1台のApplication Gatewayだけで、複数の異なるWebサイト（ドメイン）をまとめてホスティングできます。

例えば、`atsite.com` と `btypetest.net` という全く別のドメインへのリクエストを同じゲートウェイで待ち受け、それぞれに対応する個別のバックエンドプールへと正確にルーティングします。

リソースを集約できるため、公開したいサイトや環境が増えても、インフラコストや管理の手間を大幅に削減できるのがメリットです。

3. クライアント証明書の利用（相互TLS / mTLS）

一般的な「サーバー証明書」だけでなく、接続してくる端末を厳格に認証する「クライアント証明書（相互TLS / mTLS）」を標準でサポートしています。

特定の許可した社内端末やパートナー企業のシステムだけ通信を許可させたいなど、閉域環境で絶大な効果を発揮します。

ゲートウェイの入り口で証明書による厳格な認証を行い、パスした安全な通信だけをバックエンドへ通すという、ゼロトラスト時代の高セキュリティなインフラ構築が可能です。

4. WAF（Web Application Firewall）でのアクセス制御

オプションで「WAF（Webアプリケーションファイアウォール）」の関連付けが可能です。

WAFの関連付けをすることで、Web特有のサイバー攻撃からアプリケーションを保護できます。

WAFの役割

• SQLインジェクションを検知、ブロック
• クロスサイトスクリプティング（XSS）を検知、ブロック
• 一般的な脆弱性を突いた攻撃を自動で検知、ブロック
• ジオフィルタリング （特定の国からのアクセスを拒否）
• ホワイトリスト化 （特定のIPアドレスのみを許可する）

要件に応じた柔軟なアクセス制御ルールをカスタム定義できます。

application gateway と似ているサービスの比較

Azureには、システムの負荷分散やトラフィック制御を行うサービスが複数存在します。そのため、「どれをどの場面で選べばいいのか」と迷ってしまうケースが少なくありません。

ここでは、特によく比較される「Azure Front Door」および「Azure ロードバランサー」との決定的な違いを、設計のポイントを交えて分かりやすく解説します。

比較項目	Azure ロードバランサー	Azure Application Gateway	Azure Front Door
動作レイヤー	L4	L7	L7
配置スコープ	VNet内	専用サブネット内	グローバル（エッジネットワーク）
通信の識別基準	IPアドレス、ポート番号	URLパス、ホスト名（ドメイン）	URLパス、ホスト名（ドメイン）
主な得意領域	DB接続、HTTP以外の高速な分散	単一リージョン内の高度なWeb制御	複数リージョン、CDN、高速化
WAF（セキュリティ）	なし	あり（WAF SKUで統合）	あり（エッジでの防御）

Front Doorとの違いは？

Application Gatewayが指定した「仮想ネットワーク内」に配置されるのに対し、Front Doorは世界中に分散されたMicrosoftのエッジネットワーク上で動作する「グローバル」なサービスです。

そのため、単一リージョン内のコンテナやWebアプリに対して、mTLS認証などの厳格なアクセス制御を行いたい場合はApplication Gatewayが適しています。

一方で、世界中からアクセスされるシステムで、CDNによるキャッシュ配信や複数リージョン間での高速なアクティブ/アクティブ構成を組みたい場合はFront Doorの出番となります。

Azure ロードバランサー との違いは？

Azure ロードバランサー（Azure Load Balancer）との最大の違いは、「L4とL7どちらの階層でアクセスを振り分けるか」です。

Application Gatewayは「レイヤー7（HTTP/HTTPS）」で動作するため、URLのパスやホスト名といった通信の中身を解析して高度なルーティングが行えます。

これに対し、Azure ロードバランサーは「レイヤー4（TCP/UDP）」で動作するネットワークレベルのロードバランサーです。通信の中身（URLなど）は一切見ず、送信元と宛先の「IPアドレス」と「ポート番号」だけをチェックして超高速にトラフィックを分散します。

Webサイトのような柔軟な制御やSSLオフロード、WAFの適用が必要ならApplication Gateway、データベース間の通信やHTTP以外の独自プロトコルをシンプルに捌くならAzure ロードバランサー、という明確な使い分けが可能です。

application gateway の構成要素

Application Gatewayは、いくつかの独立したコンポーネントが役割を分担しながら連携して動作しています。

トラフィックが入ってきてからバックエンドに到達するまでの流れに沿って、各構成要素の具体的な役割を見ていきましょう。

1. フロントエンド IPアドレス

「アクセスを受け付けるIPアドレス」です。

• インターネットに公開する「パブリックIP」、または内部ネットワーク（VNet）用の「プライベートIP」を設定します。

2. WAF (Web アプリケーション ファイアウォール)

「Web攻撃を防ぐセキュリティ機能」です。

• 通信の中身を検査し、SQLインジェクションなどの悪意のあるリクエストを検知・ブロックします。

3. リスナー

「通信の待ち受け設定」です。

• ポート番号（80や443）、プロトコル（HTTP/HTTPS）、ドメイン名を指定してアクセスを受け付けます。
• HTTPS通信の暗号化解除（SSLオフロード）もここで行います。

4. ルール

「通信の振り分け条件」です。

• 「どのアクセス（リスナー）」を「どのサーバー（バックエンド）」へ「どうやって（HTTP設定）」流すか、という3つを紐づけます。
• URLのパス（/api/ など）に応じた転送先の振り分けもここで定義します。

5. HTTP 設定

「バックエンドサーバーとの通信方法」です。

• Gatewayからバックエンドサーバーへ通信を送る際の、ポート番号やプロトコルを指定します。
• Cookieを使ったセッション維持（同じユーザーを同じサーバーへ送る設定）などもここで定義します。

6. バックエンド プール

「転送先となるサーバーのリスト」です。

• トラフィックの最終目的地となる宛先（Azure VM、App Service、オンプレミスサーバーのIPやFQDNなど）を登録するグループです。

7. 正常性プローブ

「バックエンドサーバーの死活監視機能」です。

応答がない異常なサーバーを自動的に転送先から除外し、正常なサーバーにだけアクセスを流します。

バックエンドサーバーへ定期的にテスト通信（/healthなどへのアクセス）を送ります。

application gateway のバックエンドに設定できるもの

Application Gatewayは、トラフィックの分散先となる「バックエンドプール」に対して、非常に柔軟なリソース指定が可能です。

Azureの標準的なサービスだけでなく、ネットワーク的に到達できれば外部の環境すらターゲットに設定できます。

具体的にどのようなリソースをバックエンドに組み込めるのか、詳しく見ていきましょう。

下記の画像は実際の設定画面です。

1. Azure App Service (Web Apps など)

「AzureのWebアプリホスティングサービス」

WebサイトやAPIを手軽に動かせる「App Service」を直接ターゲットにできます。

App Serviceの前にApplication Gateway（WAF）を配置することで、サイバー攻撃からWebアプリを守る「強固な盾」として機能させるのが定番の構成です。

2. 仮想マシン (VM) / 仮想マシンスケールセット (VMSS)

「Azure上の一般的な仮想サーバー」

一番オーソドックスな構成です。

Azureの管理画面から、同じネットワーク（VNet）内にあるサーバーをリストから選ぶだけで簡単に紐付けられます。

アクセス増減に合わせてサーバー台数が自動で増減する「VMSS」にも対応しています。

3. IPアドレス

「ネットワーク上の住所（IPアドレス）を直接指定」

Azureの特定のサービス名ではなく、「IPアドレス（例: 192.168.1.10）」を直接打ち込んで指定します。

これにより、以下のようなAzure外のシステムも転送先にできます。

• 社内ネットワークにあるオンプレミスサーバー（VPN等で接続済みの場合）
• AWSやGCPなど、他社クラウドで動いているサーバー
• AKS（Kubernetes）の内部IPアドレス

4. FQDN (完全修飾ドメイン名)

「ドメイン名（例: api.example.com）で指定」

IPアドレスではなく、ドメイン名で転送先を指定します。

外部のAPIやクラウドサービスなど、「裏側のIPアドレスが定期的に変わる可能性があるシステム」を転送先にしたい場合に活躍します。

名前解決（DNS）によって自動で新しいIPを追従してくれるため、通信が途切れません。

Azure内のサービス（App ServiceやVM）を簡単に選択できるだけでなく、IPアドレスやドメイン名さえ分かれば、基本的に「どこにあるどんなサーバーでも」柔軟に転送先に設定できるのが、Application Gatewayの大きな強みです。

application gateway の利用料金

Application Gatewayの料金システムは、複雑に見えますが、基本的には「基本料金」と「使った分だけ支払う従量課金（容量ユニット）」の2つの組み合わせで決まります。

現在主流である「v2（バージョン2）」の料金体系をベースに、Webサイトの運営者が押さえておくべきポイントを分かりやすく解説します。

固定料金（ゲートウェイ時間）

Application Gatewayを起動して配置しているだけで、1時間ごとに必ず発生する基本料金です。

例：1時間あたり約83円 × 730時間 ≒ 約60,590円

料金の詳細については公式ページから確認してください。

容量ユニット（従量課金）

実際に発生したトラフィック（通信量）や、処理した接続数、CPUの負荷などに応じて変動する従量課金部分です。

例：2ユニット × 約2.29円 × 730時間 ≒ 約3,343円

オートスケールの最小値を「2」に設定していると仮定して計算しています。トラフィックが極めて少ない時間帯であっても、最低2ユニット分の料金が常時発生します。一般的なサイトであれば、ベースのトラフィックはこの2ユニット枠にほぼ収まります。

データ送信料金

インターネット側へデータを送る際には、別途一般的な「データ転送（送信）料金」が加算されますが、受信（データセンターに入ってくる通信）は無料となっています。

例：500 GB × 約14円/GB ≒ 約7,000円

Application Gatewayからインターネット側へ出ていくデータ（ユーザーへ返すWebページのデータなど）に対する課金です。月間100GB〜200GB程度であれば数百円レベルですが、少し多めに「月間 500 GB」の送信があると仮定します。

固定料金、容量ユニット、データ送信料金 の合計で約7万円かかる計算となります。

まとめ

今回の記事では、Azure Application Gatewayの基本概念から高度なルーティング機能、複雑に見える構成要素、他のロードバランサーとの違いや気になる料金システムまでを徹底的に解説しました。

実はApplication Gatewayは、アクセスが急増した際にサーバーを自動で増やす「オートスケール」だけでなく、エラー時に独自の「カスタムエラーページ（502や403画面）」を表示させる機能も備わっています。

インフラの裏側でメンテナンスや予期せぬトラブルが起きた際も、ユーザーに不骨なシステム画面を見せずに済むため、企業のWebサイトとしての信頼性を保つのに非常に役立ちます。

難しそうに見えるコンポーネントの繋がりも、実際にポータル画面で一度手を動かして構築してみることでさらに理解が深まります。

まずは検証環境などを使い、基本料金を抑えたプランで「リスナー」「ルール」「バックエンド」を紐付ける簡単な接続テストから試してみてください。