4. Elastic Load Balancing总览
Elastic Load Balancing（ELB）不是一款单一产品，而是一组面向不同流量形态的托管负载均衡器。它们共享“自动扩缩、健康检查、多可用区容灾”这些托管能力，但在工作层级、协议支持、性能特征和计费方式上差异明显。选型的核心不是比较谁“更强”，而是判断你的流量属于哪一类：是 HTTP/HTTPS 应用流量、TCP/UDP 四层流量、需要交给安全设备检查的流量，还是遗留系统仍在使用的经典负载均衡。
四类负载均衡器的定位差异
Application Load Balancer（ALB）工作在 OSI 第 7 层，理解 HTTP 与 HTTPS。它能基于主机头、路径、查询字符串、HTTP 方法、请求头做路由，支持 WebSocket、HTTP/2、gRPC，并可与 AWS WAF、Cognito、OIDC 集成。ALB 的目标是“按请求内容分发”，适合微服务、容器、多域名共用一个入口的 Web 应用。
Network Load Balancer（NLB）工作在第 4 层，处理 TCP、UDP、TLS。它按连接（流）分发，能保留客户端源 IP，支持超低延迟与极高吞吐，并可分配静态弹性 IP。NLB 适合数据库代理、游戏服务器、MQTT、金融交易等对延迟和连接稳定性敏感的场景。
Gateway Load Balancer（GWLB）同样工作在第 3/4 层，但它不是给应用做入口，而是把流量“透明地”送给第三方安全设备（防火墙、入侵检测、深度包检测）。GWLB 使用 GENEVE 封装，配合 Gateway Load Balancer Endpoint 在 VPC 中形成一条检查链，常用于集中式安全检测架构。
Classic Load Balancer（CLB）是早期产品，支持 HTTP/HTTPS 与 TCP/SSL，但不支持基于路径的路由、现代协议和许多新特性。AWS 已不再推荐新建使用，仅在维护遗留系统时保留。
协议支持与性能特征
协议支持决定了“能不能接住流量”。ALB 只接受 HTTP/HTTPS，因此不能直接承载纯 TCP 数据库连接；NLB 接受 TCP、UDP、TLS，但不解析 HTTP 语义，所以无法按 URL 路径分流；GWLB 处理 IP 层流量，用 GENEVE 封装后交给安全设备；CLB 支持 HTTP/HTTPS/TCP/SSL，但缺少现代特性。
性能上，NLB 面向“连接级”转发，单可用区可支撑数百万并发连接，延迟通常在微秒到毫秒级，且支持静态 IP，适合需要固定入口地址的场景。ALB 面向“请求级”处理，吞吐和连接数同样很高，但因为它要解析 HTTP、执行规则匹配，单请求延迟略高于 NLB。GWLB 的性能瓶颈通常不在负载均衡器本身，而在后端安全设备的处理能力。CLB 的性能与功能都已被前两者覆盖。
计费模式：LCU 是理解成本的关键
ALB、NLB、GWLB 都采用“运行小时费 + 容量单位费”的模式，但容量单位不同。ALB 使用 LCU（Load Balancer Capacity Unit），每个 LCU 包含每秒 25 个新建连接、每分钟 3000 个活跃连接、每小时 1 GB 流量、每秒 1000 条规则评估，取四项中消耗最大者计费。NLB 使用 NLCU，包含每秒 800 个新建连接、每分钟 100000 个活跃连接、每小时 1 GB 流量。GWLB 使用 GLCU，主要按端点数量和流量计费。CLB 则按运行小时和流量计费，没有 LCU 概念。
这意味着：一个高连接数、低流量的场景（如长轮询）可能由“活跃连接”项主导成本；一个高吞吐、低连接数的场景（如大文件下载）可能由“流量”项主导。选型时不能只看单价，要结合业务流量画像估算。
选型决策：从业务需求反推
实际选型可以按以下顺序判断：
- 流量是否包含 HTTP/HTTPS 语义？是，优先 ALB；否，进入下一步。
- 是否需要保留源 IP、静态 IP 或极低延迟？是，选 NLB；否，进入下一步。
- 是否需要把流量透明送给第三方安全设备？是，选 GWLB；否，进入下一步。
- 是否在维护无法改造的遗留系统？是，暂时保留 CLB，并规划迁移到 ALB 或 NLB。
例如，一个电商系统前端是 HTTPS 多域名，后端有订单、商品、支付三个微服务，应使用 ALB 按路径路由；订单服务需要连接 MySQL，MySQL 前面可以放 NLB 做 TCP 转发并保留源 IP；如果企业要求所有入站流量先经过防火墙集群，则在 VPC 入口部署 GWLB，把流量引到防火墙再回注。三者可以组合使用，而不是互斥选择。
一个可执行的选型检查表
| 判断项 | ALB | NLB | GWLB | CLB |
|---|---|---|---|---|
| 工作层级 | 第 7 层 | 第 4 层 | 第 3/4 层 | 第 4/7 层 |
| 协议 | HTTP/HTTPS/gRPC | TCP/UDP/TLS | IP/GENEVE | HTTP/HTTPS/TCP/SSL |
| 路径路由 | 支持 | 不支持 | 不适用 | 不支持 |
| 保留源 IP | 通过 X-Forwarded-For | 原生保留 | 不适用 | 部分支持 |
| 静态 IP | 不支持 | 支持 EIP | 不适用 | 不支持 |
| 计费单位 | LCU | NLCU | GLCU | 小时 + 流量 |
| 典型场景 | 微服务、Web | 数据库、游戏 | 安全检测链 | 遗留系统 |
最后需要强调：ELB 的选型不是一次性的。随着业务从单体走向微服务，入口可能从 CLB 迁移到 ALB；随着实时通信需求增加，又可能为特定端口增加 NLB。理解四类负载均衡器的层级、协议、性能和计费差异，才能在架构演进中做出有依据的决策，而不是凭习惯或默认选项。