2. 组织单元与账号结构设计
在 AWS Organizations 中，组织单元（OU）不是简单的文件夹，而是策略继承、权限边界和网络隔离的载体。OU 层级一旦确定，后续的 SCP、标签策略、备份策略、集中日志和网络共享都会围绕它展开。因此，OU 设计的目标不是“把账号分门别类”，而是让安全控制、合规边界和网络拓扑能够以最少的例外规则覆盖最多的账号。
OU 层级的设计原则
OU 层级应围绕“控制差异”而非“组织架构”来划分。如果两个账号需要完全相同的 SCP、相同的网络出口和相同的日志归属，它们就应该放在同一个 OU 下；如果它们在合规等级、数据敏感度或网络连通性上存在差异，就应分属不同 OU。常见的顶层划分方式有三种：按环境（生产、预生产、开发）、按业务线（支付、风控、营销）、按安全等级（核心、一般、沙箱）。实际落地时通常采用组合方式，例如顶层按安全等级划分，第二层再按环境细分。
一个可参考的四层结构如下：根（Root）下先分出 Security、Infrastructure、Workloads、Sandbox 四个一级 OU。Security 下挂日志归档账号和安全工具账号；Infrastructure 下挂网络枢纽账号、共享服务账号和 DNS 账号；Workloads 下按业务线分二级 OU，再按生产/非生产分三级 OU；Sandbox 下挂实验账号，并施加最严格的 SCP 限制。这种结构的核心逻辑是：安全与基础设施账号独立于业务账号，避免业务侧的策略变更影响集中管控能力。
账号命名与标签策略
账号命名应同时满足“人可读”和“机器可解析”两个要求。推荐格式为 <org>-<ou-path>-<workload>-<env>-<region>，例如 acme-security-logarchive-prod-cn 或 acme-workloads-payment-prod-cn。命名中的每一段都应与 OU 路径或标签值保持一致，这样在 CloudTrail 日志、Cost Explorer 账单和 Config 聚合器中都能快速定位账号归属。账号邮箱建议使用专用邮箱别名，如 aws+acme-payment-prod@example.com，避免使用个人邮箱导致账号无法交接。
标签策略是 OU 设计的延伸。AWS Organizations 支持在 OU 级别定义标签策略，强制账号创建资源时携带指定标签键。建议至少强制以下四个标签：CostCenter、Environment、Owner、DataClass。其中 DataClass 可取值 public、internal、confidential、restricted，并与 OU 的安全等级对应。标签策略可以设置为“强制”或“建议”，对于生产 OU 应使用强制模式，对于 Sandbox 可以使用建议模式以降低摩擦。
账号工厂流程
账号工厂的核心目标是将“创建账号”从手工操作转变为可审计、可重复的自动化流程。一个完整的账号工厂通常包含以下环节：
- 申请与审批：通过工单或内部平台提交账号申请，填写业务线、环境、数据等级、负责人和预算中心。审批流应包含安全团队对数据等级的确认。
- 账号创建：使用 AWS Organizations 的
CreateAccountAPI 或 Control Tower 的 Account Factory 创建账号。创建时指定账号名称、邮箱和 OU 归属。 - OU 放置：账号创建后立即移动到目标 OU，触发该 OU 绑定的 SCP、标签策略和备份策略。
- 基线配置：通过 CloudFormation StackSets 或 Control Tower 的 Account Baseline 自动部署 IAM 角色、CloudTrail、Config、GuardDuty 和 VPC 基线。
- 网络接入：如果使用 Transit Gateway 或 VPC 共享，需在账号创建后自动接受共享附件，并将 VPC 关联到正确的路由表。
- 验证与交付：检查 SCP 是否生效、标签是否合规、日志是否已投递到集中日志账号，然后通知申请人。
以下是一个简化的账号工厂参数表示例，用于描述创建账号时需要输入的字段和校验规则：
| 字段 | 示例值 | 校验规则 |
|---|---|---|
| AccountName | acme-workloads-payment-prod-cn | 符合命名正则，且全局唯一 |
| aws+acme-payment-prod@example.com | 域名白名单，且未被其他账号使用 | |
| OUPath | Workloads/Payment/Prod | 必须存在于组织树中 |
| DataClass | confidential | 与 OU 安全等级匹配 |
| CostCenter | CC-1024 | 存在于财务成本中心列表 |
| Owner | payment-team@example.com | 有效的内部邮箱组 |
网络隔离与 OU 的对应关系
OU 层级还应与网络隔离策略对齐。例如，生产 OU 的账号默认不拥有公网入口，所有入站流量必须经过集中式入口 VPC 的负载均衡器；非生产 OU 可以拥有独立的互联网网关，但必须通过 NAT 网关统一出口；Sandbox OU 则完全禁止与生产网络对等连接。这种“OU 决定网络可达性”的映射关系，可以通过 AWS Network Manager 或 Transit Gateway 的路由表关联来实现。当新账号加入某个 OU 时，网络接入流程应自动将其 VPC 关联到该 OU 对应的路由表，从而继承正确的隔离策略。
最后需要强调的是，OU 结构不是一成不变的。随着业务重组或合规要求变化，账号可能需要在 OU 之间迁移。迁移前必须评估目标 OU 的 SCP 是否会导致现有工作负载中断，标签策略是否会拒绝已有资源，以及网络路由是否需要重新关联。建议在迁移前使用 AWS Organizations 的策略模拟器或 Config 规则进行预检，确认无阻断项后再执行移动操作。