Azure Front Door についてよく寄せられる質問

Azure Front Door は、Application Delivery Network (ADN) をサービスとして提供することで、さまざまなレイヤー 7 負荷分散機能をアプリケーションで利用できるようにします。 これは動的サイト アクセラレーション (DSA) とグローバル負荷分散に、ほぼリアルタイムのフェールオーバーを提供します。 これは Azure で完全に管理できる、高可用でスケーラブルなサービスを提供します。

Azure Front Door では、動的サイト アクセラレーション (DSA)、TLS/SSL オフロードとエンド ツー エンド TLS、Web アプリケーション ファイアウォール、Cookie ベースのセッション アフィニティ、URL パス ベースのルーティング、無料の証明書、複数ドメインの管理などの多くの機能がサポートされます。 サポートされる機能の一覧については、Azure Front Door の概要に関する記事をご覧ください。

Front Door と Application Gateway は両方とも、レイヤー 7 (HTTP/HTTPS) のロード バランサーです。主な違いは、Front Door が非リージョン サービスであるのに対し、Application Gateway はリージョン サービスであるということです。 Front Door はリージョン全体のさまざまなスケール ユニット/クラスター/スタンプのユニット間で負荷分散ができますが、Application Gateway は、スケール ユニット内にある、仮想マシン/コンテナーなどの間で負荷分散ができます。

Front Door の背後で Application Gateway を使用するべき主要なシナリオは次のとおりです。

• Front Door は、パス ベースの負荷分散をグローバル レベルでしか実行できません。仮想ネットワーク (VNET) 内でトラフィックをさらに負荷分散したい場合は、Application Gateway を使用する必要があります。
• Front Door は VM やコンテナー レベルで機能しないので、接続のドレインは実行できません。 ただし、Application Gateway を使用すると、接続のドレインを実行できます。
• Front Door の内側で Application Gateway を使用すると、100% の TLS/SSL オフロードを実現し、その仮想ネットワーク (VNET) 内で HTTP 要求のみをルーティングできます。
• Front Door と Application Gateway は両方ともセッション アフィニティをサポートします。 Front Door は、後続のトラフィックをユーザー セッションから特定のリージョン内の同じクラスターまたはバックエンドに転送できますが、Application Gateway は、トラフィックをクラスター内の同じサーバーにアフィニタイズ (affinitize) できます。

Azure Front Door では、トラフィックをルーティングする先のパブリック VIP または公開されている DNS 名が必要です。 Front Door の背後に Azure Load Balancer をデプロイすることは、一般的なユース ケースです。

Azure Front Door では、HTTP、HTTPS、HTTP/2 がサポートされます。

HTTP/2 プロトコルのサポートを利用できるのは、Azure Front Door に接続しているクライアントだけです。 バックエンド プール内のバックエンドへの通信は、HTTP/1.1 を介して実行されます。 HTTP/2 のサポートは既定で有効です。

バックエンド プールは、Storage、Web アプリ、Kubernetes インスタンス、またはパブリック接続があるその他の任意のカスタム ホスト名で構成できます。 Azure Front Door では、バックエンドがパブリック IP またはパブリックに解決可能な DNS ホスト名のいずれかで定義されている必要があります。 バックエンド プールのメンバーは、パブリック接続がある限り、複数のゾーンやリージョンにまたがって、または Azure の外部に存在することができます。

Azure Front Door はグローバル サービスであり、特定の Azure リージョンには関連付けられていません。 Front Door を作成するときに指定する必要がある唯一の場所はリソース グループです。これはリソース グループのメタデータを格納する場所を指定します。 Front Door プロファイル自体はグローバルなリソースとして作成され、その構成は、世界のすべてのエッジ ロケーションにデプロイされます。

Azure Front Door のすべてのエッジ ロケーションのリストは、Azure Front Door のエッジ ロケーションに関する記事でご覧いただけます。

Azure Front Door は、グローバルに分散されたマルチ テナント サービスです。 そのため、Front Door のインフラストラクチャは、すべての顧客間で共有されます。 ただし、ユーザーは Front Door のプロファイルを作成することで、アプリケーションに必要な特定の構成を定義します。Front Door に加えられた変更により、他の Front Door 構成に影響が及ぶことはありません。

はい。 実際には、Azure Front Door では、ホスト、パス、クエリ文字列のリダイレクトに加えて、URL リダイレクトの一部がサポートされています。 URL リダイレクトの詳細を確認してください。

Front Door のルートには順序はなく、特定のルートは最適な一致に基づいて選択されます。 詳細については、「Front Door が要求をルーティング規則と照合する方法」を参照してください。

Front Door の機能は、トラフィックが Front Door のみを経由する場合に最適です。 Front Door 経由で送信されていないトラフィックをブロックするように配信元を構成する必要があります。 詳細については、「Azure Front Door の配信元へのトラフィックをセキュリティで保護する」を参照してください。

Front Door のフロントエンド エニーキャスト IP は、通常は変更すべきでなく、Front Door の有効期間を通じて静的のままにしておくことができます。 ただし、同じであることの保証はありません。 IP アドレスへの直接的な依存関係は存在しないようにしてください。

いいえ、Azure Front Door では静的または専用のフロントエンド エニーキャスト IP アドレスは現在サポートされていません。

はい、Azure Front Door では X-Forwarded-For、X-Forwarded-Host、および X-Forwarded-Proto ヘッダーがサポートされています。 X-Forwarded-For の場合、ヘッダーが既に存在していれば、Front Door はクライアント ソケット IP をそれに追加します。 そうでない場合、これは値としてクライアント ソケット IP アドレスを持つヘッダーを追加します。 X-Forwarded-Host と X-Forwarded-Proto の場合、値は上書きされます。

詳細については、「Front Door がサポートする HTTP ヘッダー」を参照してください。

最新の Front Door を作成、更新ときは、ほとんどの場合、3 - 20 分で世界のエッジ ロケーションにデプロイできます。

ルートや元のグループ、バックエンド プールなどに対する更新はシームレスであり、ダウンタイムは発生しません (新しい構成が正しい場合)。 証明書の更新はアトミックであるため、停止しません。

Azure Front Door Standard、Premium および (クラシック) レベルでは、トラフィックをバックエンド リソースにルーティングするために、パブリック IP またはパブリックに解決可能な DNS 名が必要です。 Application Gateway や Azure Load Balancer などの Azure リソースでは、仮想ネットワーク内リソースへのルーティングを有効にすることができます。 Front Door Premium レベルを使用している場合は、Private Link を有効にして、プライベート エンドポイント経由で内部ロード バランサーの背後にある配信元に接続できます。 詳細については、「Private Link を使用した配信元のセキュリティ保護」を参照してくださ。

配信元グループは、同じ種類の要求を機能的に処理できる一連の配信元を表します。 個別のアプリケーションまたはワークロードごとに個別の配信元グループを使用する必要があります。

配信元グループ内で、要求を処理できる個別のサーバーまたはサービス インスタンスごとに配信元を作成します。 配信元自体がロード バランサー (Azure Application Gateway など) である場合、またはロード バランサーを含むサービスとしてのプラットフォーム (PaaS) オファリングでホストされている場合、配信元グループには 1 つの配信元のみが含まれることがあります。 内部的には、配信元が配信元間のフェールオーバーと負荷分散を処理しますが、これは Front Door では認識されません。

たとえば、Azure App Service でアプリケーションをホストするとします。 Front Door を構成する方法は、デプロイするアプリケーション インスタンスの数によって異なります。

• 単一リージョンのデプロイ: 1 つの配信元グループを作成します。 その配信元グループ内に、App Service アプリを表す 1 つの配信元を作成します。 App Service アプリはワーカー インスタンス間でスケールアウトするように構成されている場合がありますが、Front Door の観点からは 1 つの配信元です。
• 複数リージョンのアクティブ/パッシブ デプロイ: 1 つの配信元グループを作成します。 その配信元グループ内に、各 App Service アプリの配信元を作成します。 プライマリ アプリケーションの優先度がセカンダリ アプリケーションよりも高くなるように、各配信元の優先度を構成します。
• 複数リージョンのアクティブ/アクティブ デプロイ: 単一の配信元グループを作成します。 その配信元グループ内に、各 App Service アプリの配信元を作成します。 各配信元の優先度が同じになるように構成します。 各配信元の重みを構成して、その配信元に送信する要求の割合を設定します。

詳細については、「Azure Front Door の配信元と配信元グループ」を参照してください。

Azure Front Door のさまざまなタイムアウトおよび制限についてのすべてのドキュメントを参照してください。

ほとんどのルール エンジンは、20 分以内に構成の更新が完了します。 更新が完了するとすぐにルールが有効になります。

Azure Front Door と Azure CDN を同時に構成することはできません。これは、どちらのサービスでも、要求に応答するときに同じ Azure エッジ サイトが利用されるためです。

Azure Front Door では、次の 3 つのサービス タグがサポートされています。

• AzureFrontDoor.Backend サービス タグには、Front Door で配信元への接続に使用される IP アドレスの一覧が提供されます。 このサービス タグは、配信元へのトラフィックをセキュリティで保護するときに使用できます。
• AzureFrontDoor.Frontend サービス タグには、クライアントが Front Door に接続するときに使用する IP アドレスの一覧が提供されます。 Azure Front Door の後方にデプロイされたサービスへの接続が許可されている必要がある送信トラフィックを制御する場合は、AzureFrontDoor.Frontend サービス タグを使用できます。
• AzureFrontDoor.FirstParty サービス タグは、Azure 内で内部的に使用されます。

Azure Front Door サービス タグのユース ケースの詳細については、「利用可能なサービス タグ」を参照してください。

Azure Front Door の HTTP キープアライブ タイムアウトは 90 秒です。 つまり、クライアントが 90 秒間データを送信しない場合、接続は閉じられます。 このタイムアウト値は構成できません。

Azure Front Door は、アプリケーションのスケーラビリティのニーズに対応できる大容量を利用した、グローバルに分散されたマルチ テナント プラットフォームです。 トラフィックは、Microsoft のグローバル ネットワークのエッジから提供され、Front Door は、リージョン間またはさまざまなクラウド間でのアプリケーション全体または個別のマイクロサービスのフェールオーバーを可能にする、グローバル負荷分散機能を提供します。

配信元が Content-Range 応答ヘッダーを送信し、値が応答本文の実際の長さと一致していることを確認してください。

詳細については、「大きなファイルの配信」を参照してください。

2022 年 11 月 8 日より、新しく作成されたすべての Azure Front Door (Standard、Premium および Classic プラン) または Azure CDN Standard from Microsoft (Classic) リソースでは、ドメイン フロンティング動作を示す HTTP 要求がブロックされます。 HTTP/HTTPS 要求内のホスト ヘッダーが、TLS ネゴシエーション中に使用された元の TLS SNI 拡張仕様と一致しない要求はブロックされます。

既存の Azure Front Door または Azure CDN Standard について、Microsoft (Classic) リソースからのドメイン フロンティングをブロックする阿合は、サポート リクエストを作成し、サブスクリプションとリソースの情報を提供してください。 ドメイン フロンティングがブロックされると、この動作を示す HTTP/HTTPS 要求は、Azure Front Door と Azure CDN Standard from Microsoft (Classic) リソースによってすべてブロックされます。

Front Door が不一致のために要求をブロックする場合:

• クライアントは HTTP "421 Misdirected Request" エラー コード応答を受け取ります。
• Azure Front Door は、値が SSLMismatchedSNI の "Error Info" プロパティの下の診断ログにブロックを記録します。

ドメイン フロンティングの詳細については、「Azure 内のドメイン フロンティングへのアプローチをセキュリティで保護する」を参照してください。

2019 年 9 月以降に作成されたすべての Front Door プロファイルでは、既定の最小値として TLS 1.2 が使用されます。

Front Door では、TLS バージョン 1.0、1.1、1.2 がサポートされます。 TLS 1.3 はまだサポートされていません。 詳細については、「Azure Front Door を使用したエンド ツー エンド TLS」を参照してください。

Azure Front Door リソースでは、Front Door プロファイルと同様に、無効になっているルーティング規則に対しては、料金は発生しません。 WAF のポリシーとルールは、無効になっていても料金が発生します。

ログとその他の診断機能については、「Monitoring metrics and logs for Front Door」(Front Door のメトリックとログの監視) を参照してください。

診断ログはお客様のストレージ アカウントに送信され、お客様はログの優先順位に基づいて保持ポリシーを設定できます。 診断ログは、Event Hubs または Azure Monitor ログに送信することもできます。 詳細については、Azure Front Door の診断に関するページを参照してください。

Azure Front Door では監査ログを使用できます。 ポータルで、Front Door のメニュー ページの [アクティビティ ログ] を選択して監査ログにアクセスします。

はい、Azure Front Door ではアラートがサポートされています。 メトリックまたはログに基づいたアラートが構成されます。

Azure Front Door Standard と Premium のアラートを作成する方法については、「アラートを構成する」を参照してください。

次のステップ

• フロント ドアの作成方法について学習します。
• Front Door のしくみについて学習します。