AWS代充 AWS Internet Gateway 与 NAT Gateway 的工作原理：VPC 出入网路径、路由配置与故障排查教程

用户搜索“AWS Internet Gateway 与 NAT Gateway 的工作原理”时，通常已经在 AWS 控制台里遇到了具体问题：EC2 放在公有子网却访问不了公网，私有子网里的 Linux 实例无法执行 yum update 或 apt update，数据库服务器担心暴露公网，或者团队在创建 NAT Gateway 后发现费用明显上升，却不确定是否真的需要。真正的决策点不是记忆定义，而是明确谁负责入站、谁负责出站、路由该怎么填、弹性 IP 何时必须绑定，以及出现网络不通时该从哪里排查。

AWS代充 先判断：你到底应该用 Internet Gateway 还是 NAT Gateway

在 AWS 实际配置里，很多故障不是资源本身有问题，而是一开始选错了网络路径。下面这张表可以直接帮助你判断。

如果你需要“让别人访问你的 EC2”，NAT Gateway 解决不了。它只负责让私有子网实例向外发起连接。反过来，如果你想“让私有子网中的服务器访问互联网下载更新，但外部不能直接打进来”，Internet Gateway 也不是直接给这台私有实例用的，而是给 NAT Gateway 所在的公有子网提供出网通道。

用户最容易卡住的三个地方

1. 以为创建了公有 IP，实例就一定能上网

实际还需要满足三个条件：实例所在子网的路由表必须有 0.0.0.0/0 指向 Internet Gateway；实例要有公有 IPv4 或绑定 Elastic IP；安全组和系统防火墙不能拦截目标流量。缺一个都不通。

AWS代充 2. 以为 NAT Gateway 创建成功后，私有子网自动获得出网能力

不对。私有子网的路由表必须显式添加默认路由 0.0.0.0/0 指向 NAT Gateway。并且 NAT Gateway 自己必须部署在公有子网里，这个公有子网需要通过 Internet Gateway 出网。

AWS代充 3. 以为安全组放行就够了

很多实例无法联网，最后发现是网络 ACL 拦截了返回流量，或者操作系统内 firewalld、ufw、Windows Defender Firewall 没放行。AWS 网络是多层生效的，不能只看一处。

准备工作：开始配置前必须确认的资源

正式操作前，先准备以下项目，避免做到一半发现条件不满足。

推荐测试拓扑如下：VPC 使用 10.0.0.0/16，公有子网为 10.0.1.0/24，私有子网为 10.0.2.0/24。公有子网放 NAT Gateway 和可公网访问的 EC2，私有子网放应用服务器或数据库。

AWS代充 实操一：配置 Internet Gateway，让公有子网实例可直接访问公网

步骤1：创建或检查 VPC 与公有子网

进入 AWS 控制台，打开 VPC 服务。

• AWS代充 点击“Your VPCs”，确认已有 VPC，例如 CIDR 为 10.0.0.0/16。
• 点击“Subnets”，创建公有子网，例如 10.0.1.0/24。
• 为该子网开启自动分配公有 IPv4：进入子网详情，选择“Edit subnet settings”，勾选“Enable auto-assign public IPv4 address”。

注意：如果这里没开启，实例即使在公有子网，也可能没有公网 IP，导致无法直接通过 Internet Gateway 通信。

步骤2：创建并关联 Internet Gateway

• 在 VPC 控制台左侧点击“Internet Gateways”。
• 点击“Create internet gateway”，填写名称，例如 igw-prod。
• 创建后选择“Attach to VPC”，绑定你的目标 VPC。

到这里，Internet Gateway 已经挂在 VPC 上，但还没有任何子网真正通过它出网。真正决定路径的是路由表。

步骤3：为公有子网配置默认路由

• 进入“Route Tables”。
• 找到与你的公有子网关联的路由表；如果没有专门的路由表，建议新建一个，例如 rtb-public。
• AWS代充 在“Routes”中添加一条路由：目标网段 0.0.0.0/0，Target 选择刚创建的 Internet Gateway。
• 在“Subnet associations”中把公有子网 10.0.1.0/24 关联到该路由表。

这一步最关键。很多用户创建了 Internet Gateway 却不生效，原因几乎都在这里。

步骤4：启动 EC2 并验证

• 创建 EC2 时，网络选择你的 VPC，子网选择公有子网。
• 如果子网未开启自动分配公网 IP，则在实例创建时手动启用“Auto-assign Public IP”。
• AWS代充 安全组中放行 SSH 22 或 RDP 3389，Web 服务则开放 80、443。

Linux 可用以下命令测试：

curl -I https://aws.amazon.com

ping 8.8.8.8

如果是 Windows，使用 PowerShell：

Test-NetConnection www.microsoft.com -Port 443

实操二：配置 NAT Gateway，让私有子网实例只出网不暴露入口

步骤1：准备 NAT Gateway 所在的公有子网

NAT Gateway 不能放在私有子网。它必须部署在一个可以通过 Internet Gateway 出网的公有子网中，因此请先完成上一节的 Internet Gateway 配置。

同时，提前申请一个 Elastic IP：

• 进入 EC2 控制台。
• 点击“Elastic IPs”。
• 选择“Allocate Elastic IP address”。

注意：NAT Gateway 创建时必须绑定 EIP，否则无法对外通信。

步骤2：创建 NAT Gateway

• 进入 VPC 控制台，点击“NAT Gateways”。
• 点击“Create NAT gateway”。
• Subnet 选择公有子网，例如 10.0.1.0/24。
• Elastic IP 选择刚申请的地址。
• 点击创建并等待状态变为 Available。

如果 NAT Gateway 长时间处于 Failed，优先检查该子网是否真的是公有子网，即其路由表是否已有 0.0.0.0/0 指向 Internet Gateway。

步骤3：为私有子网配置默认路由到 NAT Gateway

• 创建私有路由表，例如 rtb-private。
• 添加默认路由：0.0.0.0/0 指向 NAT Gateway。
• 将私有子网 10.0.2.0/24 关联到这个私有路由表。

这里不要把私有子网的默认路由直接指向 Internet Gateway，否则它就变成公有暴露路径了。私有子网实例正常情况下不应拥有公有 IP。

步骤4：在私有子网中启动 EC2 并验证

• 创建 EC2，子网选择私有子网。
• 不要分配公有 IP。
• 若需远程管理，建议通过跳板机、AWS Systems Manager Session Manager 或 VPN 进入。

登录后执行：

curl -I https://repo.amazonaws.com

sudo yum update -y

或

sudo apt update

如果可以访问外网仓库，但公网无法直接 SSH 到该实例，说明 NAT Gateway 配置符合预期。

关键配置填写说明：哪些参数填错最常见

常见故障排查：为什么实例还是上不了网

案例1：公有子网 EC2 无法 SSH

排查顺序建议如下：

• 检查实例是否有 Public IPv4 或 EIP。
• 检查公有子网路由表是否有 0.0.0.0/0 到 IGW。
• 检查安全组入站是否开放 22，来源 IP 是否正确。
• 检查网络 ACL 是否允许 22 和临时端口返回流量。
• 检查系统防火墙：Linux 的 firewalld/iptables，Windows 的 Defender Firewall。

很多用户在公司网络里连接失败，其实是本地出口 IP 变更，安全组白名单未更新。

案例2：私有子网实例不能执行 yum update

• 确认私有子网路由表的 0.0.0.0/0 指向 NAT Gateway。
• 确认 NAT Gateway 状态为 Available。
• 确认 NAT Gateway 所在公有子网有 0.0.0.0/0 到 IGW。
• 确认私有实例 DNS 可用，VPC 的 DNS resolution 和 DNS hostnames 已启用。

如果 ping IP 可以，域名不行，往往是 DNS 问题；如果域名和 IP 都不行，重点看路由和 NAT 状态。

案例3：外部无法访问私有子网中的数据库

这通常不是故障，而是设计结果。NAT Gateway 只允许私有实例向外发起连接，不允许外部主动进入私有子网。如果需要运维数据库，应通过 VPN、Direct Connect、跳板机、RDS Proxy、Session Manager 或临时运维链路实现。

案例4：NAT Gateway 已创建但费用异常高

费用通常来自两个方面：NAT Gateway 小时费和经 NAT 的流量费。如果是大量访问 S3、DynamoDB、Systems Manager，优先考虑 VPC Endpoint，减少流量穿过 NAT Gateway。对开发测试环境，还可以评估是否用 NAT Instance 替代，但需要自行维护高可用和补丁更新。

不同业务场景下怎么选配置

个人开发者

如果只是部署博客、小型 API、测试环境，一台位于公有子网的 EC2 通常就够用，挂 Internet Gateway，开放 22、80、443。若预算敏感，不建议为了单台测试机单独上 NAT Gateway。

企业用户

典型做法是 Web 层位于公有子网，通过负载均衡对外；应用层和数据库层放私有子网，通过 NAT Gateway 执行系统更新、拉取依赖。生产环境建议按可用区分别部署 NAT Gateway，避免单可用区故障影响整片私有网络出网。

跨境业务

优先考虑地域靠近用户侧和第三方 API 所在区域。若业务频繁访问外部 SaaS 接口，建议在应用子网使用 NAT Gateway，并对出口 IP 做固定管理，便于对方平台加白名单。此时使用 EIP 的 NAT Gateway 比分散的公有 EC2 更容易统一管理出网身份。

网站应用

前端服务在公有层，业务服务在私有层。SSL 证书建议挂在 ALB 或 CloudFront，避免每台实例单独暴露 443。静态资源可走 CDN，减少源站经 Internet Gateway 的直接压力。

数据库业务

MySQL、PostgreSQL、Redis 不建议直接暴露公网。数据库实例一般位于私有子网，必要的补丁更新走 NAT Gateway，备份与恢复通过私网或对象存储链路进行。若是自建 MySQL，排查连接失败时先区分是私网访问不通，还是误以为 NAT Gateway 能提供入站连接。

配置建议：按规模给出可落地方案

优化建议：不是配通就结束

安全优化

• 公有子网实例只开放必要端口，SSH 建议限制办公出口 IP。
• 私有子网实例不分配公网 IP，管理入口优先使用 Session Manager。
• 安全组按角色拆分，不要长期使用 0.0.0.0/0 开放 22 或 3389。
• 数据库、Redis 仅允许应用层安全组访问。

性能优化

• 跨可用区流量较多时，检查 NAT Gateway 是否造成额外路径绕行。
• 大规模拉包、镜像下载时，结合本地缓存、镜像仓库和 VPC Endpoint 降低出口压力。
• 网站应用配合 ALB、CDN、Route 53 健康检查提升访问稳定性。

成本优化

• 开发测试环境按需启停不必要的 NAT Gateway。
• 访问 S3、DynamoDB 优先使用 Gateway Endpoint，减少 NAT 流量费。
• 多个私有子网可共享 NAT Gateway，但生产环境需权衡单点和跨 AZ 成本。

稳定性优化

• 生产环境建议每个可用区部署独立 NAT Gateway，并让本可用区私有子网走本地 NAT。
• 关键服务器定期做 AMI 或 EBS 快照备份，便于系统重装与迁移。
• 使用 CloudWatch 监控网络流量、连接错误和实例状态检查。

如果你现在正处于“到底应该配 Internet Gateway 还是 NAT Gateway”的阶段，可以用一句话判断：需要公网主动访问你的实例，用 Internet Gateway；只需要私有实例主动访问外网，用 NAT Gateway。真正影响是否通的，不是名称，而是路由表、子网类型、公网 IP、EIP、安全组和系统防火墙这几项是否同时正确。