次の方法で共有

Azure Front Door に関してよく寄せられる質問 (FAQ)

この記事では、Azure Front Door の特徴と機能に関してよく寄せられる質問に対する回答を示します。 質問に対する回答が見つからない場合は、次のチャネルからお問い合わせください(エスカレーション順)。

  1. この記事のフィードバック セクション。

  2. Azure Front Door のフィードバック。

  3. Microsoft サポート: 新しいサポート リクエストを作成するには、Azure portal の [ヘルプ ] タブで [ ヘルプ + サポート ] ボタンを選択し、[ 新しいサポート リクエスト] を選択します。

全般

Azure Front Doorとは何ですか？

Azure Front Door は、アプリケーションをより迅速かつ確実に提供するクラウドベースのサービスです。 レイヤー 7 のロード バランシングを使用して、複数のリージョンとエンドポイントにトラフィックを分散します。 また、Web パフォーマンスを最適化するための動的サイト アクセラレーション (DSA) と、高可用性を確保するためのほぼリアルタイムのフェールオーバーも提供します。 Azure Front Door はフル マネージド サービスであるため、スケーリングやメンテナンスについて心配する必要はありません。

Azure Front Door と Azure Application Gateway の違いは何ですか?

Azure Front Door と Azure Application Gateway はどちらも HTTP/HTTPS トラフィックのロード バランサーですが、スコープは異なります。 Front Door は、リージョン間で要求を分散できるグローバル サービスであり、Application Gateway はリージョン内で要求を分散できるリージョン サービスです。 Azure Front Door はスケール ユニット、クラスター、またはスタンプ ユニットで動作しますが、Azure Application Gateway は同じスケール ユニット内の VM、コンテナー、またはその他のリソースで動作します。

現在、オリジンとして互換性があるのはどのような種類のリソースですか?

Azure Front Door では、次のようなさまざまな種類の配信元を使用できます。

  • ストレージ (Azure Blob、クラシック、静的 Web サイト)
  • クラウド サービス
  • アプリケーションサービス
  • 静的 Web アプリ
  • API Management
  • アプリケーション ゲートウェイ
  • パブリック IP アドレス
  • Azure Spring アプリ
  • コンテナ事例
  • コンテナー アプリ
  • パブリックアクセス権を持つ任意のカスタムホスト名。

配信元には、パブリックに解決できるパブリック IP または DNS ホスト名が必要です。 さまざまなゾーン、リージョン、または Azure の外部のバックエンドは、パブリックにアクセス可能である限り、組み合わせることができます。

Azure Front Door サービスはどのリージョンにデプロイできますか?

Azure Front Door は、どの Azure リージョンにも制限されず、グローバルに動作します。 Front Door を作成するときに選択する必要がある唯一の場所は、リソース グループの場所であり、これによりリソース グループのメタデータが格納される場所が決まります。 Front Door プロファイルはグローバル リソースであり、その構成は世界中のすべてのエッジ ロケーションに配布されます。

Azure Front Door POP (ポイント オブ プレゼンス) の場所はどのようなものですか?

Azure Front Door のグローバル負荷分散とコンテンツ配信を提供するポイント オブ プレゼンス (POP) の完全な一覧については、「 Azure Front Door の POP の場所」を参照してください。 このリストは、新しい POP が追加または削除されるたびに定期的に更新されます。 また、Azure Resource Manager API を使用して、現在の POP の一覧に対してプログラムでクエリを実行することもできます。

Azure Front Door は、さまざまな顧客間でリソースをどのように割り当てますか?

Azure Front Door は、アプリケーションを複数のリージョンにグローバルに分散するサービスです。 すべての顧客によって共有される共通のインフラストラクチャを使用しますが、独自の Front Door プロファイルをカスタマイズして、アプリケーションの特定の要件を構成できます。 他の顧客の構成は、他の顧客の構成から分離された Front Door の構成に影響を与えることはできません。

Azure Front Door では、ルーティング規則の順序はどのように決定されますか?

Front Door では、Web アプリケーションのルートは並べ替えられません。 代わりに、リクエストに最も適したルートを選択します。 Front Door が要求をルートに一致させる方法については、「 Front Door が要求をルーティング規則に一致させる方法」を参照してください。

バックエンドへのアクセスを Azure Front Door のみに制限する手順は何ですか?

Front Door の機能を最適に動作させるには、Azure Front Door からのトラフィックのみが配信元に到達できるようにする必要があります。 その結果、承認されていない要求や悪意のある要求は、Front Door のセキュリティ ポリシーとルーティング ポリシーに遭遇し、アクセスが拒否されます。 配信元をセキュリティで保護する方法については、「 Azure Front Door 配信元へのトラフィックをセキュリティで保護する」を参照してください。

Azure Front Door のデプロイに要する推定時間はどのくらいですか? 更新プロセス中も Front Door は動作し続けますか?

新しい Front Door 構成のデプロイ時間は、変更の種類によって異なります。 通常、変更が世界中のすべてのエッジロケーションに反映されるまでに 3 分から 20 分かかります。

注

カスタムTLS/SSL証明書の更新は、グローバルにデプロイされるまでに数分から1時間かかる場合があります。

ルートまたは配信元グループ/バックエンド プールの更新はシームレスであり、ダウンタイムは発生しません (新しい構成が正しいと仮定します)。 証明書の更新もアトミックに行われるため、停止のリスクはありません。

Front Door と CDN のプロファイルをリソース グループ間またはサブスクリプション間でダウンタイムなしで移動できますか?

  • Front Door Standard/Premium プロファイルと Azure CDN プロファイルは、ダウンタイムなしでリソース グループまたはサブスクリプション間で移動できます。 移動を実行するには、次の手順に従います。
  • Front Door Classic では、リソース グループまたはサブスクリプション間の移動はサポートされていません。 代わりに、クラシック プロファイルを Standard/Premium に移行 してから、移動を実行できます。
  • お客様が Front Door Standard/Premium に WAF を関連付けている場合、移動操作は失敗します。 お客様は、最初にWAFポリシーの関連付けを解除し、移動してから関連付ける必要があります。

機能とプロトコル

Azure Front Door ではどのような機能がサポートされていますか?

Azure Front Door は、サイトのパフォーマンスとユーザー エクスペリエンスを向上させる動的サイト アクセラレーション (DSA) など、Web アプリケーションに多くの利点を提供するサービスです。 Azure Front Door は、TLS/SSL オフロードとエンド ツー エンド TLS も処理し、Web トラフィックのセキュリティと暗号化を強化します。 さらに、Azure Front Door には、Web アプリケーション ファイアウォール、Cookie ベースのセッション アフィニティ、URL パスベースのルーティング、無料の証明書、複数のドメイン管理などが用意されています。 Azure Front Door の特徴と機能の詳細については、「 レベルの比較」を参照してください。

Azure Front Door ではどのようなプロトコルがサポートされていますか?

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

Azure Front Door は HTTP/2 をどのようにサポートしますか?

Azure Front Door では、クライアント接続の HTTP/2 プロトコルがサポートされています。 ただし、バックエンド プールの通信では HTTP/1.1 プロトコルが使用されます。 HTTP/2 サポートはデフォルトでオンになっています。

Azure Front Door は gRPC をサポートしていますか?

いいえ。 現在、Azure Front Door では、エッジから配信元までの HTTP/1.1 のみがサポートされています。 gRPCを機能させるには、HTTP/2が必要です。

Azure Front Door は HTTP から HTTPS へのリダイレクトをサポートしていますか?

Azure Front Door を使用して、URL のホスト、パス、クエリ文字列コンポーネントをリダイレクトできます。 URL リダイレクトの設定方法については、 URL リダイレクトを参照してください。

AFD は、各要求に対して AFD が処理するルール エンジン ルールを示すテレメトリを提供しますか?

はい。 [アクセス ログ] の [MatchedRulesSetName] プロパティを参照してください。

AFDは「HTTP/2 Rapid Reset」DDoS攻撃からの保護を提供できますか?

はい。 詳細については、「 HTTP/2 に対する DDoS 攻撃に対する Microsoft の対応」を参照してください。

Azure Front Door は 'x-forwarded-for' ヘッダーを保持しますか?

Azure Front Door では、X-Forwarded-For、X-Forwarded-Host、X-Forwarded-Proto ヘッダーがサポートされています。 これらのヘッダーは、Front Door が元のクライアント IP とプロトコルを識別するのに役立ちます。 X-Forwarded-For が既に存在する場合、Front Door はクライアント ソケット IP を一覧の末尾に追加します。 それ以外の場合は、クライアントソケット IP を値としてヘッダーを作成します。 X-Forwarded-Host と X-Forwarded-Proto の場合、Front Door は既存の値を独自の値に置き換えます。

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

Azure Front Door には、仮想ネットワーク内でトラフィックを負荷分散またはルーティングする機能はありますか?

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

Front Door を他のサービスと共にデプロイする

Application Gateway を Front Door の背後にデプロイする必要があるのはいつですか?

Front Door の背後にある Application Gateway は、次の状況で役立ちます。

  • トラフィックをグローバルに分散するだけでなく、仮想ネットワーク内でも分散する必要があります。 Front Door では、グローバル レベルでのみパスベースの負荷分散を行うことができますが、Application Gateway では仮想ネットワーク内で実行できます。
  • Front Door でサポートされていない接続ドレインが必要です。 Application Gateway では、VM またはコンテナーの Connection Draining を有効にすることができます。
  • すべての TLS/SSL 処理をオフロードし、仮想ネットワーク内の HTTP 要求のみを使用する必要があります。 Front Door の背後にある Application Gateway では、このセットアップを実現できます。
  • セッション アフィニティをリージョン レベルとサーバー レベルの両方で使用する必要があります。 Front Door は、ユーザー セッションからリージョン内の同じバックエンドにトラフィックを送信できますが、Application Gateway はバックエンド内の同じサーバーにトラフィックを送信できます。

Front Door の背前または前に、外部ベンダーから別の CDN をデプロイできますか?

2つのCDNをチェーンすることは一般的に推奨されるアプローチではなく、機能しますが、次の短所があります

  1. CDN のラスト マイル アクセラレーションでは、原点との接続ストリームを維持し、最適な結果を得るために原点への最適なパスを見つけることを利用します。 2つのCDNを連結すると、通常、ラストマイルの加速による利点の一部が打ち消されます。
  2. セキュリティ制御は、2 番目の CDN での効果が低下します。 クライアント IP ベースの ACLing は、2 番目の CDN では 1 番目の CDN の出口ノードがクライアント IP として認識されるため、2 番目の CDN では機能しません。 コンテンツ ペイロードは引き続き検査されます。
  3. 多くの組織は、2つのCDNがチェーンされているトラブルシューティングの複雑さに対処できず、問題が発生した場合、どのCDNに問題があるのかを特定するのが難しくなります。

Azure Load Balancer を Front Door の背後にデプロイできますか?

Azure Front Door を使用するには、パブリック VIP またはパブリックにアクセス可能な DNS 名が必要です。 Azure Front Door では、パブリック IP を使用してトラフィックを配信元にルーティングします。 一般的なシナリオは、Front Door の背後に Azure Load Balancer をデプロイすることです。 Azure Front Door Premium で Private Link を使用して、内部ロード バランサーに接続することもできます。 詳細については、「 内部ロード バランサーで Private Link を有効にする」を参照してください。

Front Door プロファイル/エンドポイントの背後で Azure CDN を構成することも、その逆も行うことは可能ですか?

Azure Front Door と Azure CDN は、アプリケーションに高速で信頼性の高い Web 配信を提供する 2 つのサービスです。 ただし、Azure エッジ サイトの同じネットワークを共有してユーザーにコンテンツを配信するため、相互に互換性はありません。 この共有ネットワークは、ルーティング ポリシーとキャッシング ポリシーの間で競合を引き起こします。 そのため、パフォーマンスとセキュリティの要件に応じて、アプリケーションに対して Azure Front Door または Azure CDN を選択する必要があります。

別の Front Door プロファイル/エンドポイントの背後に Azure Front Door プロファイル/エンドポイントを構成できますか。または、その逆を行うことができますか?

両方のプロファイル/エンドポイントが同じ Azure Edge POP を使用して受信要求を処理するという事実により、1 つの Azure Front Door プロファイル/エンドポイントを別のプロファイル/エンドポイントの背後に入れ子にできないという制限が発生します。 この設定では、ルーティングの競合とパフォーマンスの問題が発生します。 そのため、アプリケーションに複数のプロファイル/エンドポイントを使用する必要がある場合は、Azure Front Door のプロファイル/エンドポイントが連結されていないことを確認する必要があります。

Front Door の IP アドレスとサービス タグ

Front Door のエニーキャスト IP は、その有効期間中同じままですか?

Front Door のフロントエンド エニーキャストの IP アドレスは固定されており、Front Door を使用している限り変更されない場合があります。 ただし、Front Door のフロントエンド エニーキャストの固定 IP アドレスは保証されません。 IPに直接依存することは避けてください。 IP アドレスの変更時に常に情報を入手し、適切なアクションを実行するには、 Service Tag Discovery API または JSON ファイルを使用して最新の IP アドレスを定期的にフェッチする自動化を開発します。

Azure Front Door は静的 IP または専用 IP を提供しますか?

Azure Front Door は、トラフィックを利用可能な最適なバックエンドにルーティングする動的なサービスです。 現時点では、静的または専用のフロントエンドエニーキャストIPは提供していません。

Front Door がサポートするネットワーク サービス タグは何ですか?

Azure Front Door では、次の 3 つのサービス タグを使用して、クライアントと配信元の間のトラフィックを管理します。

  • AzureFrontDoor.Backend サービス タグには、Front Door が配信元にアクセスするために使用する IP アドレスが含まれています。 配信元のセキュリティを構成するときに、このサービス タグを適用できます。
  • AzureFrontDoor.Frontend サービス タグには、クライアントが Front Door に到達するために使用する IP アドレスが含まれています。 AzureFrontDoor.Frontend サービス タグは、Azure Front Door の背後にあるサービスに接続できる送信トラフィックを制御する場合に適用できます。
  • AzureFrontDoor.FirstParty サービス タグは、Azure Front Door でホストされている Microsoft サービスの一部のグループ用に予約されています。

Azure Front Door サービス タグのシナリオの詳細については、「 使用可能なサービス タグ」を参照してください。 IP アドレスの変更時に常に情報を入手し、適切なアクションを実行するには、 Service Tag Discovery API または JSON ファイルを使用して最新の IP アドレスを定期的にフェッチする自動化を開発します。

コンフィギュレーション

Azure Front Door の配信元と配信元グループを作成するためのベスト プラクティスは何ですか?

配信元グループは、同様の種類の要求を処理できる配信元のコレクションです。 異なるアプリケーションまたはワークロードごとに異なる配信元グループが必要です。

配信元グループでは、リクエストを処理できるすべてのサーバーまたはサービスの配信元を作成します。 配信元に Azure Application Gateway などのロード バランサーがある場合、またはロード バランサーがある PaaS でホストされている場合、配信元グループには配信元が 1 つだけあります。 配信元は、Front Door が認識しない配信元間のフェールオーバーと負荷分散を処理します。

たとえば、Azure App Service でアプリケーションをホストする場合、Front Door の設定方法は、所有しているアプリケーション インスタンスの数によって異なります。

  • 単一リージョンのデプロイ: 配信元グループを 1 つ作成します。 その配信元グループで、App Service アプリの配信元を 1 つ作成します。 App Service アプリはワーカー間でスケールアウトする可能性がありますが、Front Door には 1 つのオリジンが表示されます。
  • マルチリージョンのアクティブ/パッシブデプロイ: 配信元グループを 1 つ作成します。 その配信元グループで、App Service アプリごとに配信元を作成します。 各オリジンの優先度を設定して、メインアプリケーションの優先度がバックアップアプリケーションよりも高くなるようにします。
  • マルチリージョンのアクティブ/アクティブデプロイ: 1 つの配信元グループを作成します。 その配信元グループで、App Service アプリごとに配信元を作成します。 各オリジンの優先度を同じに設定します。 各オリジンの重みを設定して、そのオリジンに送信されるリクエストの数を制御します。

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

Azure Front Door のタイムアウトと制限の既定値と最大値は何ですか?

Azure Front Door は、アプリケーションに高速で信頼性の高い Web 配信を提供するサービスです。 キャッシング、ロードバランシング、セキュリティ、ルーティングなどの機能を提供します。 ただし、Azure Front Door に適用されるいくつかのタイムアウトと制限に注意する必要があります。 これらのタイムアウトと制限には、最大要求サイズ、最大応答サイズ、最大ヘッダー サイズ、ヘッダーの最大数、ルールの最大数、および配信元グループの最大数が含まれます。 これらのタイムアウトと制限の詳細については、 Azure Front Door のドキュメントを参照してください。

Azure Front Door は、Front Door ルール エンジンに追加された新しいルールを適用するためにどのくらいの時間を必要としますか?

ほとんどのルールセットの設定更新は、20 分以内に完了します。 このルールは、更新が完了した直後に適用されます。

クライアントから Azure Front Door へのヘッダー タイムアウトの値はいくつですか?

Azure Front Door では、クライアントからヘッダーを受信するためのタイムアウトが 5 秒あります。 クライアントが TCP/TLS 接続を確立した後、5 秒以内に Azure Front Door にヘッダーを送信しない場合、接続は終了します。 このタイムアウト値は構成できません。

Azure Front Door の HTTP キープアライブ タイムアウトの値はどれくらいですか?

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

2 つの異なる Front Door エンドポイントに同じドメインを使用することは可能ですか?

Front Door では要求ごとにルート (プロトコル + ホスト + パスの組み合わせ) を区別する必要があるため、複数の Front Door エンドポイントに同じドメインを使用することはできません。 異なるエンドポイント間でルートが重複している場合、Azure Front Door は要求を正しく処理できません。

ダウンタイムなしで、1 つの Front Door エンドポイントから別の Front Door エンドポイントにドメインを移行することは可能ですか?

現時点では、サービスを中断することなく、あるエンドポイントから別のエンドポイントにドメインを移動するオプションは提供していません。 ドメインを別のエンドポイントに移行する場合は、ある程度のダウンタイムを計画する必要があります。

Azure Front Door Privatelink の統合は、配信元がある地域ではサポートされていません。 どうしようか。

Azure Front Door Private Link 機能はリージョンに依存せず、配信元のリージョンとは異なるリージョンを選択した場合でも機能します。 このような場合、待機時間を短縮するために、Azure Front Door Private Link エンドポイントを有効にすることを選択するときは、常に配信元に最も近い Azure リージョンを選択する必要があります。 現在、より多くの地域でのサポートを有効にする作業を進めています。 新しいリージョンがサポートされたら、次の 手順に従って 、トラフィックを新しいリージョンに徐々に移行できます。

[パフォーマンス]

Azure Front Door では、サービスの高可用性とスケーラビリティをどのように確保していますか?

Azure Front Door は、世界中にトラフィックを分散し、アプリケーションの要求に合わせてスケールアップできるプラットフォームです。 Microsoft のグローバル ネットワーク エッジを使用して、障害が発生した場合にアプリケーション全体または特定のマイクロサービスを別のリージョンまたはクラウドに切り替えることができるグローバル負荷分散機能を提供します。

オリジンからの範囲のレスポンスをキャッシュするための条件は何ですか?

大きなファイルを配信する際のエラーを回避するには、オリジンサーバーがレスポンスに Content-Range ヘッダーを含めていること、およびヘッダー値がレスポンス本文の実際のサイズと一致していることを確認してください。

大きなファイルの配信元と Front Door を構成する方法の詳細については、「 大きなファイルの配信」を参照してください。

TLS の構成

Azure Front Door はドメイン フロンティングをどのようにブロックしますか?

ドメインフロンティングは、攻撃者がTLSハンドシェイクとHTTPホストヘッダーで異なるドメイン名を使用して、悪意のあるリクエストの実際の宛先を隠すことを可能にするネットワーク手法です。

2022 年 11 月 8 日以降に作成された Azure Front Door (Standard、Premium、Classic レベル) または Microsoft (クラシック) リソースの Azure CDN Standard では、ドメイン フロンティングのブロックが有効になっています。 SNI ヘッダーとホスト ヘッダーが一致しない要求をブロックするのではなく、2 つのドメインが同じサブスクリプションに属し、ルート/ルーティング ルールに含まれている場合は、不一致を許可します。 ドメインフロンティングのブロック適用は、2024年1月22日に、既存のすべてのドメインに対して開始されます。 この施行がすべての地域に反映されるまでに、最大で 2 週間かかる場合があります。

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

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

ドメイン フロンティングの詳細については、「 Azure 内のドメイン フロンティングへのアプローチのセキュリティ保護 」および「 Azure Front Door でのドメイン フロンティングの禁止」および「Microsoft の Azure CDN Standard (クラシック)」を参照してください。

Azure Front Door ではどの TLS バージョンがサポートされていますか?

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

Azure Front Door では、TLS 1.2 または 1.3 を使用することを選択できます。 詳細については、 Azure Front Door のエンド ツー エンド TLS に関する記事を参照してください。

請求書

無効になっている Azure Front Door リソースに対して課金されますか?

Azure Front Door リソースを無効にすることはできません。 これらは削除することしかできません。 データ転送アウト、データ転送イン、要求などの可変メーターは、トラフィックがない場合は課金されませんが、トラフィックがない場合でも基本料金が課金されます。 基本料金は、プロファイルが削除されるまで課金されます。 AFD クラシックの場合、WAF のポリシーとルールは、状態に関係なく課金されます。 WAFポリシーまたはルールを無効にしても、コストは発生します。

キャッシュ処理

HTTPリクエストヘッダーをキャッシュキーとして使用することは可能ですか?

いいえ。

Front Door は ETag をサポートしていますか?

いいえ。

8 MB を超えるファイルサイズの圧縮をサポートすることは可能ですか?

AFD は、8 MB を超えるコンテンツの動的圧縮をサポートしていません。 ただし、コンテンツが配信元によって既に圧縮されている場合、Front Door では、範囲要求がサポートされ、チャンク転送エンコードが有効になっていない限り、8 MB を超える静的圧縮コンテンツの提供がサポートされます。

AFD は、キャッシングが有効になっている場合、HTTP リクエストでの Authorization ヘッダーの設定をサポートしていますか?

いいえ。

診断とログ記録

Azure Front Door が提供するメトリックとログは何ですか?

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

診断ログの保持期間はどのくらいですか?

診断ログを独自のストレージ アカウントに保存し、保持する期間を選択できます。 または、診断ログを Event Hubs または Azure Monitor ログに送信することもできます。 詳細については、Azure Front Door の診断に関するページを参照してください。

Azure Front Door の監査ログにアクセスする手順を教えてください。

Azure Front Door の監査ログにアクセスするには、ポータルにアクセスする必要があります。 メニュー ページから Front Door を選択し、 [アクティビティ ログ] を選択します。 アクティビティ ログには、Azure Front Door の操作の記録が表示されます。

Azure Front Door のアラートを構成するにはどうすればよいですか?

Azure Front Door のアラートは、 メトリックまたはログに基づいて設定できます。 これにより、フロントエンド ホストのパフォーマンスと正常性を監視できます。

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

関連コンテンツ