亚马逊云负载均衡：从流量分发到架构韧性，一篇吃透ELB全系产品

引子：当流量洪峰来袭，谁在为你守住第一道防线？

想象一下这个场景：你的创业项目终于熬过了漫长的开发周期，产品上线当天，用户像潮水一样涌进来。服务器负载飙升，CPU告警，页面开始转圈——然后，崩了。你盯着监控面板，眼睁睁看着那一串串绿色的健康检查变成红色，心里只有一个念头：要是当初把负载均衡配好了该多好。

这个故事在云时代每天都在上演。区别在于，有的人在崩了之后学会了负载均衡，有的人在崩之前就搞懂了。今天这篇文章，就是要帮你成为后者。

亚马逊云科技（AWS）的弹性负载均衡（Elastic Load Balancing，简称ELB），从2009年推出至今，已经走过了十几个年头。它从最初那个只能做简单TCP/HTTP分发的经典负载均衡器（CLB），一路进化成了今天的“四兄弟”阵容——ALB、NLB、GWLB、CLB。每一款都有自己的脾气、自己的绝活、自己的适用场景。选对了，如虎添翼；选错了，事倍功半。

这篇文章，就是带你一次性吃透亚马逊云负载均衡的整个产品矩阵。

一、ELB是什么？它到底在解决什么问题？

先说清楚一个最基本的概念：负载均衡（Load Balancing）的核心任务，就是把 incoming 的流量，智能地分发到多个后端服务器上。它不是简单地把请求轮着发一圈就完事了——真正优秀的负载均衡器，要同时做好三件事：第一，识别哪些后端是健康的、能接活的；第二，根据流量特征和后端能力做智能分配；第三，在后端出问题的时候快速摘除、快速恢复。

亚马逊云的ELB，就是把这套逻辑做成了托管的云服务。你不需要自己搭建Nginx或HAProxy集群，不需要操心高可用、不需要担心扩容——AWS把这一切都封装好了，你只需要在控制台上点几下，或者在Terraform里写几行代码，一个生产级别的流量分发系统就上线了。

但问题来了：ELB不是一个产品，而是一个产品家族。AWS目前提供四种负载均衡器，分别是Application Load Balancer（ALB）、Network Load Balancer（NLB）、Gateway Load Balancer（GWLB），以及已经被标记为“上一代”的Classic Load Balancer（CLB）。这四兄弟虽然都叫负载均衡，但各自的工作方式、擅长的场景、甚至计费逻辑都完全不同。

二、四兄弟各显神通：ALB、NLB、GWLB、CLB 谁是谁？

（一）Application Load Balancer（ALB）——七层路由的“智能大脑”

ALB 是 AWS 负载均衡家族里最“聪明”的一个。它工作在 OSI 模型的第七层——应用层。这意味着它不仅能看到 IP 和端口，还能“读懂”HTTP请求的内容：URL路径是什么、Host头是什么、Query String里带了什么参数、甚至 Cookie 里存了什么。

举个具体的例子：假设你有一个微服务架构的电商应用，/api/products 路由到商品服务，/api/orders 路由到订单服务，/api/users 路由到用户服务。用 ALB，你只需要在监听器上配置三条路由规则，流量就会自动分流到对应的目标组。如果你想做蓝绿部署或者金丝雀发布——比如先把 5% 的流量引到新版本上看看效果——ALB 的加权目标组功能可以让你精确控制流量比例，从 0 到 999 随便调。

ALB 还天然支持 WebSocket、HTTP/2、gRPC 这些现代协议。同时，它和 AWS WAF（Web应用防火墙）深度集成，可以在流量进入后端之前先做一层安全过滤。如果你需要做用户认证，ALB 还能直接对接 Amazon Cognito 或者任何 OIDC 兼容的身份提供商。

一句话总结：如果你的流量是 HTTP/HTTPS，并且你需要基于请求内容做精细化路由——选 ALB，错不了。

（二）Network Load Balancer（NLB）——四层转发的“性能怪兽”

如果说 ALB 是“聪明”，那 NLB 就是“快”。NLB 工作在 OSI 模型的第四层——传输层。它不关心 HTTP 请求里写了什么，只看 IP 和端口，然后以极低的延迟把流量转发到后端。

NLB 能快到什么程度？它每秒可以处理数百万个请求，而且延迟是微秒级的。这种性能让它成为游戏服务器、实时音视频、金融交易、IoT 设备通信这类对延迟极度敏感的业务的天然选择。

NLB 还有一个 ALB 不具备的杀手锏：静态 IP。每个可用区（Availability Zone）的 NLB 节点都有一个固定的 IP 地址，你甚至可以给它绑定弹性 IP（EIP）。如果你的下游系统或者防火墙需要白名单机制，NLB 的静态 IP 能让你省去很多麻烦。另外，NLB 默认保留客户端的真实源 IP，后端服务器可以直接看到请求是从哪个 IP 发出来的——这对审计、风控、地理定位等场景非常关键。

还有一个高级玩法：把 NLB 放在 ALB 前面。NLB 提供静态入口 IP 和极致的性能，然后把流量转发给后端的 ALB，由 ALB 做七层的精细化路由。这种“NLB + ALB”的组合拳，在需要同时满足“固定 IP”和“高级路由”的场景下非常实用。

一句话总结：如果你的流量是 TCP/UDP/TLS，或者你对延迟有极致要求，或者你需要静态 IP——选 NLB。

（三）Gateway Load Balancer（GWLB）——安全设备的“透明管家”

GWLB 是 AWS 负载均衡家族里最年轻、也最特殊的一个成员。它工作在 OSI 模型的第三层——网络层。它的设计目标不是把流量分发给应用服务器，而是把流量透明地导向第三方虚拟安全设备——比如防火墙、入侵检测/防御系统（IDS/IPS）、深度包检测（DPI）设备。

GWLB 使用 GENEVE 封装协议来包裹原始流量，然后转发给后端的设备集群。所有的安全设备对客户端和后端应用来说都是透明的——客户端不知道中间有安全设备在检查流量，后端应用也不知道流量是被检查过才过来的。这种透明性让 GWLB 成为安全架构里的理想“流量管家”。

一句话总结：如果你需要在流量路径中插入第三方的安全设备——选 GWLB。

（四）Classic Load Balancer（CLB）——上一代的“老前辈”

CLB 是 AWS 在 2009 年推出的第一代负载均衡器，同时支持四层和七层的基本功能。但它的能力在今天来看已经明显落后——不支持基于内容的路由、不支持静态 IP、不支持 Lambda 作为目标、不支持多种现代协议。AWS 官方已经将 CLB 标记为“上一代”产品，并且推荐新业务直接选用 ALB 或 NLB。除非你有历史遗留系统必须用 CLB，否则新项目不建议再选它了。

三、选型决策：面对真实业务场景，到底该选谁？

理论讲完了，现在来点实在的。下面这些场景，你在实际工作中大概率会遇到——每个场景我都直接给出推荐方案。

场景一：你有一个 Web 应用，用 React 或 Vue 写的，后端是 Node.js 或 Java。 推荐 ALB。你需要基于 URL 路径做路由（/api 给后端，/static 给静态资源），需要 SSL 卸载，可能还需要做用户认证。这些都是 ALB 的看家本领。

场景二：你有一个多人在线游戏，或者一个实时音视频通话应用。 推荐 NLB。这类业务对延迟极度敏感，而且通常使用 TCP 或 UDP 协议。NLB 的微秒级延迟和百万级并发处理能力是刚需。

场景三：你需要在流量路径中部署一套防火墙或入侵检测系统。 推荐 GWLB。它专门为这种“透明流量安检”场景而生。

场景四：你的下游系统要求你提供固定的 IP 地址做白名单，但同时你又需要七层的路由能力。 推荐 NLB + ALB 组合。NLB 提供静态入口 IP，ALB 做七层路由。

场景五：你在 Kubernetes 上跑业务，需要用 Ingress 暴露服务。 推荐 AWS Load Balancer Controller，它可以根据你的 Ingress 资源自动创建 ALB，根据 Service 类型自动创建 NLB。

四、最佳实践：把 ELB 用好的五个关键动作

选对了类型只是第一步。真正把 ELB 用好，下面这五个实践值得认真对待。

实践一：健康检查要“准”不要“快”。 健康检查（Health Check）是 ELB 判断后端是否“活着”的唯一依据。很多人图省事，直接用默认的 TCP 健康检查——但这只能告诉你端口是不是开着，不能告诉你应用是不是真的能处理请求。更靠谱的做法是：在应用里单独开一个 /health 端点，专门做健康检查，返回 200 就代表“我很好”，返回其他状态码就代表“我有问题”。健康检查的间隔、超时、健康阈值、不健康阈值这些参数也需要根据业务特点调优——太频繁会增加不必要的负载，太慢会导致故障发现不及时。

实践二：跨可用区部署是底线，不是选项。 AWS 官方的最佳实践指南里反复强调：至少在两个可用区（AZ）中部署你的应用。ELB 本身是跨可用区高可用的——如果一个 AZ 出问题，ELB 会自动把流量切到其他 AZ 的正常实例上。但前提是你在多个 AZ 里都有健康的实例。单 AZ 部署，ELB 再强也救不了你。

实践三：用好目标组的加权路由做平滑发布。 如果你还在用“半夜停机发布”的方式做版本更新，那真的该升级了。ALB 和 NLB 都支持在同一个负载均衡器下挂多个目标组，每个目标组可以分配不同的权重。新版本上线时，先把新版本的目标组权重设为 1% 或 5%，观察一段时间没问题再逐步提高权重，最终达到 100%。这就是金丝雀发布（Canary Deployment）——把发布风险降到最低。

实践四：开启访问日志，别等出了问题再后悔。 ELB 的访问日志（Access Logs）记录了每一个请求的详细信息——来源 IP、请求路径、响应时间、后端处理时间、返回状态码。这些数据是排查问题的金矿。出了故障，看一眼日志就知道是客户端的问题、网络的问题还是后端的问题。建议把访问日志投递到 S3，然后用 Athena 做分析，成本极低但收益巨大。

实践五：和 Auto Scaling 联动，让扩缩容自动化。 负载均衡和自动扩缩容是云上高可用架构的“左右手”。Auto Scaling 根据 CPU 利用率、请求数或自定义指标自动增加或减少实例数量，ELB 自动把新实例注册到目标组、把下线的实例摘除。这套组合拳打好了，你的应用就能在流量高峰时自动扩容、在低谷时自动缩容——既保证了可用性，又控制了成本。

五、成本考量：ELB 到底要花多少钱？

聊完技术，再来聊聊钱。ELB 的计费方式取决于你用的是哪种负载均衡器。

CLB 的计费相对简单：按负载均衡器运行的小时数 + 按 GB 计费的数据处理量。

ALB 和 NLB 采用更精细的“容量单位”计费模式——ALB 用 LCU（Load Balancer Capacity Unit），NLB 用 NLCU。每个 LCU 涵盖四个维度：每秒新连接数、每分钟活跃连接数、每小时处理的数据量（GB）、每秒规则评估数。你的实际费用 = 负载均衡器小时费 + LCU/NLCU 消耗费。

对于新用户，AWS 提供了为期一年的免费套餐：每月 750 小时的负载均衡器使用时间（CLB、ALB、NLB 共享），以及 15 GB 的 CLB 数据处理量、15 个 ALB LCU、15 个 NLB NLCU。

成本优化方面有几个实用建议：第一，如果你的流量比较平稳，可以考虑预留 LCU 容量，比按需付费便宜；第二，不要在一个账号里创建一堆用不上的负载均衡器，每个闲置的 LB 都在烧钱；第三，跨可用区传输会产生额外的流量费用，如果业务对延迟不敏感，可以考虑把流量尽量限制在同一个可用区内。

上饶市万云信息科技有限公司是国内深耕多年的综合型多云服务合作商，业务覆盖阿里云、腾讯云、华为云、天翼云、火山云、微软云、谷歌云、亚马逊云八大主流公有云平台。依托多年行业深耕，企业整体业务体量成熟稳定，八大云平台全年综合销量突破20亿人民币，累计服务超100万合作客户，累计助力企业部署云服务器近1亿台。公司现有全职员工500人，行业经验10年+，单亚马逊云销量每年5000万美金，是亚马逊云头部一级代理商。如果您的业务需要亚马逊云服务，通过上饶市万云信息科技采购亚马逊云可享受8.5折优惠或15%返点，技术团队可提供从架构设计到部署交付的全链路支持。

六、结语：负载均衡不是终点，而是高可用架构的起点

回到开头那个创业故事。如果那位创业者在产品上线之前，花半天时间把 ELB 搞懂了、配好了——ALB 做流量分发、健康检查配到位、跨可用区部署做好、Auto Scaling 联动起来——那波流量洪峰对他来说不是灾难，而是一场盛大的压力测试，验证了他的架构是真的能扛。

亚马逊云负载均衡从来不是一个“有了就行”的组件。它是一整套流量管理哲学的载体：如何做健康探测、如何做流量调度、如何做灰度发布、如何做故障隔离、如何做成本控制。把 ELB 吃透了，你收获的不只是一个云服务的用法，而是一套构建高可用、高弹性系统的思维框架。

希望读完这篇文章的你，下次面对流量洪峰的时候，能从容地说一句：“没事，我有 ELB。”

常见问题解答

问1：ALB 和 NLB 可以同时使用吗？
答：可以。常见的架构是在 NLB 后面挂 ALB——NLB 提供静态入口 IP 和四层高性能转发，ALB 做七层的精细化路由。这种组合兼顾了固定 IP 和高级路由两种需求。

问2：ELB 的健康检查多久做一次比较合适？
答：默认是 30 秒一次。对于大多数业务来说这个频率是合理的。如果业务对故障恢复速度要求极高，可以缩短到 10-15 秒，但要注意健康检查本身也会消耗后端资源。建议根据业务容忍度来调，不要一味追求“快”。

问3：CLB 还能用吗？
答：能用，但 AWS 官方已经明确将其定位为“上一代”产品，并且新功能基本不再往 CLB 上添加。新项目建议直接选用 ALB 或 NLB，历史遗留系统可以逐步迁移。

问4：ELB 支持跨区域流量分发吗？
答：ELB 本身是区域级别的服务，只能在一个 Region 内的多个可用区之间做流量分发。如果需要跨区域分发，需要配合 Route 53 的 DNS 级别的负载均衡或者 Global Accelerator 来实现。

问5：ELB 的免费套餐够用吗？
答：对于个人学习、开发测试或者流量极低的小型项目，免费套餐基本够用。每月 750 小时的 LB 运行时间 + 15 个 LCU 的额度，覆盖一个中等规模的测试环境绰绰有余。但生产环境的正式业务，建议根据实际流量评估预算。

问6：GWLB 和普通的负载均衡器有什么区别？
答：最大的区别在于目标。ALB 和 NLB 的目标是应用服务器（EC2、容器、Lambda 等），而 GWLB 的目标是第三方安全设备（防火墙、IDS/IPS 等）。GWLB 的作用是把流量“引到”安全设备去检查，而不是直接把流量交给应用。