前回の振り返り
前回の記事では、Azure Front Door Standard 配下でアプリケーションが正しく動作するように、WordPress と ASP.NET Core のアプリ側の補正ポイントをまとめました。
これにより、Azure Front Door が HTTPS を終端し、App Service に届くリクエスト情報が変わっても、アプリが正しく動作するための準備が整いました。
しかし、アプリ側の改修だけでは Azure Front Door を “唯一の入口” として機能させることはできません。
本記事では
そこで本記事では、
- Azure Front Door に App Service をバックエンドとして接続する方法
- カスタムドメイン・証明書を Front Door 側に集約する手順
- App Service をインターネットから直接アクセスできないように保護する方法
といったインフラ側の構築・設定にフォーカスして書いていきます。
アプリ改修とインフラ構築の両方が揃うことで、Azure Front Door を中心に据えたセキュアでシンプルな Web アーキテクチャが完成します。
目指す構成 (Befor / After)
前回の記事ではアプリ側の補正という観点でこの構成を紹介しましたが、本記事ではインフラ側の構築という視点で Before / After を整理します。
Before: App Service がインターネットに直接公開されている
After: Azure Front Door が唯一の入口となり、App Service は保護される
Before
現在の構成では、App Service がインターネットに直接公開されており、カスタムドメインや証明書も App Service 側で個別に管理しています。
- App Service の URL に直接アクセスできてしまう
- HTTPS 終端が App Service 側にあり、管理ポイントが分散
- カスタムドメイン・証明書も App Service 側で個別管理
- Azure Front Door は静的配信にしか使われていない
After
最終的に目指す構成では、Azure Front Door がアプリケーションの前段に立ち、すべてのリクエストが Azure Front Door 経由で App Service に到達するようになります。
- すべてのリクエストが Azure Front Door 経由で App Service に到達
- HTTPS 終端・証明書管理を Azure Front Door に集約
- App Service は Azure Front Door 経由のアクセスのみ許可
- セキュリティ・運用・パフォーマンスが Azure Front Door に統合
次の章から、この「After」の構成を実現するためのインフラ側の構築手順を書いていきます。
- Azure Front Door に App Service をバックエンドとして接続
- カスタムドメイン・証明書の Azure Front Door への集約
- App Service のアクセス制御 (Azure Front Door 経由のみ許可)
- DNS 切り替えによるトラフィックの統合
これらを順に進めることで、Azure Front Door をアプリケーションの唯一の入口として運用できるようになります。
1. Azure Front Door の構築
第 1 回で Azure CDN から移行した Azure Front Door に対して、次の作業を行います。
- カスタムドメインの追加
- 配信元グループの追加
- リダイレクト用のルールセットの追加
- エンドポイントとルートの構成
- DNS レコードの更新
1-1. カスタムドメインの追加
カスタムドメインの追加は、[設定] > [ドメイン] を開き、[追加] をクリックします。
今回は、Azure 以外の DNS プロバイダーで取得したドメインを使用し、DNS の管理は Azure DNS ゾーンを利用しています。SSL/TLS 証明書は Azure Key Valut で管理し、Azure Front Door に登録済みです。
これを踏まえて、下図のように入力して [追加] をクリックします。
ドメインの追加は比較的時間を要します。筆者の環境では 1 ドメインあたり、60 分程度かかりました。
ドメインの追加が完了すると、カスタムドメインの一覧に掲載されました。この時点では、まだエンドポイントに関連付いていませんが、次に進みます。
1-2. 配信元グループの追加
-
配信元 (オリジン)
Web アプリや API、ストレージなど実際にコンテンツを提供するバックエンドを指します。Azure Front Door は受け取ったリクエストをこのオリジンへルーティングして応答を返します。 -
配信元 (オリジン) グループ
複数のオリジンをまとめて管理する論理的なグループです。Azure Front Door はこのグループ単位で負荷分散やフェールオーバーを行います。
配信元グループの追加は、[設定] > [配信元グループ] を開き、[追加] をクリックします。すると、「配信元グループの追加」ペインが現れます。
まず、配信元を追加します。「配信元グループの追加」ペインの [配信元の追加] をクリックします。「配信元の追加」ペインが現れるので、下図のように入力して [追加] をクリックします。
-
配信元のホストヘッダーを App Service の既定ホスト名にした理由
Azure Front Door がバックエンドにリクエストを転送する際、Host ヘッダーを何として送るかを指定する必要があります。
App Service は内部的に自分の既定ホスト名 (
azurewebsites.net) と一致する Host ヘッダーのリクエストだけを正しく処理します。そのため、ここをカスタムドメインにしてしまうと 404 やリダイレクトループが発生します。
よって、配信元のホストヘッダーには App Service の既定ホスト名
<appname>.azurewebsites.netを指定します。 -
証明書のサブジェクト名の検証を「無効」にした理由
Azure Front Door Standard / Premium では、Azure Front Door が HTTPS を終端し、App Service とは HTTP で通信します。
つまり、App Service 側の証明書は使用されず、証明書のサブジェクト名を検証する必要がありません。
ここを誤って「有効」にすると、Azure Front Door が証明書検証に失敗し、バックエンドの正常性チェックが通らなくなるため、503 エラーの原因になります。
「配信元グループの追加」ペインに戻り、他の項目を入力して [追加] をクリックします。
今回の構成では、配信元は単一の App Service のみであり、Azure Front Door が複数のバックエンドに振り分けることはありません。
そのため、
- セッションアフィニティは、固定先を選ぶ必要がないため不要
- 正常性プローブは、プローブ結果で切り替えるバックエンドが存在しないため不要
という理由で、どちらも無効のままで問題ありません。
しばらく待つと、配信元グループの一覧に掲載されました。カスタムドメインと同様に、この時点では、まだエンドポイントに関連付いていませんが、次に進みます。
1-3. リダイレクト用のルールセットの追加
今回は、ユーザーが etrobo.jp でアクセスされたら www.etrobo.jp にリダイレクトして欲しいので、HTTP リクエストを処理する方法を定義します。
配信元グループの追加は、[設定] > [ルールセット] を開き、[追加] をクリックします。
[ルールの追加] をクリックして「ルール (条件とアクション)」を定義し、[保存] をクリックします。
-
条件 セクション
[条件の追加] をクリックし、以下のように設定します。項目 設定値 条件 「ホスト名」を選択 演算子 「等しい」を選択 ホスト名 etrobo.jp文字列の変換 「小文字に変換」を選択 -
アクション セクション
[アクションの追加] をクリックし、以下のように設定します。項目 設定値 アクション 「URL のリダイレクト」を選択 リダイレクトの種類 「Moved (301)」を選択 プロトコルをリダイレクト 「HTTPS」を選択 宛先ホスト www.etrobo.jp宛先パス (空欄) クエリ文字列 (空欄) 宛先フラグメント (空欄)
しばらくすると、ルールセットの一覧に掲載されました。前述と同様に、この時点では、まだエンドポイントに関連付いていませんが、次の手順ですべてを関連付けます。
1-4. エンドポイントとルートの構成
ここでは、エンドポイントを追加し、ルートに前述で追加した「カスタムドメイン」「配信元グループ」「ルールセット」を関連付けます。
エンドポイントは、[設定] > [フロント ドア マネージャー] を開き、[エンドポイントの追加] をクリックします。「エンドポイントの追加」ペインが現れるので、下図のように入力し、[追加] をクリックします。
エンドポイントの一覧に掲載されたら、追加されたエンドポイントの [ルートの追加] をクリックします。
「ルートの追加」の項目を設定していきます。
まず、「ドメイン」では「エンドポイントのホスト名」と「追加したカスタムドメイン」を選択します。
そして、その他の項目を設定し、[追加] をクリックします。
| 項目 | 設定値 |
|---|---|
| 一致するパターン |
/* ※既定値 |
| 受け入れ済みのプロトコル | 「HTTPS のみ」を選択 |
| リダイレクト | 「HTTPS を使用するすべてのトラフィックをリダイレクトする」にチェックを付ける |
| 配信元グループ | 「追加した配信元グループ」を選択 |
| 配信元のパス | (空欄) |
| 転送プロトコル | 「HTTP のみ」を選択 |
| キャッシュ | 無効 ※チェックを付けない |
| ルール (ルールセット) | 「追加したルールセット」を選択 |
しばらくすると、エンドポイントにルートが追加されました。
先ほどまでエンドポイントと関連付いていなかった「カスタムドメイン」、「配信元グループ」、「ルールセット」でもちゃんと関連づいていることが確認できます。
1-5. DNS レコードの更新
Azure Front Door の構築の最後に、カスタムドメインの DNS レコードを更新します。App Service の既定ホスト名 <appname>.azurewebsites.net に向いているので、これを Azure Front Door のエンドポイント名 <endpointname>-<hashvalue>.z01.azurefd.net に変更します。
Azure DNS ゾーンで DNS の管理を行っている場合、Azure Front Door 側で操作することができます。
[設定] > [ドメイン] を開きます。対象のカスタムドメインの「DNS の状態」が下図のようにリンクが貼られているので、それをクリックします。
「エイリアス レコードの追加または更新」ペインが現れます。必要な DNS レコード情報が表示 (セット) されているので、[追加] または [更新] をクリックするだけで DNS レコードが作成されます。
DNS レコードが作成されると、対象のカスタムドメインの「DNS の状態」が「トラフィックは安全に配信されます」と表示されます。これは、トラフィックのフローが始まったことを示しています。
2. App Service の設定 (Azure Front Door 前提の構成に変更)
Azure Front Door を唯一の入口にするためには、 App Service をインターネットから直接アクセスできない状態にする必要があります。
ここでは次の 3 点を行います。
- HTTPS only の解除
- カスタムドメインと証明書の削除
- アクセス制御
2-1. HTTPS only の解除
Azure Front Door と App Service 間の通信は HTTP であるため、「HTTPS only」を解除します。
2-2. カスタムドメインと証明書の削除
今までは App Service で管理していたカスタムドメインと証明書を Azure Front Door で集約したので、カスタムドメインとバインドしていた証明書を削除します。その結果、既定のドメイン <appname>.azurewebsites.net のみとなります。
2-3. アクセス制御 (Azure Front Door 経由のみ許可)
この時点だと、既定のドメイン <appname>.azurewebsites.net でアクセスできてしまいます。このアクセスを遮断するため、App Service のアクセス制御に次のルールを適用します。
- Azure Front Door 経由のアクセスを許可
- それ以外のアクセスは拒否
App Service のアクセス制御は、[設定] > [ネットワーク] を開き、「アクセス制御」にて行います。具体的な手順は、次のドキュメントをご参照ください。
アクションで「許可」を、種類で「サービスタグ」を、サービスタグで「AzureForntDoor.Backend」を選択し、「X-Azure-FDID」に「Azure Front Door の ID」を設定して、ルールを追加します。
なお、「Azure Front Door の ID」は、Azure Front Door の「概要」に掲載されています。
公衆ネットワークアクセスで「選択した仮想ネットワークと IP アドレスから有効」、一致しないルールのアクションで「拒否」を選択されているのを確認し、保存します。
インフラ構築は以上です。それでは動作確認しましょう。
3. 動作確認チェックリスト
今回作業したことが正しく反映されているか確認します。
- Azure Front Door 経由でアプリにアクセスできる
- ブラウザでカスタムドメイン
www.etrobo.jpにアクセスすると、アプリが正常に表示されることを確認します。
- ブラウザでカスタムドメイン
- App Service の直接 URL にアクセスすると 403 / 404 になる
- ブラウザで App Service の既定のドメイン
<appname>.azurewebsites.netにアクセスすると、403 Forbiddenまたは404 Not Foundとなることを確認します。
- ブラウザで App Service の既定のドメイン
- HTTPS が Azure Front Door 側で正しく終端されている
- ブラウザでカスタムドメインにアクセスし、アドレスバーの鍵アイコンをクリックし、Azure Front Door が管理する証明書であることを確認します。
- リダイレクト (www への統一) が正しく動作する
- ブラウザでカスタムドメイン
etrobo.jpにアクセスすると、自動的にwww.etrobo.jpにリダイレクトされることを確認します。 - 開発者ツールの「ネットワーク」タブで確認
- ステータスコード:
301 - レスポンスの Location ヘッダー:
https://www.etrobo.jp/
- ステータスコード:
- ブラウザでカスタムドメイン
- DNS の TTL が反映されている
- DNS 切り替え後、クライアントが新しい CNAME を参照しているかを確認します。
nslookup www.etrobo.jpdig www.etrobo.jp
- DNS 切り替え後、クライアントが新しい CNAME を参照しているかを確認します。
本記事のまとめ
本記事では、Azure Front Door をアプリケーションの唯一の入口として運用するために必要なインフラ構築のポイントを整理しました。
- カスタムドメインと証明書を Azure Front Door に集約
- App Service を正しくバックエンドとして登録
- App Service への直接アクセスを遮断し、Azure Front Door 経由に統一
- DNS 切り替えによってトラフィックを Azure Front Door に集約
アプリ側の補正とインフラ側の構築が揃うことで、セキュアでシンプルな Web アーキテクチャが完成します。
以上で、Azure Front Door を唯一の入口として運用するためのインフラ構築が完了します。
シリーズ全体のまとめ
本シリーズでは、Azure CDN from Microsoft のリタイア対応をきっかけに、Azure Front Door をアプリケーションの唯一の入口として活用するための全プロセスを整理しました。
第 1 回：移行編
Azure CDN から Azure Front Door への移行判断の背景を整理し、AsIs / ToBe の観点で現状の課題と将来像を明確化しました。
そのうえで、実際の移行手順 (互換性検証・マネージド ID・Key Vault 権限付与・移行実行) をスクリーンショット付きで解説し、静的コンテンツ配信の Azure Front Door への統合を完了しました。
第 2 回：アプリ改修編
Azure Front Door を経由すると、App Service に届くプロトコルやホスト名が変わるため、WordPress と ASP.NET Core の双方で必要となる補正ポイントを整理しました。
X-Forwarded-* ヘッダーを正しく解釈させることで、HTTPS 判定・URL 生成・リダイレクト・認証フローなどの不具合を防ぎ、Azure Front Door 配下でもアプリが正しく動作する状態を整えました。
第 3 回：インフラ構築編
Azure Front Door をアプリケーションの唯一の入口として機能させるために、バックエンド設定・ルーティング・アクセス制御・証明書管理などの構築ポイントを整理しました。
特に、Host ヘッダーや証明書検証といった Azure Front Door 特有の落とし穴を回避しつつ、App Service への直接アクセスを遮断し、Azure Front Door 経由に統一する構成を完成させました。
最終的に得られるもの
-
パフォーマンス向上
静的・動的コンテンツがグローバルエッジ経由で高速化 -
セキュリティ強化
App Service を外部公開せず、Azure Front Door 経由のみ許可 -
運用の集約
ドメイン・証明書・ルーティング・監視を Azure Front Door に統合 -
将来の拡張性
マルチリージョン構成や可用性向上にもスムーズに発展可能
最後に
Azure Front Door を「単なる CDN の置き換え」で終わらせず、 アプリケーションの入口として最大限活用するための全体像を 3 回にわたって整理しました。
移行・アプリ改修・インフラ構築の 3 つが揃うことで、セキュアでシンプル、そして運用しやすい Web アーキテクチャが完成します。
本シリーズが、Azure Front Door を本格的に活用したい方の参考になれば幸いです。