Azure Application Gatewayの概要から作成手順、動作確認まで
Azure Application Gateway(アプリケーションゲートウェイ)の作成手順や概要について纏めてみました。
インターネットからHTTPを受信する基本構成で作成しブラウザでアクセス確認しています。
※2022年7月にv2版に記事を更新しました。
Azure Application Gateway(アプリケーションゲートウェイ)はどういうサービス
Azureで提供される負荷分散サービスの1つ
アプリケーションゲートウェイは(L7(アプリケーションレイヤ))でサーバー負荷分散を行うサービスです。
同じような負荷分散サービスとしてはAzure ロードバランサー(L4(OSIレイヤー))があります。
Azure ロードバランサーと機能面の一番の違いは、アプリケーションゲートウェイがWebアプリケーション(HTTP(S))に対するトラフィックに特化している事があります。
-
- URIパスに基づいた負荷分散等を行う事が出来る(バックエンドでパスベースの規則を選択)
- ホスト名またはドメイン名に基づくルーティングが可能
- SSLの終端が出来る
- Web Application Firewall(WAF)が利用可能
v1とv2がある
アプリケーションゲートウェイにはv1とv2があります。
Azure Application Gateway v2 とは
v1、v2の違いについてはこちらに記載があります。
Azure Application Gateway v2 とは(v1 SKU と v2 SKU の機能比較)
基本的な負荷分散的な機能面では大きな差異はありません。
v2ではゾーン冗長と言った可用性、静的IPのサポート、AKSのイングレスコントローラーと言った機能が使えます。
※公式ブログを見るとv2が強く推奨されており、将来的にはv1は廃止されていく模様です。
新しい Azure Application Gateway V2 の利用方法
Web Application Firewall(WAF)が使える
アプリケーションゲートウェイではWeb Application Firewall(WAF)を使う事が出来ます。
Web Application Firewall(WAF)はv1、v2ともに使えます。
v2ではカスタムWAFが使えます。
Azure Application Gateway 上の Azure Web アプリケーション ファイアウォールとは
Application Gateway 用の Web アプリケーション ファイアウォール ポリシーの作成
SKUは4パターン
アプリケーションゲートウェイとWAFの組み合わせで4パターンあります。
アプリケーションゲートウェイとWeb Application Firewall(WAF)両方に対して課金が発生します。
SKU | APGW | WAF |
Standard v1 | v1(S,M,L)(インスタンス数) | × |
WAF | v1(S,M,L)(インスタンス数) | 〇 |
Standard v2 | v2(インスタンス数) | × |
WAF v2 | v2(インスタンス数) | 〇(カスタムWAF) |
WAFについてはこちら。
Azure Application Gateway(アプリケーションゲートウェイ)の構成要素
アプリケーションゲートウェイは複数の要素で構成されます。
フロントエンドIPアドレス
Application Gateway のフロントエンド IP アドレスの構成
アプリケーションゲートウェイが受信するIPアドレスになります。
パブリック IP アドレス、プライベート IP アドレスがあります。(v2はパブリックIPアドレスが必須)
パブリックIPアドレスの場合はインターネットに公開するアドレスになります。
※リスナーと関連付けられる事でアプリケーションゲートウェイが受信するIPアドレスとなります。
フロントエンドIPアドレス | |
パブリックとプライベートがあります。 リスナーと関連付けて利用します。 |
![]() |
リスナー
リスナーはアプリケーションゲートウェイがアクセスを受け付ける為の設定になります。
プロトコル(HTTPもしくはHTTPS)、ポート、ホスト、IP アドレスの組み合わせで設定します。
マルチドメインやSSLオフロード設定もリスナー単位で行います。
リスナー | |
リスナーはルールに関連付ける事でバックエンドへ転送します。 | ![]() |
マルチサイトやエラーページの設定が出来ます。 HTTPSを選択すると証明書登録が可能となります。(SSLオフロード設定が出来ます。)
|
![]() |
バックエンド(HTTP設定)
Application Gateway の HTTP 設定の構成
バックエンド設定(HTTP設定)です。
バックエンドではバックエンドプールへの転送方式を設定します。
カスタムプローブの設定等もバックエンド設定で行います。
バックエンド設定 | |
バックエンドの転送方法設定になります。 | ![]() |
バックエンドの転送プロトコルやポート指定が出来ます。 正常性プローブ(個別に作成した場合)をカスタムプローブとして設定する事も出来ます。 |
![]() |
ルール
Application Gateway 要求ルーティング規則
リスナー、バックエンド プール、バックエンドを結びつける設定になります。
リスナーで受け付けたトラフィックをどのバックエンドに転送するかを設定します。
パスベースで転送するバックエンドプールを変更すると言った設定もルールで行います。
ルール | |
リスナーに対してルーティング規則を設定していきます。 | ![]() |
リスナーのタブでWEBトラフィックを受信するリスナーを指定しています。 | ![]() |
バックエンドターゲットでは、バックエンドプール、バックエンド設定との関連付けを行います。 | ![]() |
バックエンドプール
Application Gateway 構成の概要(バックエンド プール)
転送先のWEBサーバの設定になります。
バックエンドプールに複数のWEBサーバを設定すると負荷分散したトラフィックの転送が出来ます。
負荷分散方式はラウンドロビンになります。
バックエンドプール | |
バックエンドプールではトラフィック転送先の指定を行います。 | ![]() |
バックエンドターゲットで転送先を指定します。 バックエンドプールは仮想マシン、VMSS、App Service、IPアドレス(FQDN含む)で指定出来ます。 |
![]() |
Azure Application Gateway(アプリケーションゲートウェイ)で必要になるリソース
必要になる関連リソース
アプリケーションゲートウェイ作成時に必要となる関連リソースがあります。
-
- サブネット
- パブリックIP
- V1ではパブリック選択時のみ必須
- V2では必須
- ネットワークセキュリティグループ(NSG)
- GatewayManager サービスタグからの許可設定が必要
※サブネットもパブリックIPもアプリケーションゲートウェイと同時に作成出来ます。
サブネットは共用不可
Application Gateway インフラストラクチャの構成(サブネットのサイズ)
アプリケーションゲートウェイ専用のサブネットを準備する必要があります。
このサブネットの中に他のリソースを作成する事は許可されていません。
今回はAPGWと言うサブネットを準備しています。
サブネット | |
/24でAPGWと言うサブネットを作成しています。 | ![]() |
ネットワークセキュリティグループ
Application Gateway インフラストラクチャの構成(ネットワークセキュリティグループ)
受信セキュリティ規則でGatewayManagerからの通信とHTTP(S)の通信許可が必要になります。
ネットワークセキュリティグループ | |
GatewayManagerからの通信許可ポートはv1(65503 ~ 65534(TCP))とv2(65200 ~ 65535(TCP))で異なっています。 HTTP(S)の通信許可が必要になります。 |
![]() |
パブリックIP
インターネットからのアクセスを受信する場合にはパブリックIPが必要になります。
v1とv2でパブリックIPに必要な要件が異なります。
アプリケーション ゲートウェイのコンポーネント(静的パブリック IP アドレスと動的パブリック IP アドレス)
v2の場合はパブリックIPのSKUはStandard(静的)になります。
v1の場合はパブリックIPのSKUはBasic(動的)になります。
Azure Application Gateway(アプリケーションゲートウェイ)を作成
今回は試験用なので最小規模(インスタンス数1)で作成しています。
インスタンス数は2以上が推奨なので実際の利用時は注意して下さい。
バックエンドプールではIISを利用したWEBサーバ(仮想マシン)を2台配置しています。
設定値
今回作成したアプリケーションゲートウェイの設定値です。
HTTPで受信したWEBトラフィックをバックエンドのにHTTPで負荷分散するようにしています。
タブ | 設定項目 | 設定値 |
基本 | ゲートウェイ名 | TEST-APGW |
地域 | East US 2 | |
レベル | Standard v2 | |
インスタンス数 | 1 | |
仮想ネットワーク名 | APGW-TEST-VNET | |
サブネット名 | APGW | |
フロントエンドの数 | フロントエンドIPの種類 | パブリック |
パブリックIPアドレス | APGW-TEST-PubIP-Standard | |
バックエンド | 名前 | APGW-TEST-BackendPool |
ターゲット | 仮想マシン(事前準備した仮想マシンを指定) | |
ルーティング規則 | ルール名 | APGW-TEST-Rule |
優先度 | 1 | |
リスナー名 | APGW-TEST-Listener | |
フロントエンドIPプロトコル | HTTP(ポート番号80) | |
ターゲットの種類 | バックエンドプール(APGW-TEST-BackendPool) | |
バックエンドターゲット | APGW-TEST-Backend | |
バックエンドプロトコル | HTTP(ポート番号80) |
作成手順を確認
Azure Portalを使ってアプリケーションゲートウェイを作成します。
リソースを停止すると課金も停止する
アプリケーションゲートウェイは停止する事で課金を止める事が出来ます。起動停止方法についてはこちらに纏めています。
———
Webアクセスで動作確認してみる
ブラウザアクセスして動作確認してみます。
バックエンドの仮想マシンでWebサービス立ち上げ
こちらの手順を参考にIISを立ち上げた仮想マシンを2台用意しています。
アクセス確認する
アクセスはhttp://フロントエンドのアドレスで行います。
仮想マシンのホスト名はAPGW-TEST-VM-01、02としそれぞれのホスト名を表示するようにしています。
アクセス確認 | |
アプリケーションゲートウェイに割り当てたパブリックIPアドレスにブラウザでアクセスします。 ホスト名が表示される事が確認出来ます。 |
![]() |
ブラウザを更新します。 そうすると2号機が表示されます。 アプリケーションゲートウェイで負荷分散されている事が確認出来ます。 |
![]() |
バックエンド正常性の確認方法
バックエンドのWEBサーバへのアクセス状況をAzure Portalで確認する事が出来ます。
バックエンド正常性 | |
状態が健全と表示されていれば正常です。 アプリケーションゲートウェイからの転送されます。 |
![]() |
異常と表示されている場合はそのホストには転送されません。 仮想マシン側に設定されたNSG等でアプリケーションゲートウェイからの通信が許可されていない場合はここで異常と表示されます。 |
![]() |
アプリケーションゲートウェイのアクセスログについてはこちらに纏めています。併せて見て頂けると大変有難いです。
最後に
今回はアプリケーションゲートウェイの基本の纏めから初期構築、HTTPアクセスでの確認までやってみました。
リスナーで受信方法を設定、バックエンドプールで転送先を指定、バックエンド設定で転送方法を設定、ルールでそれぞれの関連付けを行い設定するという事が分かりました。
アプリケーションゲートウェイについて引き続き色々試してみたいと思います。
WAFの設定についてはこちら。
パスベースのルールの作成についてはこちら。