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

Azure Front Door は、アプリケーションをより迅速かつ確実に提供するクラウドベースのサービスです。 レイヤー 7 の負荷分散が使用されているため、複数のリージョンとエンドポイントにトラフィックが分散されます。 また、Web パフォーマンスと凖リアルタイム フェールオーバーを最適化して高可用性を確保するための動的サイト アクセラレーション (DSA) も備わっています。 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 Application Gateway はどちらも HTTP/HTTPS トラフィック用のロード バランサーですが、スコープはそれぞれ異なります。 Front Door は複数のリージョン間で要求を分散できるグローバル サービスであり、Application Gateway は 1 つのリージョン内で要求のバランスを取ることができるリージョン サービスです。 Azure Front Door はスケール ユニット、クラスター、またはスタンプ ユニットと連携しますが、Azure Application Gateway は同じスケール ユニット内の VM、コンテナー、またはその他のリソースと連携します。

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

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

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

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

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

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

• ストレージ (Azure BLOB、クラシック、静的 Web サイト)
• クラウド サービス
• App Service
• 静的 Web アプリ
• API Management
• Application Gateway
• パブリック IP アドレス
• Traffic Manager
• Azure Spring Apps
• Container Instances
• コンテナー アプリ
• パブリック アクセスが可能な任意のカスタム ホスト名。

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

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

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

Azure Front Door は、アプリケーションを複数のリージョンにグローバルに分散するサービスです。 すべてのお客様が共有する一般的なインフラストラクチャが使用されますが、独自の Front Door プロファイルをカスタマイズしてアプリケーションの特定の要件を構成することもできます。 他のお客様の構成が、お使いの Front Door の構成に影響を及ぼすことはありません。構成は互いに分離しています。

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

Front Door では、Web アプリケーションのルートは並べ替えられません。 代わりに、要求に最適なルートが選択されます。 Front Door による要求とルートのマッチング方法については、、Front Door による要求とルーティング規則のマッチング方法に関するページを参照してください。

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

Front Door のフロントエンド エニーキャストの IP アドレスは固定されており、Front Door を使用している限り変わることはほとんどありません。 ただし、Front Door のフロントエンド エニーキャストの固定 IP アドレスは保証されません。 IP に直接依存することは避けてください。

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

正解です。 [アクセス ログ] で MatchedRulesSetName プロパティを参照してください。

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

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 ヘッダーに関するページを参照してください。

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

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

Azure Front Door Standard、Premium、または (クラシック) レベルを使用するには、パブリック IP またはパブリックに解決可能な DNS 名が必要です。 パブリック IP またはパブリックに解決可能な DNS 名を要件とすることで、Azure Front Door ではバックエンド リソースにトラフィックをルーティングできます。 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 アプリごとに配信元を作成します。 メイン アプリケーションの優先度がバックアップ アプリケーションよりも高くなるように、各配信元の優先度を設定します。
• 複数リージョンのアクティブ/アクティブ デプロイ: 1 つの配信元グループを作成します。 その配信元グループで、App Service アプリごとに配信元を作成します。 各配信元の優先度が同じになるように設定します。 各配信元の重みを設定して、その配信元に送信される要求の数を制御します。

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

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

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

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

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

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

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

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

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

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

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

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

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

大きなファイルを配信するときのエラーを回避するには、配信元サーバーの応答に Content-Range ヘッダーが含まれていて、ヘッダー値が応答本文の実際のサイズと一致していることを確認します。

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

ドメイン フロンティングとは、攻撃者が TLS ハンドシェイクと HTTP ホスト ヘッダーで別のドメイン名を使用して、悪意のある要求の真の宛先を隠すネットワーク手法です。

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

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

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

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

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

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

Azure Front Door は、高速で安全な Web 配信を提供するサービスです。 これにより、Web トラフィックを複数のリージョンとエンドポイント間でルーティングおよび最適化する方法を定義できます。 Front Door プロファイルやルーティング規則などの Azure Front Door リソースは、有効になっている場合にのみ課金されます。 ただし、Web アプリケーション ファイアウォール (WAF) のポリシーと規則は、状態に関係なく課金されます。 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 のアラートは、メトリックまたはログに基づいて設定できます。 これにより、フロントエンド ホストのパフォーマンスと正常性を監視できます。

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

次のステップ

• Azure Front Door プロファイルを作成する方法について学習します。
• Azure Front Door アーキテクチャについて確認します。