亚马逊AWS官方博客
私有实例轮询使用多公网 IP 访问公网的实现方案
1.背景说明
众所周知，业务服务器是企业用以提供服务实现盈利的核心，绝大多数情况业务服务器都部署于私有网络中，以保证安全。
在私有网络中的业务服务器提供业务功能时，对网络的诉求会分成两种类型：第一种是经由互联网被访问，可以借助负载均衡器进行服务暴露实现；第二种则是主动访问互联网。
对于第二种类型，如果需要的公网 IP 数量少于或等于 8 个，可以使用 Amazon NAT Gateway 实现；若需要的公网 IP 数量大于 8 个，则需要更加灵活的方案。
本文将介绍两种方案，用于满足“需要的公网 IP 数量大于 8 个”的场景，并在文章的最后，对这两种方案进行优劣势比较。
2.方案实现
2.1 方案 1：通过 iptables 的 SNAT 规则实现
a. 架构图（其中业务服务器 2 仅作为展示，并不会真正创建）
b. 环境搭建（执行命令的机器需要有足够的权限）
1) 创建网络资源
2) 创建实例资源
c. 配置转发服务器
1) 原理解释
iptables 中提供两种模式实现四层负载均衡，分别是 random（随机）和 nth（轮询）。
random 模式基于概率实现负载均衡，请参考如下示例说明：
rules 说明：
第一条规则中，指定 –probability 0.33 ，则说明该规则有 33% 的概率会命中。
第二条规则也有 33% 的概率命中，因为规则中指定 –probability 0.5。 则命中的概率为：50% * （1 – 33%）=0.33。
第三条规则中，没有指定 –probability 参数，因此意味着当匹配走到第三条规则时，则一定命中，此时走到第三条规则的概率为：1 – 0.33 -0.33 ≈ 0.33。
由上可见，可以通过修改 –probability 参数调整规则命中率。
probability 计算规则说明：
假设有 n 个 server，则可以设定 n 条 rule 将流量均分到 n 个 server 上，其中 –probability 参数的值可通过以下公式计算得到：p=1/(n−i+1)
# 其中 i 代表规则的序号（第一条规则的序号为1）
# n 代表规则/server的总数
# p 代表第 i 条规则中 –probability 的参数值
nth 模式基于轮询实现负载均衡，请参考如下示例说明：
rules 说明：
第一条规则是从第 0 个包开始计算，匹配第 1 个包
第二条规则是从第 0 个包开始计算，匹配第 2 个包
第三条规则是从第 0 个包开始计算，匹配第 3 个包
第 4 个包回到原点，再次重新匹配，以此反复循环
2) 部署转发服务器（这次实验采用 nth 方式进行）
为了实现多公网 IP 轮询，首先需要转发服务器拥有多个公网 IP，可以将 Elastic IP 与主网卡的多个 Secondary Private IP 进行绑定实现。又由于路由的原因，无法使用 Secondary Network Interface。所以，转发服务器可以拥有多少个公网 IP，将由实例的主网卡可以拥有多少个 Secondary Private IP 决定。这次实验使用的是 t3.medium，此实例类型主网卡可以拥有最多 6 个私网地址，去掉已经使用的 Primary Private IP，总计有 5 个 Secondary Private IP。具体哪种实例可以有多少 IP，请参考如下链接：Elastic network interfaces – Amazon Elastic Compute Cloud。
创建完 Secondary Private IP 并绑定 EIP 后，下一步就是关闭实例的 source/destination check 以及登录到转发服务器进行 iptables nth 规则的设置。
d. 方案 1 测试
登录到业务服务器 1，通过 curl ip.sb 获取访问公网的 IP 地址，可以看到是以轮训的方式获取到了不同的 IP 地址，而这些 IP 地址就是在转发服务器上绑定的 EIP。
e. 环境清理
下载方案 1 环境清理：按照“方案 1 环境清理”中记载的步骤进行清理。
2.2 方案 2：借助 Private Hosted Zone、Amazon Network Load Balancer 和 Nginx 实现
a. 架构图（其中业务服务器 2 仅作为展示，并不会真正创建）
- 通过 Private Hosted Zone 将要访问的网站域名进行劫持到 Network Load Balancer 的域名，这次实验中使用了 com 作为域名，访问的网站是 www.baidu.com，因此会将 www.baidu.com 劫持为 NLB 的域名。
- 请求通过 Peering Connection 送达到 Network Load Balancer。使用两个 VPC 的原因在于，如果业务服务器和 Nginx 服务器同属一个 VPC，那么访问的 baidu.com 就都会被劫持为 NLB 的域名，Nginx 就无法将请求转发到正确的地址。
- Network Load Balancer 监听 TCP 443 端口，并将请求转发到后端 Nginx 集群。使用 TCP 协议的原因在于，只需要将请求 443 的流量进行转发即可。
- Nginx 运行于 Stream 模式，在握手阶段拿到访问的域名，并转发到想要访问的网站。在这次实验中就是 baidu.com。
- Nginx 集群处于 Auto Scaling Group 中，根据请求流量进行动态扩缩容（这次实验不会实施，仅供参考）。
b. 环境搭建（执行命令的机器需要有足够的权限）
1) 创建网络资源
2) 创建实例资源
c. 配置 Nginx 实例
Nginx 在 1.9.0 版本新增了 stream 模块，用以实现四层协议的代理。对于 TLS 请求，会在 TLS 建连阶段拿到需要访问的域名，并将请求转发到正确的域名。
默认情况下，Nginx 并不包含此模块。因此需要对 Nginx 进行编译安装并在编译时增加”–with-stream”参数。
下载ProxyInstanceDeploymentProcedure，按照ProxyInstanceDeploymentProcedure中记载的步骤进行配置。
d. 创建和配置 Network Load Balancer
e. 创建和配置 Private Hosted Zone
f. 方案 2 测试
登录业务服务器 1，通过如下命令进行测试：for i in {1..20}; do curl -I https://www.baidu.com; done。
观看 Nginx1 的日志：
观看 Nginx2 的日志：
由此可见，每次访问 www.baidu.com 都是通过不同的 IP 地址进行的访问。
g. 环境清理
下载方案 2 环境清理：，按照”方案 2 环境清理”中记载的步骤进行清理
3.方案对比
| 方案 1 | 方案 2 | |
| 优势 | 配置简单，费用低，具体费用取决于选择的实例类型 | 云原生的方案，可以集成亚马逊云科技的各个服务； 方案中的每个组件都具有高可用性，可以应对故障； Nginx 实例可以线性扩展，因此私有实例可以使用无限多个公网 IP。 |
| 劣势 | 无法同亚马逊云科技的监控、告警和事件等服务集成，出现问题时无法第一时间发现； 每台私有实例都只能指向一台转发服务器，无冗余能力； 私有实例可以使用的公网 IP 数量取决于实例类型，不具备线性扩展能力。 |
配置复杂，由于使用了更多的服务，费用高于方案 1 |
4.总结
在这篇文章中，介绍了两种不同方案以实现私有实例轮询使用多公网 IP 访问公网，并在最后进行了两种方案的对比，以帮助大家更好的选择适合自己的方案。