AWS中如何配置NAT Gateway：让出站流量走NAT且回程流量不经过NAT？

针对你遇到的这个矛盾——既要用固定IP访问带防DOS机制的云服务（IP不固定），又要保证外部能正常SSH/连接数据库，核心问题是全流量走NAT网关会导致往返路径不一致，下面给你几个可行的解决方案，按推荐度排序：

1. 精准路由：仅目标服务的出站流量走NAT网关 #

这是最直接的方案，不用改动现有架构，只需要调整路由表，让只有发往目标服务的流量走NAT网关，其他流量（包括SSH/数据库的回程）直接走互联网网关。

具体操作步骤：

• 先获取目标云服务的IP范围：大部分云服务商都会公开自己服务的IP段（比如AWS的Service Tags、阿里云的官方服务IP列表）；如果是第三方服务，也可以通过nslookup/dig查询域名对应IP，或者联系服务商获取官方IP段。
• 创建（或修改）子网关联的路由表：
  • 添加一条路由条目，目标为目标服务的IP段，下一跳指向你的NAT网关；
  • 保留默认路由（0.0.0.0/0或::/0），下一跳指向互联网网关；
• 把这个路由表关联到你的业务实例所在的子网。

这样做的好处：

• 只有访问目标服务的流量会用NAT网关的固定IP（满足白名单要求）；
• 外部发起的SSH/数据库连接，实例的回程流量会直接走互联网网关返回，往返路径一致，不会被安全策略拦截；
• 如果目标服务的IP段会动态更新，可以用云服务商提供的**前缀列表（Prefix Lists）**或自动脚本定期更新路由条目，不用手动维护。

2. 用弹性公网IP（EIP）替代NAT网关（适合实例数量少的场景） #

如果你的业务实例数量不多（比如个位数），直接给每个实例绑定EIP是更简单的方案：

• 给每个实例分配一个EIP，出站流量会自动使用这个EIP；
• 把这些EIP全部加到目标服务的白名单中；
• 外部SSH/连接数据库时，直接通过EIP访问，往返路径完全一致，不会有任何冲突。

这个方案优势是配置简单，不需要维护NAT网关和复杂路由，但如果实例数量多，EIP的成本会比NAT网关高，管理起来也更繁琐。

3. 分离管理与业务流量：双子网架构 #

如果你的系统规模较大，建议把业务流量和管理流量分开，用两个子网隔离：

• 业务子网：仅部署处理目标服务请求的实例，路由表配置为：目标服务IP段走NAT网关，无默认路由（或默认路由指向NAT网关，但通过安全组限制仅允许目标服务的出站流量）；
• 管理子网：部署跳板机（Bastion Host）或允许外部访问的管理实例，路由表默认路由指向互联网网关；
• 通过安全组规则，允许管理子网的IP访问业务子网的SSH/数据库端口。

这样做的好处：

• 业务实例的所有出站流量（除了到管理子网的）都走NAT网关，满足白名单要求；
• 管理员可以先SSH到管理子网的跳板机，再访问业务实例，或者用VPN连接到VPC直接访问业务子网的私网IP，完全避免公网暴露业务实例；
• 安全性更高，业务实例不需要公网IP，减少攻击面。

关键注意事项 #

• 检查安全组和Network ACL：确保允许SSH（默认22端口）、数据库端口（比如3306、5432）的入站流量，以及对应的出站流量；
• 验证路由规则：可以用traceroute或mtr命令测试实例到目标服务的路径，确认走的是NAT网关；同时测试外部SSH到实例的路径，确认回程是直接走互联网网关；
• 动态IP服务的适配：如果目标服务的IP完全不固定且没有公开的IP段，可以考虑用脚本定期解析域名获取IP，然后通过云服务商API自动更新路由表。

内容的提问来源于stack exchange，提问作者Michael Wiles