本文將協助您為您的工作負載選擇合適的 Azure 負載平衡服務。 它比較了 Azure Load Balancer、Application Gateway 和 Azure Front Door 在區域及全球流量分配上的差異。 它也會說明何時將它們合併使用。 若想了解更簡短的逐項服務概述，請參見「 什麼是負載平衡與內容傳遞？」
本文涵蓋的內容
應用程式交付涵蓋流量在抵達網路邊界後，您的網路如何將其分配到各後端資源。 本文涵蓋第 4 層與第 7 層的負載平衡以及全域流量加速。 同時也涵蓋了在三種主要 Azure 負載平衡服務中選擇的決策標準。
Note
本文是 《網際網路輸入：將你的應用程式公開到網際網路》 的補充說明，其重點在於說明流量如何到達你的網路。 本文著重於 如何 平衡並將流量傳遞到你的應用程式後端。
誰需要這篇文章
如果你符合以下情況，請閱讀這篇文章：
- 裝載需要在多個後端執行個體上實現高可用性的 Web 應用程式或 API。
- 需要 SSL/TLS 卸載處理、依據 URL 的路由，或 Web 應用程式防火牆（WAF）為 HTTP/HTTPS 流量提供保護。
- 將流量分散到多個 Azure 區域以達成效能或災難復原。
- 執行非 HTTP 工作負載（TCP/UDP），需要區域負載平衡並搭配健康探針。
- 想了解哪個負載平衡器最適合你的流量類型、地理範圍和安全需求。
隨即轉移重點：許多重新裝載的內部應用程式只需要區域負載平衡器。 當你向客戶發布應用程式時，加入面向網路的配送服務。
現代化重點：依應用程式類型選擇傳遞：針對全球 Web 應用程式，使用 Azure Front Door；針對非 Web 應用程式，使用流量管理員，並將其置於主動-主動區域端點之前。
跨雲焦點：將其他雲端的負載平衡器映射到 Azure 等效系統（例如 AWS ALB 映射到 Application Gateway，NLB 映射到 Azure Load Balancer），並透過樞紐防火牆後方的輻射傳送。
Azure 服務與功能
下表總結了三種主要的 Azure 負載平衡服務。
| 服務 | 它所提供的是什麼 | 何時使用它 | 主要限制 |
|---|---|---|---|
| Azure 標準負載平衡器 | 第四層（TCP/UDP）區域內的負載平衡。 健康探針、區域冗餘、出站 SNAT 規則，以及用於網路虛擬設備的 HA 埠。 | 虛擬機器擴展集、AKS 內部流量、非 HTTP/HTTPS 區域工作負載，以及 NVA 高可用性。 | 沒有 SSL/TLS 終止；沒有網頁應用程式防火牆（WAF）；沒有依據 URL 的路由；僅限區域範圍。 |
| Azure 應用程式閘道 | 第七層（HTTP/HTTPS）區域負載平衡。 SSL/TLS 終止、基於 URL 路徑的路由、多站點主機、基於 Cookie 的會話親和性，以及可選的 WAF 整合。 | 需要 SSL 卸載、URL 路由、WebSocket 支援或 WAF 保護的區域性網頁應用程式。 | 僅限區域;需要專用子網;不適合用於全球路由或 CDN 情境。 |
| Azure Front Door | 全域單播負載平衡與 CDN。 在邊緣進行 TLS 終止，整合式 WAF，來源健全狀態探查，流量分流，以及在超過 190 個全球存在點 (PoP) 上的快取。 | 全球網路應用程式、多區域主動部署、CDN 與快取，以及全球 WAF 強制執行。 | 僅限 HTTP/HTTPS；來源必須可公開存取，或可透過 Private Link（Premium 層）連線。 |
區域備援
區域冗餘保護你的應用程式交付層免於資料中心故障。 每個服務對可用性區域的處理方式不同：
- Standard Load Balancer（公共）預設為區域冗餘，因為標準公共 IP 預設為區域冗餘配置。 即使有一個可用區失效，流量仍會繼續流動。 Standard Load Balancer（內部）需要明確的區域冗餘前端設定：建立前端 IP 時必須選擇多個區域。
- 應用閘道 v2 支援在多個可用區域部署實例時的區域冗餘。 部署時指定區域。 區域冗餘的應用閘道會將實例分散到你選擇的區域，當單一區域離線時仍能維持可用性。
- Azure Front Door 是全域任播服務，因此本身即具有區域備援能力。 其超過 190 個邊緣 PoP，遍布全球多個區域，因此沒有任何單一區域或區域故障會影響全球流量路由。
Autoscaling
每個服務對規模的處理方式不同：
- 應用閘道 v2 （包含 Standard_v2 層與 WAF_v2 層）支援根據流量負載進行自動擴展。 你設定最小和最大實例數，閘道器會在這些範圍內擴展。 定價使用容量單位：即每秒新增連線數、持續連線數與吞吐量的綜合衡量。 為生產工作負載設定至少兩個實例數，以避免流量高峰時出現冷啟動延遲。
- Azure Front Door 會自動擴展為全球受管理服務。 你不需要進行容量規劃或實例規模調整。
- Standard Load Balancer 可擴展至數百萬個 TCP/UDP 流程，無需人工介入或設定變更。 這是一個完全受控的平台服務，沒有實例概念。
健康探針
這三個服務都使用健康探測來偵測不健康的後端並停止流量導向這些後端：
- Standard Load Balancer 支援 TCP、HTTP 及 HTTPS 健康探測。 設定探測間隔與不健康狀態閾值，以控制故障轉移速度。 較短的間隔能更快偵測故障，但產生更多探測流量。
-
應用閘道 使用 HTTP/HTTPS 健康探測器，具備可自訂的路徑、主機名稱及回應匹配功能。 自訂探測器可讓你驗證應用程式邏輯（例如，檢查可驗證資料庫連線能力的
/health端點）。 - Front Door 會對來源伺服器執行 HTTP/HTTPS 健康狀態探查。 它支援可設定的探針路徑、區間及回應碼匹配。 Front Door 從多個 PoP 探測來源，提供分散式健康驗證。
如何選擇
以下流程圖總結了選擇 Azure 負載平衡服務的主要決策路徑。
請使用以下決策表，為您的情境選擇合適的負載平衡服務。
我需要哪個負載平衡器？
| 我需要...... | 使用 |
|---|---|
| 單一區域內的 TCP/UDP 流量負載平衡 | Azure Standard Load Balancer：第四層分布，包含健康探針、區域冗餘及 HA 埠口。 |
| 終止 SSL/TLS，依照 URL 路徑或主機名稱路由，並為區域網頁應用程式新增 WAF | Azure 應用程式閘道：具備整合 WAF（v2 SKU）的第 7 層區域負載平衡。 |
| 透過全域路由 HTTP/HTTPS 流量、使用邊緣快取降低延遲，或跨區域進行容錯移轉 | Azure Front Door：全球單播，支援 CDN、WAF 及多區域起源健康探測。 |
關鍵約束比較
| 服務 | 層 | Scope | 關鍵限制 |
|---|---|---|---|
| Standard Load Balancer | 第 4 層 （TCP/UDP） | 區域性 | 沒有應用程式感知：無法檢查 HTTP 標頭、URL 或 Cookie。 |
| 應用程式閘道 | 第 7 層 （HTTP/HTTPS） | 區域性 | 需要專用子網路（建議 /24）;無法全域路由流量。 |
| Front Door | 第 7 層 （HTTP/HTTPS） | 全球 | 來源必須是公開的，或可透過 Private Link（僅限高級等級）存取;不支援 TCP/UDP。 |
合併服務
許多生產架構將多個負載平衡服務整合成鏈條。 各服務各自擅長：
- 前門+應用閘道器： 使用 Front Door 進行全球流量分發與邊緣 WAF，然後路由至區域應用閘道實例進行基於 URL 路徑的路由與後端池管理。 Front Door Premium 可透過 Private Link 連接應用程式閘道，保持應用程式閘道的私密性。 此模式適用於多區域部署，每個區域都有複雜的 URL 路由需求。
- Front Door + Load Balancer：使用 Front Door 進行全球 HTTP/HTTPS 分發，並在其背後設置內部 Standard Load Balancer，將流量分配至區域內的 虛擬機器擴展集 或 NVA。 Front Door 負責全球路由與快取，而 Load Balancer 則提供第四層分布以計算實例。
- Application Gateway + Load Balancer：在同一部署中，前端使用 Application Gateway 管理 HTTP/HTTPS 流量，並使用 Load Balancer 管理非 HTTP 後端層級（資料庫、訊息佇列）。 這種模式將第 7 層智慧保留在邊緣，並在內部採用輕量的第 4 層分流。
路由能力
了解路由能力有助於縮小選擇範圍：
| 能力 | Standard Load Balancer | 應用程式閘道 | Front Door |
|---|---|---|---|
| 基於 URL 路徑的路由 | No | Yes | Yes |
| 多站（主機標頭）路由 | No | Yes | Yes |
| Cookie 型工作階段同質 | No | Yes | Yes |
| 加權流量分配 | No | No | Yes |
| 地理路線 | No | No | Yes |
| SSL/TLS 卸載處理 | No | Yes | Yes |
| WebSocket 支援 | 穿透 | Yes | Yes |
| HTTP/2 支援 | No | Yes | Yes |
Tip
Application Gateway v2 會在最小和最大實例數之間自動擴展，即使流量閒置，你也至少要付費到最低容量。 把最低實例數設為你的基線負載，而不是峰值，讓自動縮放吸收尖峰。 將最低設定值配置過高，是造成應用程式閘道成本增加的常見且可避免原因。
設計考量
隨即轉移應用程式交付設計重點
- 使用內部 Azure Load Balancer 來處理重新託管的應用程式各層之間的東西向流量，以符合該應用程式原本所依賴的負載平衡方式。
- 只為對外開放到網際網路的應用程式新增公用傳遞服務；許多已移轉的內部工作負載根本不需要。
- 在初次重載時，保持傳送設計簡單且單一區域。
- 在任何進站網路流量到達工作負載前，先將它經過集線器防火牆。
現代化應用程式交付設計重點
- 依應用程式類型選擇：Azure Front Door 用於全球網頁應用（邊緣終端、WAF），非網頁應用則可選擇 Azure 流量管理員，且需要基於 DNS 的區域分發。
- 在不同區域部署主動-主動架構，並將流量分配至各區域位於中樞防火牆後方的公用端點，而該防火牆負責執行 SNAT 和 DNAT。
- 當您需要全球傳遞時，請在 Front Door 後方使用 Application Gateway 進行區域第 7 層路由與 TLS 終止。
- 針對同一個流程，不要同時部署 Front Door 和 Traffic Manager；請根據應用程式是 Web 型還是非 Web 型來擇一。
跨雲應用程式交付設計重點
- 將其他雲端的交付服務映射到 Azure：AWS Application Load Balancer 或 Google Cloud Application Load Balancing 到 Azure 應用程式閘道，以及網路負載平衡器到 Azure Load Balancer。
- 在輪輻中裝載第 7 層傳遞功能 (應用程式閘道，搭配 WAF)，並避免將公用 IP 直接指派至虛擬機器。
- 讓公用輸入流量在到達已遷移的工作負載之前，先經過受保護的中樞防火牆進行路由。
- 當工作負載在多個 Azure 區域運行時，使用 Front Door 或 Traffic Manager 來進行多區域傳送。
先決條件
在實施應用程式交付服務之前：
- 部署的虛擬網路： 你需要至少有一個帶有子網的虛擬網路。 關於子網路規劃的指引，請參見 虛擬網路與子網設計 。
- 識別的工作負載流量類型： 了解你的工作負載是使用 HTTP/HTTPS（第 7 層）還是 TCP/UDP（第 4 層）。 這種流量類型決定了你主要的負載平衡器選擇。
- 地理範圍定義： 判斷你的用戶是分布在單一區域，還是分散在全球。 全球用戶群都能從 Front Door 的單播加速中受益。
- 應用閘道的子網容量： 應用閘道需要一個專用子網路，且沒有其他資源。 一個 /24 子網路最多支援 125 個實例及五個 Azure 保留位址。
安全性考慮
負載平衡服務是你安全防護的一部分。 它們是處理進來流量的第一批元件，因此安全性設定變得至關重要。 遵循這些做法以保護您的申請交付層級。
Web 應用程式防火牆 （WAF）
針對所有生產環境 Web 工作負載，在應用程式閘道或 Front Door 上以預防模式啟用 WAF。 偵測模式只會記錄威脅，但不會阻擋它們。 在初始微調期間使用它來識別誤判，然後在生產流量開始之前切換到預防模式。
WAF 可防範常見的網路攻擊，包括：
- SQL 注入與跨站腳本（XSS）
- 協議異常與請求走私
- 機器人與爬蟲（附有機器人保護規則）
- 透過受管理的規則集防範 OWASP Top 10 漏洞
應用程式閘道 WAF 與 Front Door WAF 使用相同的規則引擎，但範圍不同。 應用閘道 WAF 保護區域部署，而前門 WAF 則在流量抵達任何來源前，於全球邊緣強制執行政策。 關於詳細的 WAF 調整與規則集設定，請參見 Web 應用程式防火牆。
DDoS 保護
在所有與負載平衡服務相關的公共 IP 位址上啟用 Azure DDoS 保護。 Standard Load Balancer 的公開前端 IP 與應用閘道的公開 IP 是體積攻擊的主要目標。 這些 IP 代表你應用程式的入口點。
Azure DDoS Protection 提供：
- 全天候流量監控並具備調適型微調功能。
- 當流量超過門檻時，自動進行攻擊緩解。
- 透過 Azure 監視器 提供攻擊遙測資料與警示。
- 針對因 DDoS 攻擊觸發的資源擴展提供成本保障（服務抵免）。
關於DDoS防護的規劃與設定，請參見 DDoS防護。
私人連結到來源 (Front Door 進階版)
Azure Front Door Premium 支援對來源的 Private Link 連線。 此功能消除了對公開可存取後端伺服器的需求。 Front Door 會透過 Azure 骨幹網路連線到您的來源，而不是透過公用網際網路。 在下列情況下使用 Private Link 來源：
- 你的後端是內部服務，不應該有公開 IP 位址。
- 您需要將來源存取權限限制在僅 Front Door 流量。
- 合規要求禁止在應用伺服器上設置公共端點。
- 您想要移除公開暴露的來源的攻擊面。
支援的 Private Link 來源包括 App Service、Azure 儲存體、Application Gateway、內部 Standard Load Balancer，以及帶有 Private Link 服務的自訂來源。
關於 Private Link 架構模式，請參見 Private Access to Azure PaaS services。
Important
Front Door 標準層不支援私人連結來源。 只有 Front Door Premium 提供此功能。
雙向 TLS （mTLS）
應用程式閘道 v2 支援使用雙向 TLS 進行後端驗證。 當你的後端伺服器需要閘道器以憑證為基礎的客戶端認證時，請使用 mTLS。 這種認證增加了信任驗證的層次。 後端可以確認流量來自合法的應用閘道實例，而非來自繞過閘道器的惡意行為者。
相關文章
- 什麼是負載平衡與內容傳遞？：Azure 應用程式閘道、Load Balancer 與 Front Door 的逐項服務概述。
- 網際網路入口：將您的應用程式暴露於網際網路：流量如何抵達您的 Azure 網路邊界。
- 虛擬網路與子網設計：子網規劃，包括應用閘道專用子網大小。
- 對 Azure PaaS 服務的私人存取權限：包括 Front Door 進階版在內的私人連結模式，可追溯到來源。
- 跨區域連接：多區域架構，以 Front Door 作為全球入口點。
- 輸出網際網路出口：SNAT、輸出規則和 NAT 閘道，用於負載平衡後端的出站流量。
瞭解更多資訊
- 什麼是 Azure Load Balancer？
- 什麼是Azure 應用程式閘道？
- Azure Front Door 是什麼？
- 依都會區劃分的 Azure Front Door 邊緣位置
- Reliability in Azure Load Balancer
- 應用程式閘道基礎結構組態
- 透過 Azure Front Door Premium 中的 Private Link 保護您的來源
下一步
Tip
自己探索？ 回到 總覽導航 器，依能力尋找你的下一篇文章。
您的隨即轉移之旅的下一步：
控制外撥網路流量：透過你的中樞防火牆集中外撥存取，並關閉預設外撥。
接下來的現代化旅程：
建立私人連接 PaaS 服務：在每個 Spoke VNet 中為你的 AKS、ASE 及管理式資料庫工作負載建立 Private Link 子網路。
接下來的跨雲端旅程：
保護您的跨雲中轉路徑：在您的安全虛擬樞紐部署 Azure 防火牆，檢查所有跨雲及網際網路流量。