ALB 適合做「應用層智慧分流與保護」，NLB 則適合「超高效能、低延遲、L4 連線轉送與固定 IP 場景」。
基本定位與 OSI Layer
- Application Load Balancer (ALB)：工作在 OSI 第 7 層，能看得懂 HTTP/HTTPS/gRPC 的 Header、Path 等資訊，做應用層的內容導向路由與進階功能。
- Network Load Balancer (NLB)：工作在 OSI 第 4 層，以 TCP/UDP/TLS 連線為主，依連線的 IP/Port 做高速轉送，不解析應用層內容。
功能特性差異
- ALB 支援：
- 依 Hostname、Path、Header、Method 等做 Rule-based routing（微服務、Blue/Green、A/B Test 很好用）。
- 與 WAF、Cognito/OIDC/SAML 做應用層驗證、Web 防護、HTTP header 操作等。
- 目標類型可用 EC2、IP、Lambda，方便 Serverless 或混合架構。
- NLB 支援：
- TCP/UDP/TLS、支援 Static IP、EIP、Preserve client IP，適合 VPN、VoIP、遊戲、IoT 等非 HTTP 流量。
- 針對大量連線、高吞吐、極低延遲場景（例如交易系統、即時通訊）表現較佳，處理量級可非常高。
效能、延遲與健康檢查
- ALB：
- 需要解析 HTTP/gRPC，功能多，延遲略高但仍然適合大多數 Web/App 工作負載。
- 健康檢查多為 HTTP/HTTPS，能檢查 URL path（例如
/healthz）回應狀態碼，較能反映應用層健康度。
- NLB：
- 幾乎只做 L4 連線分配，單位時間可處理更多連線，延遲更低。
- 健康檢查通常是 TCP 或 HTTP，但角度仍偏 L4；可做到 connection-level 高可用，但對應用錯誤的感知較有限。
常見使用情境
- 適合用 ALB 的情境：
- 標準 Web/API 服務（HTTP/HTTPS/gRPC），需要：
- Path/Host-based routing（/api /static /admin 分流）。
- 與 WAF、認證整合（例如 OIDC SSO）。
- 需要直接 terminates TLS，在 LB 上做 SSL Offloading 或 Header 轉寫。
- 適合用 NLB 的情境：
- 服務協議是 TCP/UDP（DB Proxy、MQ、遊戲伺服器、VoIP、DNS、SMTP 等）。
- 需要固定 IP 或綁 EIP（例如對合作方開防火牆白名單，或硬體設備只能設特定 IP）。
- 高併發、低延遲要求，非常看重處理量與延遲，且應用邏輯相對簡單。
整理表格
