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)

參考

• Reducing Surge Queue Length in AWS Elastic Load Balancing

alb AWS load balancer nlb