Azure Front Door 上的 Azure Well-Architected Framework 檢視方塊
Azure Front Door 是全域負載平衡器和內容傳遞網路，可路由傳送 HTTP 和 HTTPS 流量。 Azure Front Door 會傳遞和散發最接近應用程式使用者的流量。
本文假設身為架構設計人員，您已檢閱 負載平衡選項 ，並選擇 Azure Front Door 作為工作負載的負載平衡器。 它也假設您的應用程式部署至主動-主動或主動-被動模型中的多個區域。 本文中的指引提供對應至 Azure Well-Architected Framework 要素原則的架構建議。
重要
如何使用本指南
每個區段都有一個 設計檢查清單 ，可呈現主題的架構區域，以及當地語系化為技術範圍的設計策略。
本文也包含可協助具體化這些策略的技術功能 建議 。 建議並不代表 Azure Front Door 及其相依性的所有可用設定完整清單。 相反地，他們會列出對應至設計觀點的主要建議。 使用建議來建置概念證明或優化您現有的環境。
示範重要建議的基礎架構： 具有網路控制的任務關鍵性基準架構。
技術範圍
此檢閱著重於下列 Azure 資源的相互關聯決策：
- Azure Front Door
可靠性
可靠性要素的目的是要 藉由建置足夠的復原能力，以及從失敗快速復原的能力，來提供持續的功能。
可靠性設計原則提供針對個別元件、系統流程和整個系統套用的高階設計策略。
設計檢查清單
根據 可靠性的設計檢閱檢查清單，開始您的設計策略。 判斷其與業務需求的相關性，同時請記住階層和 Azure 內容傳遞網路功能。 擴充策略，視需要包含更多方法。
估計流量模式和磁碟區。 從用戶端到 Azure Front Door Edge 的要求數目可能會影響您的階層選擇。 如果您需要支援大量要求，請考慮 Azure Front Door 進階層，因為效能最終會影響可用性。 不過，有成本取捨。 效能 效率會說明這些層級。
選擇您的部署策略。 基本部署方法為 主動-主動 和 主動-被動。 主動-主動部署表示執行工作負載的多個環境或戳記會提供流量。 主動-被動部署表示只有主要區域會處理所有流量，但在必要時故障轉移至次要區域。 在多區域部署中，戳記會在不同區域中執行，以取得全域負載平衡器等全域負載平衡器，以散發流量的高可用性。 因此，請務必為適當的部署方法設定負載平衡器。
Azure Front Door 支持數種路由方法，您可以設定在主動-主動或主動-被動模型中散發流量。
上述模型有許多變化。 例如，您可以使用暖備援來部署主動-被動模型。 在此情況下，次要裝載服務會部署最少可能的計算和數據大小調整，且不會載入執行。 故障轉移時，計算和數據資源會調整以處理主要區域的負載。 如需詳細資訊，請參閱 多區域設計的主要設計策略。
有些應用程式需要用戶連線，才能在用戶會話期間停留在相同的源伺服器上。 從可靠性的觀點來看，我們不建議將用戶連線保留在相同的源伺服器上。 盡可能避免會話親和性。
在 Azure Front Door 和源伺服器上使用相同的主機名。 若要確保 Cookie 或重新導向 URL 正常運作，請在 Web 應用程式前面使用反向 Proxy，例如負載平衡器時，保留原始 HTTP 主機名。
實作健康情況端點監視模式。 您的應用程式應該公開健康情況端點，這會匯總應用程式需要處理要求的重要服務和相依性的狀態。 Azure Front Door 健康情況探查會使用端點來偵測源伺服器的健康情況。 如需詳細資訊，請參閱健康情況端點監視模式 \(部分機器翻譯\)。
利用 Azure Front Door 中的內建內容傳遞網路功能。 Azure Front Door 的內容傳遞網路功能有數百個邊緣位置，可協助承受分散式阻斷服務 (DDoS) 攻擊。 這些功能有助於改善可靠性。
請考慮備援流量管理選項。 Azure Front Door 是全域散發的服務，可在環境中以單一方式執行。 Azure Front Door 是系統中可能的單一失敗點。 如果服務失敗，用戶端就無法在停機期間存取您的應用程式。
備援實作可能十分複雜且昂貴。 請只將其視為具有非常低中斷容錯的任務關鍵性工作負載。 仔細考慮 取捨。
建議
| 建議 | 優點 |
|---|---|
| 選擇支援部署策略的 路由方法 。 加權方法會根據設定的權數係數散發流量，可支援主動-主動模型。 優先順序型值，可設定主要區域以接收所有流量，並將流量傳送至次要區域，作為備份支持主動-被動模型。 將上述方法與延遲結合，讓來源與最低的延遲接收流量。 |
您可以使用一系列決策步驟和設計來選取最佳原始資源。 選取的來源會以指定的權數比例，在允許的延遲範圍內提供流量。 |
| 藉由在 一或多個後端集區中有多個來源來支持備援。 一律有應用程式的備援實例，並確定每個實例都會公開端點或來源。 您可以將這些來源放在一或多個後端集區中。 |
多個來源支援備援，方法是將流量分散到應用程式的多個實例。 如果一個實例無法使用，則其他後端來源仍然可以接收流量。 |
|
在原點上設定健康情況探查。 設定 Azure Front Door 進行健康情況檢查，以判斷後端實例是否可用，並準備好繼續接收要求。 |
啟用的健康情況探查是健康情況監視模式實作的一部分。 健康情況探查可確保 Azure Front Door 只會將流量路由傳送至狀況良好且足以處理要求的實例。 如需詳細資訊，請參閱 健康情況探查的最佳做法。 |
| 設定將要求轉送至後端的逾時。 根據您的端點需求調整逾時設定。 如果沒有，Azure Front Door 可能會在來源傳送回應之前關閉連線。 如果所有來源都有較短的逾時，您也可以降低 Azure Front Door 的預設逾時。 如需詳細資訊，請參閱 針對沒有回應的要求進行疑難解答。 |
逾時可藉由終止超過預期完成的要求，協助防止效能問題和可用性問題。 |
| 在 Azure Front Door 和您的原點上使用相同的主機名。 Azure Front Door 可以重寫傳入要求的主機標頭，當您有多個路由傳送至一個來源的自定義功能變數名稱時，這非常有用。 不過，重寫主機標頭可能會導致要求 Cookie 和 URL 重新導向的問題。 |
設定相同的主機名，以防止會話親和性、驗證和授權發生問題。 如需詳細資訊，請參閱在反向 Proxy 與其後端 Web 應用程式之間 保留原始 HTTP 主機名 。 |
| 決定您的應用程式是否需要 會話親和性。 如果您有高可靠性需求，建議您停用會話親和性。 | 使用會話親和性時，用戶聯機會在使用者會話期間維持在相同的原點上。 如果該來源變成無法使用，用戶體驗可能會中斷。 |
| 利用 Web 應用程式防火牆隨附的 速率限制規則 ， (WAF) 。 | 限制要求以防止客戶端傳送太多流量至您的應用程式。 速率限制可協助您避免重試 Storm 之類的問題。 |
安全性
安全性要素的目的是要為工作負載提供 機密性、完整性和可用性 保證。
安全性設計原則提供高階設計策略，可藉由將方法套用至技術設計，以限制透過 Azure Front Door 提供的流量來達成這些目標。
設計檢查清單
根據 安全性的設計檢閱檢查清單，開始您的設計策略。 識別弱點和控件，以改善安全性狀態。 擴充策略，視需要包含更多方法。
檢閱 Azure Front Door 的安全性基準。
保護後端伺服器。 前端可作為應用程式的單一輸入點。
Azure Front Door 會使用 Azure Private Link 來存取應用程式的來源。 Private Link 會建立分割，讓後端不需要公開公用IP位址和端點。 如需詳細資訊，請參閱在 Azure Front Door Premium 中使用 Private Link 保護您的來源。
將您的後端服務設定為只接受具有 Azure Front Door 外部使用之相同主機名的要求。
只允許對控制平面的授權存取。 使用 Azure Front Door 角色型存取控制 (RBAC) 來限制只存取需要它的身分識別。
封鎖邊緣的常見威脅。 WAF 已與 Azure Front Door 整合。 在前端啟用 WAF 規則，以保護應用程式免於網路邊緣的常見惡意探索和弱點，更接近攻擊來源。 請考慮異地篩選，以限制依國家或地區存取您的 Web 應用程式。
如需詳細資訊，請參閱 Azure Front Door 上的 Azure Web 應用程式防火牆。
保護 Azure Front Door 免於發生非預期的流量。 Azure Front Door 使用 Azure DDoS 保護的基本方案 來保護應用程式端點免於遭受 DDoS 攻擊。 如果您需要從應用程式公開其他公用IP位址，請考慮為這些位址新增 DDoS Protection 標準方案，以取得進階保護和偵測功能。
另外還有 WAF 規則集，可偵測 Bot 流量，或可能可能是惡意的大量流量。
保護傳輸中的數據。 啟用端對端傳輸層安全性 (TLS) 、HTTP 至 HTTPS 重新導向，以及適用的受控 TLS 憑證。 如需詳細資訊，請參閱 Azure Front Door 的 TLS 最佳做法。
監視異常活動。 定期檢閱記錄以檢查攻擊和誤判。 將 WAF 記錄從 Azure Front Door 傳送至組織的集中式安全性資訊和事件管理 (SIEM) ，例如 Microsoft Sentinel，以偵測威脅模式，並在工作負載設計中納入預防措施。
建議
| 建議 | 優點 |
|---|---|
| 啟用WAF規則集，以偵測和封鎖潛在的惡意流量。 這項功能適用於進階層。 我們建議這些規則集： - 預設 - Bot 保護 - IP 限制 - 異地篩選 - 速率限制 |
默認規則集會根據 Microsoft 威脅情報的前 10 名攻擊類型和資訊，經常更新。 特製化規則集會偵測特定使用案例。 例如，Bot 規則會根據用戶端 IP 位址，將 Bot 分類為良好、不良或未知。 它們也會封鎖錯誤的 Bot 和已知的 IP 位址，並根據呼叫者的地理位置來限制流量。 藉由使用規則集的組合，您可以使用各種意圖來偵測和封鎖攻擊。 |
|
建立 Managed 規則集的排除專案。 在偵測模式中測試 WAF 原則數周，並在部署前調整任何誤判。 |
減少誤判，並允許應用程式的合法要求。 |
| 將 主機標頭 傳送至後端。 | 後端服務應該注意主機名，讓他們可以建立規則，只接受來自該主機的流量。 |
| 在適用時啟用端對端 TLS、HTTP 至 HTTPS 重新導向，以及受控 TLS 憑證。 檢閱 Azure Front Door 的 TLS 最佳做法。 使用 TLS 1.2 版做為與應用程式相關的密碼的最低允許版本。 Azure Front Door 受控憑證應該是您的預設選擇，以方便操作。 不過，如果您想要管理憑證的生命週期，請在 Azure Front Door 自定義網域端點中使用您自己的憑證，並將其儲存在 金鑰保存庫 中。 |
TLS 可確保瀏覽器、Azure Front Door 和後端來源之間的數據交換會經過加密，以防止竄改。 金鑰保存庫 提供受控憑證支援，以及簡單的憑證更新和輪替。 |
成本最佳化
成本優化著重於 偵測支出模式、優先處理重要領域的投資，以及優化其他人 以符合組織的預算，同時符合商務需求。
成本優化設計原則提供高階設計策略，以達成這些目標，並在與 Azure Front Door 及其環境相關的技術設計中視需要進行取捨。
設計檢查清單
根據成本 優化投資的設計檢閱檢查清單 ，開始您的設計策略。 微調設計，讓工作負載符合為工作負載配置的預算。 您的設計應該使用正確的 Azure 功能、監視投資，以及尋找一段時間優化的機會。
檢閱 Azure Front Door 層和定價。 使用 定價計算機 來預估每一層的實際成本。 針對您的案例，比較每個層級的功能和適用性。 例如，只有進階層支援透過 Private Link 連線到您的來源。
標準 SKU 更符合成本效益，適用於中等流量案例。 在進階 SKU 中，您會支付較高的單位費率，但您可以存取安全性權益和進階功能，例如 WAF 中的受控規則和 Private Link。 根據您的業務需求考慮可靠性和安全性的取捨。
請考慮頻寬成本。 Azure Front Door 的頻寬成本取決於您選擇的層級和數據傳輸的類型。 Azure Front Door 提供可計費計量的內建報告。 若要評估與頻寬相關的成本，以及您可以將優化工作放在何處，請參閱 Azure Front Door 報告。
優化傳入要求。 Azure Front Door 會向傳入要求計費。 您可以在設計組態中設定限制。
使用 前端 後端和 閘道匯總等設計模式來減少要求數目。 這些模式可以改善作業的效率。
WAF 規則會限制傳入流量，以將成本優化。 例如，使用速率限制來防止異常高層級的流量，或使用地理篩選只允許來自特定區域或國家/地區的存取。
有效率地使用資源。 Azure Front Door 使用可協助資源優化的路由方法。 除非工作負載非常延遲敏感，否則請將流量平均分散到所有環境，以有效地使用已部署的資源。
Azure Front Door 端點可以提供許多檔案。 降低頻寬成本的其中一種方式是使用壓縮。
針對不常變更的內容，在 Azure Front Door 中使用快取。 因為內容是從快取提供，所以您可以節省在要求轉送至後端時所產生的頻寬成本。
請考慮使用組織所提供的共享實例。 集中式服務所產生的成本會在工作負載之間共用。 不過，請考慮 使用可靠性取捨。 對於具有高可用性需求的任務關鍵性應用程式，我們建議使用自發實例。
請注意所記錄的數據量。 如果不需要特定要求，或記錄數據保留很長一段時間，則與頻寬和記憶體相關的成本可能會累算。
建議
| 建議 | 優點 |
|---|---|
| 針對支援的端點使用快取。 | 快取可優化數據傳輸成本，因為它可將 Azure Front Door 實例的呼叫數目減少到原點。 |
|
請考慮啟用檔案壓縮。 針對此設定，應用程式必須支援壓縮，而且必須啟用快取。 |
壓縮可減少頻寬耗用量，並改善效能。 |
| 停用單一後端集區中的健康情況檢查。 如果您的 Azure Front Door 原始來源群組中只有一個原始來源設定，則不需要這些呼叫。 |
您可以停用不需要進行路由決策的要求，以節省頻寬成本。 |
卓越營運
營運卓越主要著重於 開發實務、可觀察性和發行管理的程式。
營運卓越設計原則提供高階設計策略，以達成工作負載作業需求的那些目標。
設計檢查清單
根據 營運卓越的設計檢閱檢查清單 來開始您的設計策略，以定義與 Azure Front Door 相關的可觀察性、測試和部署程式。
使用基礎結構即程式代碼 (IaC) 技術。 使用 Bicep 和 Azure Resource Manager 範本等 IaC 技術來布建 Azure Front Door 實例。 這些宣告式方法提供一致性和直接的維護。 例如，藉由使用 IaC 技術，您可以輕鬆地採用新的規則集版本。 一律使用最新的 API 版本。
簡化組態。 使用 Azure Front Door 輕鬆地管理設定。 例如，假設您的架構支援微服務。 Azure Front Door 支援 重新導向功能，因此您可以使用路徑型重新導向以個別服務為目標。 另一個使用案例是通配符網域的設定。
使用 Azure Front Door 路由方法來處理漸進式曝光。 針對 加權負載平衡方法 ，您可以使用 Canary 部署，將特定百分比的流量傳送至後端。 此方法可協助您在受控制的環境中測試新功能和版本，再推出這些功能。
收集及分析 Azure Front Door 作業數據，作為工作負載監視的一部分。 使用 Azure 監視器記錄擷取相關的 Azure Front Door 記錄和計量。 此數據可協助您針對使用者行為進行疑難解答、瞭解用戶行為，以及優化作業。
將憑證管理卸除至 Azure。 簡化與認證輪替和更新相關聯的作業負擔。
建議
| 建議 | 優點 |
|---|---|
| 使用 HTTP 至 HTTPS 重新導向 來支援向前相容性。 | 啟用重新導向時，Azure Front Door 會自動將使用較舊通訊協定的用戶端重新導向，以使用 HTTPS 來進行安全體驗。 |
|
擷取記錄和計量。 包含資源活動記錄、存取記錄、健康情況探查記錄和 WAF 記錄。 設定警示。 |
監視輸入流程是監視應用程式的重要部分。 您想要追蹤要求並改善效能和安全性。 您需要數據來偵錯 Azure Front Door 設定。 有了警示，您可以立即收到任何重大作業問題的通知。 |
| 檢閱 內建的分析報告。 | Azure Front Door 配置檔的整體檢視可協助根據流量和安全性報告，透過 WAF 計量來推動改善。 |
| 盡可能使用受控 TLS 憑證。 | Azure Front Door 可以為您發出和管理憑證。 這項功能可消除憑證更新的需求，並將因無效或過期 TLS 憑證而中斷的風險降到最低。 |
| 使用通配符 TLS 憑證。 | 您不需要修改組態，即可個別新增或指定每個子網域。 |
效能效率
效能效率是關於 維護用戶體驗，即使 透過管理容量來增加負載也一定。 此策略包括調整資源、識別和優化潛在的瓶頸，以及優化尖峰效能。
效能效率設計原則提供高階設計策略，以針對預期的使用量達成這些容量目標。
設計檢查清單
根據 效能效率的設計檢閱檢查清單，開始您的設計策略。 定義以 Azure Front Door 的主要效能指標為基礎的基準。
藉由分析預期的流量模式來規劃容量。 進行徹底測試，以瞭解應用程式在不同負載下執行的方式。 請考慮同時交易、要求速率和數據傳輸等因素。
根據您的 SKU 選擇進行規劃。 標準 SKU 更符合成本效益，適用於中等流量案例。 如果您預期負載較高，建議您使用進階 SKU。
定期檢閱 Azure Front Door 報告來分析效能數據。 這些報告提供各種計量的深入解析，這些計量可作為技術層級的效能指標。
使用 Azure Front Door 報告來設定工作負載的實際效能目標。 請考慮回應時間、輸送量和錯誤率等因素。 將目標與您的業務需求和使用者期望一致。
優化數據傳輸。
使用快取來減少靜態內容的延遲，例如影像、樣式表單和 JavaScript 檔案，或不會經常變更的內容。
將您的應用程式優化以進行快取。 在應用程式中使用快取到期標頭，以控制用戶端和 Proxy 應該快取內容的時間長度。 較長的快取有效性表示源伺服器較不頻繁的要求，這會導致流量降低和延遲降低。
減少透過網路傳輸的檔案大小。 較小的檔案會導致載入時間更快，並改善用戶體驗。
將應用程式中的後端要求數目降到最低。
例如，網頁會顯示使用者配置檔、最近的訂單、餘額和其他相關信息。 不要對每組資訊提出個別的要求，而是使用設計模式來建構應用程式，以便將多個要求匯總成單一要求。
藉由匯總要求，您會在前端與後端之間傳送較少的數據，並在用戶端與後端之間建立較少的連線，以減少額外負荷。 此外，Azure Front Door 會處理較少的要求，以防止多載。
優化健康情況探查的使用。 只有在來源的狀態變更時，才會從健康狀態探查取得健康情況資訊。 在監視精確度與最小化不必要的流量之間達到平衡。
健康情況探查通常用來評估群組內多個來源的健康情況。 如果您的 Azure Front Door 原始來源群組中只有一個原始來源設定，請停用健康狀態探查以減少源伺服器上的不必要的流量。 因為只有一個實例，所以健康情況探查狀態不會影響路由。
檢閱原始路由方法。 Azure Front Door 提供各種路由方法，包括延遲型、優先順序型、加權和會話親和性型路由至原始來源。 這些方法會大幅影響應用程式的效能。 若要深入瞭解案例的最佳流量路由選項，請參閱 流量路由方法到來源。
檢閱源伺服器的位置。 您的源伺服器位置會影響應用程式的回應性。 源伺服器應該更接近使用者。 Azure Front Door 可確保來自特定位置的使用者存取最接近的 Azure Front Door 進入點。 效能優點包括更快的用戶體驗、更能使用 Azure Front Door 的延遲型路由，以及使用快取將內容儲存在更接近使用者的數據傳輸時間降到最低。
如需詳細資訊，請參閱 依位置的流量報告。
建議
| 建議 | 優點 |
|---|---|
|
啟用快取。 您可以針對 快取優化查詢字串。 若為純靜態內容，請忽略查詢字串，以充分利用快取。 如果您的應用程式使用查詢字串，請考慮將它們包含在快取索引鍵中。 在快取索引鍵中包含查詢字串，可讓 Azure Front Door 根據您的設定來提供快取回應或其他回應。 |
Azure Front Door 提供強固的內容傳遞網路解決方案，可在網路邊緣快取內容。 快取可減少後端伺服器上的負載，並減少網路上的數據移動，這有助於卸除頻寬使用量。 |
| 當您存取可下載的內容時，請使用檔案壓縮。 | Azure Front Door 中的壓縮可協助以最佳格式傳遞內容、具有較小的承載，並將內容更快傳遞給使用者。 |
當您在 Azure Front Door 中設定健康情況探查時，請考慮使用 HEAD 要求而不是 GET 要求。 健康狀態探查只會讀取狀態代碼，而不是內容。 |
HEAD 要求可讓您查詢狀態變更，而不擷取其整個內容。 |
| 評估是否應將來自相同使用者的要求導向至相同的後端伺服器時啟用 會話親和性 。 從可靠性的觀點來看，我們不建議使用此方法。 如果您使用此選項，應用程式應該正常復原，而不會中斷用戶會話。 負載平衡也有取捨，因為它會限制將流量平均分散到多個後端的彈性。 |
優化使用者會話的效能和維護持續性，特別是當應用程式依賴在本機維護狀態資訊時。 |
Azure 原則
Azure 提供一組與 Azure Front Door 及其相依性相關的大量內建原則。 您可以透過 Azure 原則稽核上述一些建議。 例如，您可以檢查：
- 您需要進階層來支援 Azure Front Door 配置檔中的受控 WAF 規則和 Private Link。
- 您必須使用最低 TLS 版本，也就是 1.2 版。
- 您需要 Azure Front Door Premium 與 Azure PaaS 服務之間的安全、私人連線。
- 您必須啟用資源記錄。 WAF 應該已啟用要求本文檢查。
- 您必須使用原則來強制執行 WAF 規則集。 例如，您應該啟用 Bot 保護，並開啟速率限制規則。
如需完整的治理，請檢閱 Azure 內容傳遞網路的內建定義，以及 Azure 原則 內建原則定義中列出的其他 Azure Front Door 原則。
Azure Advisor 建議
Azure Advisor 是個人化的雲端顧問，可協助您遵循最佳做法來將 Azure 部署最佳化。 以下是一些建議，可協助您改善 Azure Front Door 的可靠性、安全性、成本效益、效能和營運卓越。
下一步
請考慮下列文章作為資源，示範本文中反白顯示的建議。
- 使用下列參考架構作為如何將本文指引套用至工作負載的範例：
- 使用下列產品檔建置實作專業知識：