彈性負載平衡設計 — ALB、NLB、GWLB

ANS-C01 中的 Elastic Load Balancing 與 SAA-C03 的層次完全不同。架構師考試會問「HTTP 流量該選 ALB 還是 NLB？」。進階網路 Specialty 考試則會問：「你有一個多區域應用程式，在 Global Accelerator 後方設有區域 ALB，並在單獨的檢測 VPC 中使用 GENEVE 封裝的內嵌第三方防火牆，此外還有一個使用 AWS Load Balancer Controller 透過 IP 模式目標群組的 EKS 叢集，需要支援端到端 HTTP/2 的 gRPC 服務，以及需要用戶端憑證透傳的 mTLS 身份驗證，外加一項源 IP 必須保留到應用程式的監管要求 — 請在 60 秒內設計出 ELB 層」。這是一個網路工程師的問題，涉及 ALB 接聽受器規則、NLB 靜態 IP 與 TLS 透傳、GWLB GENEVE 連接埠 6081、目標群組類型、跨可用區域負載平衡預設值、多憑證 TLS 的 SNI、AWS Load Balancer Controller 的 IngressClass 與 TargetGroupBinding，以及可用區域偏移 (Zonal Shift) — ANS-C01 經常在單個五行描述的情境中測試每一個變動組件。

此主題完整涵蓋了網域 1 (網路設計，佔考試 30%) 的任務陳述 1.3。官方 ANS-C01 考試指南逐字列出了知識點：「負載平衡在第 3 層、第 4 層和第 7 層如何運作」、「不同類型的負載平衡器」、「連接模式 (內部 vs 外部)」、「擴展因素」、「與 Global Accelerator、CloudFront、AWS WAF、Route 53、EKS、ACM 的整合」、「配置選項 (Proxy Protocol、跨可用區域、粘性工作階段、路由演算法)」、「目標群組類型 (TCP、GENEVE、IP vs 執行個體)」、「適用於 Kubernetes 叢集的 AWS Load Balancer Controller」，以及「加密與身分驗證考量 (TLS 終止、TLS 透傳)」。在 65 題考試中，大約有 7 到 10 題涉及此領域。

為什麼 ELB 設計是 ANS-C01 網域 1 的核心

AWS 架構的每一層最終都會終止於負載平衡器 — 公有流量終止於 ALB，內部東西向流量終止於內部 ALB 或 NLB，第三方安全性檢測終止於 GWLB，EKS Pod 流量終止於由 Load Balancer Controller 建立的 ALB 或 NLB。選錯負載平衡器類型會導致代價高昂的重做：NLB 無法執行基於路徑的路由，ALB 無法像 NLB 那樣保留來源 IP，兩者都無法像 GWLB 那樣透明地檢測封包。Specialty 考試測試這一點，是因為網路工程師被期望在需求壓力下做出正確的選擇。

考試獎勵的心理模型是 OSI 分層比對：在路由決策所在的層級選擇負載平衡器。ALB 位於第 7 層 (HTTP/HTTPS/gRPC)，並檢測請求標頭、路徑、主機和方法。NLB 位於第 4 層 (TCP/UDP/TLS)，並根據 5-tuple 進行路由而不解析內容。GWLB 位於第 3 層 (IP) 且是透明的 — 它透過 GENEVE 封裝將每個封包轉發到設備。確定路由決策所在的層級，負載平衡器類型便隨之確定。

白話文解釋 ELB 設計 — ALB, NLB 與 GWLB

ELB 結合了在不同 OSI 層運行的三種負載平衡器類型，每種在路由、目標選擇、加密和整合方面都具有獨特的功能。我們用三個類比來幫助內化。

類比 1：飯店接待櫃台

想像三個具有不同專長的飯店接待櫃台。

Application Load Balancer (ALB) 是豪華飯店的禮賓人員。禮賓人員會詳細閱讀客人的請求 (「我想要一間面向中庭的安靜房間、素食早餐、延遲退房」)，檢測多個屬性 (主機、路徑、查詢字串、標頭、方法、Cookie)，並將客人引導至特定的服務櫃台：SPA、餐廳、健身房或商務中心。禮賓人員可以為你分配固定的房間 (粘性工作階段)、提供 gRPC 服務 (多語言)，並能流利地溝通 HTTP/2。ALB 目標就像特定的服務櫃台 — SPA、餐廳 — 每個櫃台運行著不同的計畫。

Network Load Balancer (NLB) 是飯店的代客泊車櫃台。代客泊車人員不會問你需要什麼 — 他們只看你的車 (5-tuple：源 IP、源連接埠、目的地 IP、目的地連接埠、協定) 並指引你到停車位。泊車人員保留原車 (源 IP) 而不更改它，在每個區域為你提供專用停車位 (每個可用區域靜態 IP，可選彈性 IP)，並能每分鐘處理 100 萬輛車而不費吹灰之力。NLB 不會閱讀你的行程；它只是快速可靠地停車。

Gateway Load Balancer (GWLB) 是飯店後方裝卸區的保安檢查站。進入的每件貨物 (封包) 都會經過檢查站，檢查站會將其包裝在防篡改包裝中 (GENEVE 封裝，連接埠 6081)，送往安全性設備 (Palo Alto、Fortinet、Suricata IDS) 進行檢查，然後原封不動地交還。檢查站是透明的 — 貨物永遠不知道自己被檢查過。GWLB 是在不修改應用程式的情況下，在資料路徑中插入第三方安全性設備的方法。

類比 2：擁有多條服務線的餐廳

想像一家連鎖餐廳。

ALB 是精緻的坐下來點餐餐廳，服務人員會記錄你的完整訂單，將特定菜餚路由到正確的廚房工作站 (基於路徑的路由：前菜去冷盤廚房、主菜去燒烤區、甜點去西點房)，可以拆分桌位 (基於主機的路由：婚禮去私人包廂、一般顧客去大廳)，並能在服務中途更換菜單 (基於規則的重新導向、固定響應)。服務人員能流利使用 HTTP/2 和 gRPC，並記得你的飲食偏好 (透過 Cookie 實現粘性工作階段)。ALB 無法在 5 秒內開一家新餐廳 — 為突發流量高峰進行預熱 (Pre-warming) 是一個實際存在的問題。

NLB 是速食店的車道服務 (Drive-through)。車子到達，收銀員只看車牌 (5-tuple)，分配到取餐窗口。沒有菜單檢測，沒有深奧的問題，只有傳輸量 — 每秒數百萬個訂單。車道服務有固定的入口地址 (每個可用區域一個靜態 IP，即彈性 IP)，保留顧客的原車 (源 IP 保留)，且無需預熱即可立即擴展。

GWLB 是裝卸區的食品安全檢查員。每輛運送食材的卡車都要經過檢查員，由其卸貨、檢查、重新包裝 (GENEVE 包裝)，並送往第三方食品安全實驗室 (Palo Alto VM-Series、Fortinet、Aviatrix) 進行檢測，然後重新裝車並轉發。廚房永遠不知道檢查發生過 — 完全透明。

類比 3：郵政分揀系統

ALB 是專業郵件路由中心，它會打開每個包裹以閱讀目的地、寄件人、內容、特別說明，並據此調度 (路徑、主機、標頭、Cookie、查詢參數路由)。它還可以即時重寫地址 (透過重新導向進行 URL 重寫)、產生預設回覆 (固定響應操作)，並要求簽收才能送達 (authenticate-cognito, authenticate-oidc)。ALB 有許多專業的輸送帶 (目標群組)，每條都通往不同的建築 (執行個體、IP 模式、Lambda 函數)。

NLB 是大宗包裹分揀機，它只讀取郵寄標籤 (5-tuple)。包裹在毫秒內被送往正確的集散站，無需內容檢測。來源標籤端到端保留 (源 IP 保留)。每個可用區域 (AZ) 都有自己專屬的郵箱 (靜態 IP，可選彈性 IP)。

GWLB 是邊境的海關檢查。每個越境的包裹都包裝在海關防篡改包裝中 (GENEVE)，通過海關 (第三方設備)，然後在另一端原封不動地轉發。寄件人和收件人都不知道的透明海關。

負載平衡器層級 — 第 3、4 和 7 層

OSI 模型框架是考試獎勵的重點。每種 ELB 類型都在特定層運行。

第 7 層 — ALB

ALB 在應用程式層檢測 HTTP/HTTPS 流量。它可以看到完整的 HTTP 請求：方法、URI 路徑、主機標頭、查詢字串、標頭、Cookie、主體 (在限制內)、用戶端憑證 (mTLS)。它可以根據其中任何一項進行路由、終止 TLS、修改標頭 (X-Forwarded-For)，以及執行由 Lambda 支援的操作。ALB 不支援任意的 TCP、UDP 或非 HTTP 協定 — 僅支援 HTTP、HTTPS 和 gRPC。

第 4 層 — NLB

NLB 僅看到第 4 層連線：源 IP、源連接埠、目的地 IP、目的地連接埠、協定 (TCP 或 UDP)。它不檢測內容。它可以選擇在接聽受器終止 TLS (TLS 接聽受器類型)，但在使用 TCP/UDP 接聽受器時它是完全透明的。NLB 支援 TCP、UDP 或 TLS 上的任何協定 — 包括非 HTTP 協定 (SSH, RDP, MQTT, 自訂二進位協定, TCP 上的 gRPC 等)。

第 3 層 (透明) — GWLB

GWLB 在第 3 層 (IP 封包) 運行。它不終止任何連線。每個封包都封裝在 GENEVE 封裝 (UDP 連接埠 6081) 中，並透過 支援 GENEVE 的目標群組 轉發到第三方設備。設備檢測 (並可選擇修改) 封包，然後將其發回 GWLB，由 GWLB 剝離 GENEVE 包裝並轉發到原始目的地。應用程式不會察覺 GWLB 的存在。

Application Load Balancer 深度解析

接聽受器與規則

ALB 接聽受器 (Listener) 綁定到連接埠 (通常為 80 或 443) 和協定 (HTTP, HTTPS)。每個接聽受器都有按優先順序評估的規則。一條規則包含條件 (主機標頭、路徑模式、查詢字串、源 IP CIDR、HTTP 請求方法、HTTP 標頭) 和操作 (轉發到目標群組、重新導向、返回固定響應、身分驗證、重新導向到 OIDC)。

當沒有其他規則符合時，預設規則會生效。預設情況下，每個接聽受器最多 100 條規則 (可透過 Service Quotas 提高)。

基於內容的路由

這是測試最頻繁的 ALB 功能。範例：

• 基於主機：api.example.com 路由到 API 目標群組；static.example.com 路由到靜態內容目標群組。
• 基於路徑：/api/* 路由到 API 目標群組；/static/* 路由到 S3 前端的目標群組。
• 基於標頭：User-Agent: Mobile* 路由到行動裝置優化的目標群組。
• 基於查詢字串：?version=v2 路由到 v2 目標群組進行 Canary 測試。

目標群組類型

• 執行個體 (Instance)：目標是 EC2 執行個體 ID；ALB 路由到執行個體的主要 IP。
• IP：目標是 VPC CIDR 或對等/連線 CIDR 中的任意 IP；適用於透過 VPN/DX 連接的內部部署伺服器，或透過 Load Balancer Controller IP 模式連接的 EKS Pod。
• Lambda：目標是 Lambda 函數；ALB 為每個請求叫用該函數，並帶有序列化的事件負載。

粘性工作階段 (Sticky sessions)

ALB 支援兩種粘性工作階段模式：負載平衡器產生的 Cookie (AWSALB) 和應用程式 Cookie (現有的 Cookie 名稱，如 JSESSIONID)。粘性持續時間是可配置的 (1 秒到 7 天)。適用於在每個執行個體本地儲存工作階段狀態的有狀態應用程式。

gRPC 與 HTTP/2 支援

ALB 原生支援 HTTP/2 端到端和 gRPC 協定。目標群組可以配置為 protocol_version: GRPC。健康檢查可以使用 gRPC 健康狀態。這是需要 HTTP/2 多路複用 (Multiplexing) 的現代微服務的標準答案。

身分驗證操作

ALB 可以針對 Amazon Cognito 使用者集區 或任何 符合 OIDC 規範的身分提供者 (Auth0, Okta, Azure AD) 驗證傳入請求。配置為接聽受器規則操作；ALB 處理 OAuth 流程、設定工作階段 Cookie，並在 JWT 標頭中將使用者身分轉發到後端。

Network Load Balancer 深度解析

TCP, UDP 與 TLS 接聽受器

NLB 支援三種接聽受器協定：

• TCP：純第 4 層，源 IP 保留。
• UDP：第 4 層 UDP (例如 DNS、遊戲、IoT MQTT-SN)；源 IP 保留。
• TLS：NLB 終止 TLS，然後將純文字 TCP 轉發到目標。源 IP 不保留 (可以啟用 Proxy Protocol v2 以在標頭中保留)。

每個可用區域的靜態 IP

NLB 啟用的每個可用區域 (AZ) 都會自動獲得 AWS 分配的靜態 IP。你可以選擇為每個 AZ 分配一個彈性 IP (EIP)，用於品牌塑造或白名單目的。NLB IP 在 LB 的生命週期內不會改變 — 非常適合在客戶防火牆上設定白名單。ALB 的 IP 會改變 (它們隨流量擴展/縮減)，因此 ALB 必須使用基於 DNS 的可達性。

源 IP 保留 (Source IP preservation)

使用 TCP 接聽受器 的 NLB 會將用戶端的源 IP 一路保留到目標。這是「應用程式需要真實用戶端 IP」的標準答案。使用 TLS 接聽受器 時，源 IP 會在 TLS 終止點被替換為 NLB 的 IP — 要恢復用戶端 IP，請在目標群組上啟用 Proxy Protocol v2，它會在連線前綴中附加原始 5-tuple。

與 Application Load Balancer 源 IP 保留的比較

ALB 在 TCP 層級不保留源 IP — 它終止 HTTP 連線並建立到後端的新連線。相反，ALB 會設定 X-Forwarded-For 標頭來攜帶原始用戶端 IP。應用程式必須讀取該標頭 (並信任該 LB)。

NLB 擴展與預熱

NLB 立即擴展而無需預熱 — 它可以從冷啟動開始每秒吸收 100 萬次以上的請求。這與需要為已知高峰預熱的 ALB 不同。NLB 的流量狀態追蹤分佈在數千個底層節點上。

可用區域偏移 (Zonal shift)

可用區域偏移 是一項 AWS 託管功能，允許你立即從負載平衡池中移除特定可用區域中的 NLB 目標 — 適用於可用區域層級的受損。透過 API 或主控台觸發；受影響 AZ 中的目標將在配置的持續時間內 (1 小時到 3 天) 被排除。這是 2024 年後的新功能，與考試相關。

Gateway Load Balancer 深度解析

GWLB 解決什麼問題

在兩個網路 (例如支點 VPC 和中央檢測 VPC) 之間內嵌插入第三方安全性設備 (Palo Alto VM-Series、Fortinet FortiGate、Check Point CloudGuard、Aviatrix 閘道、Suricata IDS)。在 GWLB 之前，這需要透過 VPN 隧道和在設備上禁用源/目的地檢查等複雜路由技巧。GWLB 使這變得微不足道。

GENEVE 封裝

GWLB 在 UDP 連接埠 6081 上將每個 IP 封包封裝在 GENEVE (Generic Network Virtualization Encapsulation) 中。設備接收 GENEVE 封裝的封包，檢測內部的 IP 封包，然後將其發回 GWLB，由 GWLB 剝離 GENEVE 包裝並轉發到原始目的地。原始封包的源/目的地 IP 被保留。

GWLB 端點 (GWLBe)

取用者 VPC 透過 GWLB 端點 (GWLBe) 取用 GWLB 的服務 — 這是一個將流量路由到 GWLB GENEVE 管道的特殊 VPC 端點。取用者 VPC 中的路由表指向 GWLBe；從取用者的角度來看，GWLBe 是一個透明的下一躍點 (Next hop)。

內嵌 (Bump-in-the-wire) 拓撲

標準模式：路由表將 0.0.0.0/0 (或特定目的地) 發送到 GWLBe；GWLBe 轉發到 GWLB；GWLB 進行封裝並發送到設備群 (目標群組)；設備返回；GWLB 轉發到原始目的地。應用程式對此毫無察覺。

GWLB 上的跨可用區域負載平衡

GWLB 始終跨所有可用區域分配流量 — 沒有按區域相似性的選項。這與 ALB (預設啟用但可配置) 和 NLB (預設禁用) 不同。

使用案例

• 集中式檢測 VPC — 所有支點 VPC 透過 TGW 路由到檢測 VPC；GWLB 插入第三方設備。
• 出口過濾 — 來自支點的對外網際網路流量在到達 NAT 閘道和 IGW 之前透過 GWLB 進行檢測。
• 合規性 — 規定必須使用特定商業防火牆廠商的受管產業使用 GWLB 進行整合。

跨可用區域負載平衡 — 預設值與成本

跨可用區域負載平衡 (Cross-zone load balancing) 會在所有啟用的可用區域 (AZ) 中的目標之間分配流量。若未啟用，LB 僅將流量發送到與請求進入點位於相同可用區域的目標。不同 LB 類型的預設值不同，這對可靠性和成本都有影響。

預設值

• ALB：預設啟用，且跨可用區域流量不收費。
• NLB：預設禁用；啟用後會按 GB 收取跨 AZ 資料傳輸費。
• GWLB：始終啟用，無法切換。

為什麼 NLB 預設禁用

NLB 針對超低延遲和超高傳輸量進行了優化。跨 AZ 流量會增加延遲 (亞毫秒級，但可測量) 和成本。預設關閉允許營運人員在需要時 (通常是當可用區域間的目標分佈不均時) 選擇開啟。

成本影響

對於啟用了跨可用區域負載平衡的 NLB，每個跨 AZ 封包會被計費兩次：一次離開源 AZ，一次進入目的地 AZ。對於高傳輸量工作負載 (例如每秒數百萬個 TCP 連線)，這筆費用可能遠超 LB 的每小時成本。

何時在 NLB 上啟用

• 目標在可用區域間分佈不均 (例如可用區域 a 有 5 個執行個體，可用區域 b 有 1 個)。
• 可用區域層級的容錯要求可用區域 a 的目標在可用區域 b 目標失敗時處理可用區域 b 的流量。
• 按可用區域劃分的流量高峰不可預測，且你希望平滑負載。

TLS 終止 vs TLS 透傳

在負載平衡器終止 TLS

LB 終止 TLS 連線 — 解密流量，以純文字形式套用路由/檢測邏輯，然後重新加密到後端或以純文字形式轉發。優點：LB 可以檢測 HTTP 標頭 (路徑、主機等) 進行路由；在 LB 端集中管理憑證；減輕後端的運算負擔。缺點：LB 與後端之間的流量除非明確重新加密，否則是不加密的；LB 可以看到純文字流量。

在 NLB 實作 TLS 透傳 (Passthrough)

具有 TCP 接聽受器 (而非 TLS 接聽受器) 的 NLB 會將加密流量透傳到後端而不終止。後端處理 TLS 終止。優點：端到端加密，LB 端無解密；mTLS 可以運作，因為用戶端憑證會到達後端；憑證在後端管理。缺點：LB 無法檢測內容進行路由 (無基於路徑的路由)；每個後端必須有自己的憑證 (或透過萬用字元共用)。

在 NLB 終止 TLS

具有 TLS 接聽受器 的 NLB 在 LB 端終止 TLS，然後將純文字 TCP 轉發到後端。當後端不具備 TLS 能力但你希望用戶端使用 TLS 時使用。

相互 TLS (mTLS)

對於用戶端呈現憑證的 mTLS 身份驗證，具有 TCP 接聽受器 (透傳) 的 NLB 是標準答案，因為後端需要用戶端憑證。ALB 最近也新增了 mTLS 支援 — ALB 可以驗證用戶端憑證並在標頭中轉發身分。

SNI (伺服器名稱指示) — 每個接聽受器多個憑證

ALB 和 NLB 都支援 SNI，允許單個接聽受器關聯多個 TLS 憑證。LB 根據 TLS ClientHello 中的 SNI 主機名稱選擇憑證。這使得單個 LB 可以為數十個不同的網域提供服務，而無需為每個網域建立專用的接聽受器或 LB。

適用於 Kubernetes 的 AWS Load Balancer Controller

AWS Load Balancer Controller 是一個 Kubernetes 控制器，它根據 Kubernetes 資源建立和管理 ALB 及 NLB。它是 EKS 原生將服務公開到外部的方案。

IngressClass 與 Ingress

Kubernetes Ingress 資源指定 HTTP 流量的主機/路徑路由。Load Balancer Controller 監控 Ingress 資源、建立 ALB、配置接聽受器規則以比對 Ingress，並將後端 Pod 註冊為目標。IngressClass 欄位選擇哪個控制器處理該 Ingress (例如 alb 表示由 ALB 管理)。

LoadBalancer 類型的 Service

對於非 HTTP 流量，帶有註釋 (Annotations) 的 LoadBalancer 類型 Service 會觸發 NLB。控制器將 Pod 註冊為 IP 模式目標並將流量路由到它們。

IP 模式 vs 執行個體 模式

• 執行個體模式 (Instance mode)：ALB 目標是運行 kubelet 的 EC2 執行個體；流量透過 kube-proxy 的 NodePort 進入，並透過 iptables 轉發到 Pod。
• IP 模式 (IP mode)：ALB 目標直接是 Pod 的 IP (使用 VPC CNI)；流量跳過 kube-proxy，透過 VPC 網路直接 Pod 對 Pod。

IP 模式是目前的推薦做法：延遲更低、調試更簡單、沒有 kube-proxy 跳轉。需要具備足夠 Pod IP 容量 (前綴分配) 的 VPC CNI。

TargetGroupBinding

對於更進階的情境，TargetGroupBinding 自訂資源將現有的目標群組綁定到 Kubernetes Service。適用於跨命名空間共用目標群組或在 Kubernetes 外部管理的現有目標群組。

連線清空與取消註冊延遲

當目標被取消註冊 (自動縮減、部署、手動移除) 時，LB 會停止向其發送新連線，但允許進行中的連線完成。取消註冊延遲 (Deregistration delay) (預設 300 秒，範圍 0–3600) 控制 LB 在強制關閉進行中連線前等待的時間。

調校建議

• 長連線 (WebSocket、影片串流、gRPC 串流)：設定 1800–3600 秒。
• 短 HTTP 請求：60–120 秒即可。
• 激進部署：0 秒 (立即切斷) — 當部署頻繁且可接受短暫中斷時很有用。

整合模式

Global Accelerator + NLB

Global Accelerator 在 AWS 邊緣位置提供靜態任播 IP，路由到最近健康區域的 NLB 端點，為非 HTTP 流量 (TCP, UDP) 提供亞 100 毫秒的全域延遲。這是遊戲、VoIP、金融交易的標準配置。

CloudFront + ALB 源頭

CloudFront 在邊緣快取 HTTP 響應，並將快取未命中路由到 ALB 源頭。使用 ALB 的 DNS 名稱 (或 CloudFront Origin Shield) 作為源頭。如果使用 S3 源頭，請結合源頭存取控制 (OAC)。

Route 53 別名 + ALB/NLB

區域頂點 (Zone apex) 的 Route 53 別名記錄指向 ALB 或 NLB DNS。配合評估目標健康狀況 (Evaluate Target Health)，Route 53 僅在目標健康時返回 LB。跨兩個區域 LB 的故障轉移路由可實現多區域主動-被動。

ALB + Cognito 用於身分驗證

帶有 authenticate-cognito 操作的 ALB 接聽受器規則將未經驗證的使用者重新導向到 Cognito 託管 UI，完成 OAuth 流程，設定工作階段 Cookie，並在 JWT 標頭中將通過驗證的使用者身分轉發到後端。

常見陷阱回顧 — ANS-C01 中的 ELB

陷阱 1：NLB 具有動態 IP

錯誤。NLB 在其生命週期內擁有每個可用區域固定的 IP；ALB 則具有動態 IP。

陷阱 2：ALB 跨可用區域預設禁用

錯誤。ALB 跨可用區域預設啟用且免費。NLB 跨可用區域預設禁用且收費。

陷阱 3：GWLB 使用 VXLAN

錯誤。GWLB 在 UDP 連接埠 6081 上使用 GENEVE。

陷阱 4：ALB 在 TCP 層級保留源 IP

錯誤。ALB 終止 HTTP 並建立新連線。源 IP 在 X-Forwarded-For 標頭中轉發。

陷阱 5：NLB 在流量高峰前需要預熱

錯誤。NLB 立即擴展；ALB 則需要為已知高峰進行預熱。

陷阱 6：GWLB 跨可用區域負載平衡是可配置的

錯誤。GWLB 始終跨所有區域分配流量；不可配置。

陷阱 7：ALB 支援任何 TCP 協定

錯誤。ALB 僅支援 HTTP、HTTPS 和 gRPC。對於任意 TCP/UDP，請使用 NLB。

陷阱 8：Lambda 目標適用於 NLB

錯誤。僅 ALB 支援 Lambda 目標群組。

陷阱 9：NLB 目標群組始終需要在後端 SG 允許源 IP

在歷史上是正確的；現在 NLB 支援安全性群組作為選用功能。

陷阱 10：每個可用區域固定 IP 意味著每個可用區域一個 EIP

部分正確。NLB 會自動分配一個靜態 IP；如果你願意，還可以為每個 AZ 分配一個 EIP。

陷阱 11：AWS Load Balancer Controller 僅適用於 Fargate

錯誤。它適用於任何 EKS 叢集，包括 EC2 工作節點或 Fargate。

陷阱 12：粘性工作階段在 LB 重啟後仍然存在

部分正確。ALB 負載平衡器產生的 Cookie 粘性工作階段只要 Cookie 有效 (可配置持續時間，預設 1 天) 就會存在。應用程式 Cookie 粘性則隨應用程式 Cookie 存在而存在。

決策矩陣 — 選擇正確的負載平衡器

常見問答 — ANS-C01 中的 ELB 設計

Q1: 我該何時為應用程式選擇 ALB 或 NLB？

當路由決策位於 HTTP 層時使用 ALB — 例如基於路徑的路由、基於主機的路由、標頭檢測、透過 Cookie 實現的粘性工作階段、帶有 HTTP/2 的 gRPC、Lambda 後端、帶有標頭轉發身分的 mTLS、Cognito 或 OIDC 身分驗證操作。在以下情況下使用 NLB：(a) 協定不是 HTTP (TCP, UDP, 自訂二進位, MQTT, SSH, RDP, 遊戲)，(b) 應用程式在 TCP 層級需要原始用戶端 IP (源 IP 保留)，(c) 需要靜態 IP 用於白名單，(d) 需要亞毫秒延遲下的超高傳輸量，(e) 必須具備無需預熱的即時擴展能力。ANS-C01 題目經常結合各種約束條件 — 例如「HTTP 流量，但後端讀取 connection.peer_address 獲取源 IP」 — 這種組合會迫使你選擇「帶有 PROXY PROTOCOL 的 NLB」或「帶有 X-Forwarded-For 的 ALB」；答案取決於應用程式的靈活性。

Q2: GWLB 如何實現第三方安全性設備的整合？

GWLB 位於兩個網路 (例如支點 VPC 和中央檢測 VPC) 之間。來自支點的流量透過 GWLB 端點 (GWLBe) 路由到 GWLB。GWLB 在 GENEVE (UDP 連接埠 6081) 中封裝每個封包並附帶元資料，然後發送到由第三方設備執行個體 (Palo Alto, Fortinet, Aviatrix, Check Point) 組成的目標群組。設備接收 GENEVE 包裝的封包，檢測內部負載 (如果啟用了 TLS 檢測則進行解密，套用 IDS 規則等)，然後將封包發回 GWLB — 可能是修改過的、丟棄的或未更改的。GWLB 剝離 GENEVE 包裝並轉發到原始目的地。應用程式不知道路徑中存在設備。考試標準情境：「我們需要插入 Palo Alto VM-Series 進行外向網際網路檢測，而不改變應用程式行為」 — 答案是帶有內嵌路由表的 GWLB。

Q3: 為什麼 NLB 跨可用區域負載平衡預設為禁用？

NLB 優化了超低延遲。跨 AZ 流量會增加 1-2 毫秒的延遲和每 GB 的成本。預設關閉意味著營運人員必須主動選擇開啟，這代表對成本與可用性權衡的認知。在以下情況下啟用跨可用區域：(a) 目標分佈不均 (例如可用區域 a 有 10 個執行個體，可用區域 b 有 2 個 — 若不跨 AZ，可用區域 b 的用戶端只能獲得 2 個執行個體的容量)，(b) 可用區域層級的彈性要求可用區域 a 用戶端能故障轉移到可用區域 b 的目標，(c) 按可用區域劃分的流量高峰不均勻。在以下情況下禁用：(a) 目標按可用區域均衡，(b) 成本敏感度高，(c) 延遲至關重要。ANS-C01 將「為可用區域目標分佈均衡的應用程式禁用跨可用區域以優化成本」視為標準的成本意識答案。

Q4: AWS Load Balancer Controller 如何與 Kubernetes Ingress 整合？

你在 EKS 叢集中透過 Helm 或靜態清單安裝控制器。你建立一個 Kubernetes Ingress 資源，並帶有指定 ALB 配置的註釋 (例如公有或內部、目標類型 IP 或執行個體、接聽受器連接埠、SSL 憑證 ARN)。控制器監控 Ingress 資源，建立符合規範的 ALB，根據 Ingress 的主機/路徑規則配置接聽受器規則，並將後端 Pod IP (IP 模式) 或節點 NodePort (執行個體模式) 註冊為目標。對 Ingress 的更新 (如新增路徑) 會自動更新 ALB 規則。對於 LoadBalancer 類型 Service (非 HTTP)，類似工作流程會選擇 NLB。IP 模式是首選，因為它跳過了 kube-proxy 跳轉，提供了 Pod 到 LB 的直接可見性。

Q5: 我可以在單個 ALB 或 NLB 接聽受器上擁有多個 TLS 憑證嗎？

可以，透過 SNI (伺服器名稱指示)。TLS ClientHello 包含請求的主機名稱；LB 將其與接聽受器上配置的憑證進行比對，並呈現匹配的憑證。預設情況下，每個接聽受器最多 25 個憑證 (可提高)。這允許單個 LB 為 app1.example.com、app2.example.com、app3.example.com 提供不同的憑證 — 當出於合規原因無法接受萬用字元憑證時非常有用。SNI 受到所有現代瀏覽器和 TLS 用戶端的支援；舊版用戶端 (Windows XP, Java 6) 不支援 SNI，將接收到預設憑證 (可能與其請求不符)。

Q6: 取消註冊延遲 (連線清空) 何時會太長或太短？

太短 (0 秒)：當目標取消註冊時，進行中的 HTTP 請求會被突然斷開；使用者會看到 5xx 錯誤。通常適用於開發環境。

太長 (3600 秒)：部署需要一個小時才能完成；輪詢更新會停滯。自動縮減被延遲。

最佳平衡點：

• HTTP REST API：60–120 秒。
• WebSocket / 串流 gRPC：1800–3600 秒 (讓連線自然過期)。
• 資料庫連線池：比照連線池的最大空閒時間 (通常為 300 秒)。

ANS-C01 會測試 WebSocket / 長連線情境 — 對於「影片串流使用者在縮減期間看到中斷」，較長的取消註冊延遲是正確答案。

Q7: 對於非 HTTP 流量，Global Accelerator 如何比 CloudFront 提供更好的改進？

CloudFront 僅限 HTTP (HTTP/HTTPS)。對於 TCP、UDP、TCP 上的 gRPC、遊戲、VoIP、MQTT、MQTT-SN、自訂二進位協定 — CloudFront 無法運作。Global Accelerator 在所有 AWS 邊緣位置提供靜態任播 IP，透過 AWS 骨幹網路將流量路由到最近的健康區域 NLB 端點，並支援任何 TCP/UDP 協定。結果：用戶端在 <50 毫秒內連線到最近的邊緣，後端流量使用 AWS 私有骨幹網路而非公共網際網路。關於「針對遊戲/VoIP/非 HTTP 的全域低延遲」的 ANS-C01 問題，正確答案是 Global Accelerator + NLB；CloudFront 是錯誤答案。

Q8: Proxy Protocol v2 對 NLB TLS 終止有什麼作用？

當 NLB 終止 TLS 時，原始用戶端的 IP 在 TCP 層級被替換為 NLB 的 IP — 後端只能看到 NLB。Proxy Protocol v2 是一種標準化二進位標頭，NLB 會將其預先附加到 TCP 串流中，其中包含原始 5-tuple (源 IP、源連接埠、目的地 IP、目的地連接埠、協定)。後端應用程式讀取 Proxy Protocol 標頭 (連線開始處的幾個位元組)，提取原始用戶端 IP，然後繼續處理 TLS 解密後的 TCP 串流。沒有 Proxy Protocol，後端只能看到 NLB IP。這需要應用程式支援 — 大多數現代代理 (HAProxy, NGINX, Envoy) 都原生支援 Proxy Protocol。當 NLB-TLS 終止與「必須看到原始用戶端 IP」的要求結合時，ANS-C01 會獎勵啟用 Proxy Protocol。

Q9: 如何架構具備全域故障轉移的多區域 ALB？

每個區域建立一個 ALB。從 Route 53 健康檢查 ALB 端點 (使用別名-評估目標健康狀況)。使用 Route 53 故障轉移路由策略，將主要區域的 ALB 作為主記錄，次要區域的 ALB 作為次要記錄。或者使用基於延遲的路由並對兩個區域進行健康檢查評估，以便使用者獲得最低延遲的健康區域。對於逐漸切換，請使用具有變動權重的加權路由。或者，在區域 ALB 前方放置 Global Accelerator 作為端點群組 — Global Accelerator 的任播 IP 在區域受損時，能為用戶端提供亞 100 毫秒的故障轉移時間。對於最高可用性的多區域方案，Specialty 的答案是：Global Accelerator + 作為端點群組的區域 ALB，並在區域頂點將 Route 53 別名指向 Global Accelerator 的靜態 IP。

Q10: 何時該使用 IP 模式目標群組而非執行個體模式？

在以下情況下使用 IP 模式：

• 目標是 EKS Pod (使用 VPC CNI 獲取 Pod IP)。
• 目標是透過 VPN 或 Direct Connect 可達的內部部署伺服器 (ALB 可以路由到連線 VPC/CIDR 中的非 VPC IP)。
• 需要透過跳過 kube-proxy 或 NodePort 來降低延遲。
• 需要 Pod 層級而非節點層級的健康檢查。

在以下情況下使用 執行個體模式：

• 目標是裸機 EC2 執行個體，且你希望簡單註冊。
• 應用程式使用主機連接埠 (綁定到 NodePort)，且你希望 LB 路由到 EC2 執行個體的連接埠。

對於現代 EKS 工作負載，IP 模式是預設的最佳實務。有關 EKS 負載平衡的 ANS-C01 題目會偏向 IP 模式。

進階閱讀與相關操作模式

• Elastic Load Balancing 使用者指南
• 什麼是 Application Load Balancer
• 什麼是 Network Load Balancer
• 什麼是 Gateway Load Balancer
• Elastic Load Balancing 如何運作
• ALB 的目標群組
• Network Load Balancers
• 適用於 Kubernetes 的 AWS Load Balancer Controller

一旦 ELB 設計就緒，ANS-C01 的下一個自然操作層級是：邊緣架構 — CloudFront 與 Global Accelerator，它們位於 ALB 和 NLB 前方以實現全球覆蓋；Route 53 DNS — 公有、私有與混合架構，用於指向 ALB/NLB 的別名記錄；安全性群組與 NACL — 有狀態 vs 無狀態，用於 LB 進入點/目標 SG 的分層控制；以及網路加密 — TLS, ACM, IPsec 與 MACsec，用於 LB 接聽受器的憑證管理。

• 邊緣架構 — CloudFront 與 Global Accelerator — ANS-C01 學習筆記
• Route 53 DNS — 公有、私有與混合架構 — ANS-C01 學習筆記
• 安全性群組與 NACL — 有狀態 vs 無狀態 — ANS-C01 學習筆記
• 網路加密 — TLS, ACM, IPsec 與 MACsec — ANS-C01 學習筆記