公网 IP、负载均衡和 NAT 网关怎么选？入站与出站架构

公网 IP、负载均衡和 NAT 网关经常同时出现在云网络架构里，但职责不同：公网 IP 让单个资源直接通信，负载均衡接收并分发入站流量，NAT 网关主要为私网资源提供统一出站。把三者当成替代品，会导致暴露面、可用性和费用判断失真。

直接结论：公网 IP 是单个资源的地址，负载均衡是接收入站并把请求分给健康后端的入口，NAT 网关主要让没有公网 IP 的私网实例主动访问互联网。正式多实例网站默认用负载均衡；数据库和应用放私网，需要更新软件时再经 NAT 出站。三者都可能产生资源和流量费用，创建前先看价格摘要。

三种入口分别适合什么

方式	主要用途	适用条件	关键边界
实例公网 IP	单节点入站与出站	测试、管理、简单单机	暴露实例，难做多节点切换
负载均衡	入站分发与健康检查	多实例生产服务	协议、会话和健康检查需正确配置
NAT 网关	私网节点统一出站	节点不应接受公网入站	不是公网入站负载均衡器

为什么生产应用常用负载均衡

公网负载均衡可以把客户端请求转到私网目标，目标实例无需各自暴露公网 IP。健康检查可以摘除故障节点，但只能判断配置的检查条件；如果健康接口过于简单，仍可能把无法完成真实业务的节点视为健康。

NAT 网关解决的是出站治理

应用节点需要下载更新、调用第三方 API，又不需要接受公网连接时，可以位于私网并通过 NAT 出站。这样可以集中管理出口地址和访问策略。NAT 仍可能成为成本或容量关注点，需核对连接数、吞吐、跨区路径和流量费用。

推荐的设计步骤

1. 画清客户端到服务的入站路径，以及服务访问外部系统的出站路径。
2. 把数据库、缓存和内部任务节点保持在私网。
3. 多节点 Web/API 通过负载均衡接入，管理端使用受控入口。
4. 为健康检查、连接排空、超时、真实客户端 IP 和 TLS 建立测试。
5. 检查单 NAT、单可用区目标和 DNS 是否形成新的单点。

边界条件

不同平台的四层、七层负载均衡、固定 IP、IPv6、NAT 规格和计费方式不同。公网 IP 也不等于应用已安全开放；安全组、系统防火墙、身份认证和日志仍需独立设计。

不要用错流量方向

需求	默认资源	典型误区
外部访问单台测试机	公网 IP	以为有 IP 就自动开放端口
外部访问多台应用	负载均衡	把后端也全部暴露公网
私网实例统一下载更新	NAT 网关	以为 NAT 能接收公网主动入站
第三方固定出口白名单	带稳定公网地址的 NAT	忽略多可用区和故障切换

普通网站的可执行架构

1. 在两个可用区建立公有和私有子网。
2. 负载均衡放公有子网，监听 80/443；后端应用只接受负载均衡安全组访问。
3. 数据库不分配公网 IP，只接受应用网段或安全组。
4. 私有实例确需出站时，把默认路由指向对应 NAT；高可用要求下按平台能力设计多区出口。

公网地址、路由、安全组和应用监听必须同时正确。有公网 IP 但子网没有互联网路由，或路由正常但进程只监听本机地址，外部仍然访问不到。

不通时按三条链分别检查

• 公网 IP 不通：核对地址绑定、互联网网关、入站安全组、网络 ACL、系统防火墙和监听端口。
• 负载均衡后端不健康：从负载均衡网络访问健康端口，检查路径返回码、超时与证书终止位置。
• NAT 出站失败：检查 NAT 状态、公有子网到互联网的路由、私有路由表关联和返回流量。

开启流日志后，拒绝记录能说明包到达哪个网络接口，但不能直接证明应用正常。502/504 多数已越过公网入口，应继续查后端连接与应用日志。

费用、验收和迁移回退

除资源小时费，还要核对公网 IPv4、处理容量、出站、跨区和 NAT 数据处理费。分别从外部网络访问域名，从私网实例访问授权的更新站点，再检查健康目标、源地址记录、DNS、TLS 和账单标签。迁移前降低 DNS TTL，保存旧路由和安全组，旧公网入口保留到缓存过期；异常时恢复旧 DNS 或路由。确认无人引用后再释放地址，因为释放后通常无法找回。

安全策略要跟职责一致

负载均衡安全组只开放真实业务端口，后端只接受入口安全组，不接受全网；NAT 负责出站不代表私网实例可以忽略出站域名、端口和审计。需要固定第三方白名单时记录出口地址与故障切换方式。任何公网 IP 都不是安全能力，地址存在不等于端口应该开放，网络可达也不代表应用健康。

完成当前任务后继续检查

• CDN、全球加速和源站直连怎么选？静态缓存与动态链路对比
• 单可用区、多可用区和多区域怎么选？高可用与灾备架构

官方资料

• AWS Elastic Load Balancing 工作方式
• AWS NAT gateway

需要核对目标区域的网络产品时，可联系黑鲨云 @heishayun。