在我们的团队中，我们使用 AWS 作为我们的主要云提供商，目前，我们在他们的平台上托管了 3 个项目。
我们将在接下来的几周内再有 2 个项目，但首先，我们要组织我们的项目，因为我们目前的组织有点混乱。
我们希望我们的项目按照以下规则进行组织：
- 每个项目都必须有一个暂存环境和生产环境。
- 每个项目都是彼此独立的，因此无法从另一个项目内部看到一个项目的资源，即 VPC 和 S3 Buckets。
- 客户负责支付项目（暂存和生产环境）的费用。
- 即使客户负责支付账单，我们也必须能够访问环境来部署我们的代码并执行与开发、测试和运营相关的其他任务。
- 我们可以为每个项目分配一个开发团队。开发人员应该可以同时参与一个或多个项目。此外，我们应该可以在项目之间调动开发人员，并取消他们对项目的访问权限。
那么，是否可以按照前面提到的规则在 AWS 中组织项目？
答案1
逻辑组织的主要选项是：
- 所有东西都放在一个账户/一个 VPC 中，通过标记或子网进行分离（不太理想）
- 每个环境每个应用程序一个帐户/一个 VPC（更好）
- 每个环境每个应用程序一个帐户（我认为对于较大的组织来说最好，但对于较小的组织来说有一些开销）
主要考虑因素为：
- 轻松启用或阻止访问，特别是如果您的帐户与 AD 联合。只需将某人添加到 AD 组即可授予他们访问权限，然后将其删除即可撤销访问权限，这很方便，他们只需承担您希望他们拥有的策略的角色即可
- 工作负载之间的隔离
- 减少爆炸半径
- 避免每个账户的 AWS API 限制
- 成本分配，使用标签是可以的，但使用账户更容易（如果您使用中央通信账户或回程到本地，则带宽除外）
- 监控
- 复杂性 - 账户越多，管理起来就越困难，但应用程序隔离也有助于降低复杂性
- 合规性 - 使用单独的账户可能更容易实现 PCI 合规性，因为您可以更轻松地证明隔离
AWS 控制塔是截至 2022 年 AWS 在该领域的最佳实践，您应该了解一下。它使用 AWS Organizations，这对于进行合并计费和使用服务控制策略非常有用。如果您需要设置账户之间的通信，Transit Gateway 很有用。您不能只运行 Control Tower 并称其足够好，您仍然需要处理网络、安全和用户管理，但这是一个很好的开始。
旧版 AWS Landing Zone这个答案在 2019 年推荐的现在已成为遗留问题，并标记为“不会获得更新”。
我花了很多时间考虑这个问题，这只是一个简短的回答。如果您需要更多信息，请发表评论，我会尽力扩展我的答案。