AWS实名认证 AWS Elastic Load Balancing 详解：ALB、NLB 与 GLB 的区别与选型配置指南
用户搜索这个主题，通常不是为了了解 ELB 的分类，而是在实际部署时遇到决策难题：网站要不要用 ALB，游戏或 MQTT 这类长连接要不要换 NLB，已有防火墙设备上云后怎么接入 GLB，以及为什么明明已经创建了负载均衡，后端实例却一直显示 unhealthy。
如果你现在正在 AWS 控制台准备创建负载均衡，建议先看下面这张对照表，再按后面的配置步骤操作，能少走很多回头路。
先解决决策问题：ALB、NLB、GLB 到底怎么选
| 业务场景 | 优先选择 | 原因 | 容易踩坑的点 |
| 网站、HTTPS、API、按路径转发 | ALB | 支持基于 Host/Header/Path 的转发规则，适合 Web 应用 | 后端健康检查路径填错、证书区域错误、WebSocket 空闲超时 |
| TCP、UDP、TLS 透传、长连接、高并发连接 | NLB | 四层转发，保留源地址能力更适合协议型业务 | 目标组协议选错、客户端 IP 处理不当、后端监听端口未放通 |
| 把流量引到防火墙、WAF 设备、第三方安全设备链路 | GLB | 适合网络流量分发到虚拟安全设备做检测与过滤 | 目标设备未支持 GENEVE、路由表未改、设备健康检查未通过 |
最常见的误选有三种：
- AWS实名认证 把 API 网关或网站放在 NLB 后面，结果发现无法按路径分发 /api 和 /admin。
- 把 TCP 长连接业务放在 ALB 后面，遇到协议不兼容、超时或连接被中断。
- 希望把南北向流量先送到防火墙检查，却仍然选了 ALB/NLB，后面发现流量无法按预期进入安全设备链路。
用户真正关心的不是“区别”，而是这几个落地问题
1. 网站和 API 应该选 ALB 还是 NLB
如果你要做的是 Nginx、Apache、Node.js、Java Web、Kubernetes Ingress、REST API，且希望按域名或 URL 路径转发，请直接选 ALB。因为你通常需要以下能力：/api 转发到服务 A，/static 转发到服务 B，不同域名走不同目标组，以及在负载均衡处终止 HTTPS。
如果你只是暴露 443/TCP、1883、3306、6379 之类的端口，不需要看 HTTP Header，不需要路径路由，那 NLB 会更直接。
2. 为什么后端服务已经启动，健康检查还是失败
这通常不是实例坏了，而是配置错位。ALB 最常见的问题是健康检查路径写成 /，但应用实际只在 /health 返回 200。NLB 常见问题是目标组用 TCP 检查，但后端实际上并未在该端口监听，或者实例安全组没放通来自负载均衡所在子网的流量。GLB 则更多是安全设备没有正确响应探测或设备接口绑定错误。
3. 为什么业务要保留客户端真实 IP
做审计、风控、限流、访问日志、地理封禁时，真实源 IP 很关键。Web 业务通常用 ALB 并读取 X-Forwarded-For；四层协议业务更常用 NLB，因为应用常常直接依赖源地址做鉴权或连接控制。若你已经上线后才发现日志里全是内网地址，往往意味着负载均衡类型选错，或者后端没有正确取头信息。
正式创建前的准备清单
账号与权限
- 需要具备 EC2、VPC、Elastic Load Balancing、IAM、ACM 的相关权限。
- 若使用 HTTPS，建议提前在 ACM 中申请或导入证书。
- 如果要绑定 Auto Scaling 组，需确认伸缩组角色可注册到目标组。
前置资源
| 资源 | 必需性 | 说明 |
| VPC | 必需 | 负载均衡必须部署在 VPC 内 |
| 至少两个子网 | 建议 | 生产环境建议跨两个可用区 |
| EC2 或 IP 目标 | 必需 | 作为目标组后端实例 |
| 安全组 | ALB 必需 | NLB 不像 ALB 那样依赖同样方式管理入口访问 |
| 证书 | HTTPS 必需 | ALB/TLS 监听常用 |
地域与可用区怎么选
不要只按价格选地域。应优先看用户访问延迟、数据库所在区域、是否需要跨境访问、是否已有其他依赖资源在同一地域。负载均衡与后端实例尽量在同一 VPC、同一地域内，避免跨区域回源增加延迟和流量费用。
可用区建议至少启用两个。很多用户只开一个子网，表面能跑，但后面维护、硬件故障或实例替换时容易造成单点问题。
控制台创建教程：先讲 ALB，再讲 NLB，最后讲 GLB
步骤1：创建 ALB，适合网站与 API
进入 AWS 控制台，打开 EC2 页面，在左侧找到 Load Balancers，点击 Create Load Balancer，选择 Application Load Balancer。
| 参数 | 建议填写 | 说明 |
| Scheme | Internet-facing 或 Internal | 公网访问选 Internet-facing，内网服务选 Internal |
| IP address type | IPv4 | 若业务已启用双栈再考虑 dualstack |
| VPC | 与后端一致 | 避免跨 VPC 复杂互通 |
| Mappings | 至少2个可用区子网 | 提升可用性 |
| Security groups | 放通 80/443 | 来源可先限制为办公网或 CDN 回源段 |
| Listeners | HTTP:80 或 HTTPS:443 | 生产建议直接上 HTTPS |
接着创建目标组。如果后端是 EC2，Target type 选 Instances；如果是固定内网地址，选 IP addresses。Protocol 常见为 HTTP，Health check path 建议明确写成 /health 或 /status，不要默认用 /。
创建完成后，在 Listener rules 中设置转发规则：
- 域名 a.example.com 转发到 target-group-a
- 路径 /api/* 转发到 api-target-group
- 路径 /admin/* 转发到 admin-target-group
注意事项：
- 如果你希望后端拿到 HTTPS 信息，可检查 X-Forwarded-Proto。
- 后端 Nginx、Apache 需要正确处理 X-Forwarded-For，否则日志看到的是负载均衡地址。
- 若访问 502/503，先看目标组健康状态，不要先怀疑域名解析。
步骤2：创建 NLB，适合 TCP/UDP/长连接
同样在 Load Balancers 中点击 Create Load Balancer，选择 Network Load Balancer。
| 参数 | 建议填写 | 说明 |
| Scheme | Internet-facing 或 Internal | 按公网/内网服务选择 |
| Listeners | TCP、UDP 或 TLS | 根据协议选择，别误填成 HTTP |
| VPC/Subnets | 与目标组一致 | 尽量跨两个可用区 |
| Target type | Instances 或 IP | 容器、数据库代理常选 IP |
| Health check | TCP 或 HTTP | 纯端口存活可用 TCP，更精确应用状态可用 HTTP |
AWS实名认证 如果你部署的是 MySQL 代理、Redis Proxy、MQTT、游戏网关、SFTP、SMTP，这一步通常更合适。创建目标组时，Port 要与后端服务监听端口一致，例如 3306、6379、1883、25565 等。
注意事项：
- 后端实例安全组必须允许对应端口访问，否则目标组会一直不健康。
- 如果服务依赖客户端源地址做白名单，NLB 更容易满足，但应用本身也要确认读取方式。
- 若启用了 TLS 监听，要规划证书和后端加密方式，不要把“TLS 终止”和“TLS 透传”混为一谈。
步骤3：创建 GLB，适合接入安全设备流量链路
如果你的目标不是简单转发到 Web 或 TCP 服务，而是要把流量送到防火墙、入侵检测、第三方虚拟安全设备，则创建 Gateway Load Balancer。
控制台路径仍在 EC2 的 Load Balancers 中，选择 Gateway Load Balancer。这里和 ALB、NLB 最大不同不在界面，而在网络路径设计。创建时要确认安全设备 AMI 或实例已经按厂商要求部署，并支持 GENEVE 6081。
| 关键项 | 配置建议 | 错误后果 |
| 目标组协议 | GENEVE | 协议不对将无法转发到安全设备 |
| 健康检查 | 按厂商建议设置 | 设备显示 unhealthy，流量无法进入 |
| 路由表 | 修改子网路由指向 GWLBE | 即使 GLB 已创建，流量也不会经过设备 |
| 对称路由 | 保持回程一致 | 会话异常、丢包、状态跟踪失效 |
实际操作中，GLB 真正难点不在“点哪里”，而在于后续两步：
- 创建 Gateway Load Balancer Endpoint，并放到需要引流的 VPC 或子网。
- 修改入口和回程路由，确保流量能进设备也能从同一路径回来。
很多用户创建完 GLB 觉得没效果，原因是路由表没切，或者安全设备本身没做好探测接口与转发策略。
不同业务怎么配，避免选型失误
个人开发者
如果你只有一个博客、管理后台或轻量 API，优先 ALB。配置建议为 2 vCPU/4 GB 的两台 Web EC2，ALB 挂两个可用区子网，80 跳转到 443，证书放在 ACM。这样后续加新服务时可以直接按路径扩展，不必重做入口架构。
企业用户
若有多个微服务或不同域名站点，使用 ALB + 多目标组更合适。规则设计时按域名、路径拆分，后端按环境区分 prod、staging。日志接入 S3 或 CloudWatch，便于审计与追踪 5xx 错误。
跨境业务
核心问题不是 ALB 还是 NLB，而是先选靠近用户的地域，再看是否结合 Global Accelerator、CloudFront 或 Route 53 延迟路由。若你的服务是 HTTPS 网站，入口常见组合是 CloudFront + ALB；若是 TCP 加速需求，更常考虑 NLB 配合其他全球流量接入方式。
AWS实名认证 网站应用
只要涉及 HTTPS 卸载、WebSocket、重定向、路径路由、Header 转发，优先 ALB。后端 Nginx 应增加真实 IP 处理，例如记录 X-Forwarded-For，否则日志与限流判断会失真。
数据库或协议型业务
数据库不建议直接暴露公网，但如果是代理层、只读接入层或私网入口，NLB 更常见。尤其是 Redis、MySQL 代理、MQTT 等场景，NLB 的协议适配更简单。注意数据库本身的高可用与连接池问题，不要把负载均衡当成数据库扩容手段。
故障排查：这些问题最常见
健康检查失败的排查顺序
- 确认目标实例进程是否在监听端口：Linux 可用 ss -lntp 或 netstat -lntp。
- 确认实例安全组是否放通目标端口。
- 确认子网 NACL 没有拒绝回包。
- ALB 场景下检查健康检查路径是否返回 200-399。
- 应用是否把探测请求重定向到登录页，导致检查失败。
域名解析正常但访问超时
先看负载均衡类型和监听器。最常见错误是域名指向 ALB，但只建了 443 监听没有证书；或者指向 NLB，但后端实例只开了本地回环监听地址，外部无法访问。
为什么源 IP 丢失
ALB 后端要从 HTTP 头读取 X-Forwarded-For；NLB 场景则检查应用是否支持源地址识别以及中间代理是否又做了一层转发。日志中只看到 127.0.0.1 或内网代理地址，通常是后端 Web 服务没有信任上游代理头。
跨可用区流量异常
若部分请求成功、部分失败，检查启用的子网和目标组实例分布是否一致。不要只在一个可用区注册实例，却在多个可用区开放入口而没有验证回程与容量。
性能看起来不稳定
很多时候不是 ELB 本身性能问题，而是后端连接池、线程数、Keepalive、应用超时设置不匹配。建议同时看 CloudWatch 指标：TargetResponseTime、HTTPCode_ELB_5XX、HTTPCode_Target_5XX、HealthyHostCount、ProcessedBytes、ActiveFlowCount。
配置优化建议：安全、性能、成本、稳定性分开做
安全优化
- ALB 前端只开放 80/443，80 强制跳转到 443。
- 后台实例安全组不要对 0.0.0.0/0 放开业务端口，尽量只允许来自负载均衡或应用网段。
- AWS实名认证 GLB 场景下，先验证安全设备策略和回程路由，再放量上线。
- 启用访问日志，便于定位扫描、CC、异常来源地址。
性能优化
- AWS实名认证 Web 应用优先使用 ALB，并检查后端 Keepalive、gzip、HTTP/2 兼容情况。
- 协议型长连接优先 NLB，减少不必要的七层处理。
- 健康检查不要过于频繁，避免小规模实例被探测放大负载。
- AWS实名认证 静态资源可前置 CDN，减少 ALB 回源压力。
成本优化
- 不要为单一 TCP 服务使用复杂的 ALB 规则，能用 NLB 就不要叠加多余能力。
- 测试环境可以只开一个可用区，但生产环境不建议这样省成本。
- 按业务拆分目标组，避免因配置混乱导致额外实例扩容。
稳定性优化
- 至少两个可用区部署后端实例。
- 负载均衡创建后先做端到端压测，再切正式 DNS。
- 重要服务保留快照与基础设施模板，故障时可快速重建。
- 修改监听规则前先在测试域名验证，避免生产流量误切。
给还在犹豫的用户一个直接结论
如果你正在部署网站、后台系统、API 网关或多服务入口，先选 ALB；如果你部署的是 TCP/UDP、数据库代理、长连接或对源地址敏感的服务，优先 NLB；如果你要把业务流量强制送到防火墙或第三方安全设备链路，才考虑 GLB。多数选型错误不是因为不懂概念，而是没有从协议、路由、源 IP、健康检查和后续扩展方式去判断。
真正能减少返工的做法，是在创建前先画出一张简单流量图：用户从哪里来，先经过什么入口，后端按什么协议监听，是否要 HTTPS 终止，是否要看到真实 IP，是否要经过安全设备。把这五个问题定下来，ALB、NLB、GLB 的选择通常会非常明确。
