AWS VPC - 不同环境的弹性 IP

Question

我正在尝试为不同的环境（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 限制？

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

问候， 阿卜杜勒

Answer 1

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

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

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

• 您无需向所有人授予生产访问权限，
• 你可以指定一些资源只在特定环境下创建，
• “代码空间”类型事件 (!) 见 https://arstechnica.com/information-technology/2014/06/aws-console-breach-leads-to-demise-of-service-with-proven-backup-plan/

Answer 2

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

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

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

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