AWS Landing Zone 架构图：用 Organizations 和 Control Tower 搭建多账户环境

所有东西都放在一个 AWS 账户里，在出问题之前一直都行得通。一段测试脚本删掉了生产环境的存储桶。财务没法按团队拆分账单。审计人员问谁能修改审计日志，诚实的回答是“任何有管理员权限的人”。Landing Zone（着陆区）是在工作负载进驻之前打好的多账户基础：每个新账户都会继承的账户结构、身份、护栏、日志和网络。

本文借助一张架构图，逐步讲解 Landing Zone 的设计：为什么要用多个账户、推荐的组织单位、核心账户、基于服务控制策略（SCP）、资源控制策略（RCP）和声明式策略的护栏、身份、集中日志与安全工具、网络，以及如何用 Control Tower（包括 Landing Zone 4.0 的变化）或 Terraform 来搭建。

为什么要用多个账户

AWS 账户是 AWS 提供的最强隔离边界。IAM 权限、服务配额、成本和大多数故障都止步于账户边界。拆分账户能带来：

• 有限的影响范围。 沙盒里的一次失误或一份泄露的凭证碰不到生产环境。
• 清晰的归属和计费，可以按团队、应用或环境划分。
• 更简单的权限。 不必在一个账户里堆满基于标签的条件，每个账户只授予其团队需要的访问权限。
• 相互独立的配额，一个团队的压测不会耗尽另一个团队的限额。

代价是协调：身份、日志、护栏和网络必须跨几十个账户协同工作。Landing Zone 提供的正是这种协调。

结构：组织单位

AWS Organizations 把账户分组到组织单位（OU）中，附加到某个 OU 的策略会作用于其下的每个账户。AWS 关于组织 AWS 环境的白皮书推荐了一组起步用的 OU：

尽早把 Workloads 拆分成 Prod 和 Non-prod 两个子 OU。两者的护栏不同，事后再迁移账户会很痛苦。再添加一个 Suspended OU，附加拒绝一切的策略，用来存放等待关闭的账户。

管理账户

管理账户拥有组织、合并账单和 Control Tower。不要在里面放工作负载，原因很关键：正如 Organizations 文档所说，SCP 不会影响管理账户中的用户或角色。你部署在那里的任何东西都不受护栏约束，所以要让它的用户和资源尽可能少。

核心账户

• Log Archive。 在 S3 中接收组织的 CloudTrail 跟踪和 AWS Config 历史记录。几乎没有人拥有写入或删除权限；可以考虑启用 S3 Object Lock，让管理员也无法篡改日志。
• Security Tooling，也叫 Audit。它是 GuardDuty、Security Hub、IAM Access Analyzer 和 AWS Config 聚合器的委派管理员，安全团队无需访问管理账户，就能在一个地方看到所有账户。
• Network。 拥有 Transit Gateway、到数据中心的专线连接、DNS 解析器和 IP 地址管理，并通过 AWS Resource Access Manager 共享给工作负载账户。
• Shared Services。 CI/CD、制品仓库以及许多团队都会用到的其他工具。

护栏：SCP、RCP 和声明式策略

Organizations 提供多种策略类型，它们回答的是不同的问题：

策略只做限制，从不授予权限。先从一份简短、价值高的护栏清单开始：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeavingOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    },
    {
      "Sid": "ProtectCloudTrail",
      "Effect": "Deny",
      "Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail", "cloudtrail:UpdateTrail"],
      "Resource": "*"
    }
  ]
}

区域限制很受欢迎，也很容易写错，因为 IAM 这类全局服务必须保持允许。每条新策略在附加到 Workloads 之前，都要先在一个只包含一个代表性账户的预发布 OU 上测试。

Control Tower 把护栏打包成三类控制：用 SCP 和 RCP 实现的预防性控制，用 AWS Config 规则实现的检测性控制，以及在 CloudFormation 创建资源之前进行检查的主动控制。

身份

人员永远不应该在工作负载账户中拥有带长期密钥的 IAM 用户。把 IAM Identity Center 连接到企业身份提供商，用 SCIM 预置用户和组，再通过按账户分配给组的权限集授予访问权限：例如，开发者在 Non-prod 中拥有高级用户权限，在 Prod 中只有只读权限。

保留两个带硬件 MFA 的应急（break-glass）身份，离线保管并进行监控。至于根用户，IAM 现在可以集中管理成员账户的根访问权限，这项功能于 2024 年 11 月推出。你可以彻底删除成员账户的根凭证，并在一个集中的位置完成少数只有根用户才能做的操作。

日志与检测

1. CloudTrail 中的组织跟踪把每个账户、每个区域的 API 活动记录到 Log Archive 账户。
2. AWS Config 在所有位置记录资源配置，聚合器放在 Security Tooling 中。
3. 在整个组织启用 GuardDuty 和 Security Hub，并以 Security Tooling 作为委派管理员，这样新账户会被自动覆盖。
4. 检测结果发送到你的 SIEM 系统或值班工具。

网络

工作负载账户拥有自己的 VPC，但不拥有自己的连接。Network 账户提供通过 Resource Access Manager 共享的 Transit Gateway、集中的出口与流量检查、云和数据中心之间的 DNS 解析，以及一份 IP 地址规划。这份规划最好用 Amazon VPC IP Address Manager 管理，确保任意两个 VPC 都不重叠。每个工作负载 VPC 内部的内容见 AWS VPC 架构图，跨区域扩展这套设计见 AWS 多区域架构图。

搭建：Control Tower 还是 Terraform

AWS Control Tower 会设置组织、核心账户、组织跟踪、Config 和一个控制目录，并提供用于创建新账户的 Account Factory。根据 Control Tower 发布说明，2025 年 11 月 17 日发布的 Landing Zone 4.0 版本让它灵活了很多：

• AWS Config、CloudTrail、安全角色和 AWS Backup 的集成变为可选。
• 不再强制要求 Security OU，你可以定义自己的 OU 结构。
• 最小化部署可以只使用 Organizations 集成和控制。
• Config 和 CloudTrail 获得专用资源，服务关联的 Config 聚合器取代了旧的聚合方式。

使用 Terraform 的团队常把 Control Tower 与 Account Factory for Terraform（AFT）结合起来，AFT 从 Git 仓库预置和定制账户。自 2026 年 9 月起，AFT 可以以仅 plan 模式运行定制，在应用之前预览变更。也有团队完全用 Terraform 管理 Organizations，或者使用 Landing Zone Accelerator on AWS 解决方案。三种方式都可行；关键是账户创建要自动化、可重复。

账户开通

新账户应该一到手就能用：一次申请（通常是一个拉取请求）会在正确的 OU 中创建账户，应用基线配置（Identity Center 分配、预算和告警、接入 Transit Gateway 的 VPC、默认安全服务），然后交给团队。Organizations 默认把一个组织限制在 10 个账户，可以通过 Service Quotas 调整，所以要在需要之前就申请提额。

常见错误

• 把工作负载放在任何 SCP 都不生效的管理账户中。
• 只有一个扁平的 Workloads OU，导致生产和开发共用同一套护栏。
• 团队已经在某些假设之上完成构建后，才写出打破这些假设的护栏。
• 管理员可以修改的 Log Archive 账户。
• 手工创建的账户，每个都略有不同。

Landing Zone 架构图

这张图的读法如下：

• 顶部的管理账户持有组织和策略，它指向每个 OU 的连线代表护栏的附加关系。
• Security OU 包含接收所有账户日志的 Log Archive，以及管理 GuardDuty 和 Security Hub 的 Security Tooling。
• Infrastructure OU 包含 Network 账户（其 Transit Gateway 连接各工作负载 VPC）和用于 CI/CD 的 Shared Services。
• Workloads OU 把 Prod 和 Non-prod 账户分开；Sandbox OU 保持隔离。
• 右侧的 IAM Identity Center 通过权限集为人员授予访问权限。
• Markdown 块列出了起步阶段的护栏。

把账户结构画清楚

• 把 OU 画成容器，把账户放在里面；层级结构就是策略模型。
• 把管理账户单独画出来。 它在护栏之外，图上也应该表达这一点。
• 只画跨账户的流向：流向归档的日志、网络连接、委派管理和身份。
• 按职能而不是账户编号为账户命名。

背后的安全模型可参阅零信任架构图。如果你用代码管理基础设施，Terraform 架构图介绍了如何绘制由 Terraform 管理的环境。

在 Archboard 中构建

1. 使用 Google 或 GitHub 登录，并新建一张图。
2. 添加一个安全节点包中的 策略 节点表示管理账户，再添加一个 身份提供商 表示 IAM Identity Center。
3. 为各 OU 添加四个基础节点包中的 框架 节点：Security、Infrastructure、Workloads 和 Sandbox。
4. 在 Security 中添加一个云节点包中的 对象存储 节点表示 Log Archive，再添加一个 DevOps 节点包中的 告警 节点表示 Security Tooling。在 Infrastructure 中添加一个网络节点包中的 路由器 表示 Network 账户，再添加一个 DevOps 节点包中的 流水线 表示 Shared Services。
5. 为 Prod、Non-prod 和 Sandbox 账户添加云节点包中的 计算实例 节点。
6. 把管理账户连接到每个 OU，把各账户连接到 Log Archive，把 Network 账户连接到工作负载，再添加一个基础节点包中的 Markdown 块写上护栏。

这个示例共用 14 个图表节点，在 Free 套餐的限制之内。

常见问题

什么是 AWS Landing Zone？ 在工作负载迁入之前，按照你的安全和运维标准搭建好的多账户 AWS 环境，包括组织单位、核心账户、身份、护栏、日志和网络。

搭建 Landing Zone 必须用 AWS Control Tower 吗？ 不必。Control Tower 是托管的搭建方式，4.0 版本让它更加灵活。你也可以用 Terraform、Account Factory for Terraform 或 Landing Zone Accelerator 来管理 Organizations。

SCP 和 RCP 有什么区别？ SCP 限制成员账户中的主体能做什么。RCP 限制能对成员账户中的资源做什么，例如阻止存储桶被共享到组织之外。两者都不授予权限。

为什么管理账户应该保持为空？ SCP 不适用于管理账户中的用户和角色，所以放在那里的任何东西都在护栏之外。它还控制着账单和组织本身，是你最敏感的账户。

一个组织可以有多少个账户？ 默认 10 个。这个配额可以通过 Service Quotas 调整，而且只有管理账户才能申请提额。

免费开始 — 1 个席位，无需信用卡。