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

Question

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

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

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

Answer 1

good practice 将生产与测试或开发环境完全分开，最好通过为它们单独帐户来实现：

SDLC OU 中的帐户托管非生产工作负载，因此不应具有来自其他帐户的生产依赖项。

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

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

Answer 2

我遇到了类似的问题。

每个环境的 VPC 可以很好地分离资源，因此我建议至少有 PROD 和 nonPROD（开发、测试、uat）VPC。

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

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

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

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

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