3. AWS Organizations组织架构设计
当企业从“几个独立 AWS 账户”走向“可治理的多账户体系”时，AWS Organizations 是承载治理逻辑的骨架。它本身不部署业务资源，而是定义账户之间的归属关系、策略作用范围以及集中管理的边界。理解 Organizations 的关键，不是记住控制台按钮，而是理解“组织 → 根 → OU → 成员账户”这条层级链，以及策略如何沿这条链向下继承。
组织创建时，第一个账户自动成为管理账户（Management Account），同时系统会创建一个隐含的根（Root）。根不是一个 OU，而是整棵组织树的起点，所有 OU 和未归入 OU 的成员账户都直接挂在根下。管理账户承担组织级操作：邀请成员、创建 OU、挂载 SCP、启用可信访问、配置集中账单等。它不应承载业务负载，因为 SCP 对管理账户本身不生效，且管理账户一旦被入侵，影响面覆盖整个组织。
根 OU 规划：先定“不可协商的边界”
根 OU 规划的本质，是决定哪些策略必须作用于全组织。根是 SCP 继承链的顶端，挂在根上的 SCP 会作用于除管理账户外的所有成员账户。因此根层只应放“全组织都必须遵守”的护栏，例如：禁止关闭 CloudTrail、禁止删除集中日志桶、禁止使用未批准的 Region、禁止创建根访问密钥。这些策略一旦挂到根，任何 OU 和账户都无法绕过。
一个常见的规划误区是把业务分类直接建在根下，例如“生产 OU、测试 OU、开发 OU”。这在初期可用，但当组织扩展到多业务线、多合规域时，根下会迅速膨胀。更稳妥的做法是根下先按治理职能分层，例如：
- Security OU：集中日志、审计、安全工具账户，SCP 最严格，通常禁止业务部署。
- Infrastructure OU：网络、共享服务、CI/CD 账户，允许受控的基础设施操作。
- Workloads OU：按业务线或环境再分子 OU，承载实际业务。
- Sandbox OU：实验账户，SCP 相对宽松，但必须限制成本与敏感数据。
- Suspended OU：待回收或已冻结账户，SCP 禁止一切操作，仅保留审计读取。
多 OU 分层：继承链与策略叠加
OU 可以嵌套，形成多层结构。SCP 的继承规则是：从根到目标账户路径上的每一层 SCP 都会生效，且取并集后取交集——即所有层级的允许集合必须同时满足，任一层的拒绝都会生效。这意味着越靠近账户的 OU，越适合放“更细的例外或收紧”，而不是放“放宽”。因为下层无法覆盖上层的拒绝。
举例：根层 SCP 拒绝所有非批准 Region；Workloads OU 允许 us-east-1 和 ap-southeast-1；某业务子 OU 只允许 ap-southeast-1。最终该子 OU 下账户只能在 ap-southeast-1 操作。若某账户需要临时使用 us-east-1，不能通过在下层加 Allow 解决，只能调整上层策略或将该账户移出该子 OU。这是设计时必须提前想清楚的“策略不可逆”特性。
成员账户邀请：从创建到加入
成员账户有两种进入方式：一是通过 Organizations 直接创建新账户，二是邀请已有账户加入。邀请流程需要目标账户接受，且目标账户必须满足：不是其他组织的成员、没有未结清的组织关系、具备接受邀请的权限。实际操作中，管理账户在控制台或 CLI 发起邀请后，目标账户会在其 Organizations 页面看到邀请，接受后即成为成员。
使用 CLI 时，典型命令如下：
# 在管理账户中发起邀请
aws organizations invite-account-to-organization \
--target '{"Type": "EMAIL", "Id": "security-admin@example.com"}' \
--notes "Security OU 集中日志账户"
# 在目标账户中查看并接受邀请
aws organizations list-handshakes-for-account
aws organizations accept-handshake --handshake-id h-xxxxxxxx
邀请被接受后，账户会出现在根下。此时应立即将其移入规划好的 OU，否则它会直接继承根层 SCP。移动账户使用 aws organizations move-account --account-id <id> --source-parent-id <root-id> --destination-parent-id <ou-id>。移动是幂等的，但要注意：移动后 SCP 继承链立即变化，若目标 OU 有更严格的策略，账户内正在运行的操作可能被中断。
组织策略继承：SCP 之外还要看什么
Organizations 中不止 SCP 一种策略。实际治理中常同时使用：
- SCP：限制账户内可执行的最大权限集合，作用于 IAM 主体，不作用于资源策略和服务角色。
- 标签策略（Tag Policy）：强制资源标签键值规范，影响成本分摊与自动化。
- 备份策略：集中定义备份计划，自动应用到 OU 下账户的资源。
- AI 服务禁用策略：按 OU 控制可用的 AI/ML 服务范围。
这些策略的继承方式与 SCP 类似，但作用对象不同。设计 OU 时，应把“需要统一强制”的策略放在上层 OU，把“业务线差异化”的策略放在下层 OU。例如备份策略可以放在 Workloads OU，让所有业务账户自动获得基础备份；而 Prod 子 OU 再叠加更短的 RPO 策略。
一个可落地的初始 OU 结构示例
以下结构适合大多数中型企业起步，后续可按业务线在 Workloads 下继续拆分：
| 层级 | 名称 | 典型账户 | 关键策略 |
|---|---|---|---|
| 根 | Root | — | Region 限制、CloudTrail 保护、日志桶保护 |
| OU | Security | 日志归档、审计、安全工具 | 禁止业务部署、强制加密 |
| OU | Infrastructure | 网络、共享服务、CI/CD | 允许网络与 IaC 操作，限制数据面 |
| OU | Workloads / Prod | 支付、订单、用户 | 仅生产 Region、强制备份、禁止根密钥 |
| OU | Workloads / Dev | 开发、测试 | 允许两 Region、成本上限告警 |
| OU | Sandbox | 个人实验 | 禁止敏感数据、预算硬限制 |
| OU | Suspended | 待回收账户 | 拒绝一切操作，仅审计读取 |
落地顺序建议：先创建组织并确认管理账户不承载业务；再建立根层 SCP 护栏；然后创建上述 OU；接着邀请或创建成员账户并立即移入对应 OU；最后逐层挂载 SCP、标签策略和备份策略。每完成一层，用目标账户验证策略是否按预期生效，例如在 Sandbox 账户尝试创建非批准 Region 的 EC2，确认被拒绝；在 Prod 账户确认备份计划已自动关联。验证通过后再继续下一层，避免策略叠加后难以定位问题来源。