1

我正在尝试为不同的环境（dev/test/pre-prod/prod）建立一个 VPC 架构，并且我面临一个关于弹性 IP 限制限制的问题。首先很高兴知道架构是否朝着正确的方向发展。因此，让我在这里向您解释详细信息：

  1. 1 个用于所有环境的 VPC，带有 1 个 Internet 网关
  2. 一个区域的 VPC
  3. 3 个可用区，每个可用区有 1 个私有子网和 1 个实用程序子网（共 6 个子网）
  4. 3 个 NAT 网关 - 每个公用事业子网一个，分配给其网络接口的 3 个弹性 IP
  5. 每个私有子网中的 EC2 实例（主节点和节点）
  6. 用于连接企业网络的虚拟专用网关

我正在使用 Terraform 将整个基础设施作为代码自动化（这在这里无关紧要）。当我为一个环境（比如说开发）运行 Terraform 脚本时，上面详述的整个基础设施都创建得很好并且运行良好。但是现在当我为另一个环境（比如测试）运行脚本时，我用完了弹性 IP（因为每个区域限制为 5 个 EIP）。

重新架构它的最佳方法是什么，以便我可以为不同的环境创建基础架构，同时不达到这些 EIP 限制？

非常感谢您的帮助。如果需要更多详细信息，请告诉我。

问候， 阿卜杜勒

4

2 回答 2

3

我建议每个环境都在其自己的 AWS 账户中进行管理，而不是将所有环境混合在一个账户中。当您使基础架构自动化时，额外的分离非常容易，它为您提供了更高级别的安全性和环境之间的隔离。一个环境中的黑客攻击不会影响另一个环境。

我们以这种方式保留 3 个环境。生产、开发和故障安全环境。故障安全帐户包含不同区域中的生产备份。

按帐户分隔环境有多种好处。例如：

于 2018-01-30T11:46:35.043 回答
2

正如评论中提到的，EIP 限制只是您遇到了 EIP 的 AWS 服务限制，因此您应该与 AWS 讨论提高它的问题。Rodrigo M建议在单独的 AWS 账户中运行单独的工作负载是绕过服务限制的另一种方法，但由于他的回答中列出的许多其他原因，这也是一个好主意。

如前所述，您可能需要考虑仅在非生产 VPC 中运行单个 NAT 网关，因为这将降低您的成本（以及减少您需要的 EIP）。

NAT 网关在它们所在的可用区域内具有高可用性，但显然不是跨区域。这意味着，如果您在恰好包含您的 NAT 网关的 AZ 上出现单个 AZ 故障，那么您的其他 AZ 将失去通过 NAT 网关的连接，从而将故障传播到逻辑分离的 AZ 之外。如果您要为每个 AZ 设置一个 NAT 网关，那么当一个 AZ 发生故障时，它只会影响该单个 AZ（那时显然已完全关闭）。

对我自己来说，较少的 HA 适用于非生产环境，每个非生产 VPC 每月可节省 65 美元。然而，在生产环境中，我很乐意吃掉那一点额外的成本来减少由 AZ 故障造成的损害，以及我为避免单点故障所做的所有其他工作。

于 2018-01-30T14:40:59.437 回答