ApplicationGatewayとAzure Front Doorを組み合わせてみる
タイトルを見る限りだとぱっと見普通だなと思われそうですが、今回執筆するイメージは以下の通りです。
Application Gatewayをエンドポイントとして、そのバックエンドにFrontDoor, App Serviceと続くのですが、
- なんだこの構成...
- 悪手じゃないか...
- コストが無駄にかかるだけじゃん...
と思う方もいらっしゃるかと思います。
ただ、世の中にはこういう要件を必要とされる方もいらっしゃるかもしれません。
それまではFrontDoorをエンドポイントとして運用し、App Serviceをバックエンドとする構成が最近のスタンダードかなと思います。
急遽上記の要件を満たすためにApplicationGatewayを導入した際のポイントをまとめたいと思います。
FrontDoorの設定
特殊な設定は不要です。 Application Gatewayからのトラフィックを受信できるよう、カスタムドメインを設定しておけば良いです。
1つ留意事項としては、FrontDoorにて受け付けるトラフィックをApplication Gatewayに制限することは難しそうです。
Application Gateway自体の送信元IPアドレスが変更される可能性があるためです。
また、FrontDoorにWAFを追加し、カスタムルールでIP制限をかけようと試みましたが、ダメでした。
Application Gatewayの設定
こちらも特殊な設定は不要です。 カスタムドメインを設定しつつ、フロントエンドIP、リスナー、ルール、HTTP設定、バックエンドプール、カスタムプローブの各コンポーネントを設定していけば問題ないです。
ポータルから設定する learn.microsoft.com コンポーネントについて
個人的に留意したのは以下の通りです。
- バックエンドプールに設定する際はFQDNをFrontDoorで設定したカスタムドメインを指定する
- バックエンド設定の追加にて
ホスト名をオーバーライドするの選択でバックエンドターゲットからホスト名を選択するを選択 - 一通り設定した後バックエンド正常性を確認すると異常のステータスとなるが、これはサポートに問い合わせたところ現状はこのままで良いとのこと。FrontDoorとはIPv6ベースでチェックしているようだが、portal上ではNG扱いになるとのことだとか。
そのほか
前段にApplication Gatewayにすることで構成が少し複雑になりました。
App Serviceでクライアントが要求したhostを取得する場合は x-original-host を取得しましょう。
意識しないとFrontDoorのヘッダーが取得され意図しない挙動が発生する可能性があるので要注意です。
