Azure Application Gatewayについて

はじめに

最近、仕事上でApplication Gatewayに触れる機会が多く、機能や設定について整理しておきたいと思いました。
自分用の覚え書きなので言及しない項目もありますが、読んだ方の参考になれば幸いです。

Application Gatewayとは

簡単に言えば、アプリケーションのフロントに設置して通信を制御するロードバランサーです。
NSGを設定してアクセス元のIPアドレスを制限するようなL3(ネットワーク)レベルの通信制御も可能ですが、本質的にはL7(アプリケーション層)の通信を制御するためのものとなっています。

設定など

長いので以降はAppGWと略します。

VNET・サブネット

AppGW専用のサブネットを用意して、委任する必要があります。
先述のIP制限などを行う場合、このサブネットにNSGを関連付けますが、AppGWの動作のために必要な通信があるため、それらを塞がないように注意が必要です。

AppGWの動作に必要な許可ルールは、以下2つのサービスタグに対するものになります。

  1. GatewayManager (ポート:65200-65535)

  2. AzureLoadBalancer (ポート:任意)

IPアドレス

AppGWのフロントエンドにIPアドレスを設定する必要があります。
パブリック、プライベートともに設定可能ですが、通常、パブリックIPなしの構成にはできないようです。
※インターネットからアクセスを受けるには、パブリックIPが必要です。

WAF

L7の通信制御を行うもののため、WAF機能も用意されています。
WAFの有効・無効は構成の項目で選択可能で、有効化する場合は、WAFポリシーをセットする必要があります。
WAFポリシーはプリセットが用意されていますが、独自のカスタマイズも可能なようです。

バックエンドプール

AppGWのフロントが受け付けた通信の送り先を設定します。
別のVNETのプライベートIP宛てに通信させるような場合、VNETのピアリングや宛先側でのNSG許可も必要になります。

バックエンド設定

バックエンドに通信する際のプロトコルやポートなどを設定します。

フロントエンドIP構成

AppGWのフロントになるIPアドレスを設定し、リスナー(後述)との関連付けを行います。

リスナー

フロントエンドIPと関連付くリスナーについての設定を行う項目です。
フロントのIPやポート、HTTPSのときの証明書、アクセスを待ち受けるホスト名を設定します。

私自身、詳しく理解できてはいないのですが、ここでいうホスト名は、HTTPリクエストに含まれるHostヘッダーのことで、フロントエンドIPに紐づいたドメインやFQDNのことではありません。
ドメインやFQDNといったDNS関係の設定はL3(ネットワーク)の通信に関係しますが、AppGW上ではL7(アプリケーション)の処理が行われるため、
らしいです。
とはいえ、特に何も設定されていなければ、FQDNとHostヘッダーは一致しているのではないかと思います。

リスナーに設定したHostヘッダーを持つリクエストしか処理されないので、ここの設定は非常に重要です。
なお、ホスト名は5つまでしか入れられませんが、ワイルドカードが使えます。

HTTPSのときの証明書についての補足です。
マネージドIDにアクセスポリシーを付与して、KeyVaultに格納した証明書を参照する、という設定が可能ですが、ポータルで設定を行う場合、デフォルトではAppGWと同一のリソースグループのものしか選択できません。
別のリソースグループのものを使用する場合、ポータルでは設定変更できず、azコマンドで操作する必要があります。(詳細は割愛します)

ポータル上の操作でAppGWを作成する場合で、別リソースグループにある証明書を使いたいときは、一旦、仮の証明書を当てておき、デプロイ後にコマンドで設定変更する、といったひと手間が必要になります。
HTTPSだけど証明書は設定しないでおく、といったことはできません。

ルール

リスナーとバックエンドの関連付けを行います。

書き換え

リスナーが受け付けた通信をバックエンドにルーティングする際にヘッダー情報などの書き換えを行う場合は、この項目で設定します。

リスナーの項目で先述したHostヘッダーの例でいうと、Hostヘッダーが指定のパターンに一致している場合、それを別の値に書き換える、といったことが可能です。
バックエンドではフロントと異なるホスト名を受け付けているような場合に用いられる設定のようです。

指定のパターンに対して、等しい・等しくない、が判定されますが、パターンの書き方は正規表現に対応しています。
ただ一致させたい文字列を書くだけでは、その文字列が含まれるパターンは全て一致の判定になるので、パターンに完全一致させたいときなどは注意が必要です。

正常性プローブ

バックエンドに対して正常に通信できているかを確認する設定です。
疎通状態を定期的に確認するようです。

おまけ

同じような設定のAppGWをいくつも作成する必要がある場合、一度、テンプレート化して、それを編集したカスタムテンプレートでデプロイを行うと簡単に量産できます。

カスタムテンプレートのデプロイでAppGWを作成する場合、AppGWを配置するVNET・サブネットなど、いくつかのリソースを事前に用意しておく必要があります。


この記事が気に入ったらサポートをしてみませんか?