Front Door 的最佳做法

本文摘要說明使用 Azure Front Door 的最佳做法。

一般最佳做法

避免合併 流量管理員和 Front Door

針對大部分的解決方案，我們建議使用 Front Door 或 Azure 流量管理員，但不是兩者。 Azure 流量管理員 是以 DNS 為基礎的負載平衡器。 它會將流量直接傳送至來源的端點。 相反地，Azure Front Door 會在用戶端附近的存在點 （PoP） 終止連線，並建立與來源的個別長期連線。 產品的運作方式不同，且適用於不同的使用案例。

如果您需要內容快取和傳遞 （CDN）、TLS 終止、進階路由功能或 Web 應用程式防火牆 （WAF），請考慮使用 Front Door。 若要使用從用戶端直接連線到端點的簡單全域負載平衡，請考慮使用 流量管理員。 如需選取負載平衡選項的詳細資訊，請參閱 負載平衡選項。

不過，作為需要高可用性的複雜架構的一部分，您可以將 Azure 流量管理員 放在 Azure Front Door 前面。 在 Azure Front Door 無法使用的不太可能情況下，Azure 流量管理員 接著可以將流量路由傳送至替代目的地，例如 Azure 應用程式閘道 或合作夥伴內容傳遞網路 （CDN）。

重要

請勿將 Azure 流量管理員 放在 Azure Front Door 後面。 Azure 流量管理員 應該一律位於 Azure Front Door 前面。

限制來源的流量

Front Door 的功能在流量僅流經 Front Door 時的效果最佳。 您應該將來源設定為封鎖未透過 Front Door 傳送的流量。 如需詳細資訊，請參閱保護針對 Azure Front Door 來源的流量。

使用最新的 API 版本和 SDK 版本

當您使用 API、ARM 範本、Bicep 或 Azure SDK 使用 Front Door 時，請務必使用最新的可用 API 或 SDK 版本。 API 和 SDK 更新會在新功能可用時發生，也包含重要的安全性修補程式和錯誤修正。

設定記錄

Front Door 會追蹤每個要求的相關廣泛遙測。 當您啟用快取時，源伺服器可能不會收到每個要求，因此請務必使用 Front Door 記錄來瞭解解決方案的執行方式，並回應用戶端。 如需 Azure Front Door 記錄計量和記錄的詳細資訊，請參閱 監視 Azure Front Door 和 WAF 記錄中的計量和 記錄。

若要為您自己的應用程式設定記錄，請參閱 設定 Azure Front Door 記錄

TLS 最佳做法

使用端對端 TLS

Front Door 會終止來自用戶端的 TCP 和 TLS 連線。 然後，它會從每個存在點 （PoP） 建立新的連線到來源。 最好是使用 TLS 保護每個連線，即使是裝載在 Azure 中的來源。 此方法可確保您的數據在傳輸期間一律會加密。

如需詳細資訊，請參閱 使用 Azure Front Door 的端對端 TLS。

使用 HTTP 至 HTTPS 重新導向

用戶端使用 HTTPS 連線到您的服務是很好的作法。 不過，有時候您需要接受 HTTP 要求，以允許可能不瞭解最佳做法的較舊用戶端或用戶端。

您可以將 Front Door 設定為自動重新導向 HTTP 要求以使用 HTTPS 通訊協定。 您應該啟用 [ 重新導向所有流量] 以在路由上使用 HTTPS 設定。

使用受控 TLS 認證

當 Front Door 管理 TLS 認證時，會降低您的營運成本，並協助您避免因忘記續訂認證而造成成本高昂的中斷。 Front Door 會自動發出並輪替受控 TLS 認證。

如需詳細資訊，請參閱使用 Azure 入口網站 在 Azure Front Door 自定義網域上設定 HTTPS。

針對客戶管理的憑證使用「最新」版本

如果您決定使用自己的 TLS 憑證，請考慮將 金鑰保存庫 憑證版本設定為 「最新」。 藉由使用「最新」，您可以避免重新設定 Front Door 以使用新版本的憑證，並等候在 Front Door 環境中部署憑證。

如需詳細資訊，請參閱 選取要部署的 Azure Front Door 憑證。

功能變數名稱最佳做法

在 Front Door 和您的來源上使用相同的網域名稱

Front Door 可以重寫 Host 傳入要求的標頭。 當您管理一組路由至單一來源的客戶對應自定義功能變數名稱時，這項功能會很有説明。 當您想要避免在 Front Door 和來源中設定自定義功能變數名稱時，這項功能也可以有所説明。 不過，當您重寫 Host 標頭時，要求 Cookie 和 URL 重新導向可能會中斷。 特別是當您使用像是 Azure App 服務 的平臺時，會話親和性和驗證和授權等功能可能無法正常運作。

在重寫 Host 要求的標頭之前，請仔細考慮您的應用程式是否正常運作。

如需詳細資訊，請參閱 在反向 Proxy 與其後端 Web 應用程式之間保留原始 HTTP 主機名。

Web 應用程式防火牆 （WAF）

啟用 WAF

針對因特網對向應用程式，建議您啟用 Front Door Web 應用程式防火牆 （WAF），並將其設定為使用受控規則。 當您使用 WAF 和 Microsoft 管理的規則時，您的應用程式會受到各種攻擊的保護。

如需詳細資訊，請參閱 Azure Front Door 上的 Web 應用程式防火牆 （WAF）。

遵循 WAF 最佳做法

Front Door 的 WAF 有自己的設定和使用最佳做法集。 如需詳細資訊，請參閱 Azure Front Door 上 Web 應用程式防火牆 的最佳做法。

健康情況探查最佳做法

當原始群組中只有一個來源時，停用健康情況探查

Front Door 的健康情況探查是設計來偵測來源無法使用或狀況不良的情況。 當健康情況探查偵測到來源問題時，Front Door 可以設定為將流量傳送至來源群組中的另一個來源。

如果您只有單一來源，則 Front Door 始終會將流量路由至該來源，即使其健全狀態探查報告了狀況不良狀態也是如此。 健全狀態探查的狀態不會執行任何動作來變更 Front Door 的行為。 在此案例中，健康情況探查不會提供權益，您應該停用它們以減少來源上的流量。

如需詳細資訊，請參閱 健康情況探查。

選取良好的健康情況探查端點

請考慮您告訴 Front Door 健康情況探查要監視的位置。 監視您特別設計用於健康情況監視的網頁或位置通常是個好主意。 您的應用程式邏輯可以考慮提供生產流量所需的所有重要元件狀態，包括應用程式伺服器、資料庫和快取。 如此一來，如果有任何元件失敗，Front Door 可以將流量路由傳送至服務的另一個實例。

如需詳細資訊，請參閱 健全狀況端點監視模式

使用 HEAD 健康情況探查

健康情況探查可以使用 GET 或 HEAD HTTP 方法。 最好使用 HEAD 方法進行健康情況探查，以減少來源的流量負載量。

如需詳細資訊，請參閱 健康情況探查支援的 HTTP 方法。

下一步

瞭解如何 建立 Front Door 配置檔。