Azure CDN from Microsoft から Azure Front Door へ移行しました

はじめに

年末年始に、筆者が活動しているコミュニティ「ET ロボコン」のサイト周りのインフラを改修することになり、その一環で Azure Front Door の構築 (移行と活用) に没頭していました。実際にやってみていろいろと学びを得ることができました。せっかくなので、3 つの記事に分けてアウトプットしておこうと思います。

• Azure CDN from Microsoft から Azure Front Door へ移行しました
• Azure Front Door をアプリケーションの唯一の入口にする:アプリ改修編
• Azure Front Door をアプリケーションの唯一の入口にする:インフラ構築編

本記事では、今回のインフラ面の「AsIs・ToBe」と「Azure CDN から Azure Front Door の移行」について書いていきます。

Azure Front Door と Azure CDN の違い

本記事で登場する Azure Front Door と Azure CDN についてカンタンに紹介します。どちらもアプリケーション層で高度なルーティングとキャッシュ機能を備え、グローバルにコンテンツを配信する Azure サービスです。

• Azure Front Door
  世界中の POP を入口にして、静的・動的コンテンツの両方を高速かつ安定して配信するアプリケーションフロントエンドサービス。Microsoft の専用バックボーンネットワークを使うため、インターネット経由より速くて安定。

• Azure CDN
  世界中のエッジ拠点に静的コンテンツをキャッシュして、ユーザーの近くから高速に配信する仕組み。主に画像・CSS・JavaScript などの静的ファイル向け。

サービスの違いについては、次のドキュメントをご参照ください。

Azure CDN from Microsoft のリタイアと移行判断の背景

ずいぶん前からアナウンスされていましたが、Azure CDN from Microsoft は 2027 年 9 月 30 日にサービス終了します。それまでに Azure Front Door にアップグレードしなければなりません。

Retirement: Azure CDN Standard from Microsoft (classic) will be retired on September 30th, 2027

サービス終了までは時間があるものの、現状の用途では Azure CDN のほうが安価であるため、当初は移行に踏み切れずにいました。

しかし、だんだんとサービス終了が近づくにつれ、今までサポートされていた機能が制限されるようになりました。

Retirement: Azure Front Door (classic) and Azure CDN from Microsoft Classic SKU ending CNAME based domain validation and new domain/profile creations by August 15, 2025

今後更なる機能制限が起こり得るかもしれませんし、移行するなら Azure Front Door をできる限り活用していこうと思い立ち、移行しようと決めました！

また、ET ロボコンのオフシーズン¹である年末年始がタイミング的にとても良いですし、サービス終了間近に移行して万が一トラブルが発生するとたいへん困るので、この機会を逃すまいと考えた次第です。

現状 (AsIs) と最終構想 (ToBe)

現状 (AsIs)

公式サイトでは、Microsoft Azure Storage for WordPress プラグインを使って、画像などのファイルを Azure Blob Storage に保存しています。そして、HTTPS を有効にしてカスタムドメインをマップし、静的コンテンツを配信していました。

Web サイト (App Service) はインターネットから直接アクセスされる構成となっていました。

App Service はリージョン固定であるため、アクセス元が遠いほどレスポンス遅延が大きくなります。また、App Service のエンドポイントが外部に露出するため、Bot やスキャンなどの不要なアクセスがアプリに直接届きやすく、閲覧者の体験にも影響する可能性があります。

さらに、App Service 側でカスタムドメインや証明書を個別に管理する必要があり、更新漏れのリスクや運用負荷が大きくなります。

課題 (AsIs の問題点)

• 遅延の問題
  単一リージョンの App Service では地理的に遠いユーザーほど遅延が大きい
• セキュリティの問題
  App Service が直接インターネットに露出している
• 運用の問題
  ドメイン・証明書管理が分散している

最終構想 (ToBe)

最終的には、静的コンテンツの配信のほかに、既存のいくつかの Web サイトを接続して Azure Front Door を活用していきます！

これにより、単なる「Azure CDN の置き換え」にとどまらず、パフォーマンス・セキュリティ・運用・可用性・コストといった複数の観点でメリットが得られます。

ToBe のメリット

パフォーマンス向上

• グローバルエッジで高速化
  • 静的コンテンツを最寄りのエッジ拠点 (キャッシュサーバー) に置いておけるため、毎回 Azure のデータセンターまで取りに行くより圧倒的に速くなる
    ※従来の Azure CDN と同様のメリット
  • 動的コンテンツも最寄りの POP (Azure Front Door の入口) から Microsoft の専用バックボーンネットワークを通って App Service に到達するため、公共インターネットを経由するよりも遅延が少なく、安定した通信ができる

セキュリティ強化

• App Service の露出を最小限に
  • App Service のアクセス制限で、Azure Front Door 経由以外のアクセスを遮断

運用の集約

• 静的コンテンツと Web アプリの入口を一本化
  • すべてのリクエストが Azure Front Door を経由する構造になり、管理ポイントがひとつにまとまる
• 運用がシンプルに
  • ドメイン管理、証明書管理、ルーティングが Azure Front Door に集約される
• 監視・ログの統合
  • Azure Front Door と App Service のログを一元的に分析できる

可用性の向上

• 可用性の向上 (将来的には)
  • App Service を複数リージョンに配置すれば、Azure Front Door の正常性プローブが自動で正常リージョンへルーティング

コスト最適化

• コスト最適化の可能性
  • 静的コンテンツがエッジで処理されるため、App Service の負荷が減る
    ※従来の Azure CDN と同様のメリット

AsIs・ToBe 対比表

前述で AsIs・ToBe それぞれについてを説明しましたが、分かりやすく観点ごとの対比を次の表にまとめてみました。

観点	AsIs	ToBe
パフォーマンス	単一リージョンで遅延	POP + バックボーンで高速化
セキュリティ	Azure App Service が露出	Azure Front Door 経由のみ許可
運用	ドメイン・証明書を個別管理	Azure Front Door に集約
可用性	単一リージョン	将来的にマルチリージョン化可能
コスト	静的配信がエッジで完結	静的配信がエッジで完結

Azure Front Door への移行手順

今回は、コスト面を考慮した結果、Azure Front Door Standard に移行することとします。

移行作業は、対象の Azure CDN プロファイルの [設定] > [移行] にて、手順に従って操作していきます。

なお、Azure Front Door への移行は、移行元の Azure CDN プロファイルの状況により、移行に必要な手順 (3 ～ 5 つの手順) が異なります。

移行対象

移行対象の Azure CDN プロファイルには、次の 2 つのエンドポイントがあります。双方とも HTTPS アクセスを有効 (独自の証明書を使用、Azure Key Vault にて管理) にしています。

• Storage の Blob サービス エンドポイント
• Storage の静的 Web サイト エンドポイント

次から、今回作業した各フェーズを紹介していきます。

互換性の検証

まず、対象の Azure CDN プロファイルが移行条件に合致しているか確認します。このフェーズは [検証] をクリックするだけです。

[検証] をクリックすると、下図のように確認中のメッセージが表示されるので、しばらく待ちます。

移行条件に合致していれば、下図のように緑色チェックが付きます。

これで検証フェーズは終わりで、次のフェーズに移ります。

移行の準備

このフェーズでは、新しい Azure Front Door プロファイルを作成します。今回の移行先は Standard なので、「Standard」レベルを選択して [準備] をクリックします。

確認ダイアログが表示されるので、問題なければ [はい] をクリックします。

すると、下図のように処理中のメッセージが表示されるので、しばらく待ちます。

新しいプロファイルが作成されると、下図のように緑色チェックが付きます。なお、新しいプロファイルの名前は移行元と同じです。

必要に応じて、作成された新しいプロファイルの構成をチェックしましょう。

マネージド ID の有効化

このフェーズでは、 Azure Key Vault の証明書へアクセスするために、移行の準備で作成した新しい Azure Front Door プロファイルにマネージド ID を構成します。

[有効化] をクリックします。

すると、「ID」ペインが現れます。今回は「システム割り当てマネージド ID」を使用するので、[システム割り当て済み] タブを開き、[状態] を「オン」にして [保存] をクリックします。

完了すると、下図のように緑色チェックが付き、マネージド ID が有効になった旨のメッセージが表示されます。

Azure Front Door のマネージド証明書を使用している場合は、Azure Key Vault へのアクセス許可の割り当ては必要ありませんので、マネージド ID 関連のフェーズはスキップして移行フェーズに進めます。

Azure Key Vault への権限付与

このフェーズでは、移行対象の Azure CDN プロファイルで使われているすべての Azure Key Vault リソースに、先ほど有効化したマネージド ID でのアクセス許可を割り当てます。

[許可] をクリックします。

しばらくすると、下図のように緑色チェックが付き、Azure Key Vault リソースにマネージド ID でのアクセス許可を付与した旨のメッセージが表示されます。

移行の実行

このフェーズを実行すると、移行対象の Azure CDN プロファイルは Azure Front Door にアップグレードされます。

それでは、[移行] をクリックします。

確認ダイアログが表示されるので、このまま移行を進めても良い場合は [はい] をクリックします。

移行フェーズは比較的時間を要します。筆者の環境では 30 分程度で完了しました。移行が完了すると、Azure Front Door プロファイルが表示されました。

これで移行作業は完了！
Azure Blob Storage に格納されている静的コンテンツも正常にアクセスできます。

ここまでの作業について、以下のドキュメントもご参照ください。

移行後の作業

移行完了時点で、古い Azure CDN プロファイルのエンドポイント hoge0.azureedge.net は、移行後の Azure Front Door プロファイルの [設定] > [ドメイン] の [移行済みのドメイン] タブに、「移行されたカスタムドメイン」として追加されています。

このドメインは、移行された既定のルートに関連付けられているため、この状態でも正常にトラフィックが処理されます。ただ、この旧 Azure CDN エンドポイントが不要であるなら削除することもできます。

筆者は、次のように考えたため、取り除くことにしました。

• 旧 Azure CDN エンドポイントを残す必要はない
• ドメイン管理をシンプルにしたいため、ちょっと複雑なこの状態を取り除きたい

旧 Azure CDN エンドポイントの削除

作業していくうえで、次のポイントを意識して進めていきました。ご参考まで。

旧 Azure CDN エンドポイント削除のチェックポイント

• Azure Front Door 側で、すべてのトラフィックが正常に処理されている
• ログを確認し、旧 Azure CDN のエンドポイントへのアクセスがゼロ
• 外部サービス、アプリ、スクリプトなどが xxxxx.azureedge.net を参照していない
• キャッシュ TTL の期間が十分に経過している

DNS レコードの切り替え

移行完了時点では、カスタムドメインの名前解決 (CNAME) では、旧 Azure CDN エンドポイント hoge0.azureedge.net を指しています。移行プロセスでは、DNS レコードの更新までは行ってくれません。

カスタムドメイン	種類	TTL	値 (現在の向き先)
contents.etrobo.jp	CNAME	3600	hoge0.azureedge.net
docs.etrobo.jp	CNAME	3600	hoge1.azureedge.net

旧 Azure CDN エンドポイントを外す前に、確実に移行後の Azure Front Door にトラフィックを流すため、まず DNS レコードを切り替えます。

カスタムドメインの名前解決で、移行後の Azure Front Door エンドポイント hoge0-xxxxx.z01.azurefd.net を指すように切り替えます。

カスタムドメイン	種類	TTL	値 (新しい向き先)
contents.etrobo.jp	CNAME	3600	hoge0-xxxxx.z01.azurefd.net
docs.etrobo.jp	CNAME	3600	hoge1-xxxxx.z01.azurefd.net

古い CNAME を参照しているクライアントが残っていると、404 エラーや証明書エラーが起きる可能性があるため、DNS の TTL が十分に経過してから次の手順に進みます。

ルートの更新

次に、対象のルートから旧 Azure CDN エンドポイントの関連付けを解除します。

移行後の Azure Front Door プロファイルの [設定] > [フロント ドア マネージャー] から対象のエンドポイントの「ルート」を開きます。

「ドメイン」ドロップダウンリストから「旧 Azure CDN エンドポイント hoge0.azureedge.net」のチェックを外し、[更新] をクリックします。

移行済みのドメインを削除

更新完了後、Azure Front Door プロファイルの [設定] > [ドメイン] の [移行済みのドメイン] タブを開くと、各ドメイン (旧 Azure CDN エンドポイント) の「エンドポイントの関連付け」が「なし」となり、削除できる状態になりました。

削除するドメインのチェックを付け、[ドメインの削除] をクリックします。

最後に

今回の移行作業では、Azure CDN from Microsoft のリタイア対応という目的を超えて、今後のサイト運用を Azure Front Door に集約するための土台づくりを進めることができました。

実際に手を動かしてみると、移行プロセス自体はポータル上でガイドされているものの、次のような点が特に重要だと感じました。

• Azure Front Door に統合することで、パフォーマンス・セキュリティ・運用の改善余地が大きく広がる
• マネージド ID と Azure Key Vault の権限付与は、証明書管理を Azure Front Door に集約するうえで重要
• 旧 Azure CDN エンドポイントの削除は、ログ確認や依存関係の洗い出しを丁寧に行うことで安全に進められる
• 移行後のログ確認や TTL 待ちなど、運用観点のチェックがトラブル防止に役立つ

本記事では「Azure CDN から Azure Front Door への移行」にフォーカスしました。

次回の記事では、Azure Front Door をアプリケーションの入口としてできる限り活用するために、App Service をオリジンとしてどう接続し、どのように保護するかについて書こうと思います。

Azure Front Door を「単なる CDN の置き換え」で終わらせず、アプリケーションの入口として最大限活用したい方の参考になれば幸いです。

(つづく)

1. 毎年 2 月の開催発表会から始まり、11 月のチャンピオンシップ大会までイベントを催しています。(が、実行委員会は年中活動しています) ↩