亚马逊云负载均衡完全使用指南：从ALB到NLB的实战选型与配置详解

一、流量洪峰下的第一道防线：为什么你的架构需要一个负载均衡器

做过线上项目的人都知道，流量这东西从来不跟你讲道理。今天还是个安安静静的小站点，明天可能就因为某个活动或者一条爆款内容，瞬间被海量请求冲垮。几年前我接手过一个电商项目，上线第一天数据库和Web服务器都扛得好好的，结果第二天早上九点——用户开始上班摸鱼刷网页——CPU直接飙到95%，页面加载时间从200毫秒变成20秒，客服电话被打爆。后来查日志才发现，单台EC2实例在峰值时每秒要处理将近一万个请求，根本顶不住。

从那以后我就明白了：高可用不是锦上添花，是生存底线。而AWS Elastic Load Balancing（ELB），就是这个防线上的核心武器。ELB做的事情本质上很简单——把 incoming 流量分散到多个后端目标上——但它的价值远不止“分摊压力”这么表面。它还能做健康检查，自动剔除挂掉的实例；能做基于内容的路由，把不同请求分发给不同的微服务；能提供静态IP入口，解决传统负载均衡最头疼的地址漂移问题。

说白了，ELB就是你的架构在面对流量洪峰时的缓冲区和调度中心。没有它，你的后端实例就像直接暴露在枪林弹雨里的步兵；有了它，就像给每个后端配了一个智能盾牌和交通指挥。AWS目前提供了四种负载均衡器：Application Load Balancer（ALB）、Network Load Balancer（NLB）、Gateway Load Balancer（GWLB），以及已经进入淘汰序列的Classic Load Balancer（CLB）。前三种是当前的主流选择，搞清楚它们的区别和使用场景，是每个AWS架构师的必修课。

二、三款主力负载均衡器：ALB、NLB、GWLB到底有什么不一样

很多人刚接触ELB的时候，第一反应是“不就分个流嘛，有什么区别”。但等你真正开始配置的时候就会发现——区别大了去了。这三款产品虽然都叫“负载均衡”，但它们在OSI模型层级、路由能力、性能特征、适用场景上的差异，直接决定了你选错了会踩多大的坑。

Application Load Balancer（ALB）运行在第七层——应用层。它看得懂HTTP和HTTPS协议，能根据URL路径、Host头、HTTP头、查询字符串甚至请求方法来做路由决策。比如你可以配置一条规则：所有访问 `/api/*` 的请求转发到API服务的目标组，`/images/*` 转到图片处理服务，其他请求默认走前端应用。这种基于内容的路由能力，让ALB成为微服务架构和Web应用的首选入口。此外ALB还支持WebSocket、HTTP/2、gRPC协议，能直接以Lambda函数作为目标，深度集成AWS WAF和Cognito认证。

Network Load Balancer（NLB）运行在第四层——传输层。它不关心你的请求内容是HTML还是JSON，只看IP地址和端口。NLB的强项是极致的性能和极低的延迟——每秒可以处理数百万个请求，延迟在毫秒级别。它还能为每个可用区分配一个静态IP，支持绑定弹性IP。如果你的业务需要TCP/UDP直通、静态IP白名单、或者对延迟极度敏感（比如游戏后端、金融交易系统、实时消息服务），NLB是最佳选择。NLB还有一个独特优势：它天然保留客户端的真实源IP，不需要像ALB那样靠 `X-Forwarded-For` 头来传递。

Gateway Load Balancer（GWLB）跑在第三层——网络层。它的定位跟前两者完全不同——不是用来直接分发业务流量，而是用来串联第三方网络虚拟设备，比如防火墙、入侵检测系统（IDS/IPS）、深度包检测（DPI）设备。GWLB使用GENEVE封装协议，对所有IP流量做透明转发，把流量“灌”给安全设备集群处理完再吐出来。简单说，ALB和NLB是“往前端分流量”，GWLB是“往中间插一道安全过滤”。

用一个比喻来收尾这部分：ALB是懂业务的交通警察——看车牌（Host头）、看目的地（URL路径）、看货物类型（HTTP方法），按规则分流；NLB是高速路口的闸机——不管你是谁、运什么，只看你是从哪个口进来的就走哪条道，速度最快；GWLB是安检通道——所有车都得过一遍X光机，确认没问题再放行。

三、从零搭建ALB：监听器、目标组与健康检查的完整配置流程

理论说完了，来点实操。下面以ALB为例，走一遍完整的配置流程。AWS提供了多种创建方式：Management Console（点点点）、AWS CLI、或者Infrastructure-as-Code工具（Terraform、CloudFormation）。新手建议从Console入手，先把概念和流程跑通。

第一步：创建目标组（Target Group）。目标组就是后端服务器的“集合”。在EC2控制台的“负载均衡”菜单下找到“目标组”，点击创建。你需要指定：目标类型（实例、IP地址或Lambda函数）、协议和端口（比如HTTP 80）、VPC网络、以及健康检查配置。健康检查这一步非常关键——它决定了ALB怎么判断你的后端实例是死是活。通常配置为：检查路径 `/health` 或 `/ping`，期望返回HTTP 200，间隔30秒，超时5秒，连续2次成功算健康、3次失败算不健康。千万别把健康检查路径设成一个耗时的业务接口，否则健康检查本身就能把实例拖垮。

第二步：创建ALB并配置监听器（Listener）。在“负载均衡器”页面点击创建，选择“Application Load Balancer”。需要配置：名称、Scheme（面向互联网还是内部）、IP地址类型、以及至少两个可用区的子网（为了高可用）。然后是监听器——ALB的“前门”。每个监听器绑定一个协议和端口，比如HTTP 80或HTTPS 443。至少需要一个监听器，ALB才能开始接收流量。如果需要HTTPS，还需要在ACM（AWS Certificate Manager）里申请或上传证书，然后在监听器上配置SSL终止。

第三步：配置监听器规则（Listener Rules）。这是ALB真正体现“智能路由”的地方。每个监听器有一个默认规则（兜底转发），还可以添加最多100条额外规则。规则由条件（Conditions）和动作（Actions）组成。条件可以是：path-pattern（URL路径）、host-header（域名）、http-header（任意HTTP头）、query-string（查询参数）、source-ip（来源IP）等。动作最常见的是 `forward`（转发到某个目标组），也可以是 `redirect`（重定向）或 `fixed-response`（直接返回固定内容）。规则按优先级顺序评估——数字越小优先级越高。举个例子：你可以配置优先级10的规则——路径 `/api/*` 转发到API目标组；优先级20——路径 `/admin/*` 转发到管理后台目标组；优先级100（默认）——其余所有请求转发到前端目标组。

第四步：注册目标并验证。把EC2实例手动注册到目标组，或者通过Auto Scaling组自动注册。然后在ALB的“目标组”页面查看实例的健康状态——绿色表示健康，红色表示不健康。如果是红色，去检查安全组是否放行了健康检查流量、实例上的服务是否正常响应健康检查路径。全部绿色之后，复制ALB的DNS名称（比如 `my-alb-123456789.elb.amazonaws.com`），浏览器打开就能访问你的应用了。

四、进阶实战：粘性会话、跨可用区与TLS终止的高级配置

基础配置跑通之后，还有几个高级功能值得掌握，它们往往决定了生产环境的质量。

粘性会话（Sticky Sessions）。有些应用把用户会话状态存在本地内存里（比如购物车、登录状态），这就要求同一个用户的请求始终打到同一台后端服务器上。ALB支持两种粘性方式：一种是ALB自己生成的cookie（`AWSALB`），可以设置过期时间，最长7天；另一种是沿用应用自己生成的cookie（`AWSALBAPP`）。在目标组的“属性”里开启粘性即可。需要注意的是，粘性会话和弹性伸缩是有一点矛盾的——如果粘住的实例被缩容掉了，用户的会话就断了。所以要么把会话状态移到Redis等外部存储，要么谨慎评估粘性的必要性。

跨可用区负载均衡（Cross-Zone Load Balancing）。默认情况下，ALB是开启跨可用区负载均衡的——也就是说，即使某个可用区的实例少一些，ALB也会把流量均匀地分给所有可用区的健康实例。NLB默认是关闭的——流量只在本可用区内的实例间分配。这个区别在实际运维中影响很大：ALB开启跨可用区能更好地应对单可用区实例故障，但会产生跨可用区的流量费用；NLB关闭跨可用区则更省成本，但需要你在每个可用区部署相同数量的实例来保证负载均衡。

TLS终止与证书管理。ALB可以在监听器层面终止TLS加密——浏览器到ALB走HTTPS，ALB到后端实例走HTTP。这样后端实例就无需处理加解密开销，也无需管理证书。证书通过ACM托管，自动轮转。配置方式很简单：在HTTPS监听器里选择ACM证书即可。如果你有更严格的安全要求（比如双向TLS认证，即mTLS），ALB也是支持的。

将NLB置于ALB之前——这是一个高级架构模式：用NLB提供静态IP入口，然后把流量转发给后端的ALB做七层路由。这样既解决了ALB没有固定IP的问题（某些企业防火墙需要白名单），又保留了ALB的智能路由能力。缺点是多了一层转发，延迟会略微增加，成本也会上升。

五、选型决策树与成本考量：到底该选哪一个

聊完了功能差异和配置细节，回到那个终极问题：我的项目到底该选ALB、NLB还是GWLB？

这里给出一套决策逻辑，按顺序问自己几个问题：
第一问：你的流量是HTTP/HTTPS还是TCP/UDP？如果是HTTP/HTTPS，且需要按URL路径、域名、请求头做路由分发——选ALB。这是绝大多数Web应用、API网关、微服务架构的标准答案。
第二问：如果你的流量是TCP/UDP（比如数据库连接、游戏协议、物联网MQTT），或者你需要静态IP来做防火墙白名单，或者你对延迟的要求极其苛刻（毫秒以下）——选NLB。
第三问：如果你需要在流量路径里插入第三方防火墙、IDS/IPS等安全设备——选GWLB。注意GWLB不直接面向终端用户，而是作为“流量清洗管道”存在。
第四问：如果你不确定未来需求会怎么变——可以先用ALB起步。因为ALB功能最丰富、最灵活，后续如果需要静态IP，可以在ALB前面再套一层NLB。

关于成本，也需要有个基本概念。ALB的计费由两部分组成：每小时固定费用（us-east-1约$0.0225/小时）+ LCU（Load Balancer Capacity Unit）消耗费用。LCU取决于每秒新建连接数、活跃连接数、处理流量和规则评估数四个维度。NLB类似，但用的是NLCU，单价略有不同。GWLB按GLCU计费。简单估算：一个中等流量的Web应用（每秒100个新连接），ALB每月费用大约在$80-$100左右。对于中小型项目来说，这个成本是完全可以接受的——想想你少加几天班修复因流量突增导致的系统崩溃，这点钱就值回来了。

最后想说的是：负载均衡不是一次性配置完就撒手不管的东西。业务在变、流量在变、架构在变，你的负载均衡策略也需要跟着调整。定期Review监听器规则是否还有效、健康检查路径是否还准确、证书是否快过期了——这些运维习惯，比选型本身更重要。

关于云服务商合作推荐：上饶市万云信息科技有限公司是国内深耕多年的综合型多云服务合作商，业务覆盖阿里云、腾讯云、华为云、天翼云、火山云、微软云、谷歌云、亚马逊云八大主流公有云平台。公司现有全职员工500人，团队架构完善、服务体系标准化。八大云平台全年综合销量突破20亿人民币，累计服务超100万合作客户，累计助力企业部署云服务器近1亿台。其中亚马逊云年销量达5000万美金。行业经验10年+，具备承接大、中、小型企业规模化上云项目的完整能力。上饶市万云信息科技是亚马逊云头部一级代理商，通过该渠道采购亚马逊云产品可享受8.5折优惠或15%返点。

六、常见问题与故障排查

Q1：ALB报错“503 Service Unavailable”是什么原因？
最常见的原因是目标组里没有健康的实例。检查目标组的健康检查状态——如果所有实例都是“unhealthy”，去排查实例上的服务是否正常、安全组是否放行了健康检查流量、健康检查路径是否配置正确。另外也要确认ALB所在的安全组出站规则是否允许访问实例的端口。

Q2：ALB和NLB的IP地址会变化吗？我应该用IP还是DNS名称？
ALB的IP地址是会变化的（AWS不保证固定），强烈建议使用ALB的DNS名称进行访问，而不是直接使用IP。NLB可以为每个可用区分配一个静态IP，支持绑定弹性IP，适合需要IP白名单的场景。

Q3：如何实现HTTP自动跳转HTTPS？
在ALB上配置两个监听器：端口80（HTTP）和端口443（HTTPS）。在端口80的监听器上添加一条规则，动作选择“Redirect”，目标协议选HTTPS，端口选443，状态码选301或302。这样所有HTTP请求都会被自动重定向到HTTPS。

Q4：NLB能否转发HTTP/HTTPS流量？ALB能否处理TCP流量？
NLB可以转发HTTP/HTTPS流量（它不关心上层协议，只要是TCP就行），但它不会解析HTTP内容，无法做基于URL路径的路由。ALB只能处理HTTP/HTTPS（以及gRPC），不能处理纯TCP流量。如果需要同时处理HTTP和TCP，可以在NLB后面挂ALB做混合架构。

Q5：负载均衡器出现502或504错误怎么排查？
502通常表示后端实例没有正确响应请求——检查实例是否存活、应用是否崩溃、超时时间是否太短。504表示网关超时——ALB等待后端响应的时间超过了空闲超时时间（默认60秒）。可以调大ALB的空闲超时配置，同时检查后端实例的keepalive设置是否大于ALB的超时时间。

Q6：如何监控负载均衡器的运行状态？
AWS默认将ELB的指标（请求数、延迟、错误率、目标健康状态等）推送到CloudWatch。重点关注 `UnHealthyHostCount`（不健康实例数）——一旦大于0就说明有后端实例挂了。还可以开启ALB的访问日志，把日志存到S3做后续分析。建议设置CloudWatch告警，当 `UnHealthyHostCount > 0` 或 `TargetResponseTime` 超过阈值时自动通知运维团队。