Microsoft AZ-104: Azure 負載平衡與流量管理 — 學習指南

By Laurynas Brazys · 7 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

屬於 Microsoft Azure Administrator Associate AZ-104 — 學習指南. 使用經過驗證的解答練習： Microsoft 考試中心, 或參加限時模擬考試： ExamRoll.io.

概觀

Azure 提供一個分層的產品組合來分散和保護流量：Azure Load Balancer (第 4 層, TCP/UDP)、Application Gateway (第 7 層, HTTP/S)、Azure Front Door (全球第 7 層邊緣)、Azure Traffic Manager (以 DNS 為基礎) 以及 Azure CDN (邊緣快取)。每項服務都針對請求路徑中的特定區段——從全球 DNS 決策和邊緣 POP，到區域性 HTTP 路由以及私人的東西向流量。精通的關鍵在於根據協定和目標對象選擇正確的服務、適當地組合它們，並設定健康狀態探查和規則以驅動可靠的容錯移轉。

Azure Load Balancer (L4)：SKU、建構區塊、NAT/輸出以及浮動 IP

Standard Load Balancer 是生產等級的 L4 負載平衡器。它具備區域感知/區域備援能力，支援 HA 連接埠、進階診斷/計量、預設安全 (除非您定義規則，否則沒有輸入流量)、可設定的輸出規則，以及大規模的後端。Basic 是一個舊版 SKU，其規模/功能有限且不具備區域備援；它即將被淘汰，不應為新的工作負載選擇此 SKU。

核心元件定義了流量的流動方式：

• 前端 IP：向用戶端公開的 VIP。外部 LB 使用公用 IP 或公用 IP 前置詞；內部 LB 使用來自子網路的私人靜態 IP。Standard SKU 支援多個前端和區域備援的公用 IP。
• 後端集區：位於相同區域/VNet 中的 NIC、NIC 上的 IP 組態或虛擬機器擴展集執行個體。單一集區可以服務多個規則。Standard SKU 支援在一個區域內跨區域的後端。
• 健康狀態探查：判斷哪些後端執行個體是健康的。TCP 探查會完成交握；HTTP/HTTPS 探查會對一個路徑發出 GET 請求，並將 200–399 視為成功。您可以控制協定、連接埠、路徑 (針對 HTTP/S)、間隔和狀況不良閾值 (在標記為停止運作前，連續失敗的次數)。
• 負載平衡規則：將一個前端 (IP/連接埠/協定) 綁定到一個後端集區和健康狀態探查。規則設定包括後端連接埠、協定 (TCP/UDP)、工作階段持續性、閒置逾時和浮動 IP (Direct Server Return)。

輸入 NAT 規則是針對個別 VM 的轉譯，它會將特定的前端連接埠轉送到單一後端 NIC/連接埠 (例如，在沒有負載平衡的情況下，將 RDP 或 SSH 公開給一台 VM)。它們不使用健康狀態探查，也不是一種向外擴展的機制。

輸出規則定義了 Standard Load Balancer 後端透過 LB 的公用前端起始連往網際網路連線時的 SNAT 行為。它們讓您能夠控制由哪個前端提供 SNAT 連接埠，以及為每個後端執行個體分配多少連接埠，有助於在高輸出並行性下避免 SNAT 連接埠耗盡。如果 NAT Gateway 附加到子網路，它會取代 LB 的 SNAT；對於一致且可擴展的輸出，應優先使用 NAT Gateway。

浮動 IP (Direct Server Return) 是一個規則選項，當目的地的 IP/連接埠必須端對端地保留時使用。它對於叢集情境是必要的，例如 SQL Server Always On 可用性群組接聽程式。對於 SQL AG，請使用內部 Standard Load Balancer，並以 TCP 探查 (非 HTTP) 指向叢集的探查連接埠，並在 LB 規則上啟用浮動 IP；不要用 HTTP 探查連接埠 1433，因為 SQL 並非 HTTP 工作負載。

內部與外部負載平衡器的選擇取決於目標對象和安全性邊界。當您需要在 VNet 內部或透過私人連線 (VPN/ExpressRoute) 為企業營運應用程式、資料庫和 NVA 公開一個私人 VIP 時，請使用內部 LB。對於面向網際網路的 L4 服務，請使用外部 LB。對於內部 LB，請在目標子網路中指派一個靜態私人前端；對於外部 LB，請綁定一個 Standard Public IP，並可選擇性地使用多個前端。

跨區域負載平衡器 (Cross-region Load Balancer) 提供跨區域的全球性、Anycast 第 4 層負載平衡。您在每個區域部署 Standard Public Load Balancer (區域層)，並將它們的公用前端放入單一全球負載平衡器 (全球層) 的後端。全球 LB 會對每個區域 LB 使用健康狀態探查，並根據 5 元組雜湊 (5-tuple hashing) 的流量對稱性，將用戶端導向至延遲最低的健康區域。它僅支援 TCP/UDP——不進行 TLS 終止——並與區域性的 L7 閘道互補。

Application Gateway (L7) 與 Azure Front Door (全球 L7)

Application Gateway 是一個區域性的第七層 (Layer 7) 反向代理，內建 WAF。它會終止 HTTP/HTTPS 連線、檢查標頭和路徑，並將流量路由至私有或公有後端。

Application Gateway 的主要建構元件：

• 接聽程式 (Listeners)：繫結一個前端 IP/連接埠/主機名稱和 SSL 設定以接受流量。SNI 讓每個 IP 能支援多個 TLS 站台。使用基本接聽程式處理單一站台、多站台接聽程式進行主機式路由，以及使用萬用字元主機來涵蓋廣泛範圍。
• 路由規則與 HTTP 設定：規則將接聽程式對應到後端集區，並指定套用於後端的 HTTP 設定 (協定、連接埠、主機標頭覆寫、以 Cookie 為基礎的親和性、連線耗盡、要求逾時)。您可以重新導向、重寫標頭，或根據 URL 路徑區段進行路由。
• 後端集區 (Backend pools)：目標可以是 NIC IP、FQDN、應用程式服務或虛擬機器擴展集。自訂健康狀態探查會檢查特定路徑/主機，並採用成功的狀態碼。
• WAF：基於 OWASP 核心規則集的保護，提供偵測或預防模式，並具備自訂規則、排除清單，以及在 v2 版本中每個路由的關聯設定。v2 版本支援自動擴展和區域備援。

進階 L7 模式：

• URL 路徑式路由：將 /api/* 路由到微服務，並將 /images/* 路由到靜態來源或 CDN，從而在單一 VIP 後方實現微服務扇出 (fanout)。
• 多站台託管：使用 SNI 接聽程式和基於主機標頭的規則，在單一閘道上託管 contoso.com 和 fabrikam.com。這對於整合很有用，並可透過每個站台的 WAF 策略實現強式隔離。
• SSL 終止：在閘道上卸載 TLS，以進行集中式憑證管理和 WAF 檢查。當後端需要加密或用戶端憑證驗證時，請使用端對端 TLS (重新加密)。

Azure Front Door 在邊緣提供全球 HTTP/HTTPS 負載平衡與加速，採用 anycast、分割 TCP (split TCP) 和 POP 到來源的最佳化技術。它最適合需要全球路由、邊緣 WAF 和可選邊緣快取的面向網際網路的應用程式。

• 全球負載平衡：使用來自多個 POP 的健康狀態探查，將使用者路由至延遲最低的健康來源。來源群組支援基於優先順序和延遲的容錯移轉，並在需要時提供工作階段親和性。
• WAF：受控管規則集，包含機器人保護、自訂規則、地理/IP 篩選、速率限制，以及每個路由的關聯設定。
• 快取：在 Front Door Standard/Premium 中，邊緣快取是整合的；可依路徑定義快取行為、控制查詢字串快取和 TTL，並在全球範圍內卸載靜態內容。
• 健康狀態探查：每個來源群組的探查 (HTTP/HTTPS)，可從不同的 POP 設定路徑、間隔和協定。路由決策會綜合考量健康狀況和延遲。

當有區域性 L7 需求 (私有後端、東西向流量、複雜的重寫) 時，請使用 Application Gateway；而全球 L7、邊緣安全和加速需求，則使用 Front Door。它們通常組合使用：Front Door 位於邊緣，每個區域部署 Application Gateway，閘道後方再使用內部 LB 處理 L4 服務。

Traffic Manager (以 DNS 為基礎) 與 Azure CDN

Traffic Manager 是一種以 DNS 為基礎的全球流量分送服務。它不代理流量；而是根據策略和健康狀況回傳端點的 DNS 名稱/IP，讓用戶端直接連線。健康狀況是透過分散式探查對 HTTP/HTTPS/TCP 端點進行檢查；較低的 TTL 會減少容錯移轉的延遲，但會增加 DNS 查詢量。

• 優先順序 (Priority)：主動/被動容錯移轉。將主要端點放在第一位；除非不健康，否則 Traffic Manager 會一直使用它，然後才容錯移轉到下一個優先順序的端點。
• 加權 (Weighted)：按權重分送流量，以支援漸進式轉換或 A/B 測試。
• 效能 (Performance)：選擇從使用者所在地區到端點之間網路延遲最低的端點。
• 地理 (Geographic)：根據使用者的地理位置進行路由，以符合資料主權或內容本地化的需求。
• 多重值 (Multivalue)：為同一服務回傳多個健康的端點，以支援簡單的用戶端容錯移轉。 您可以巢狀化設定檔以建立混合式策略 (例如，頂層是地理路由，地理區域內再使用加權路由)。當您需要處理非 HTTP 協定、服務無法從邊緣代理中獲益，或需要在異質端點 (Azure、內部部署、第三方) 之間進行 DNS 層級的控制時，請使用 Traffic Manager。

Azure CDN 將靜態和可快取的內容卸載到邊緣 POP，以減少來源負載和延遲。

• 設定檔 (Profiles)：用於容納一或多個端點的容器，這些端點與特定提供者/層級 (例如 Microsoft、Akamai 或 Verizon 系列) 相關聯。設定檔有助於區分環境或成本中心。
• 端點 (Endpoints)：定義來源詳細資料 (主機名稱、來源主機標頭、協定/連接埠) 和邊緣主機名稱。每個設定檔可以有多個端點，用於不同的應用程式或內容類型。
• 快取規則：預設和自訂規則可控制 TTL、路徑式行為、查詢字串處理 (轉送、忽略或快取每個唯一的查詢) 和壓縮。使用規則來強制快取來源 TTL 較短的資產，或略過對動態 API 的快取。
• 自訂網域：將易記的主機名稱與 CDN 管理的 TLS 對應。透過 CNAME 驗證網域所有權，並使用受控管憑證啟用 HTTPS。可視需要與地理篩選或規則引擎結合使用。

設計選擇、跨區域整合與健康狀態探查行為

內部與外部負載平衡器的選擇，取決於使用者群體與路由的曝露程度。如果消費者僅位於私有網路內部，請使用內部 LB 以避免公開曝露並簡化 NSG 的控管。對於網際網路使用者或合作夥伴，請使用公用前端。對於大規模的對外連線，應優先選擇 NAT Gateway 而非 LB 的 SNAT；僅在 LB 的前端必須提供 SNAT 的情況下，才保留輸出規則。

Cross-region Load Balancer 與區域性的 Standard Public Load Balancer 整合，為 TCP/UDP 服務實現主動-主動 (active-active)、全球性的 Layer 4 彈性。將區域性 LB 的公用前端放置於全域 LB 的後端集區中。全域層級的健康狀態探查會反映區域的可用性；路由會導向延遲最低的健康區域，並在整個區域（或其區域性 LB）變得不健康時自動進行容錯移轉。當您需要在不同的 VIP 之下同時支援多種通訊協定時（例如，透過跨區域 LB 的 TCP 服務以及透過 Front Door 的 HTTP/S），請將此方案與 Front Door 結合使用。

健康狀態探查是容錯移轉的真相來源：

• TCP 探查：適用於任何 TCP 服務。完成三向交握 (3-way handshake) 即代表成功。適用於 SQL、SMTP 或自訂的 TCP 通訊協定。
• HTTP/HTTPS 探查：透過請求一個路徑並預期收到 200–399 的回應碼，來驗證應用程式層級的健康狀態。它們允許主機/路徑的自訂，並能區分出應用程式的部分故障。HTTPS 探查會驗證 TLS 交涉，但交握之後的憑證有效性則不予驗證；對於虛擬主機代管的應用程式，請使用正確的主機標頭。
• 狀況不良閾值：Azure Load Balancer 在連續 N 次探查失敗後，會將後端標記為關閉（可設定；預設的間隔很短，以加速容錯移轉）。Application Gateway 和 Front Door 會從多個探測點進行探查，並在它們的探查集合中累積足夠的連續失敗次數時，才將來源視為關閉。復原則需要連續的成功次數。調整間隔與閾值，以在敏感度與狀態抖動 (flapping) 之間取得平衡；確保探查能觸及一個輕量級且具備相依性感知能力的端點。

實務問題情境

Adobe 需要在全球曝露一個多區域的 SaaS，此 SaaS 由 Web 前端、微服務，以及一個 SQL Server Always On 可用性群組所組成，要求具備嚴格的安全性、快速的容錯移轉，以及為全球使用者提供低延遲。他們同時也曝露一個舊有的、以 TCP 為基礎的遙測資料擷取服務。

1. 在邊緣部署 Azure Front Door Standard，並為 www.adobe.com 和 api.adobe.com 設定 WAF 政策與路由。來源是位於美國東部 (East US) 與西歐 (West Europe) 的 Application Gateway，並以延遲路由與優先級容錯移轉的方式分組。

• 原因：Front Door 提供全球 Anycast、邊緣 WAF，以及可選用的快取功能，以加速並保護網際網路的 HTTP/S 流量；它會自動選擇最近的健康區域。

2. 在每個區域部署具備 WAF 的 Application Gateway v2。為兩個主機名稱設定具備 SNI 的多站台接聽程式、指向微服務的 URL 路徑路由，以及指向每個服務 /healthz 的自訂健康狀態探查。啟用端對端 SSL，並將後端主機覆寫為服務的 FQDN。

• 原因：Application Gateway 提供區域性的 L7 路由、貼近應用程式的 WAF 檢測、基於路徑的扇出 (fanout)，以及個別路由的政策；它能安全地連線至私有後端，並處理標頭重寫/重新導向。

3. 在每個區域為 SQL AG 接聽程式部署一個內部的 Standard Load Balancer。設定一個靜態的私有前端、一個指向 Windows 容錯移轉叢集探查連接埠的 TCP 健康狀態探查，以及一條啟用浮動 IP (Floating IP) 並指向接聽程式連接埠的負載平衡規則。

• 原因：SQL 接聽程式需要具備直接伺服器回傳 (Direct Server Return) 的 L4。浮動 IP 保留了目的地的語意，而 TCP 探查能準確地反映 AG 的擁有權。這也呼應了已知的要求：在 1433 連接埠上進行 HTTP 探查是無效的。

4. 使用 Azure Front Door 的快取規則來支援 /static/* 的 Web 靜態資產，設定長的 TTL 與重新驗證，同時為 downloads.adobe.com 上的大型媒體下載建立一個 Azure CDN 設定檔與端點，並具備特定路徑的快取與查詢字串的變化功能。

• 原因：Front Door 快取在邊緣路由的同時，降低了核心 Web 靜態內容的延遲，而專用的 CDN 端點則為下載優化了大型物件的交付，並確保快取政策的獨立性。

5. 透過每個區域的 Standard Public Load Balancer 來發布舊有的 TCP 遙測資料擷取服務，然後在其前端放置一個 Cross-region Load Balancer 作為單一的公用 VIP。設定指向每個區域 LB 的全域探查，並使用延遲路由。

• 原因：該服務是 TCP 而非 HTTP；Cross-region Load Balancer 提供了具備自動容錯移轉與低延遲區域選擇的全域性主動-主動 L4 功能。

6. 僅為一個代管於 Azure 外部的合作夥伴 SFTP 端點，新增一個採用優先級 (Priority) 政策的 Azure Traffic Manager，列出合作夥伴的主要端點以及一個代管於 Azure 的備援端點。

• 原因：Traffic Manager 是以 DNS 為基礎，且可以包含外部端點；它為不希望使用代理的非 HTTP 與第三方目標，提供了簡單的主動/被動容錯移轉。

7. 對於應用程式子網路的對外連線，請附加 NAT Gateway，並移除對 LB 輸出 SNAT 的依賴。在 Azure Monitor 中監控探查結果以及 LB/App Gateway/Front Door 的指標，並調整探查間隔/狀況不良閾值以消除狀態抖動。

• 原因：NAT Gateway 可以可靠地擴展對外連線，而不會耗盡 SNAT 連接埠；精確的健康狀態探查調整能在各個層級上帶來更快、更穩定的容錯移轉行為。

← Azure 虛擬網路 · 所有領域 · Azure 儲存體 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Microsoft →