【Day 14】Azure Load Balancer & Application Gateway：流量調度與高可用防線 feat. AWS 雙強對照

系列專欄：從 AWS 視角征服 Azure：AZ-900 30 天通關實戰
難度指數：★★★★☆
核心考點：Layer 4 vs Layer 7 負載平衡本質差異、Azure Load Balancer（Public vs Internal、Standard vs Basic SKU、5-tuple Hash 雜湊演算法、健康探測機制）、Azure Application Gateway（HTTP/HTTPS 應用層代理、URL Path-based Routing 路徑分流、Multi-site Hosting 多網站代管、Cookie-based Session Affinity 連線階段同質性、SSL/TLS 卸載終止、WAF v2 防護整合）、全域負載平衡四強分工體系（Load Balancer / Application Gateway / Azure Traffic Manager / Azure Front Door）、AWS NLB ↔ ALB ↔ Route 53 ↔ CloudFront 跨雲架構選型。

🎯 前言與今日目標

本文由antigravity ide 產出，昨天 Day 13 我們成功打造了混合雲的「天塹之橋」（VPN Gateway 與 ExpressRoute），讓 Titan 科技的自建機房能安全接入雲端。但當數以萬計的線上用戶、合作夥伴與物聯網裝置同時湧入雲端要塞時，任何單一虛擬機（VM）或單一 API 節點都不可能承受如此龐大的流量衝擊。

要實現真正的高可用性（High Availability, HA）與彈性擴展（Elasticity），就必須在流量入口處部署強大的「調度指揮官」——將成千上萬的連線請求，智慧化地分配到後端健康的伺服器叢集中。

在 AWS 世界裡，架構師的標準武器庫是 Network Load Balancer (NLB) 與 Application Load Balancer (ALB)；而在 Azure 生態中，對應的兩大主力正是 Azure Load Balancer 與 Azure Application Gateway。然而，Azure 不僅有這兩款區域型服務，還擁有全域級的 Azure Traffic Manager 與 Azure Front Door。在 AZ-900 原廠考綱與真實架構實務中，考生最常陷入以下致命誤區：

1. 分不清「第 4 層 (L4)」與「第 7 層 (L7)」的職責邊界：試圖用 Azure Load Balancer 去解析 HTTP 請求路徑（如 /images 或 /api），或者誤以為它能擋下 SQL Injection 攻擊。
2. 混淆「DNS 導流」與「反向代理」的本質：分不清 Traffic Manager（純 DNS 層級解析）與 Front Door / Application Gateway（真正經手封包的反向代理）的架構定位。

今天是 Phase 2「核心運算與網絡要塞」的最後收官日！我們的目標是一口氣征服 Azure 流量調度家族：掌握 L4 與 L7 負載平衡本質差異、Azure Load Balancer 的運作特徵、Application Gateway 的進階應用層功能與 WAF 整合，並建立跨越區域（Regional）與全球（Global）的原廠四強選型決策思維鏈！

📚 Part 1：0.5 小時觀念裝備（AWS ↔ Azure 深度對照）

📐 Azure 流量調度家族四強全景架構圖

           使用者端請求 (Client HTTP/S / TCP 流量)
                             │
       ┌─────────────────────┴─────────────────────┐
       │                                           │
  【區域性 (Regional)】                       【全球性 (Global)】
  針對單一區域內部虛擬網路                    跨越跨國多個 Azure 區域
       │                                           │
 ┌─────┴─────┐                               ┌─────┴─────┐
 │           │                               │           │
 ▼           ▼                               ▼           ▼
第 4 層     第 7 層                         DNS 層      邊緣 L7 ＋ CDN
┌─────────┐ ┌─────────┐                     ┌─────────┐ ┌─────────┐
│ Azure   │ │ App     │                     │ Traffic │ │ Azure   │
│ Load    │ │ Gateway │                     │ Manager │ │ Front   │
│ Balancer│ │ (+WAF)  │                     │         │ │ Door    │
└────┬────┘ └────┬────┘                     └────┬────┘ └────┬────┘
     │           │                               │           │
     ▼           ▼                               ▼           ▼
TCP/UDP     HTTP/HTTPS                      DNS 路由    全球 Anycast
超低延遲    URL 路由/TLS                    跨區分流    WAF+動態加速
(對照 NLB)  (對照 ALB)                      (對照 R53)  (對照 CF+ALB)

讀圖方式：Azure 流量調度服務分為兩大維度——地理範圍（區域性 vs 全球性） 與 網路分層（第 4 層傳輸層 vs 第 7 層應用層 vs DNS 層）。

• 區域性工作負載：非 HTTP/S 的原生 TCP/UDP 流量選用 Azure Load Balancer（L4）；需要 URL 路由、Cookie 階段黏性或 WAF 網頁防護的 Web 流量選用 Application Gateway（L7）。
• 全球跨區域工作負載：僅需依照地理位置或延遲做 DNS 就近導向選用 Traffic Manager；需要邊緣節點加速、SSL 終止與全球 WAF 統一防護選用 Azure Front Door。

📐 AWS ↔ Azure 負載平衡四強深度對比表

┌────────────┬──────────────────────────────┬──────────────────────────────┐
│ 比較維度   │ AWS 對應服務                 │ Azure 主力服務               │
├────────────┼──────────────────────────────┼──────────────────────────────┤
│ L4 區域型  │ Network Load Balancer (NLB)  │ Azure Load Balancer          │
│ L7 區域型  │ Application Load Balancer    │ Azure Application Gateway    │
│ DNS 全球型 │ Amazon Route 53 (Routing)    │ Azure Traffic Manager        │
│ 邊緣全球型 │ CloudFront + ALB + AWS WAF   │ Azure Front Door             │
│ 運作層級   │ Layer 4 / Layer 7 / DNS      │ Layer 4 / Layer 7 / DNS      │
│ 封包解密   │ ALB 支援 TLS 終止            │ App Gateway 支援 TLS 終止    │
│ 網頁防護   │ AWS WAF                      │ Azure Web App Firewall (WAF) │
└────────────┴──────────────────────────────┴──────────────────────────────┘

💡 架構師重點筆記：許多架構師直覺認為「既然有了 Application Gateway，是不是就不需要 Load Balancer 了？」答案是大錯特錯！在經典三層式（Three-tier）架構中，兩者經常協同作戰：前端 Web 入口掛載 Application Gateway 做 URL 路由與 WAF 防禦，而內部的 API 與資料庫層之間，則由內部 Azure Load Balancer 提供極低延遲、高吞吐量的 L4 TCP 流量分發！

🧱 核心服務運作機制與技術剖析

1. Azure Load Balancer（第 4 層傳輸層負載平衡）

• 運作機制：僅檢查封包的 TCP/UDP 標頭，完全不檢查封包 Payload（應用程式內容）。因此具備極致的超低延遲（微秒級）與極高的吞吐量。
• 分流演算法（5-tuple Hash）：預設採用「五元組雜湊」演算法將流量指派給後端集區（Backend Pool）：
  • 來源 IP (Source IP)
  • 來源連接埠 (Source Port)
  • 目的地 IP (Destination IP)
  • 目的地連接埠 (Destination Port)
  • 傳輸通訊協定 (Protocol：TCP 或 UDP)
• 兩大類型：
  • Public Load Balancer（公用負載平衡器）：具備公用 IP，負責將來自網際網路的外部流量分發至內部 VM。
  • Internal / Private Load Balancer（內部負載平衡器）：僅擁有私有 IP，負責在同一個 VNet 內不同層級（如 Web 層到 App 層）之間分流。
• 健康探測（Health Probes）：定期對後端節點發送探測封包（TCP 或 HTTP/HTTPS）。若節點未在時限內回應，負載平衡器會自動將其標記為不健康，並停止向其轉發新連線。

2. Azure Application Gateway（第 7 層應用層閘道器）

Application Gateway 是一個專為 Web 應用程式量身打造的**反向代理（Reverse Proxy）**服務，運作於 OSI 第 7 層，具備高度智慧化的路由與安全能力：

• URL Path-based Routing（路徑型路由）：
  • 請求 http://contoso.com/images/* ➔ 導向至專門處理靜態圖檔的 VM 集區。
  • 請求 http://contoso.com/video/* ➔ 導向至配置高頻寬的影音串流伺服器集區。
• Multi-site Hosting（多網站代管）：
  在同一個 Application Gateway 實體上，僅綁定單一公用 IP，即可依據不同的主機名稱（如 api.contoso.com 與 shop.contoso.com）將請求導向各自獨立的後端集區。
• SSL/TLS Termination / Offloading（憑證卸載終止）：
  用戶端與閘道器之間使用 HTTPS 加密，閘道器內部解密後，可使用未加密的 HTTP 與後端 VM 通訊，大幅減輕後端伺服器進行加解密計算的 CPU 負擔。
• Cookie-based Session Affinity（連線階段同質性／黏性工作階段）：
  透過閘道器注入的 Cookie，確保來自同一瀏覽器的後續請求，始終被導向到同一台後端伺服器（適合傳統需要維護本地 Session 的應用）。
• Web Application Firewall (WAF) 整合：
  原生內建微軟 WAF 引擎（基於 OWASP Core Rule Set），能主動偵測並封鎖常見的 Web 應用威脅，包括 SQL Injection (SQLi)、Cross-Site Scripting (XSS)、遠端程式碼執行 (RCE) 等。

3. 全球級調度雙雄：Traffic Manager vs Front Door

• Azure Traffic Manager (DNS 路由)：
  純粹在 DNS 層運作。當使用者發出 DNS 查詢時，Traffic Manager 根據路由方法（優先權、延遲、地理位置）回傳最合適區域端點的 IP 位址。封包本身不經過 Traffic Manager，因此它無法做 SSL 卸載，也沒有 WAF 功能。
• Azure Front Door (邊緣 Anycast 反向代理 ＋ CDN ＋ WAF)：
  微軟全球邊緣網路（POP 節點）上的第 7 層應用交付平台。採用 Anycast 路由技術，流量在距離用戶最近的邊緣節點立刻進入微軟骨幹網，內建動態網站加速（DSA）、全域快取 CDN、SSL 終止與全域 WAF 防護。

📖 AZ-900 核心名詞解釋與速查

• Azure Load Balancer：運作於 OSI 第 4 層的高效能、超低延遲負載平衡器，僅依據 TCP/UDP 五元組進行流量分發。
• Azure Application Gateway：運作於 OSI 第 7 層的應用程式反向代理服務，支援 URL 路徑路由、多網站代管與 SSL 卸載。
• Web Application Firewall (WAF)：專為保護 Web 應用程式免受常見安全弱點（如 SQL 隱碼攻擊、跨站腳本攻擊）侵害的防火牆模組。
• Azure Front Door：微軟全球級邊緣第 7 層負載平衡與應用程式加速平台，結合 CDN、Anycast 路由與全域 WAF。
• Azure Traffic Manager：基於 DNS 查詢機制的跨區域全域流量分發器，依據最佳延遲或容錯移轉原則回傳端點 IP。
• 5-tuple Hash (五元組雜湊)：由來源 IP、來源連接埠、目的 IP、目的連接埠與通訊協定組成的運算法則，用於 L4 負載平衡器決定分發目標。
• URL Path-based Routing (路徑型路由)：根據 HTTP 請求網址列中的特定路徑（如 /images），智慧化導向不同伺服器集區的第 7 層功能。

🎮 Part 2：1 小時實戰情境 Role-Play

🏛️ 情境背景：Titan 科技全球雙區域 Web 平台的流量調度難題

Titan 科技旗下的旗艦電商交易平台即將迎接雙 11 跨國購物節，全球並發預估將突破每秒 20 萬次請求。系統架構分為兩大部署區域：東亞區域（East Asia，服務亞太用戶）與西歐區域（West Europe，服務歐洲用戶）。

在今日的跨國架構技術審查會上，產品經理與資安主管共同提出了三項硬性架構需求：

1. 業務路徑精確分流：平台入口統一使用 https://shop.titan.com，但所有靜態圖片請求（路徑為 /media/*）必須導向至高記憶體的快取伺服器叢集，而購物車與結帳 API（路徑為 /checkout/*）必須導向至高運算力的交易處理叢集。
2. 應用層資安合規防禦：近期遭受多起有組織的黑客 SQL 注入（SQL Injection）探測，資安政策強制要求在入口端點必須具備自動偵測並攔截 OWASP Top 10 攻擊的能力。
3. 全球就近導向與區域容錯：跨國使用者在瀏覽網站時，必須自動由延遲最低的區域提供服務；當某一區域的伺服器集區遭遇斷電或故障時，流量必須在秒級內無感容錯移轉至另一個健康區域。

CTO 要求架構團隊在一個工作天內評估並推薦最符合這三大需求的雲端網路方案。

🧩 決策任務

為了同時達成「基於 URL 路徑分流、OWASP 攻擊防禦，以及跨區域智慧導流」的複合目標，身為首席架構師，你應向 Titan 科技提出何種架構設計方案？

• A. 在每個區域各部署一座 Azure Load Balancer，並搭配 NSG 規則過濾 SQL 注入攻擊，外層掛載 Traffic Manager 進行跨區導流。
• B. 在入口部署 Azure Front Door（啟用 WAF），由 Front Door 負責全球 Anycast 導流、WAF 防禦與 /media、/checkout 的 URL 路由轉發，後端直接對接各區域的工作負載。
• C. 僅部署 Azure Traffic Manager，並在各區域的虛擬機器本機上安裝防毒軟體來抵禦 SQL 注入與 XSS 攻擊。
• D. 放棄雲端託管負載平衡，在每台 VM 上自行編譯 Nginx 反向代理，手動編寫正規表示式過濾攻擊。

🎯 解題拆解與解析

✅ 正解：B. 部署 Azure Front Door（啟用 WAF）

❌ 深入陷阱拆解：逐一剖析為什麼其他選項致命

• ❌ 選項 A 致命陷阱（L4 無法理解 URL 且 NSG 無法防禦 Web 攻擊）：
  這是 AZ-900 考場上最經典的雙重致命誤區！
  1. Azure Load Balancer 是第 4 層設備：它只看得懂 TCP/UDP 封包頭，根本看不到 HTTP 協定內的 URL 網址列，完全無法執行 /media/* 與 /checkout/* 的路徑分流。
  2. NSG 不是 WAF：NSG 只能根據 IP、連接埠與協定放行或拒絕封包，對於偽裝在正常 TCP 443 封包內部的 SQL Injection 或 XSS 攻擊 payload，NSG 毫無辨識與防禦能力。
• ❌ 選項 C 致命陷阱（Traffic Manager 不經手封包，無法做應用層防禦與 URL 分流）：
  Traffic Manager 僅僅是在 DNS 查詢階段回傳不同的 A 紀錄 IP 位址。一旦 DNS 解析完成，瀏覽器直接與目標 IP 連線，封包根本不經過 Traffic Manager！因此它既無法檢查 URL 路徑，更無法提供 WAF 網頁防護；而仰賴 VM 本地防毒軟體無法在邊界阻斷分散式 Web 攻擊。
• ❌ 選項 D 致命陷阱（高維運負擔與可用性黑洞）：
  在雲端原生時代，自建 Nginx 缺乏原廠的跨區 SLA 保證、自動高可用與威脅情報特徵庫即時更新，大幅增加了維運成本，且無法利用微軟全球 Anycast 骨幹網絡的邊緣加速優勢。

💡 架構師總結思考：

• 如果題目情境是單一區域內部：答案通常是 Application Gateway with WAF。
• 如果題目情境是跨區域、跨全球且需要 WAF 與 URL 分流：最完美的解答正是 Azure Front Door！

🎯 Part 3：AZ-900 精選高頻真題解析 ＋ AWS SAA / CLF 雙雲概念連動

本節精選 5 題核心真題（3 題 ExamTopics 高頻題 ＋ 2 題 gratisexam 歷史題庫題），全數改寫為 Titan 科技實戰情境，剔除已退役技術，並依照原廠思維鏈進行拆解。

📝 AZ-900 真題 1：基於 URL 路徑將 HTTP 流量分流至不同後端集區（ExamTopics 高頻題改編）

題目情境

Titan 科技正在規劃將一套傳統的單體式（Monolithic）電商網站重構為微服務架構。目前在同一個 Azure 虛擬網路中，部署了兩組虛擬機器擴展集（VMSS）：

• 第一組集區專門處理商品影像串流請求（路徑為 http://titan.com/images/*）。
• 第二組集區專門處理線上金流結帳請求（路徑為 http://titan.com/checkout/*）。

架構師需要推薦一項負載平衡服務，能夠根據用戶發出之 HTTP 請求的 URL 路徑，將連線精確指派至相對應的後端虛擬機器集區。

請問架構師應推薦哪一項 Azure 服務？

• A. Azure 負載平衡器 (Azure Load Balancer)
• B. Azure 應用程式閘道 (Azure Application Gateway)
• C. 網路安全性群組 (Network Security Group)
• D. 虛擬網路對等互連 (Virtual Network Peering)

架構師推理思維鏈

• 【關鍵字識別】：URL path-based routing（基於 URL 路徑的路由）、HTTP traffic（HTTP 應用層流量）、distribute to different backend pools（分發至不同後端集區）。

• 【核心考點定位】：第 7 層應用程式閘道器（Application Gateway）的招牌特性。

• 【陷阱識破】：

  • Azure Load Balancer 是第 4 層（L4）負載平衡，只能根據 IP/Port 進行分流，無法讀取或剖析 HTTP 請求的 URL 路徑。
  • NSG 只能決定 Allow 或 Deny，無法做負載平衡轉發。

• 【逐一排除干擾項】：

  • 選項 A 缺乏 HTTP 協定深度檢視能力。
  • 選項 C 是安全群組過濾器。
  • 選項 D 是跨 VNet 互連網路通道。

• 【關聯官方最佳實踐】：Azure Application Gateway 原生支援路徑型路由規則（Path-based Routing Rules），可依據 URL 模式精確對應後端不同池。正解為 B。

• 來源與驗證：改寫自 ExamTopics 社群高頻核心考題；並經 Microsoft Learn：Azure 應用程式閘道 URL 路徑型路由概觀 交叉驗證確認。

📝 AZ-900 真題 2：非 HTTP 的高效能 TCP/UDP 傳輸層分流（ExamTopics 高頻題改編）

題目情境

Titan 科技研發了一套車聯網（IoT）即時感測器回傳系統。全球數萬台連網汽車每秒都會透過自訂的 二進位 TCP 連接埠 9000 向雲端回傳遙測封包。該系統不使用任何 HTTP 或 Web 協定，要求極致的微秒級低延遲，且要求負載平衡器本身能承受百萬級連線吞吐量。

請問架構師應推薦採用哪一項服務來負責分發車聯網感測器的 TCP 流量？

• A. Azure 應用程式閘道 (Azure Application Gateway)
• B. Azure 負載平衡器 (Azure Load Balancer)
• C. Azure 服務匯流排 (Azure Service Bus)
• D. Azure API 管理 (Azure API Management)

架構師推理思維鏈

• 【關鍵字識別】：TCP port 9000（原生 TCP 協定）、non-HTTP（非 HTTP 流量）、ultra-low latency（超低延遲）、layer 4 load balancing。

• 【核心考點定位】：OSI 第 4 層負載平衡器的選型依據。

• 【陷阱識破】：

  • Application Gateway 與 API Management 是專為 HTTP/HTTPS 設計的第 7 層反向代理，無法處理非 HTTP 的純 TCP/UDP 專有通訊協定！

• 【逐一排除干擾項】：

  • 選項 A 僅支援 HTTP/HTTPS/WebSocket。
  • 選項 C 是非同步傳訊佇列，不是網路層級的流量負載平衡器。
  • 選項 D 專門用於 REST API 治理與中繼。

• 【關聯官方最佳實踐】：Azure Load Balancer 專職於第 4 層（TCP/UDP）封包分流，完全不介入應用層解析，是處理自訂 TCP 通訊協定與極低延遲情境的唯一標準解。正解為 B。

• 來源與驗證：改寫自 ExamTopics 高頻題庫（Layer 4 TCP 負載平衡考點）；並經 Microsoft Learn：什麼是 Azure 負載平衡器？ 交叉驗證確認。

📝 AZ-900 真題 3：DNS 層級的跨區域流量分發與故障轉移（ExamTopics 高頻題改編）

題目情境

Titan 科技在日本東部（Japan East）與美國東部（East US）分別部署了完整的 Web 應用程式實體。架構團隊需要實施一項全域流量分發方案，要求：

1. 依據客戶端發出請求的地理位置與最佳網路延遲，將用戶導向最近的區域。
2. 該方案必須純粹在 網域名稱系統（DNS）層級 完成位址解析，而不經手或代理任何實際的資料封包內容。

請問架構師應推薦哪一項 Azure 服務？

• A. Azure 流量管理員 (Azure Traffic Manager)
• B. Azure 負載平衡器 (Azure Load Balancer)
• C. Azure 堡壘主機 (Azure Bastion)
• D. Azure 虛擬網路 (Azure Virtual Network)

架構師推理思維鏈

• 【關鍵字識別】：distribute traffic across regions（跨區域分發）、DNS level（DNS 層級解析）、does not proxy data packets（不代理實際資料封包）。

• 【核心考點定位】：Azure Traffic Manager 的運作本質。

• 【陷阱識破】：

  • Azure Load Balancer 是單一區域內的傳輸層負載平衡（除跨區域負載平衡外，依舊走 IP Anycast 而非 DNS 解析）。
  • 題目明確指出「在 DNS 層級完成，不代理封包」，這正是 Traffic Manager 的教科書式定義！

• 【關聯官方最佳實踐】：Azure Traffic Manager 是一個以 DNS 為基礎的流量負載平衡器，根據設定的路由方法（如效能、優先權、地理位置）提供最佳的 DNS 回應，客戶端隨後直接與目標 IP 連線。正解為 A。

• 來源與驗證：改寫自 ExamTopics 高頻真題；並經 Microsoft Learn：什麼是流量管理員？ 交叉驗證確認。

📝 AZ-900 真題 4：對外發布 VM 服務之網路元件判斷（2020 gratisexam Q68 改編）

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（Q68 改編），屬歷史題庫層，已與 Microsoft Learn 交叉驗證，破除 Traffic Manager 與負載平衡器對外暴露 HTTP 的常見誤區。

題目情境

Titan 科技的 Azure 環境中包含多台虛擬機器。目前系統工程師需要確保一台名為 VM1 的特定虛擬機器能夠直接從公開網際網路透過 HTTP（TCP 80 連接埠）被外部客戶端存取。

提案的解決方案是：「在 Azure 中建立並修改一個 Azure 流量管理員設定檔 (Azure Traffic Manager Profile)。」

請問這個解決方案是否能達成既定目標？

• A. 是 (Yes)
• B. 否 (No)

架構師推理思維鏈

• 【關鍵字識別】：ensure VM1 accessible from Internet over HTTP（確保 VM1 可透過 HTTP 從網際網路存取）、modify Traffic Manager Profile（修改 Traffic Manager 設定檔）。

• 【核心考點定位】：Traffic Manager 的功能邊界與對外發布 VM 的必要條件。

• 【陷阱識破】：

  • Traffic Manager 只是 DNS 路由工具。它負責將網域名稱解析為特定 IP，但它本身不能替 VM 開放網路連接埠，也無法讓沒有 Public IP 或沒有負載平衡器前端的 VM 被公網存取！
  • 如果 VM1 沒有配置 Public IP，或者其關聯的 NSG 未開放 Port 80，光設定 Traffic Manager 根本毫無作用。

• 【正確做法】：
  要讓單台 VM 能夠被網際網路透過 HTTP 存取，正確做法是為該 VM 配置公用 IP 位址（Public IP），或者將其置於 Azure Public Load Balancer / Application Gateway 後端，並在關聯的 網路安全性群組 (NSG) 中新增允許 Inbound Port 80 的規則。

• 【最終判定】：修改 Traffic Manager 無法達成目標。正解為 B。

• 來源與驗證：改寫自 2020 gratisexam Q68；並經 Microsoft Learn：針對 Azure 流量管理員進行疑難排解 交叉驗證確認。

📝 AZ-900 真題 5：大檔案全球加速與邊緣分發之最佳架構（2020 gratisexam Q39 改編）

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（Q39 改編），屬歷史題庫層，已與 Microsoft Learn 交叉驗證，對比 CDN、Application Gateway 與 ExpressRoute 的邊界。

題目情境

Titan 科技計劃在 Azure 上架設一個全球化的影音串流與教學網站。該網站將供散布於全球五大洲的數十萬名使用者線上點閱，且後端儲存庫中託管了大量超過 4K 解析度的高畫質影片大檔案。

架構團隊需要推薦一項 Azure 服務，用以提供全球使用者最佳的影片播放與下載體驗（最低的載入延遲與最高傳輸流暢度）。

請問架構師應推薦哪一項服務？

• A. Azure 應用程式閘道 (Application Gateway)
• B. Azure 專用通道線路 (ExpressRoute Circuit)
• C. Azure 內容傳遞網路 (Azure Content Delivery Network, CDN)
• D. Azure 流量管理員設定檔 (Traffic Manager Profile)

架構師推理思維鏈

• 【關鍵字識別】：accessed by users worldwide（全球使用者存取）、large video files（大型影片檔案）、best playback experience（最佳播放與快取體驗）。

• 【核心考點定位】：靜態與大檔案內容之邊緣快取加速服務。

• 【陷阱識破】：

  • Application Gateway 是單一區域內的 L7 反向代理，無法將大型檔案快取至全球邊緣節點。
  • ExpressRoute 是地端機房至 Azure 的私有專線，不是給網際網路終端消費者看影片用的。
  • Traffic Manager 只能做 DNS 導向，無法快取影片內容。

• 【關聯官方最佳實踐】：Azure CDN（內容傳遞網路） 透過分散在全球主要城市的邊緣伺服器節點（Point-of-Presence, POP）將靜態內容與大型影音檔案快取在距離終端使用者最近的位置，從而將網路延遲降至最低。正解為 C。

• 來源與驗證：改寫自 2020 gratisexam Q39；並經 Microsoft Learn：什麼是 Azure 內容傳遞網路 (CDN)？ 交叉驗證確認。

💡 AWS SAA-C03 / CLF-C02 概念補充與雙雲考點連動演練

為了讓具備 AWS 背景（CLF-C02 / SAA-C03）的雲端架構師快速建立跨雲直覺，我們整合 cxcxc-io 雲端架構圖庫（圖 2 ALB 路徑路由與圖 4 高併發管線）與 Gemini 深度研究報告 的關鍵精髓，進行雙雲架構連動解析：

📌 【AWS 經典考題 1】ALB 微服務路徑路由 vs 目標群組（SAA-C03 核心架構題）

AWS 考題情境：
在 cxcxc-io 圖 2 的經典微服務架構中，客戶端請求抵達單一 Application Load Balancer (ALB) 入口。公司希望將 /orders/* 的請求分發至執行於 ECS 叢集 A 的訂單服務（Port 80），將 /payment/* 的請求分發至執行於 ECS 叢集 B 的支付服務（Port 90/100）。應如何配置？
A. 在 ALB 建立一條基於 Path-based 的 Listener 規則，將兩個路徑分別指向不同的 Target Group（目標群組）
B. 必須部署兩座獨立的 Network Load Balancer (NLB) 分別監聽不同連接埠
C. 建立兩條 Route 53 紀錄將 /orders 與 /payment 解析到不同 EC2 實體
D. 只能透過 API Gateway 轉發，ALB 不具備解析 URL 路徑的能力

• AWS 解題思維：正確答案為 A。ALB 運作於 Layer 7，原生支援 Path-based Routing Rules，可依據 URL 路徑將封包解碼並轉發至不同的 Target Group。
• 🔄 Azure 知識映射：這正是 Azure Application Gateway 的一對一完全等價設計！
  • AWS ALB Listener Rules ➔ Azure Application Gateway Routing Rules (路徑型規則)
  • AWS Target Group (目標群組) ➔ Azure Backend Pool (後端集區)
  • AWS Health Check ➔ Azure Health Probes (健康探測)
    兩者的設計哲學完全一致：皆以單一公網入口 IP 承接流量，解開 HTTP 標頭後依路徑分派至異質後端集區。

┌──────────────────────────────────────────────────────────┐
│ cxcxc-io 圖 2 概念對照：ALB 路徑路由 vs App Gateway      │
├──────────────────────────────────────────────────────────┤
│ AWS 微服務路徑路由 (cxcxc-io 圖 2)                       │
│                      [Client 請求]                       │
│                            │                             │
│                            ▼                             │
│                    [ALB / ELB 入口]                      │
│                            │                             │
│         ┌──────────────────┴──────────────────┐          │
│         │ /orders/*                          │ /payment/*│
│         ▼                                     ▼          │
│  [ECS Cluster A (Port 80)]           [ECS Cluster B]     │
│  (Target Group A)                    (Target Group B)    │
│                                                          │
│ Azure 映射 (Application Gateway URL Path-based Routing)  │
│                      [Client 請求]                       │
│                            │                             │
│                            ▼                             │
│                 [Application Gateway 入口]               │
│                            │                             │
│         ┌──────────────────┴──────────────────┐          │
│         │ /orders/*                          │ /payment/*│
│         ▼                                     ▼          │
│  [Backend Pool: Orders VMSS]         [Backend Pool: Pay] │
└──────────────────────────────────────────────────────────┘

📌 【AWS 經典考題 2】高併發全球交付與 SLA 複合計算陷阱（SAA-C03 / Gemini 深度報告考點）

AWS 考題情境：
參考 cxcxc-io 圖 4 的高併發電商架構：User ➔ Route 53 ➔ CloudFront (邊緣快取) ➔ ALB ➔ EC2 ASG。架構師評估將此拓撲遷移至 Azure 時的可用性承諾。若前端 Application Gateway 原廠 SLA 為 99.95%，後端 VMSS 跨雙 Availability Zones 原廠 SLA 為 99.99%，請問整體應用服務的複合 SLA（Composite SLA）為何？
A. 高於 99.99%，因為兩者具備多層冗餘互補
B. 等於 99.99%，以可用性最高的一層為準
C. 約為 99.94%（99.95% × 99.99%），串聯相依組件的複合可用性必然低於單一組件
D. 等於 99.95%，以入口網關的可用性為硬性上限

• AWS 解題思維：正確答案為 C。無論在 AWS 還是 Azure，串聯（In Series）相依服務的複合可用性必須相乘：$99.95% \times 99.99% \approx 99.94%$！
• 🔄 Azure 知識映射：這正是 Gemini 深度研究報告所特別標註的「四大高頻陷阱：SLA 複合計算」！
  在 AZ-900 考場與架構評審中，考生極易直覺誤以為「加了 Application Gateway 後，整體架構可用性一定會提升」。實際上，在串聯架構中，任何一環故障整體即中斷，因此整體 SLA 永遠小於最低的那個組件！要打破串聯瓶頸，必須引入並聯容錯（如跨區域部署兩組 App Gateway，由 Azure Front Door 或 Traffic Manager 進行全域容錯轉移）。

┌──────────────────────────────────────────────────────────┐
│ cxcxc-io 圖 4 概念對照：高併發管線 vs Azure 全球交付     │
├──────────────────────────────────────────────────────────┤
│ AWS 經典高併發電商管線 (cxcxc-io 圖 4)                   │
│ [User] ➔ [Route 53] ➔ [CloudFront] ➔ [ALB] ➔ [EC2 ASG]   │
│                                                          │
│ Azure 全球高可用應用交付映射                             │
│ [User] ➔ [Traffic Manager / Front Door] ➔ [App Gateway]  │
│                                         ➔ [Azure VMSS]   │
│                                                          │
│ • 串聯可用性鐵律：複合 SLA 必然相乘 (99.95% × 99.99%)    │
│ • 破除單點故障：必須在多區域並聯部署，由全域負載平衡調度 │
└──────────────────────────────────────────────────────────┘

📐 Part 4：以戰代訓課程對照

⚠️ 課程缺口說明：在 2026 年微軟官方最新 Skills Measured 考綱中，「Describe Azure networking services」明確要求掌握 Azure 負載平衡服務的基本定位。由於實體課程教材在此主題完全留白，本文完整提取 RPG 素材庫 Day 12 的精華，並嚴格依據微軟官方 Microsoft Learn 標準擴充補足。

🚀 今日總結與明日預告

🏆 今日 3 點速記

1. 第 4 層 vs 第 7 層的職責鐵律：Azure Load Balancer 是 L4 傳輸層，只認 IP 與 TCP/UDP 連接埠，超低延遲且吞吐極高，看不懂 URL 也無 WAF 功能；Application Gateway 是 L7 應用層反向代理，看得懂 HTTP/S 網址路徑，支援 URL 分流、多網站代管、SSL 卸載並內建 WAF 防護。
2. 全域流量調度雙雄分工：Traffic Manager 是純粹的「DNS 導流器」，不經手實際封包；Azure Front Door 是全球邊緣網路上的「L7 Anycast 反向代理 ＋ CDN ＋ WAF」，適合全球化動態 Web 應用一站式交付。
3. 經典縱深防禦：雙層負載平衡協同：外網 Web 入口使用 Application Gateway（啟用 WAF）阻絕 Web 威脅並做路徑分流，內部微服務與資料庫層採用 Internal Load Balancer 進行高速轉發，兼具安全深度與效能極致。

🔮 明日預告：Day 15 Azure Blob Storage & Tiers (Hot/Cool/Cold/Archive)

恭喜各位冒險者！我們在今日正式攻克了 Phase 2 的核心運算（VM、App Service、容器）與網路要塞（VNet、NSG、ExpressRoute、負載平衡）！
明天起，我們將正式挺進 Phase 3：資料金庫與數據服務（Day 15–21）！
首場戰役是重量級的 Day 15：Azure Blob Storage & Tiers (Hot/Cool/Cold/Archive)！我們將對照 AWS S3，深入剖析 Azure 儲存體帳戶的三層結構，並全面揭秘 2026 最新考綱新增的 Cold（冷存取層） 與各層級（Hot、Cool、Cold、Archive）的成本計費與存取特徵，敬請期待！