1 年ぐらい Public Preview だった Azure Front Door の Standard / Premium がやっと GA しました。
ぶっちゃけ機能的には劇的な変化はないですが、長らく問題となっていた Subdomain Takeover 対策が標準で入ったことや、Private Link を使ってオリジンへの安全な接続が行えるようになっているのは大きいです。
これまでの Azure CDN (Microsoft) や Front Door からの移行は今後数か月以内に対応されるようなので、準備が整った時点でサクッと移行するのが良いでしょう。CDN 周りの移行は DNS レベルで簡単に切り替えできるので、さっさとやっておくのも手です。
Azure Portal から作成する際には新しい Front Door とこれまでの Front Door / Azure CDN が全て統合されているので、最初は若干混乱しそうです。新しい Front Door 推しなのが良く伝わります。
ちなみに Front Door Standard / Premium の GA と同時に Azure CDN (Microsoft) と以前の Front Door は統合されて Classic 扱いになりました。既存リソースの種類が変わっているので気を付けましょう。
新しい Front Door Standard / Premium とこれまでの Front Door の比較表が出ていますが、当然ながら機能的には全て上回っているので Classic となったサービスを使う長期的なメリットはないです。
気になる価格に関してですが、これまでの Front Door はルーティングルールの数でも課金されていましたが、Front Door Standard / Premium では時間当たりの固定料金 + リクエスト数 + 転送量という分かりやすいものになっています。運用していたルーティングルールの数によっては、かなり安くなることもありそうです。
特徴としては Standard でも WAF の料金が含まれているので、使わないと損した気分になりそうです。
Private Link サポートの変更
Front Door Standard / Premium が Public Preview になった時に Private Link 周りの確認をしていましたが、GA では利用できるリージョンの拡大と対象のサービスが限定されたようです。
リージョンに関しては Availability Zone に対応していれば良いみたいなので、もちろん Japan East では問題なく利用できます。
対象となるサービスは Azure Storage (Blob) / App Service / ILB となっていますが、Azure Portal からは ILB が選択肢に出てこないので若干怪しい気がしています。
Origin support for direct private end point connectivity is limited to Storage (Azure Blobs), App Services and internal load balancers.
Secure your Origin with Private Link in Azure Front Door Premium | Microsoft Docs
プレビュー中は Static Web Apps に対しても使えていましたが、若干制限が厳しくなっています。とはいえメインは App Service に対して使うことになる気はします。
Rule Engine の改善
これまでも Azure CDN と Front Door にも Rule Engine は用意されていましたが、Standard / Premium の Rule Engine は条件式に正規表現が使えるようになったみたいです。
後方参照などは使えないので、あくまでも条件式のマッチに使うだけという形です。とはいえ条件式をシンプルに書けるようになりそうです。
正直なところ GA アナウンスの記事を読んでいて、イマイチ意味が分からなかったのがサーバー変数のサポートでした。IIS の URL Rewrite を書いたことがある人にはすんなり理解されそうです。
今すぐに良い利用方法は思いついていないですが、簡単な文字列操作も出来るようなのでピンポイントで役に立つ時が来そうです。意外に使いどころが無さそうな予感は少しあります。
Application Gateway との使い分け
よく質問されるのが Front Door と Application Gateway のどちらを利用するべきかというものです。それぞれ L7 のロードバランサーという共通点はありますが、Front Door はグローバルサービスで Application Gateway は特定のリージョンの VNET にデプロイされるという大きな違いがあります。
Front Door の公式ドキュメントの FAQ でも使い分けについては記載されています。
Application Gateway は名前の通り VNET に閉じたアプリケーションに対して、外部からアクセス可能なエンドポイントを用意します。同時に VNET 内での負荷分散や TLS オフロードも行ってくれますが、あくまでも特定の VNET に紐づくサービスです。
Front Door が Private Link に対応したことで VNET に閉じたアプリケーションに安全にアクセスできるようになりましたが、グローバルサービスなので負荷分散という観点では主に複数リージョン間になります。
ちょいちょい App Service の前に Application Gateway を入れているアーキテクチャを見ますが、App Service 自体が Application Gateway に相当する仕組みを内部で持っているので、正直なところ無駄なリソースです。App Service の前に Front Door を入れる構成の方がほぼ間違いはありません。
基本的に Application Gateway は使わないようにして Front Door を使うようにしていますが、クライアント証明書認証が必須な場合には Application Gateway を利用する必要が出てきます。
クライアント証明書認証は App Service でも対応していますが、送信された証明書の妥当性の検証は自前で行う必要があるので、正しく実装するには証明書周りの知識が必要になります。
Application Gateway では CA 証明書をアップロードしておけば自動的に検証してくれるため、App Service に比べると安全かつ簡単に対応できます。
