4. 目标平台架构设计

当迁移目标从“把几台服务器搬到云上”升级为“承载企业核心业务”时，架构设计的第一性问题就不再是选哪种实例，而是账户边界与网络边界如何划分。AWS的多账户模型不是管理上的洁癖，而是把安全隔离、成本归属、配额上限和故障爆炸半径同时收敛到可治理的单元里。本节围绕Landing Zone、Control Tower与组织单元（OU）三条主线，给出一套可落地的目标平台架构设计方法。

一、先定边界：多账户不是目的，隔离维度才是

设计多账户结构时，先回答“我要隔离什么”。常见隔离维度有四类：安全边界（生产与非生产、核心数据与普通应用）、成本归属（按业务线或成本中心）、配额与限流（避免单一账户的API限流影响全局）、合规与审计（日志、密钥、审计账户独立）。一个典型的中大型企业目标结构如下：

• 管理账户（Management）：仅用于账单、组织策略与Control Tower管理，不部署业务负载。
• 安全账户（Security/Log Archive）：集中存放CloudTrail、Config、GuardDuty、Security Hub的日志与告警。
• 基础设施账户（Infrastructure）：承载共享网络（Transit Gateway、DNS、目录服务）、CI/CD流水线与镜像仓库。
• 业务OU：按业务线划分，每个业务线内再分生产、预发、开发账户。
• 沙箱OU：用于实验与培训，施加最严格的预算与网络限制。

这里的关键判断是：账户数量不是越多越好。账户过多会带来跨账户角色、VPC对等和日志汇聚的复杂度。经验上，一个业务线3～5个账户、全组织20～60个账户是可管理的区间；超过后应优先考虑用标签和资源组做成本与权限细分，而不是继续切账户。

二、用Control Tower建立Landing Zone基线

Landing Zone的本质是一套“已经帮你配好安全与治理基线”的多账户环境。Control Tower在组织之上自动创建Log Archive和Audit账户，并部署三类关键能力：账户工厂（Account Factory）用于标准化开账户，防护栏（Guardrails）用于强制或检测合规，仪表盘用于查看合规状态。防护栏分两类：预防性（基于SCP，直接拒绝违规操作）和检测性（基于Config规则，发现后告警）。

落地时建议先启用一组最小防护栏，再逐步加严。例如：禁止关闭CloudTrail、禁止在非批准区域创建资源、禁止使用根用户访问密钥、要求S3桶开启加密与版本控制。下面是一段用于限制区域和禁止删除日志的SCP示例（示例参数，需按实际合规要求调整）：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideApprovedRegions",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["cn-north-1", "cn-northwest-1"]
        }
      }
    },
    {
      "Sid": "ProtectLogArchive",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "logs:DeleteLogGroup"
      ],
      "Resource": "*"
    }
  ]
}

注意：SCP只约束成员账户中的IAM主体，不影响管理账户本身，也不影响服务关联角色。因此日志账户的写入权限要通过资源策略和跨账户角色单独设计，不能只依赖SCP。

三、网络拓扑：集中出口、分段隔离、可观测

多账户网络的核心是“共享网络账户 + Transit Gateway + 分段子网”。推荐的目标拓扑是：在基础设施账户中创建Transit Gateway（TGW），各业务VPC通过Attachment接入；出网流量统一经过集中式出口VPC（Egress VPC）的NAT Gateway；跨VPC的东西向流量通过TGW路由表按OU隔离，生产与非生产默认不通。VPC内部按三层子网划分：公有子网放ALB/NAT，应用私有子网放计算，数据私有子网放RDS/ElastiCache，数据库子网不设默认路由。

可用区设计上，生产VPC至少跨2个AZ，关键负载跨3个AZ；每个AZ内的子网使用不重叠的CIDR，建议按“/16 VPC + /20 子网”规划，预留至少50%地址空间给未来扩容。跨账户访问数据库时，优先使用VPC Peering或TGW + 安全组引用，而不是把数据库暴露到公网。

四、OU与策略：把治理写进结构里

组织单元（OU）是SCP和Control Tower防护栏的作用域。推荐按“顶层按环境、下层按业务线”或“顶层按业务线、下层按环境”二选一，但不要混用。前者适合强合规行业（生产OU统一加严），后者适合多业务线独立运营。无论哪种，都应设置一个Sandbox OU和一个Suspended OU（用于隔离即将下线或存在风险的账户）。

策略设计遵循“默认拒绝、显式放行、最小权限”。SCP只做边界控制，不替代IAM策略；权限边界（Permissions Boundary）用于限制角色最大权限；标签策略（Tag Policy）强制成本与归属标签。一个可执行的标签规范示例：

五、可扩展与高可用的落地检查

架构设计完成后，用一组可验证的问题做自检：新业务上线是否能在1天内通过Account Factory开出标准账户？生产VPC是否跨至少2个AZ且数据库有只读副本或多可用区部署？跨账户访问是否全部通过角色和资源策略，而非长期密钥？日志是否已汇聚到Log Archive账户并设置保留策略？SCP是否覆盖了区域限制、根用户保护、日志防删除三条底线？如果这些问题都能给出明确答案，目标平台架构就具备了可扩展、高可用与安全的基础。