选 AWS Load Balancer，先看你的应用在第几层工作

很多团队在做 AWS 架构设计时，都会遇到同一个问题：AWS Load Balancer 到底选 ALB 还是 NLB？如果只看名字，很容易把它们都理解成“把流量分发到后端服务器”。但在真实项目里，选错负载均衡类型，会直接影响协议支持、转发规则、客户端 IP 获取、延迟表现、证书管理和后续扩展方式。

简单说，ALB 更适合 HTTP 和 HTTPS 应用，NLB 更适合 TCP、UDP、TLS 这类四层流量。如果你的系统是网站、API、微服务网关、容器服务入口，优先看 ALB。如果你要承接长连接、游戏服务、IoT 接入、数据库代理、自定义 TCP 服务，NLB 通常更合适。

采购侧也要关心这个问题。因为负载均衡不是单独存在的产品，它会和 EC2、ECS、EKS、Auto Scaling、ACM 证书、CloudWatch、WAF、Route 53 一起影响整体成本和可运维性。选型时不能只问“哪个更强”，而要问“我的业务流量、协议和扩展方式需要什么”。

进化云面向 AWS 国际站用户提供账户注册、代充值、折扣代理及产品代购协助。如果企业暂时没有国际信用卡，或希望统一处理 AWS 账号和充值流程，可以在做架构选型前，先把账号、预算和付款方式梳理清楚。涉及折扣、充值到账和服务细节，以实际咨询和 AWS 官方最新说明为准。

ALB 适合什么场景？它解决的是应用层转发问题

ALB 的全称是 Application Load Balancer，工作在应用层。它能理解 HTTP 和 HTTPS 请求，所以可以根据域名、路径、请求头等条件，把流量转发到不同目标组。

这类能力对 Web 应用很有用。比如一个企业官网里，/api 转发到后端服务，/admin 转发到管理后台，/static 交给另一组服务处理。你不需要为每个入口单独准备一个负载均衡器，也不必把所有路由逻辑都塞进应用代码里。

如果你的架构里有 ECS 或 EKS，ALB 也常被用作服务入口。它可以和目标组、健康检查、自动伸缩配合使用。当后端实例或容器异常时，ALB 会根据健康检查结果停止向异常目标转发流量。这样做不能保证业务永不故障，但能减少单个节点异常对整体访问的影响。

ALB 还适合需要 HTTPS 证书统一管理的应用。证书可以结合 AWS Certificate Manager 使用，具体支持范围和配置方式以 AWS 官方文档为准。对企业团队来说，把 TLS 终止放在负载均衡层，通常比在每台业务服务器上单独维护证书更容易管理。

可以把 ALB 看成应用入口层。它关注的是请求内容、URL 路由、HTTPS 处理和服务分组。只要你的访问流量主要是浏览器、移动端 App、开放 API 或 Webhook，ALB 往往是第一选择。

NLB 适合什么场景？它更关注连接、协议和低延迟

NLB 的全称是 Network Load Balancer，工作在网络层。它不关心 HTTP 路径，也不会像 ALB 那样做复杂的应用层路由。它更擅长处理 TCP、UDP、TLS 等协议流量，并把连接分发到后端目标。

如果你的业务需要保留客户端源 IP，NLB 是常见选择。比如安全审计、访问控制、日志分析或后端服务需要识别真实来源地址时，NLB 的行为更贴近四层转发需求。具体是否能直接满足，还要结合目标类型、协议和架构设置判断。

NLB 也常用于长连接和非 HTTP 服务。典型场景包括即时通信、游戏网关、IoT 接入、专有协议服务、数据库访问入口、内部 TCP 服务等。这些业务通常不需要按 URL 做路由，但对连接稳定性、吞吐和延迟更敏感。

如果你要暴露固定入口，也可以关注 NLB 的静态 IP 相关能力。是否需要绑定 Elastic IP、是否跨可用区部署、是否对外提供固定访问地址，都要结合网络设计来定。涉及具体限制和计费规则，建议以 AWS 官方最新说明为准。

NLB 不是 ALB 的升级版。它只是解决另一类问题。你不能指望它像 ALB 一样按路径分流，也不应该把 HTTP API 的复杂路由全部交给 NLB。反过来，ALB 也不适合承接所有四层协议流量。

ALB 和 NLB 的核心区别，不只是一张功能表

如果只做概念对比，ALB 和 NLB 的差别很清楚：一个偏应用层，一个偏网络层。真正做架构时，建议从协议、路由、后端类型、客户端 IP、证书、运维和成本几个维度判断。

判断维度 ALB 更适合 NLB 更适合
流量协议 HTTP、HTTPS TCP、UDP、TLS
转发方式 按域名、路径、请求规则转发 按连接和端口转发
常见入口 网站、API、微服务、容器服务 长连接、自定义协议、网关服务
客户端 IP 通常通过请求头传递 更适合源 IP 保留需求
证书处理 常用于 HTTPS 入口和证书集中管理 常用于 TLS 或四层入口场景
架构重点 应用路由和服务拆分 连接性能和协议兼容

如果你是开发负责人，先看应用协议。HTTP/HTTPS 优先评估 ALB，TCP/UDP 优先评估 NLB。不要先从“哪个性能更好”开始问，因为性能需求要放在协议和业务形态之后判断。

如果你是采购或 IT 管理人员，重点看系统边界。一个业务系统可能同时需要 ALB 和 NLB。比如前端 Web API 使用 ALB，对内的 TCP 服务或数据接入层使用 NLB。这不是重复采购，而是不同入口承担不同职责。

如果你负责成本控制，需要关注的是请求量、连接数、跨可用区流量、后端资源规模、日志和监控等整体费用。负载均衡费用只是其中一部分。具体价格、折扣和计费项会随 AWS 区域和产品规则变化，实际预算应以 AWS 官方说明和咨询结果为准。

企业应用架构里，怎么按场景选择负载均衡

企业系统很少只有一个入口。比较常见的结构是：公网用户访问 Web 或 API，内部服务之间通过私有网络通信，后台任务、数据服务和第三方接入各自使用不同协议。负载均衡选型要放到这张架构图里看。

如果你的系统是典型 Web 应用，例如官网、后台管理系统、SaaS 控制台、电商接口，建议优先使用 ALB。它能按域名和路径拆分服务，适合蓝绿发布、灰度入口、微服务迁移等场景。后端可以是 EC2 实例，也可以是容器任务或 IP 目标，具体支持方式以 AWS 官方文档为准。

如果你的系统对外提供 HTTP API，也建议先看 ALB。你可以把不同版本的 API 放进不同目标组，比如 /v1 和 /v2 对应不同服务。这样做的好处是路由清楚，迁移时也更容易分阶段处理。

如果你的业务是 TCP 长连接，比如消息通道、实时推送、游戏接入、工业设备连接，NLB 更符合需求。这类业务通常不关心 URL，但很关心连接保持、源地址、端口和协议兼容。用 ALB 承接这类服务，往往会在协议层面先遇到限制。

如果你的系统有内外网两套入口，可以把公网入口和内网入口拆开设计。公网 Web/API 用面向互联网的 ALB；内网 TCP 服务用内部 NLB。这样边界更清楚，也便于安全组、子网和访问策略分开管理。

如果你的团队正在做容器化迁移，建议先梳理服务入口。不是每个服务都需要单独一个负载均衡器。对外暴露的服务才需要入口层；内部服务可以通过服务发现、内部负载均衡或集群网络能力处理。过早给每个微服务都配独立入口，后面成本和运维都会变重。

配置 AWS Load Balancer 前，先把四个问题问清楚

负载均衡的配置本身并不复杂，难的是前期判断。我们建议在打开 AWS 控制台前，先把下面几个问题写清楚。

第一，客户端用什么协议访问？ 如果是浏览器、App、HTTP API，大概率是 ALB。如果是 TCP、UDP、自定义协议，优先看 NLB。协议决定了大方向。

第二，是否需要按域名或路径分流？如果你希望 api.example.com、admin.example.com 或 /api、/console 分别进入不同服务，ALB 更合适。NLB 不适合承担这类七层路由。

第三，后端目标是什么？EC2、ECS、EKS、IP 地址、Lambda 等目标类型的支持范围不同。不要凭经验套用旧方案，具体要以 AWS 当前文档为准。尤其是容器和 Serverless 场景，目标组类型会影响后续部署方式。

第四，安全边界怎么设计？公网入口、内网入口、跨可用区、证书、访问日志、WAF、CloudWatch 告警都要一起考虑。只创建一个负载均衡器，然后把所有端口都放开，不是企业应用里推荐的做法。

如果你正在做 AWS 云服务器选型，也要把负载均衡一起算进去。实例规格、可用区数量、Auto Scaling 策略、健康检查间隔都会影响最终体验和成本。可以先整理业务访问量级、协议、区域和预算，再做方案评估。

一个可执行的选型流程

实际落地时，可以按下面的顺序走。这个流程适合采购、开发和技术负责人一起评审，避免只从单个角度做决定。

  1. 先列出所有入口：公网 Web、开放 API、后台管理、内部服务、第三方回调、设备接入等。
  2. 给每个入口标明协议：HTTP、HTTPS、TCP、UDP 或 TLS。
  3. 判断是否需要七层规则：域名、路径、Header、重定向、HTTPS 证书集中管理。
  4. 判断是否需要四层能力：源 IP、长连接、自定义端口、UDP、固定入口地址等。
  5. 确认后端目标：EC2、容器、IP、Serverless 或混合架构。
  6. 评估安全配置：安全组、子网、内外网类型、证书、访问日志和告警。
  7. 再看成本：负载均衡费用、后端资源、跨区流量、日志存储和监控费用都要纳入预算。

按这个顺序，通常不会偏得太远。只要第一步把入口列全，后面是 ALB 还是 NLB，就会变成一个比较清楚的技术判断。

常见选型误区：不是所有流量都该放到同一个入口

一个常见误区是为了省事，把所有服务都挂到同一个负载均衡器后面。短期看配置少了，长期看问题会变多。Web、API、长连接、内部服务的安全要求和运维节奏不同，混在一起会让规则越来越乱。

另一个误区是只按成本选型。负载均衡的费用当然要看，但如果为了少建一个入口，把七层路由放进应用代码，或者让四层服务绕到不合适的入口，后面排查问题的成本可能更高。成本优化应该建立在架构边界清楚的基础上。

还有团队会忽略健康检查。健康检查不是装饰项，它决定负载均衡器什么时候把目标摘除。检查路径、端口、返回码和超时时间要和应用真实状态匹配。比如 Web 服务可以准备一个轻量的健康检查接口，不要让检查请求依赖复杂数据库查询，否则会把偶发慢查询误判成服务异常。

日志也容易被忽视。上线前建议确认访问日志和 CloudWatch 指标是否打开，至少要能看到请求量、目标健康状态、错误趋势和延迟变化。没有这些信息，线上出现问题时只能靠猜。

采购和账户层面，也要提前规划

AWS Load Balancer 的技术选型完成后，还要回到账号和付款问题。企业使用 AWS 国际站时，常见的卡点不是会不会创建 ALB 或 NLB，而是账号注册、充值方式、预算控制、产品开通和后续账单管理。

如果公司没有国际信用卡，或者希望减少多账号付款和充值沟通成本，可以考虑通过服务商处理 AWS 账户注册与代充值。进化云提供 AWS 国际站账户注册、代充值、折扣代理及全系列产品代购协助，适合需要中文沟通、统一付款和技术支持的团队。充值到账时间、折扣和具体服务范围，以实际咨询为准。

对技术负责人来说，建议在项目启动前同步三件事：预计区域、主要产品和预算上限。比如负载均衡会不会跨多个可用区，后端是 EC2 还是容器，是否需要 CloudFront、Route 53、WAF、RDS 或 S3 配合。把这些信息提前给到采购和服务支持团队，后续开通和充值会更顺。

如果你还没有确定整体架构，可以先做一版成本优化方案。它不需要一开始就精确到每一项费用，但至少要把主要资源、流量方向和增长空间列出来。这样在咨询折扣或充值方式时，沟通会更具体。

什么时候选 ALB，什么时候选 NLB

可以用一句话收束：面向 HTTP/HTTPS 应用入口，优先选 ALB；面向 TCP/UDP/TLS 和长连接服务，优先选 NLB。

如果你是 Web 应用、API 网关、微服务入口、容器服务入口，ALB 更贴近需求。它的价值在于七层路由、证书处理、目标组管理和应用级健康检查。

如果你是自定义协议、长连接、游戏网关、设备接入、内部 TCP 服务，NLB 更合适。它的价值在于四层转发、协议兼容、源 IP 保留和连接处理能力。

如果一个企业系统同时存在这两类流量，不必强行二选一。把 ALB 和 NLB 分别放在合适的位置，反而更容易维护。下一步可以先画出入口清单，再按协议和路由需求做一轮评审；如果账号、充值或产品采购还没准备好，也可以同步咨询进化云，先把 AWS 国际站账户和预算流程安排清楚。

FAQ

AWS ALB 和 NLB 哪个更适合企业官网？

企业官网、后台系统和普通 Web API 通常优先选择 ALB。它支持 HTTP/HTTPS 场景下的应用层路由，更适合按域名、路径和目标组管理服务。

AWS Load Balancer 可以同时使用 ALB 和 NLB 吗？

可以。企业架构里很常见。公网 Web/API 可以使用 ALB，内部 TCP 服务、长连接或自定义协议入口可以使用 NLB。具体设计要看协议、安全边界和后端部署方式。

NLB 能不能替代 ALB 做网站入口？

如果只是简单转发 TCP 或 TLS 流量，NLB 可以承接部分入口需求。但它不适合做复杂的 HTTP 路由。如果网站需要按路径、域名或请求规则分流，ALB 更合适。

使用 AWS 国际站一定需要国际信用卡吗？

AWS 国际站账号和付款方式要以 AWS 官方规则为准。对于没有国际信用卡或希望统一处理充值的团队，可以咨询进化云的账号注册与代充值服务，具体流程和到账情况以实际咨询为准。