ELB 为何分为 4 种类型 - ALB / NLB / GWLB / CLB 设计决策的内幕
从 OSI 参考模型的层级、性能特性和历史经过，解析 ALB、NLB、GWLB、CLB（Classic）这 4 种负载均衡器为何未统合而并存。
Classic Load Balancer - ELB 的起点
2009 年推出的 Elastic Load Balancing（现在的 Classic Load Balancer）是 AWS 首个负载均衡服务。CLB 被设计为能够同时处理 L4（TCP）和 L7（HTTP/HTTPS）流量的通用负载均衡器。然而，这种「什么都能做」的设计后来带来了问题。L4 和 L7 的负载均衡在技术上是根本不同的处理。L4 只查看数据包的源和目标 IP 地址与端口号来进行路由。L4 完全不解析数据包的内容（HTTP 头部或正文）。L7 则解析 HTTP 请求的内容（URL 路径、主机头、Cookie 等）来进行路由。若用 1 个服务提供这 2 种处理，就会产生一种权衡：L7 的开销会影响 L4 的处理，L7 的功能扩展会影响 L4 的稳定性。由于这一限制，CLB 无法实现 L7 的高级路由（基于路径的路由、基于主机的路由）。如今 AWS 将 CLB 定位为面向构建在 EC2-Classic 网络上的应用，并建议迁移到 ALB 或 NLB。CLB 属于旧一代，这一点也体现在其操作 API 的系列上。CLB 使用初代 Elastic Load Balancing API（版本 2012-06-01）操作，而之后加入的 ALB、NLB、GWLB 则属于以目标组为前提的另一套 API（elasticloadbalancingv2，版本 2015-12-01）。
ALB 的诞生 - 专注 L7 的设计
2016 年推出的 Application Load Balancer（ALB）是完全专注于 L7（HTTP/HTTPS）的负载均衡器。CLB 无法做到的基于路径的路由（/api/* 转到 API 服务器、/static/* 转到静态文件服务器）、基于主机的路由（将 api.example.com 和 www.example.com 转到不同的目标组），以及基于 HTTP 头部和 Cookie 的路由，由此得以实现。ALB 专注于 L7 所实现的重要功能，是对 WebSocket 的原生支持和对 HTTP/2 的支持。CLB 的 HTTP/HTTPS 监听器无法处理 WebSocket，需要采用通过不解析内容的 TCP 监听器直接透传的变通办法。CLB 也不支持 HTTP/2。ALB 还陆续加入了与 AWS WAF 的集成、内置 Cognito 认证、将 Lambda 函数作为目标直接调用等与应用层密切相关的功能。这些功能正因为能解析 L7 的 HTTP 请求才得以实现，在 L4 负载均衡器上从原理上就无法做到。能够解析 L7 的优势，也体现在对新协议的支持上。ALB 的目标组有一项名为协议版本的设置，除默认的 HTTP/1.1 之外，还可以选择 HTTP/2 和 gRPC（截至 2026 年 8 月的官方文档记载）。选择 gRPC 后，ALB 会解析 gRPC 请求，按包、服务、方法将请求分配到合适的目标组，并能处理单向、客户端流式、服务器流式、双向流式的全部类型。健康检查以 /package.service/method 的格式指定方法，判定为成功的 gRPC 状态码也由用户自己决定。限制方面，监听器协议仅限 HTTPS，监听器规则的操作仅限 forward，目标类型仅限 instance 和 ip，Lambda 函数不能作为目标。ALB 的费用以 LCU（Load Balancer Capacity Unit）这一独有单位计算。LCU 由新建连接数、活动连接数、处理的数据量、规则评估数这 4 项指标中的最大值决定。
NLB 的诞生 - 追求 L4 极限性能
2017 年推出的 Network Load Balancer（NLB）专注于 L4（TCP/UDP/TLS），是追求极限性能的负载均衡器。NLB 每秒可处理数百万请求，延迟也比 ALB 更低。不过 AWS 并未以具体数值公布两者的延迟，官方对 NLB 的描述仅停留在「超低延迟」这一定性说法上。正确的做法是在自己的工作负载上实测后再判断，而不是靠比较产品目录上的数值来选择。这种性能差异源于 NLB 完全不解析数据包的内容。NLB 以流（源 IP + 端口、目标 IP + 端口的组合）为单位决定路由，之后的数据包会转发到同一目标。由于完全没有解析 HTTP 头部、读取 Cookie、评估 URL 路径之类的处理，通过所需的处理环节本身就少，开销也就小。NLB 的另一项重要特征是支持静态 IP 地址。ALB 的 IP 地址会动态变化，因此只能通过 DNS 名称访问。NLB 在每个 AZ 都拥有固定的 IP 地址（可分配 Elastic IP），因此可以登记到防火墙的 IP 白名单中。像金融机构和电信运营商这样需要固定连接目标 IP 地址的环境，NLB 是必不可少的。此外，NLB 能将客户端的源 IP 保留到目标，因此应用端无需依赖转发头即可判断访问来源。
Gateway Load Balancer 的加入 - 在路径中插入设备的第 4 种选择
2020 年加入的 Gateway Load Balancer（GWLB）是第 4 种负载均衡器。ALB 和 NLB 是「为收到的流量选择目的地」的装置，而 GWLB 是「在流量的路径中插入检查设备」的装置，两者的目标方向本来就不同。GWLB 的用途是把防火墙、入侵检测与防御系统（IDS/IPS）、深度包检测设备等第三方虚拟设备，整合为透明的单一入口和出口，并按需求进行扩展。GWLB 在 OSI 参考模型的第 3 层（网络层）工作，监听所有端口上的所有 IP 数据包，并转发到监听器规则中指定的目标组。为了让同一条流到达同一台设备，GWLB 默认以 5 元组（另有 3 元组、2 元组）维持流粘性。GWLB 与已注册的设备之间，通过 GENEVE（RFC 8926）协议的 6081 端口传递流量（截至 2026 年 8 月的官方文档记载）。这里之所以需要封装，并非出于设备一方的考虑，而是透明性要求本身所致。原样传送原始数据包、不做任何改写，是透明运行的前提。而原样的数据包的源和目标 IP 与 GWLB 和设备的 IP 都不一致，因此在基于 IP 的普通 VPC 路由中，GWLB 和设备都会被绕过。除了把原始数据包封装进新的 L3 数据包之外，没有其他办法让两者之间的通信成立。此外，GENEVE 能以 TLV（Type-Length-Value）格式携带任意附加信息，因此 GWLB 可以为每个数据包附上端点 ID 和流 Cookie 等信息。由此，即使是 CIDR 有时会重叠的多租户设备，也能区分流量的来源，避免把流量弄混。仅有固定长度字段的 VXLAN 和 GRE 无法满足这一要求，官方将此说明为选择 GENEVE 的理由。部署也采用专门的形式。GWLB 与虚拟设备放在同一 VPC 中，并将设备注册到目标组。跨越 VPC 边界传递流量时，使用基于 AWS PrivateLink 的 Gateway Load Balancer 端点。使用方的 VPC 在路由表中把这个端点指定为下一跳，因此端点和应用服务器需要建在不同的子网中。之所以能在不改变应用端设置的情况下插入检查，是因为这种路径设计与封装两者兼备。
为何不统合为一个
「把 ALB 和 NLB 统合为 1 个服务不就好了吗」这个疑问很自然，但不统合的理由在技术上很明确。L4 和 L7 的负载均衡，处理流水线根本不同。L7 要接收所有数据包，重组为 HTTP 请求，解析头部，评估路由规则，必要时改写头部，然后才转发到目标。这种处理会消耗内存和 CPU。L4 只查看数据包的头部（IP + TCP/UDP）来决定转发目标，不触及数据包的内容。若把这 2 种处理统合到 1 个服务中，L4 的性能会被 L7 的处理流水线拖累而下降。加上 GWLB 之后，无法统合的理由就更进一步地清楚了。ALB 和 NLB 自身充当连接或请求的终点，是会在必要时改写头部或地址的装置。GWLB 则相反，不改写原始数据包是其规格上的要求，为此 GWLB 拥有以封装和路由表联动为前提的数据路径。如果把终结型装置和透明型装置合成 1 个产品，设置项中就会混入对另一方毫无意义的内容，用户也就无法看出「现在执行的是哪一种动作」。CLB 保持「什么都能做」的设计却无法实现 L7 的高级路由，这一事实说明这种分化并非事后附加的权宜之计。AWS 的设计理念「专用型服务」，是为了避免这类权衡而将功能分离并分别优化的方针。之所以有 4 种，并不是选项的泛滥，而是为在 L7 终结、在 L4 终结、在 L3 透明插入，以及旧一代通用型这 4 种不同的工作，分别分配了最适合的实现的结果。
选择判断标准
4 种 ELB 的选择由工作负载的特性决定。处理 HTTP/HTTPS 流量，并且需要基于路径或基于主机的路由时，选 ALB。Web 应用、REST API、微服务大多以 ALB 最优，gRPC 也能通过目标组的协议版本原生处理，因此 ALB 是首选。处理 TCP/UDP 流量，并且需要极限性能或静态 IP 时，选 NLB。NLB 适合游戏服务器、来自 IoT 设备的连接、金融交易系统这类不需要 L7 解析、以连接数和延迟为主导因素的工作负载。想在流量的路径中插入第三方的防火墙、IDS/IPS、深度包检测设备时，选 GWLB。与其说是选择负载均衡器，不如说是把检查平台的入口和出口集中到 1 处、让设备群扩展的设计决策。不过，这以支持 GENEVE 的设备和路径设计为前提，因此要先在官方文档中确认集成要求再决定是否采用。新建系统时不选 CLB。AWS 将 CLB 定位为面向 EC2-Classic 网络（已于 2022 年停用）上的应用，并建议迁移到 ALB 或 NLB。迁移有官方的迁移向导，可以根据现有 CLB 的设置创建同等的 ALB 或 NLB。不过，向导只会创建新的负载均衡器，并不会转换现有的 CLB，因此流量的切换需要自己进行。也有组合使用的模式。在 NLB 后方配置 ALB，就能兼顾 NLB 的静态 IP 与 ALB 的 L7 路由。NLB 可用于 AWS PrivateLink 的端点服务，因此在通过 PrivateLink 公开服务、同时又需要 L7 路由时，会选择这种架构。GWLB 与其他 3 种并不互斥，基本用法是将 GWLB 插入 ALB 或 NLB 前方的路由路径中一起使用。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。