Azure Application Gatewayとは？その仕組みや機能、料金体系を徹底解説

Microsoft Azure上でWebアプリケーションを運用する際、アクセス集中への負荷分散とセキュリティ対策は避けて通れない課題です。Azure Application Gatewayは、レイヤー7（アプリケーション層）で動作するロードバランサーとして、URLパスやホスト名に基づく高度なルーティング、WAFによるセキュリティ保護、SSLオフロードによるパフォーマンス向上を統合的に提供します。


本記事では、Application Gatewayの基本機能からSKU選定、料金体系、V1廃止（2026年4月）に伴う移行対応、次世代のApplication Gateway for Containersまで、体系的に解説します。

Azure Application Gatewayとは（2026年最新ガイド）

Azure Application Gatewayは、Microsoft Azureが提供するレイヤー7（アプリケーション層）のロードバランサーです。通常のロードバランサーがネットワークレベルでトラフィックを分散するのに対し、Application GatewayはHTTPリクエストの内容（URLパス、ホスト名、HTTPヘッダーなど）を理解した上で、最適なバックエンドサーバーにトラフィックを振り分けます。Azure Load Balancerがレイヤー4で動作するのに対し、Application Gatewayはアプリケーション層の高度な制御が可能です。

AzureApplicationGatewayイメージ図

以下の表で、Azure Application Gatewayの基本情報を整理しました。この表を確認した上で、次のセクションで2026年の最新動向と各機能の詳細を紹介します。

項目	内容
サービス名	Azure Application Gateway
提供元	Microsoft Azure
動作レイヤー	レイヤー7（アプリケーション層）
主な機能	負荷分散 / URLルーティング / SSLオフロード / WAF
SKU	Basic（プレビュー）/ Standard V2 / WAF V2
料金体系	従量課金制（ゲートウェイ時間＋容量ユニット）
2026年の注目変更	V1廃止（4/28）/ AGC GA / TLS 1.0-1.1廃止済み

この表が示すように、Application Gatewayは単純な負荷分散にとどまらず、WAFによるセキュリティ保護やSSLオフロードによるパフォーマンス向上まで統合的にカバーするサービスです。2026年はV1廃止と次世代サービスの登場により、アーキテクチャの見直しが求められる転換期となっています。

V1廃止とApplication Gateway for Containersの登場

2026年のApplication Gateway周辺では、3つの重要な変更が進行しています。インフラ設計に直接影響するため、早期の対応計画が不可欠です。

第一に、Application Gateway V1が2026年4月28日に廃止されます。V1を利用中の環境は、廃止日までにV2への移行を完了する必要があります。V2はV1と比較して、自動スケーリング、ゾーン冗長、静的VIP、WAF統合など大幅な機能強化が施されており、移行によって運用品質の向上も期待できます。V2はAzure Resource Managerモデルで管理されるため、リソースグループ単位の一元管理やARMテンプレート/Bicepによるデプロイ自動化にも対応しています。

第二に、TLS 1.0およびTLS 1.1のサポートが2025年8月31日に廃止されました。Application GatewayのリスナーでTLS 1.2以上を使用していない場合、通信が拒否されるため、証明書設定と最小TLSバージョンの確認が必要です。

第三に、Application Gateway for Containers（AGC）が次世代サービスとしてGAされました。AGCはKubernetes Gateway API（Ingress APIの後継）に対応し、Envoyベースのデータプレーンによるリアルタイムに近い設定反映を実現します。1,400以上のバックエンドPodと100以上のリスナーをサポートし、AKSとのネイティブ統合やWAF対応も備えています。コンテナ化されたワークロードを運用する企業にとって、AGCはAzure Front Doorと並ぶ重要な選択肢です。

主要機能とアーキテクチャ

Azure Application Gatewayは、リクエストの受信からバックエンドへの転送まで、リスナー・ルール・バックエンドプールの3つの構成要素で処理を行います。以下の表で、Application Gatewayが提供する主要機能を整理しました。

AzureApplicationGatewayの動作イメージ

機能	説明	実務的な効果
負荷分散	ラウンドロビン・最小接続数でトラフィック分散	サーバー過負荷の防止とレスポンス安定化
URLパスベースルーティング	URLパス（/images、/apiなど）に応じた振り分け	コンテンツ種別ごとの最適なサーバー割当
ホスト名ベースルーティング	ホスト名（example1.com等）ごとの振り分け	1つのゲートウェイで複数ドメイン管理
SSLオフロード	SSL/TLS暗号化・復号化をゲートウェイ側で処理	バックエンドサーバーの負荷軽減
WAF	SQLインジェクション・XSS等の攻撃からの保護	アプリケーション層のセキュリティ強化
自動スケーリング（V2）	トラフィック変動に応じたインスタンス自動調整	ピーク時の安定性とコスト最適化

この表から分かるのは、Application Gatewayがルーティング・パフォーマンス・セキュリティの3つの領域を1つのサービスで統合している点です。特にWAFとSSLオフロードの組み合わせにより、Azure Firewallとは異なるアプリケーション層に特化したセキュリティ対策を提供します。

Azure Application Gatewayの機能

Application Gatewayのアーキテクチャは、3つの構成要素で成り立っています。リスナーはクライアントからのリクエストを特定のポート・プロトコル（HTTP/HTTPS）で待ち受け、SSL証明書の設定にも対応します。ルールはリスナーで受信したリクエストを、URLパスやホスト名、HTTPヘッダーの内容に基づいて適切なバックエンドに転送する条件を定義します。バックエンドプールは実際にリクエストを処理するサーバー群（仮想マシン、App Service、AKSなど）の集合で、ここに負荷が均等に分散されます。

AzureApplicationGatewayロードバランサー機能イメージ

URLルーティング・SSLオフロード・WAFの実践

URLパスベースルーティングは、Application Gatewayの最も活用頻度の高い機能です。例えば、/imagesへのリクエストは画像専用サーバーに、/apiへのリクエストはAPIサーバーに振り分けることで、各バックエンドのリソースを最適に活用できます。ホスト名ベースルーティングと組み合わせれば、example1.comとexample2.comで異なるバックエンドプールを使い分ける構成も1つのゲートウェイで実現可能です。

SSLオフロードは、SSL/TLSの暗号化・復号化処理をバックエンドサーバーではなくApplication Gateway側で行う機能です。バックエンドサーバーの計算リソースを暗号化処理から解放でき、特にHTTPSトラフィックが大量に発生する環境ではパフォーマンスに顕著な改善が見られます。TLS 1.2以上が必須となった現在、証明書管理をAzure Key Vaultと連携させることで、証明書の自動更新と安全な管理を実現できます。

WAF（Web Application Firewall）は、OWASP Core Rule Setに基づいてSQLインジェクション、クロスサイトスクリプティング（XSS）、リモートコマンド実行などの攻撃パターンを検出・ブロックします。V2ではWAFがApplication Gatewayに直接統合されており、カスタムルールの設定やBot保護機能も利用可能です。セキュリティ要件の高いWebアプリケーションでは、WAF SKUの選択が推奨されます。

SKU選定と料金体系

Azure Application Gateway V2には、Basic（プレビュー）、Standard V2、WAF V2の3つのSKUが用意されています。以下の表で、各SKUの違いを比較しました。

機能	Basic SKU（プレビュー）	Standard V2	WAF V2
主な用途	小規模・低トラフィック環境	中〜大規模Webアプリ	セキュリティ重視のWebアプリ
負荷分散	基本的なレイヤー7負荷分散	URLベース・ホスト名ベースルーティング	URLベース・ホスト名ベースルーティング
自動スケーリング	非対応	対応	対応
可用性ゾーン	非対応	対応	対応
WAF	非対応	非対応	対応（カスタムルール・Bot保護）
静的VIP	非対応	対応	対応
料金目安（2026年3月時点）	低コスト	$0.246/ゲートウェイ時間	$0.443/ゲートウェイ時間

実務で選ぶ際のポイントは、トラフィック量とセキュリティ要件のバランスです。Basic SKUは現在プレビュー段階であり、本番ワークロードにはStandard V2またはWAF V2が推奨されます。WAF V2はStandard V2の約80%増のコストが発生しますが、WAFポリシーとルールの利用料は含まれているため、別途WAFサービスを契約する必要はありません。

V2の料金体系は従量課金制で、ゲートウェイ時間（固定費）と容量ユニット（CU）料金（変動費）の2つで構成されます。容量ユニットは処理するトラフィック量・接続数・計算量に基づいて計算され、自動スケーリングにより負荷に応じて最適なCU数が自動調整されます。Azure料金体系の詳細と合わせて、Azure Pricing Calculatorでの事前見積もりが推奨されます。

Azureサービス連携と構築手順

Application Gatewayは、Azure VNet上の専用サブネットにデプロイされ、さまざまなAzureサービスと連携して動作します。Azure Kubernetes Service（AKS）との連携では、コンテナ化されたアプリケーションのトラフィックをApplication Gateway Ingress Controller（AGIC）経由で管理できます。Azure Web AppsやAzure Container Appsとの連携では、PaaSサービスのバックエンドに対する負荷分散とWAF保護を提供します。

構築手順は、Azure Portalから以下の流れで進めます。まずAzureアカウント、サブスクリプション、リソースグループ、VNet（専用サブネット含む）、パブリックIPアドレスを事前に準備します。

Azureポータルの「リソースの作成」から「Application Gateway」を検索し、選択します。

ApplicationGateway選択画面

基本設定画面でSKU（Standard V2またはWAF V2）、リージョン、VNet、サブネットを指定します。

ApplicationGateway設定画面

フロントエンドIPの構成方法を選択し、パブリックIPアドレスを割り当てます。

フロントエンド画面

バックエンドプールにトラフィック転送先のサーバー群（仮想マシン、App Service等）を追加します。

バックエンドプール画面

ルールの設定で、リスナー、ルーティングルール、バックエンドプールを関連付けます。必要に応じてURLパスベースやホスト名ベースのルーティングルールを追加できます。

ルールの設定画面

ルーティングルールの追加画面

入力内容を確認し、「確認および作成」から「作成」をクリックするとデプロイが開始されます。

導入時の注意点と運用ガイド

Azure Application Gatewayを効果的に運用するには、技術的な設計だけでなく、移行計画やセキュリティ設定の最適化も重要です。以下の表で、導入時に注意すべき5つのポイントを整理しました。

注意点	詳細	対策
V1廃止対応	2026年4月28日にV1がサービス終了	V2への移行計画を策定し、早期にテスト環境で検証
TLSバージョン	TLS 1.0/1.1は廃止済み	リスナーの最小TLSバージョンを1.2以上に設定
サブネット設計	Application Gateway専用サブネットが必要	/24以上のサブネットを確保し、他リソースと共有しない
WAF設定	デフォルトルールだけでは不十分な場合がある	カスタムルールとBot保護機能を業務要件に応じて追加
コスト管理	容量ユニットが予想以上に増加するリスク	最小・最大インスタンス数の設定とアラートによる監視

特に差が出るのがV1廃止への対応状況です。2026年4月28日を過ぎるとV1インスタンスは利用できなくなるため、移行未着手の場合はV2への移行を最優先で進める必要があります。V2への移行時には、静的VIPの変更、WAFポリシーの再設定、バックエンドヘルスプローブの調整が必要になるケースがあるため、テスト環境での事前検証が不可欠です。

Azure Monitorとの連携による監視体制の構築も運用上の重要なポイントです。Application Gatewayのメトリクス（応答時間、失敗リクエスト数、バックエンドヘルス状態など）をリアルタイムで監視し、閾値を超えた場合にアラートを発報する設定を推奨します。

Azure Monitorイメージ

監視設定と段階的導入ステップ

診断ログを有効化することで、Application Gatewayの詳細な動作記録を取得できます。特定のリクエストの失敗原因やセキュリティイベントの検出に役立ち、WAFログと組み合わせれば攻撃パターンの分析も可能です。Azure Log Analyticsにログを送信すれば、KQLクエリによる高度な分析やカスタムダッシュボードの構築もできます。

Application Gatewayの導入は、以下の3ステップで段階的に進めることが推奨されます。

• Step 1 要件定義とSKU選定（1〜2週間）
  トラフィック量、セキュリティ要件、バックエンドの構成（VM/App Service/AKS）を整理し、Standard V2またはWAF V2のいずれかを選定します。コンテナワークロード中心の場合は、Application Gateway for Containers（AGC）も候補に含めます。
  
  

• Step 2 テスト環境での構築・検証（2〜4週間）
  テスト用VNetにApplication Gatewayをデプロイし、リスナー・ルール・バックエンドプールの設定を検証します。WAF SKUの場合は、カスタムルールとBot保護の設定を業務要件に合わせて調整します。V1からの移行の場合、既存ルールの再現と動作確認をこの段階で完了させます。
  
  

• Step 3 本番環境への展開と監視設定（1〜2ヶ月）
  テスト結果を基に本番環境へデプロイし、Azure Monitorによるメトリクス監視とアラート設定、診断ログの有効化を行います。可用性ゾーンをまたいだ展開で高可用性を確保し、定期的なWAFルールの更新とログ分析で継続的なセキュリティ強化を図ります。
  
  

Azureの始め方ガイドも参考にしながら、まずは要件整理とSKU選定から着手することが第一歩です。

まとめ

本記事では、Azure Application Gatewayの基本機能から2026年の最新動向まで、体系的に解説しました。

Application Gatewayは、レイヤー7のロードバランサーとして、URLパス・ホスト名ベースのルーティング、SSLオフロード、WAFによるセキュリティ保護を1つのサービスで提供します。2026年はV1の4月廃止、TLS 1.0/1.1の廃止、次世代のApplication Gateway for Containers（AGC）のGA済みという3つの大きな変更が進行しており、既存環境の見直しと移行計画の策定が急務です。

SKU選定ではトラフィック量とセキュリティ要件に応じてStandard V2またはWAF V2を選択し、Azure MonitorとWAFログによる継続的な監視体制を構築することで、Webアプリケーションの安定稼働とセキュリティ強化を両立できます。