AWS 從之前就推出 ALB (Application Load balancer) 和 NLB (Network Load balancer) 這兩種能取代 CLB (Classic Load balancer) 的類型，也在介面上做出「區別」。
實際上這三種 Load balancer 都各司其職，擁有自己在 AWS 的一個定位
CLB (Classic Load Balancer)
- 支援 EC2-Classic (較早期的 EC2 Type, ex. T1、M1/2/3、C1/3 …)
- 支援 TCP and SSL listens
- 支援 Sticky sessions (cookies)
算是第一代的 Load balancer，基本上能支援一般 Load balancer 的需求，直至目前仍有很多使用者使用。
ALB (Application Load Balancer)
- Layer 7 層級的 Load balancer
- 支援 Content Path Routing，透過 Target Group 指定到不同來源路徑 (ex. /admin)，這是 Microservice 之後很常見的 Load balance 功能，也是選用 ALB 使用者最主要的原因之一。
- 支援 On-Premises、EC2、Lambda 作為 Target，地端只要提供 Routing 去的了的 IP 就可以不用買 Load balance 啦 XDD .. (但是 Latency 也需要考量)
- 支援使用 AWS WAF
- 內建 AWS shield：遇到 DDos 之類的攻擊，AWS 會提供基本的防禦機制。
- 隨時可以更換 AZ 腳位
- 價格比 CLB 還便宜一些
第二代的 Load Banlancer，AWS 提供了很多的誘因建議用戶採用 ALB 方案，但是 ALB 並不能涵蓋 CLB 所有的需求 (ex. TCP listen)。
基本上所有 HTTP / HTTPS 的服務在 ALB 上都能獲得更好的效能與功能，純 API 服務的不二選擇。
NLB (Network Load Balancer)
- Layer 3~4 層級的 Load balancer
- 支援 TCP、UDP
- 號稱能處理每秒千萬請求的 Load balancer
- 與 CLB/NLB 最大應用情境的不同
- By Pass 流量直接導入後端 instance，所以沒有 Security Group。
- 提供 Static IP
- 定價跟 ALB 一樣，也比 CLB 便宜一些
- Block traffic 因為底層 Layer 4 的關係會需要更多時間
NLB 是因應 ALB 不足所延伸的 Load balancer，提供非 HTTP / HTTPS 使用者更好的效能，更常用來作為 Socket、DNS、NTP、Proxy 等服務 Load balance。
總結 & 棄用 CLB
AWS 發展至今三種 Load Balancer，ALB / NLB 兩種幾乎打天下，而且更便宜，除非仍有 EC2-Classic 的 instance 還在運作，否則基本上不太建議再使用 CLB 這個類型。
然而還在使用 CLB 的人，也提供不建議使用的原因
- 更差的備援：CLB 會因為 ENI 在某個有異常的 AZ 機房導致 CLB 無法正常切換，而 ALB / NLB 解決了這個問題，甚至 ALB 可以隨時切換你的 AZ 腳位。
- 效能的瓶頸：AWS 基本上會替你 Scale-Out 底層 ENI，但是每一個 ENI 都有 Surge Queue Length 最多 1024 的限制，超過就會開始出問題。(參考 CloudWatch Metrics for Your Classic Load balancer)
參考