深入理解AWS负载均衡ELB：ALB与NLB选型、核心组件及高可用架构实践

做运维和架构这么些年，我越来越觉得负载均衡是云上架构里最容易“被低估”的一环。很多人觉得它不就是把流量分一分嘛，但真到线上出问题的时候——后端一台机器悄悄挂了、流量突增把单点打爆、或者新版本上线想灰度验证——你才会意识到，一个设计良好的负载均衡层能给业务兜住多少底。

今天想认真聊聊 Amazon Elastic Load Balancing（后文简称 ELB）。这不是一篇照抄文档的科普，我会把 ELB 到底是什么、四种产品怎么选、核心组件怎么理解、从零配置的完整流程、以及我踩过的一些坑和优化心得，一次性讲清楚。不管是刚接触 AWS 的新手，还是已经在生产环境里用了一段时间想查漏补缺的同学，这篇都应该能给你一些实在的参考。

1. ELB 到底解决的是什么问题

1.1 从单机到集群：流量分发的需求是怎么来的

先回到最朴素的场景。早期做一个 Web 应用，部署很简单：一台服务器，装好 Nginx、跑起后端进程、绑定数据库，再把公网 IP 解析到域名上，用户就能访问了。这种单机架构最大的问题不是性能，而是“单点故障”——机器宕机、进程崩溃、网络抖动，任何一个环节出问题，整个服务就不可用了。

后来业务量上来，一台机器扛不住，于是有了多台服务器。问题接着就来了：用户的请求先到谁那儿？如果全部打到其中一台，那跟单机没有区别；如果靠 DNS 轮询，DNS 缓存又会让流量分配严重不均；而且后端随便哪台挂了，DNS 层面根本感知不到，用户依然会被解析到故障机器。这时候就需要一个专门的“流量调度层”，也就是负载均衡器。

ELB 就是 AWS 在这个位置上提供的全托管负载均衡服务。它的作用很直白：作为流量的统一入口，按照你配置的规则，把进来的请求分发给后端的多台目标（EC2 实例、IP、Lambda 函数、容器等），并且在分发过程中自动感知后端健康状态，把不健康的实例摘掉，恢复后再加回来。这样用户永远只跟负载均衡器打交道，后端扩缩容对用户完全无感。

1.2 自己搭负载均衡 vs 用 ELB，差别在哪

很多人问过一个问题：我用 Nginx 自己搭一个负载均衡不也行吗？答案是，小流量场景完全可以，但到了生产环境，自建方案会面临几个很现实的问题。

第一，自建的负载均衡器本身就是新的单点。如果这台 Nginx 挂了，所有后端全部失联。你得再给它配 Keepalived、做主备、做健康检查，等于为了维护负载均衡又引入了一套新的运维复杂度。ELB 是 AWS 托管的，本身多可用区部署、自动故障转移，你不用关心它底层跑在哪、挂没挂。

第二，自建方案和“弹性伸缩”的联动很麻烦。后端实例要自动伸缩时，自建负载均衡需要额外写脚本去动态更新上游列表；ELB 跟 Auto Scaling 原生集成，目标组里的实例随伸缩组自动注册、自动注销，省掉一个巨大的运维隐患。

第三，自建方案缺少开箱即用的可观测性。ELB 标配 CloudWatch 监控指标（请求数、延迟、健康主机数等）、访问日志（直接写到 S3）、以及跟 X-Ray、WAF 等服务的深度集成。这些能力自建时都要自己搭，搭完还不一定有人家做得成熟。

所以在 AWS 生态里做架构，除非你有一万个理由必须自建（比如特殊的网络协议要求、强制合规需求），否则直接用 ELB 是更省心、也更符合云原生实践的选择。

1.3 谁需要重点搞懂 ELB

简单列几类人，你可以对号入座：

• 后端实例数量超过一台，或者使用了 Auto Scaling，那么 ELB 是必须掌握的组件。
• 采用微服务架构，需要按域名、URL 路径做路由分发，ALB 的基本操作必须熟练。
• 对网络性能和延迟有极致要求的场景，比如游戏服务器、实时通信，NLB 的选型和配置是绕不开的。
• 负责成本优化和架构治理的同学，需要搞清楚不同负载均衡器的计费模型，避免每个月账单莫名其妙涨一截。

2. 四种负载均衡器怎么选：ALB、NLB、CLB、GWLB

2.1 ALB：应用层负载均衡，微服务架构的主力

ALB（Application Load Balancer）工作在网络模型的第七层，也就是应用层。它能够解析 HTTP/HTTPS 协议内容，所以具备很多四层负载均衡不具备的能力。

我用的最多的是它的路径路由和主机名路由。比如你有一个域名 api.example.com，你可以配置一条规则：路径以 /users 开头的请求转发到“用户服务目标组”，路径以 /orders 开头的请求转发到“订单服务目标组”。再比如你有一个泛域名 *.example.com，还可以按主机名把 a.example.com 和 b.example.com 分发给不同的服务。这在微服务和多租户场景下非常实用。

ALB 还支持 HTTP/2、WebSocket 和 gRPC。如果你用容器服务（ECS/Fargate）或者 Kubernetes（配合 AWS Load Balancer Controller），ALB 几乎是默认选择。它兼具传统负载均衡和七层网关的能力，能直接在监听器上挂 ACM 证书（AWS Certificate Manager）做 HTTPS 终结，省去在每台后端实例上管理证书的麻烦。

2.2 NLB：网络层负载均衡，性能和延迟优先

NLB（Network Load Balancer）工作在第四层，主要处理 TCP、UDP 和 TLS 流量。它的核心优势是性能和极低延迟，官方宣称可以每秒处理数百万请求，而且它不是通过代理转发流量，而是尽量保持连接的五元组信息，某种意义上更接近“透传”的模式。

NLB 适合这么几类场景：

• 对延迟极其敏感的在线业务，比如实时竞价、高频交易、游戏对战服务器。
• 后端协议不是 HTTP/HTTPS，而是自定义 TCP 协议或 UDP 流量的场景，比如 DNS 服务器、游戏 UDP 端口、IoT 设备接入。
• 需要保留客户端真实 IP 的场景。NLB 默认保留客户端 IP，后端可以直接看到用户的来源地址，不像 ALB 需要通过 X-Forwarded-For 头去拿。

NLB 还支持分配弹性 IP（Elastic IP），这在某些合规场景下很关键——你需要对外暴露固定的公网 IP，并且把这个 IP 加入第三方防火墙白名单。ALB 只能给一个 DNS 名，而 NLB 可以绑定固定 IP，这是很多企业选型时的一个重要考量。

2.3 CLB 与 GWLB：老牌选手和新类型

CLB（Classic Load Balancer）是 ELB 系列里的“老前辈”，同时支持四层和七层的基本能力，也能做 HTTP/HTTPS/TCP 的负载均衡。但它的功能相对受限：没有路径路由、没有按主机名路由的灵活规则、跟容器和 Kubernetes 的集成也远不如 ALB/NLB 顺畅。AWS 官方早就不推荐在新架构里使用 CLB，我现在的建议也很简单：老项目能用就用，新项目一律不要碰，直接选 ALB 或 NLB。

GWLB（Gateway Load Balancer）是 ELB 家族的新成员，它解决的问题是“把第三方虚拟设备接入流量路径”。比如你想在 VPC 的南北向流量里加一层防火墙、入侵检测系统（IDS/IPS）或者流量镜像工具，传统做法是手动改路由表把这些设备串进链路，维护麻烦而且容易断。GWLB 负责在流量转发路径中透明地接入这类虚拟设备，让第三方安全/网络设备可以横向扩展，同时不影响原有路由架构。做安全治理、等保合规的同学肯定绕不开它。

2.4 选型速查表

选型时我的经验就三条。如果你处理的是 HTTP/HTTPS 流量，默认选 ALB，不要犹豫；如果对延迟和性能要求极高，或者流量不是 HTTP 协议，选 NLB；如果要在链路里串第三方防火墙或安全设备，思考 GWLB。至于 CLB，除非你在维护一个十年前的老环境，否则真的不要新创了。

3. 核心组件拆解：监听器、目标组与健康检查

3.1 监听器：流量入口的“门卫”

监听器（Listener）是 ELB 面向用户的一端。它定义了 ELB 在哪个端口上监听什么协议的流量，以及这份流量按照什么规则转发。

创建监听器的时候，你需要指定协议和端口。最常见的组合是 HTTP:80 和 HTTPS:443。如果你配 HTTPS 监听器，还需要绑定 SSL/TLS 证书，可以使用 ACM 证书，也可以把自己在第三方机构申请的证书上传到 IAM 或 ACM 里。

一个 ALB 可以配置多个监听器，每个监听器里还能配置多条转发规则，按优先级从上往下匹配。规则支持条件（路径、主机名、HTTP 请求方法、请求头、查询字符串、源 IP），命中条件后执行动作（转发到目标组、返回固定响应、跳转 URL 等）。

举个例子：我之前的订单服务做过一次 A/B 测试，用 ALB 规则实现了一个简单的灰度发布。我配置了一条规则：当请求携带的 header X-Canary: true 时，把流量转发到“订单服务-新版本”目标组；其余请求全部转给“订单服务-稳定版”。整个过程中后端实例无感知，测试完成后临时改一下规则，就能把流量全部切到新版本，或者快速回滚。这个思路大家可以借鉴，比在代码里做开关要直观得多。

另外提一个比较容易漏掉的点：ALB 的规则默认有一个“默认动作”，也就是所有请求都不匹配自定义规则时走的兜底路径。我见过很多事故是运维调整规则时把默认动作改错了，导致所有请求被转发到了错误的目标组。规则改完后一定要记得检查默认动作。

3.2 目标组：后端实例的抽象集合

目标组（Target Group）是 ELB 向后转发流量的“目的地集合”。这个概念值得花时间理解，因为它不只是“一堆后端机器”那么简单。

目标组定义了几个关键信息：目标类型（实例、IP 地址、Lambda 函数）、协议端口、VPC、健康检查参数。同一个 ELB 可以关联多个目标组，通过监听器规则把不同条件的流量分发给不同目标组。反过来，同一个目标组也可以被多个 ELB 或监听器复用。

目标组里的注册目标有几种方式：

• 手动注册：选择现有 EC2 实例或输入 IP 地址。
• 自动注册：关联 Auto Scaling 组，伸缩组扩容时自动添加实例，缩容时自动移除。
• 基于 IP：目标是 VPC 内的某个 IP 地址，适合不能直接使用实例 ID 的场景，比如 RDS 只读副本前做接入、本地数据中心通过专线和 IP 方式接入。

生产环境里强烈建议用目标组 + Auto Scaling 的组合，而不是手动管理实例列表。手动注册容易出两个问题：一是扩容后忘记添加、缩容后没及时清理；二是实例 IP 变化（很多环境默认 DHCP 分配 IP）导致目标组里的 IP 失效。Auto Scaling 集成后，这些动作全部自动完成，后端实例的“生老病死”都跟着伸缩组走，误操作的几率大幅下降。

还有一个细节点：目标组可以设置在端口上做“按端口注册”，比如一台实例可以同时注册 80 端口和 8080 端口，分别对应两组不同的服务。这在同一个实例上跑多个服务、且需要分别负载均衡时很实用。

3.3 健康检查：保证高可用最关键的一环

健康检查（Health Check）是 ELB 能否实现故障自动转移的核心机制。它的原理很简单：ELB 按照你配置的间隔时间，定期向后端目标发送探测请求，连续收到成功响应达到“健康阈值”后，把目标标记为健康；连续失败达到“不健康阈值”后，把目标标记为不健康，立刻停止往这个目标转发流量。

关键参数有这么几个：

• 健康检查协议和端口：可以跟业务端口不同。很多团队会开一个专门的管理端口做健康检查。
• 健康检查路径：比如 /healthz、/actuator/health 这类专门设计的探活接口。
• 间隔时间（Interval）：默认 30 秒，两次探测之间的时间间隔。
• 超时时间（Timeout）：单次探测等待响应的时间，默认 5 秒。
• 健康阈值（Healthy Threshold）：连续成功多少次判定为健康，默认 5 次。
• 不健康阈值（Unhealthy Threshold）：连续失败多少次判定为不健康，默认 2 次。

我自己的习惯是把健康检查间隔调到 10 到 15 秒，不健康阈值保持 2 到 3 次，健康阈值 2 到 3 次。太频繁的探测会给后端造成不必要的压力，尤其是后端实例数量很大的时候，探测请求也会成为不小的一笔流量；太宽松又会让故障发现变慢。

健康检查路径是整个 ALB 配置里最容易踩坑的地方。很多人图省事，探活路径直接填 /，但首页往往是静态文件或者缓存，哪怕后端数据库挂了、业务进程已经死锁，首页依然能返回 200，导致 ELB 永远认为实例健康，流量继续往坏实例上打。正确的做法是为健康检查单独开发一个接口，这个接口必须真实反映服务的“可用状态”，比如检查依赖的数据库连接、缓存连接和内部关键组件是否正常，再返回 200 或 500。

3.4 跨可用区与安全组：容易被忽略的两个细节

ELB 的“跨可用区容灾”能力最关键。创建 ELB 时，AWS 要求你至少选择两个可用区（AZ）的子网。ELB 会自动把流量分发到不同可用区的后端目标上，这样即使某个可用区整体不可用，ELB 也能把流量转移到其他可用区的实例上。

这个能力是默认开启的。如果关闭“跨可用区负载均衡”，ELB 只会在每个可用区内部分发流量——某个可用区故障时，该区内的所有目标即使挂掉，流量也不会跨区转移。生产环境请务必保持开启。

再说安全组。ELB 本身有安全组，后端实例也有安全组。比较合理的配置是：

• ELB 的安全组：放行入站 80/443 端口，来源可以是 0.0.0.0/0（公网访问）或者指定 CIDR。
• 后端实例的安全组：只放行来自 ELB 安全组的流量。做法是在入站规则里指定“来源”为 ELB 安全组的 ID，而不是写死某个 IP 段。

这样做的好处是：如果将来 ELB 的 IP 发生变化（ALB 本身就是动态 IP），后端安全组也不需要改，因为引用的是安全组 ID 而非 IP。这也是 AWS 官方推荐的最佳实践。

我曾经见过一个客户，后端实例的安全组只放行了某个固定 IP，结果 ALB 的地址一变，整个服务立刻不可用。排查了很久才发现是安全组规则里写死了 IP，改成引用 ELB 安全组 ID 后问题立刻消失。这个细节写出来，希望大家别走弯路。

4. 从零搭建一个 ALB 的完整流程

4.1 准备阶段：VPC、子网与安全组规划

动手创建 ALB 之前，先规划好网络环境。我常用的标准方案是：创建 VPC，CIDR 用 10.0.0.0/16；在 VPC 内划分至少两个可用区（比如 ap-southeast-1a 和 ap-southeast-1b），每个可用区都有两个子网——一个公有子网（路由到 IGW）用于放置负载均衡器，一个私有子网（不走公网）用于放置后端实例。

如果你用的是 AWS 控制台，在创建 VPC 时可以直接选“VPC and more”，一次性把公/私子网、路由表、NAT 网关都生成好，非常省事。VPC 建好后，还需要考虑：

• 后端 EC2 实例是否需要出网能力？如果需要访问外网，要么放到公有子网，要么在私有子网里配置 NAT 网关。
• 安全组规划：ALB 安全组放行 80/443 入站；后端安全组放行来自 ALB 安全组的流量。

这些看着简单，但很多新手在这一步就埋了坑——子网选择错误会导致后续创建 ALB 时找不到可用子网，或者后端实例与 ELB 不在同一个网络平面。所以提前规划好网络，后面基本是一路顺畅。

4.2 创建目标组并注册实例

进入 EC2 控制台，在左侧菜单找到“目标组”，点击“创建目标组”。需要填写的关键项：

• 目标类型：选择“实例”或“IP 地址”。
• 协议和端口：比如 HTTP:80。
• VPC：选择刚才创建的 VPC。
• 健康检查协议和路径：HTTP，路径建议填 /healthz，具体看应用探活接口设计。
• 高级健康检查参数：按需要调整间隔、超时、阈值。

创建完目标组后，在目标组详情页的“目标”标签页里，点击“注册目标”，勾选要加入的 EC2 实例并点击“包含”。这时候可以看到实例出现在待注册列表里，状态是“initial（初始化）”。ELB 会立即执行健康检查，实例通过后状态会变成“healthy”。

如果你已经把实例纳入了 Auto Scaling 组，想实现自动注册，那就在伸缩组配置的“负载均衡”里关联这个目标组，以后伸缩组启停实例时都会自动去目标组注册/注销。这个方案强烈推荐，因为手动注册在两个实例以上的场景中很容易漏配。

4.3 创建 ALB 并配置监听器

创建 ALB 的操作也不复杂：进入 EC2 控制台，点击“负载均衡器” → “创建负载均衡器”，选择 ALB，然后按步骤填写：

• 名称：比如 my-web-alb。
• 方案类型：面向 Internet（公网访问）还是内部专用。
• IP 地址类型：IPv4 或 Dualstack（IPv4+IPv6）。
• 网络映射：选择刚才规划的公有子网，至少选两个可用区。
• 安全组：选择 ALB 专用的安全组。
• 监听器和路由：选择协议端口，比如 HTTP:80；默认动作选择“转发到目标组”，选中上面创建好的目标组。

创建完成后，还可以为 ALB 配置 HTTPS 监听器。操作路径是：在监听器标签页，点击“添加监听器”，选择 HTTPS:443，选择 ACM 证书，默认动作还是转给目标组。之后可以配置一条规则，把 HTTP:80 的请求重定向到 HTTPS:443，让所有用户都走加密通道。

这里有个细节：ACM 证书必须在 ALB 所在区域申请，跨区域证书无法直接选中。如果你的域名是外部注册的，可以先去 ACM 控制台申请公有证书，做 DNS 验证后等几分钟就下发成功了，整个过程一般几分钟内完成。

4.4 验证测试：流量分发与故障转移

ALB 创建完成后，在 EC2 控制台的负载均衡器详情页会有一个 DNS 名称，类似 my-web-alb-1234567890.ap-southeast-1.elb.amazonaws.com。直接用浏览器访问这个地址，多刷新几次，如果后端有两台实例，一般能看到请求被轮流分发到不同的实例上——最简单的验证方式是后端实例返回不同的实例 ID 或主机名，页面变化就说明负载均衡生效。

接下来模拟故障：手动停止一台后端实例（不是重启，而是直接 Stop）。等几秒，观察目标组页面，停止的实例状态会从 healthy 变成 unhealthy，ELB 停止向它转发流量。此时继续访问 ALB 地址，业务不受影响，所有请求会打到还活着的实例上。再把停掉的实例启动，等健康检查通过后，状态回到 healthy，流量会重新分配给它。

这个过程看似简单，却是 ELB 最核心的价值——“高可用性”的直观体现。理解了健康检查 + 自动摘除 + 自动恢复这个机制，你对 ELB 的理解就已经超过多数初级运维了。

4.5 用 CLI 快速实现

如果你追求自动化，用 AWS CLI 也能完成同样的操作。下面给出一组常用的核心命令，方便你集成到 CI/CD 脚本里。

bash复制# 创建目标组
aws elbv2 create-target-group \
  --name my-targets \
  --protocol HTTP \
  --port 80 \
  --vpc-id vpc-0abc123def456 \
  --health-check-protocol HTTP \
  --health-check-path /healthz \
  --healthy-threshold-count 3 \
  --unhealthy-threshold-count 3 \
  --timeout 5 \
  --interval 30

# 注册实例到目标组
aws elbv2 register-targets \
  --target-group-arn arn:aws:elasticloadbalancing:ap-southeast-1:123456789012:targetgroup/my-targets/aaa111 \
  --targets Id=i-0abcd1234efgh5678

# 创建 ALB，启用跨可用区
aws elbv2 create-load-balancer \
  --name my-web-alb \
  --subnets subnet-aaa111 subnet-bbb222 \
  --security-groups sg-0abc123def \
  --scheme internet-facing \
  --type application \
  --ip-address-type ipv4

# 创建监听器并关联目标组
aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:ap-southeast-1:123456789012:loadbalancer/app/my-web-alb/mmm222 \
  --protocol HTTP \
  --port 80 \
  --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:ap-southeast-1:123456789012:targetgroup/my-targets/aaa111

注意，命令中的 ARN、VPC ID、子网 ID 需要按你自己的环境替换。实际使用时建议把这些操作写成自动化脚本，配合 Terraform 或 CloudFormation 来管理，避免每次都在控制台里点半天。

5. 企业级优化与常见问题排查实录

5.1 常见问题排查速查表

做 ELB 的排障做多了，你会发现绝大多数问题都能归到几个固定类别里。我整理了一张速查表，方便你对号入座：

5.2 几个生产环境里的避坑心得

第一，健康检查路径一定要设计成“真实探活”。这条前面提过，但值得再强调一次。探活接口必须检查应用依赖的核心资源（数据库连接、缓存、消息队列），否则等缓存故障把服务拖垮时，ELB 还傻乎乎地往这台“健康”实例上分发请求。

第二，不要把后端实例放到公网子网。按理说这是个基础问题，但我真的见过有人把 EC2 放在公有子网、同时也没有任何防护的架构。合理的做法是 ALB 在公有子网，后端 EC2 在私有子网，后端安全组只放行 ALB 安全组的流量。这样即便后端有安全漏洞，攻击者也很难直接访问到实例本身。

第三，规则和默认动作一定要加“变更评审”机制。ALB 规则的变化影响面很大，一条写错的路径重定向就能让整个业务 502。我在团队里推了个简单的做法：所有 ELB 规则变更必须通过 Pull Request 提交，使用 Terraform 管理规则，审核后自动应用。靠人肉点控制台太容易出事了。

第四，日志和监控一定要提前配好。ELB 的访问日志默认是不开启的，需要手动配置到 S3，开启后才有请求明细、延迟、后端返回码等关键信息。CloudWatch 指标里要重点监控 HealthyHostCount、TargetResponseTime、RequestCount 和 HTTPCode_ELB_5XX_Count，任何异常都能第一时间通过告警感知。

5.3 成本控制：别让负载均衡器悄悄吃掉预算

ELB 的计费模型是“每个 LCU（Load Balancer Capacity Unit）用时 + 固定小时费”，具体来说，是根据新连接数、活跃连接数、处理流量字节数、规则评估数四个维度分别折算，哪个维度消耗最大，就按哪个维度计费。换句话说，如果你ELB上的规则数量特别多、每秒请求量很大、或者有很多长连接，成本会明显上升。

几个实用的成本优化建议：

• 多个服务共用一个 ALB，不要每个微服务单独建一个。ALB 支持多监听器 + 多规则 + 多目标组，完全可以按域名和路径隔离不同服务。
• 清理闲置负载均衡器。每月拉一次账单，看有没有创建了却一直没流量的 ALB/NLB，删掉就能省钱。
• 关注跨可用区流量费用。如果后端和 ELB 的流量大量跨 AZ，会产生跨 AZ 流量费，尽量让同一份流量在同一个 AZ 内消化掉（当然容灾需求优先，这个平衡要自己把握）。
• 对于稳定且低 QPS 的小服务，有时候直接用 NGINX 或者 API Gateway 也能满足需求，不一定非要上 ELB。ELB 的价值在高并发、高可用、自动伸缩场景里体现得最充分，杀鸡不用牛刀。

5.4 结合 Auto Scaling：让 ELB 弹性价值最大化

ELB 的终极形态是跟 Auto Scaling 联动。常态做法是：创建启动模板 → 创建伸缩组 → 关联目标组 → 配置伸缩策略（基于 CPU、内存、请求数或自定义指标）。当后端负载上涨，伸缩组自动扩容新实例，新实例启动后自动注册到目标组；负载下降，伸缩组自动缩容，目标组自动注销实例。整个过程中 ELB 始终保证只有健康的实例在接收流量。

这里有一个值得注意的点：新实例启动后，如果应用启动时间较长（比如 Java 应用要一两分钟），可能会被健康检查判定为失败并立刻摘除。解决办法是把健康检查的“健康阈值”和“间隔时间”调整得宽松一些，或者让应用启动完成后立刻返回 200，避免误杀。另外，使用“预热”方式也能降低冷启动对后端的影响——在启动脚本里模拟流量空跑，让 JIT 编译、数据库连接池先热起来，再做健康检查。

关于“逐渐增加流量”这一点，ALB 目标组提供了一个很有用的功能叫“渐进式健康检查”（缓慢开始模式）。新注册的目标在一段时间内会从较低权重开始接收流量，逐步增加到正常权重，这样后端实例“冷启动”时不会被瞬间打满，对稳定性非常有帮助。它的配置项是目标组属性里的 slow_start，默认关闭，按需开启，单位是秒，最大 15 分钟。生产环境建议开启，特别是后端实例启动时需要加载大量缓存数据的场景。

5.5 安全加固：WAF、TLS 与安全组协同

如果 ELB 面向公网提供 HTTP/HTTPS 服务，建议在 ALB 前面再叠一层 AWS WAF（Web Application Firewall）。WAF 可以通过托管规则集自动拦截常见的 Web 攻击（SQL 注入、XSS、恶意 Bot 等），而不需要改动应用代码。创建 Web ACL 后，把它关联到 ALB 即可，整个配置大概十分钟就能完成，但能挡住大量低水平攻击，性价比很高。

TLS 方面，要注意监听器上选择的安全策略。AWS 提供了多档 TLS 安全策略，从兼容老客户端的 TLS 1.0 到强安全性的 TLS 1.3。默认策略相对保守，如果业务上没有老客户端兼容性要求，建议选择较新的 TLS 版本并禁用过时的加密套件。ALB 支持在监听器级别配置这项策略，改完后对后面握手失败的请求会有明显改观。

结合前面说的安全组，你的完整安全链路应该是：DNS/CDN → WAF → ALB（TLS 终结） → 后端安全组（只放行 ALB 安全组） → 后端服务。每一层都有自己的职责，但是整体协作，才能形成一套真正可落地的纵深防御体系。

6. 最后再分享一点个人经验

做 AWS 架构这几年，ELB 是我几乎每个项目都会用到的服务，但它很少成为舞台上的主角——因为它越是稳定，大家越感觉不到它的存在。而一旦它出了问题，整个业务的可用性立刻暴露在风险中。我的体会是：越基础的服务，越值得花时间把它的原理和细节吃透。

具体到今天聊的这些内容，最想让你带走的是三件事：一是选型时想清楚自己的流量类型和路由需求，不要 ALB/NLB 随便揪一个就用；二是健康检查一定要认真设计，探活接口必须真实反映应用可用性；三是成本和安全从一开始就纳入架构决策，别等账单和事故来了才补救。

如果这篇分享能帮你少踩几个坑，或者解决几个一直没想明白的问题，那就值了。后面用到 Gateway Load Balancer、或者想把 ALB 和 EKS 的 Ingress 联动起来的时候，我们再来接着聊。