每个环境的 AWS VPC，还是具有针对不同环境的多个子网的单个 VPC？
AWS VPC per environment, or single VPC with multiple subnets for different environments?
假设我有三个环境——开发、测试和生产。我相信我有两个关于如何在 AWS 中设置它们的选项：
- 为每个环境创建一个 VPC，总共三个 VPC。然后在每个 VPC 中为 availibility/redundancy 添加不同可用性区域中的子网。创建第四个 'shared services' VPC，其中包含所有不同环境所需的服务。
- 创建具有多个子网的单个 VPC。我会在不同的可用性区域中创建子网，并在子网中均匀分布不同的环境资源，这样即使一个区域出现故障，我也不会失去一个环境
以下哪一种方法被认为是最佳做法？如果有的话，各自的优点或缺点是什么？我是 AWS 的新手，到目前为止还无法找到最佳答案
good practice 是将生产环境与测试或开发环境完全分开，最好通过为它们设置单独的帐户来实现：
Accounts in the SDLC OU host non-production workloads and therefore should not have production dependencies from other accounts.
由于您没有使用不同的帐户，最接近的（如果您想遵循良好做法）是拥有不同的 VPC（选项 1）。此外，为了进一步分离环境，VPC 可以位于不同的区域。
此外，我鼓励您 re-think 为什么需要任何公共资源（即第四个 VPC）。如果您通过第四个 VPC 在 prod 和 devel 之间共享某些东西（例如 RDS），那将是一场等待发生的灾难。
我遇到了类似的问题。
每个环境的 VPC 可以在资源之间创建很大的分离，所以我建议至少有 PROD 和 nonPROD（开发、测试、 uat) VPC.
每个环境有一个 VPC 会导致成本增加：
- 每个 VPC 每个子网的 NAT 网关/NAT 实例
- VPC 端点（它们可能非常昂贵，每个端点大约 7 美元，而且您通常需要多个，但您必须记住，每个 AZ 只能连接一个子网）。
- VPN（在每个 VPC 内）
- CICD（如果您正在使用 self-hosted 代理 [例如使用 Azure DevOps]，则每个 VPC 中都需要一个代理）
- 管理可能会更困难（更多冗余资源等）。
（当然，您可以使用 VPC Peering 解决一些问题，但我认为这不是这种情况下的正确解决方案）
另一方面，每个环境有一个 VPC 可以带来一些好处：
- 所有ENV的子网矩阵可以相同，这样更容易调试
- 每个环境一个 VPN 可以降低“意外进入错误环境”的几率
- 相互资源影响的风险最小。
对于生产环境，明确的答案是将其隔离到自己的 AWS 账户中（而不仅仅是一个单独的 VPC）。有了 Control Tower 和 SSO，管理多个 AWS 账户的复杂性不再像过去那样了。
对于 Dev、Staging、QA、Demo 等非生产环境，答案不太明确。我当然想听听其他人的意见。我可以看到 3 种主要方法。
每个环境都有自己的 AWS 账户。
这可以用于演示或 UAT 环境（除了 Prod），但对于通常在内部用于开发的其他类型的环境来说，这似乎有点过分了。
此解决方案还增加了成本。
每个环境都有自己的 VPC，在一个共享的 AWS 账户中。
这会在网络级别和 ACL 级别隔离每个环境。
缺点：
- 每个 AWS 账户 5 个 VPC 的限制
- [Filip Niko
. 回答的额外费用
优点：
- 简化设置？因为所有 VPC 都可以以相同方式配置（例如通过 CDK）。
- 环境之间的隔离比下面的解决方案 3 更好。
每个环境都有自己的网络堆栈，位于共享的 VPC 和 AWS 账户内。
缺点：
- 更难“丢弃并重新创建”。使用 CDK，可以通过创建 VPC 及其服务轻松地提供一个新的“环境”。我猜测（请确认）当一个 VPC 包含所有内容时，这会更难。
- 对于 public 面临的环境不安全。
优点：
- 一个VPC可以有200个子网。即使每个环境（public、私有和隔离）分配 3 个子网，这也会产生约 60 个环境。
- 整体便宜。减少 NAT，需要端点。
我很想听听有关上述内容的反馈。
假设我有三个环境——开发、测试和生产。我相信我有两个关于如何在 AWS 中设置它们的选项：
- 为每个环境创建一个 VPC，总共三个 VPC。然后在每个 VPC 中为 availibility/redundancy 添加不同可用性区域中的子网。创建第四个 'shared services' VPC，其中包含所有不同环境所需的服务。
- 创建具有多个子网的单个 VPC。我会在不同的可用性区域中创建子网，并在子网中均匀分布不同的环境资源，这样即使一个区域出现故障，我也不会失去一个环境
以下哪一种方法被认为是最佳做法？如果有的话，各自的优点或缺点是什么？我是 AWS 的新手，到目前为止还无法找到最佳答案
good practice 是将生产环境与测试或开发环境完全分开，最好通过为它们设置单独的帐户来实现：
Accounts in the SDLC OU host non-production workloads and therefore should not have production dependencies from other accounts.
由于您没有使用不同的帐户，最接近的（如果您想遵循良好做法）是拥有不同的 VPC（选项 1）。此外，为了进一步分离环境，VPC 可以位于不同的区域。
此外，我鼓励您 re-think 为什么需要任何公共资源（即第四个 VPC）。如果您通过第四个 VPC 在 prod 和 devel 之间共享某些东西（例如 RDS），那将是一场等待发生的灾难。
我遇到了类似的问题。
每个环境的 VPC 可以在资源之间创建很大的分离，所以我建议至少有 PROD 和 nonPROD（开发、测试、 uat) VPC.
每个环境有一个 VPC 会导致成本增加：
- 每个 VPC 每个子网的 NAT 网关/NAT 实例
- VPC 端点（它们可能非常昂贵，每个端点大约 7 美元，而且您通常需要多个，但您必须记住，每个 AZ 只能连接一个子网）。
- VPN（在每个 VPC 内）
- CICD（如果您正在使用 self-hosted 代理 [例如使用 Azure DevOps]，则每个 VPC 中都需要一个代理）
- 管理可能会更困难（更多冗余资源等）。
（当然，您可以使用 VPC Peering 解决一些问题，但我认为这不是这种情况下的正确解决方案）
另一方面，每个环境有一个 VPC 可以带来一些好处：
- 所有ENV的子网矩阵可以相同，这样更容易调试
- 每个环境一个 VPN 可以降低“意外进入错误环境”的几率
- 相互资源影响的风险最小。
对于生产环境，明确的答案是将其隔离到自己的 AWS 账户中（而不仅仅是一个单独的 VPC）。有了 Control Tower 和 SSO，管理多个 AWS 账户的复杂性不再像过去那样了。
对于 Dev、Staging、QA、Demo 等非生产环境，答案不太明确。我当然想听听其他人的意见。我可以看到 3 种主要方法。
每个环境都有自己的 AWS 账户。 这可以用于演示或 UAT 环境（除了 Prod），但对于通常在内部用于开发的其他类型的环境来说，这似乎有点过分了。 此解决方案还增加了成本。
每个环境都有自己的 VPC，在一个共享的 AWS 账户中。 这会在网络级别和 ACL 级别隔离每个环境。
缺点：
- 每个 AWS 账户 5 个 VPC 的限制
- [Filip Niko
优点：
- 简化设置？因为所有 VPC 都可以以相同方式配置（例如通过 CDK）。
- 环境之间的隔离比下面的解决方案 3 更好。
每个环境都有自己的网络堆栈，位于共享的 VPC 和 AWS 账户内。
缺点：
- 更难“丢弃并重新创建”。使用 CDK，可以通过创建 VPC 及其服务轻松地提供一个新的“环境”。我猜测（请确认）当一个 VPC 包含所有内容时，这会更难。
- 对于 public 面临的环境不安全。
优点：
- 一个VPC可以有200个子网。即使每个环境（public、私有和隔离）分配 3 个子网，这也会产生约 60 个环境。
- 整体便宜。减少 NAT，需要端点。
我很想听听有关上述内容的反馈。