每个环境的 AWS VPC，还是针对不同环境具有多个子网的单个 VPC？

Question

假设我有三个环境 - 开发、测试和生产。我相信我有两个关于如何在 AWS 中设置它们的选择：

1. 每个环境创建一个 VPC，所以总共三个 VPC。然后在每个 VPC 内添加不同可用区中的子网以实现可用性/冗余。创建第四个“共享服务”VPC，其中包含所有不同环境所需的服务。
2. 创建具有多个子网的单个 VPC。我会在不同的可用区域中创建子网，并将不同的环境资源均匀地分布在子网中，这样如果一个区域出现故障，我就不会失去一个环境

这些方法中的哪一种被认为是最佳实践？如果有的话，每种方法的优点或缺点是什么？我是 AWS 的新手，到目前为止一直无法找到最佳答案的明确答案

Answer 1

将好的做法是有产量从测试或开发环境完全分离，这是最好的有他们独立账户来实现：

SDLC OU 中的帐户承载非生产工作负载，因此不应与其他帐户具有生产依赖关系。

由于您没有使用不同的帐户，因此您可以获得的最接近的（如果您想遵循良好做法）是拥有不同的 VPC（选项 1）。此外，为了进一步分离环境，VPC 可以位于不同的区域。

此外，我鼓励您重新思考为什么需要任何公共资源（即第四 VPC）。如果您通过第四个 VPC 在 prod 和 devel 之间共享某些东西（例如 RDS），那将是一场等待发生的灾难。

Answer 2

我遇到了类似的问题。

每个环境的 VPC 可以在资源之间创建很大的分离，因此我建议至少拥有PROD和非PROD（开发、测试、uat）VPC。

每个环境拥有一个 VPC 可能会导致成本增加：

• 每个 VPC 每个子网的 NAT 网关/NAT 实例
• VPC 端点（它们可能非常昂贵，每个端点大约 7 美元，您通常需要多个，但您必须记住，每个可用区只能连接一个子网）。
• VPN（在每个 VPC 内）
• CICD（如果您使用自托管代理 [例如使用 Azure DevOps]，则每个 VPC 中都需要一个代理）
• 管理可能更困难（更多冗余资源等）。

（当然，您可以使用VPC Peering解决一些问题，但我认为在这种情况下这不是正确的解决方案）

另一方面，每个环境拥有一个 VPC 可以带来一些好处：

• 所有 ENV 的子网矩阵可以相同，因此更容易调试
• 每个环境一个 VPN 可以降低“意外进入错误环境”的机会
• 将相互资源影响的风险降至最低。