我正在为一个系统（建立在 AWS 上）设计一种架构，该系统将在不同区域拥有多个不同的生产环境。
最初，我认为每个环境使用 1 个 VPC 是个好主意，另一个运营和维护 (OAM) VPC 提供堡垒主机并用于与环境 VPC 建立 ssh 连接（然后可以阻止来自公共互联网的所有入站 ssh 流量）。每个环境 (env) VPC 都会有 VPC 与 OAM VPC 对等。
这种方法的问题在于，如果我想从 OAM VPC 访问所有环境 VPC，它们必须各自具有不同的 CIDR 范围。这有两个含义：
- 我需要跟踪哪个环境具有哪个 CIDR 范围
- 我将为未来的可扩展性设定一个限制——要么 CIDR 范围太少或太大，在这种情况下我可能会达到环境数量的限制，要么太小或太多，在这种情况下我会限制每个环境中可以放置的东西的数量。
另一种方法是让所有环境 VPC 彼此完全隔离，这意味着每个 VPC 可以具有相同的 CIDR 范围。对我来说，这似乎是一个优势，因为相同的环境意味着更容易维护和更少的人为错误。此外，我们可以在每个环境中容纳更多的东西。但要访问它们，我必须在每个环境中添加一个堡垒主机，这 a) 不太安全，b) 浪费。
有没有最佳实践来协调这两个相互冲突的需求（安全性和一致性）？
答案1
不要使用重叠的 CIDR 块，因为它会限制您的连接选项 - Transit Gateway 和 VPC 对等连接不适用于重叠范围。您会让自己陷入困境。
私有地址空间几乎是无限的。为每个帐户分配一个 /16 块，为每个 VPC 分配一个 /8，或者任何他们需要的。如果您需要与本地 CIDR 范围集成，这种方法就不太管用了。如果您需要面向公众，这种方法仍然有效。我将 CIDR 信息记录在包含我的 AWS 设计的 Word 文档中，但您可以使用电子表格。
AWS VPC 可以拥有添加了额外的 CIDR 范围如果空间不足。
您应该考虑使用 AWS Control Tower 和多账户环境，而不是多 VPC。了解其优势，但可管理性和影响范围才是关键。虽然自动化需要更多工作，但可扩展性非常好。
我通常为每个应用程序和每个环境创建一个 AWS 账户，因此如果我有三个应用程序和四个环境（开发、测试、预生产、生产），我将有 12 个账户。我还使用网络、安全、日志记录、审计和平台沙盒账户。您可以使用 Guard Duty、AWS Config、Security Hub 来保护它，最好使用 CloudFormation 和某种管道来创建。