现在我们所有的系统都在一个传统的数据中心和传统的网络拓扑中。
我们计划迁移到 AWS，并在此过程中试图弄清楚如何实施我们的开发/测试/暂存/生产环境。我们应该吗：
1) 每个环境都有单独的 AWS 账户并使用合并计费？
2) 为每个环境创建单独的 VPC？- 请记住，我们可能需要多个区域/可用区来实现高可用性
3) 每个环境分离子网。或者我们应该为 Web 服务器/数据库服务器/管理类型服务器使用单独的子网？
我已经进行了一些谷歌搜索和阅读，但找不到任何明确的答案。似乎有很多不同的意见。请注意，我发现的大多数帖子不一定是有安全意识的人，所以我想我会在这里问。
其他人在使用 AWS 为云安全、网络拓扑和网络安全分层方法做些什么。
根据我们面向 AWS DevSecOps 的经验，1、2 和 3的混合可能是最有效的解决方案。
1)Have separate AWS accounts for each environment and use consolidated billing?
完全同意这是我们在 2017 年初从 AWS 支持部门获得的官方建议。将user-mgmt、security-audit-logging 和 shared-resources-services 以及 project-app账户分开的多账户架构将减少最大可能的 爆炸半径。
考虑以下 AWS 官方链接作为参考，因为 AWS 组织结构将取决于您的具体要求。
对于它的自动化，您将有一些替代方案，例如 AWS python SDK + bash 或 terraform（请考虑，如果您的组织少于 10 个帐户从 AWS Web 控制台管理它，这将非常简单）。然而，保持 id 一个 IaC（从我们的角度来看，使用 Terraform 或 AWS Cloud Formation 的 InfraAsCode 方法几乎是必须做的）。
2)Create separate VPCs per environment? - keep in mind we'll likely want multiple regions/availability zones for High Availability
由于我们假设我们要实施多账户 AWS 组织方法，那么每个账户 x 环境将至少有 1 个 VCP。在我们的案例中，在某个区域拥有一个 VPC 就足够了，因为对于高可用性、自我修复、冗余和弹性，我们使用多可用性区域 (multi-az) 配置（例如：us-east-1a、us- east-1b 和 us-east-1c，将在 3) 中扩展。请记住选择您的区域评估网络性能（延迟 - https://www.cloudping.info/）和成本（N.Virginia-us-east-1、Ohio-us-east-2、Orego-us-west -2 - https://www.concurrencylabs.com/blog/choose-your-aws-region-wisely/）。
发布步骤要牢记：
让我们考虑以下信息来评估是否还需要多区域。正如官方文档中定义的那样 -> https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html Amazon EC2 托管在全球多个位置。这些位置由区域和可用区组成。每个区域都是一个单独的地理区域。每个区域都有多个独立的位置，称为可用区
因此，对于在一个区域但在隔离位置（数据中心）内托管我们的 HA 应用程序，参考每个区域的 AWS SLA 就足够了：
如果由于合规性框架，您仍然需要多区域主动-主动方法：然后通过构建多区域应用程序并在正常生产状态下使用 DNS 在它们之间进行平衡，您可以调整 DNS 权重并将所有流量发送到 AWS 区域可用，这甚至可以使用 Route53 或其他提供健康检查机制和负载平衡的 DNS 服务自动执行。对于多区域架构，请考虑：https : //aws.amazon.com/blogs/aws/latency-based-multi-region-routing-now-available-for-aws/
参考 SLA 链接：
3)Separate subnets per environment. Or should we use separate subnets for web severs/database servers/management-administration type servers?为生产级环境获得所需的多可用区部署至少 3 个私有子网（通过冗余 AWS Nat-GW - 其中至少 2 个位于不同的可用区）和 3 个公共子网（通过 Internet GW）当然每个在一个单独的 AZ。对于 Dev/Qa/Stg（可以合并到一个帐户中以提高成本效率），并且在不同的 AZ 中至少有 2 个私有子网和 2 个公共子网。这适用于 EC2 和 RDS ( https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html )，建议用于 S3 版本控制和多区域复制
基于之前介绍的内容，让我们介绍一下我们的参考架构。
AWS org 多账户架构
安全 - 杂项
注意1：请记住至少使用 AWS 加密来加密每个静态服务存储 - https://docs.aws.amazon.com/aws-technical-content/latest/efs-encrypted-file-systems/encryption-of-data- at-rest.html
注 2： AWS 架构完善的框架的 5 个支柱 - https://aws.amazon.com/blogs/apn/the-5-pillars-of-the-aws-well-architected-framework/
注 3： AWS 标记策略 - https://aws.amazon.com/answers/account-management/aws-tagging-strategies/
注 4：防止 AWS 机密进入 git 存储库 - https://www.binbash.com.ar/archives/1038
戴上我的安全帽，我认为您的最佳解决方案是使用＃1。不便因素肯定存在，但 2 和 3 会造成单点故障 - 如果单个 AWS 授权用户的凭证被泄露，所有环境都会受到影响。