AWS Organizations：一个组织还是多个组织，这是个架构问题

当你在 AWS 上管理的账户从几个变成几十个、上百个，迟早要面对一个架构级决策：所有账户放在一个 AWS Organization 里，还是拆成多个？这个选择一旦落地，后续的安全策略、成本管理、合规边界都会被它锁死，改起来代价极高。本文把两种模式的利弊和适用场景掰开讲清楚，并给出可直接操作的实践示例。

单组织模式：集中管控的力量

把所有账户收进一个 Organization，最大的好处是治理半径短。

统一策略下发——一条 Service Control Policy（SCP）可以同时约束开发、测试、生产所有账户，不用逐个组织重复配置。比如禁止所有账户使用特定区域或特定服务：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenySpecificRegions",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "eu-west-1",
            "ap-northeast-1"
          ]
        }
      }
    }
  ]
}

这条 SCP 挂到 Organization Root 或某个 OU 上，下面所有账户立刻生效，零遗漏。

合并计费与折扣——单组织下所有账户的消费合并计算，Reserved Instance 和 Savings Plans 的覆盖率自动跨账户共享，能显著压低整体成本。多组织之间则无法共享这些折扣。

跨账户访问简化——一个 Organization 内可以统一配置 IAM 角色（如 OrganizationAccountAccessRole），管理账户能直接切换到任何成员账户，审计和应急响应不需要额外的信任链配置。

但单组织也有明显的副作用：爆炸半径大。一条写错的 SCP 可能同时卡死所有账户的关键操作；一个管理账户的泄露意味着整个组织沦陷。组织层级越深，OU 结构越复杂，策略的继承和叠加就越容易产生意料之外的组合效果。

多组织模式：隔离的代价与收益

拆成多个 Organization，核心动机是隔离。

合规与数据主权——不同业务线可能受不同监管约束。比如一条业务要求数据留在欧盟，另一条没有这个限制；或者收购来的公司有自己的合规框架，短期内无法对齐。多组织让每条业务在独立的治理边界内运行，互不干扰。

爆炸半径收敛——一个组织的 SCP 误配、管理账户事故，只影响该组织内的账户，不会波及另一条业务。对安全团队来说，这是最直接的防线。

自治与速度——大型企业里不同事业部对云平台的治理节奏不同。多组织允许各团队独立制定 OU 结构、标签策略、SCP 规则，不必在单一组织里反复协调折中。

代价同样清晰：

• 折扣损失——Savings Plans 和 RI 无法跨组织共享，每个组织独立达到用量门槛才能拿到最优价格。
• 重复建设——每个组织都要独立搭建 Control Tower、配置 Guardrails、设置审计管道，运维成本翻倍。
• 全局视角缺失——没有天然的地方看所有组织的统一成本大盘和安全态势，需要额外集成（如跨组织把 Cost Explorer 数据推到同一个数据仓库）。

决策框架：什么时候选哪条路

不是所有场景都黑白分明，但几个典型模式可以直接套用：

一个常见误区是"用 OU 就够了"。OU 是逻辑分组，但 SCP 的继承机制意味着上层策略会穿透到所有子 OU，你无法在同一个组织里让某个 OU 完全不受 Root SCP 的约束。如果需要真正的策略隔离，只有多组织能做到。

实践：用 CLI 快速验证你的组织结构

无论选哪种模式，先摸清现有账户分布再动手。以下命令可以直接运行（需要 AWS CLI 和管理账户的凭证）：

# 列出当前组织所有账户
aws organizations list-accounts --output table

# 查看现有 OU 结构（递历）
aws organizations list-organizational-units-for-parent \
  --parent-id r-xxxx \
  --output table

# 把一条 SCP 挂到指定 OU（替换 PolicyId 和 TargetId）
aws organizations attach-policy \
  --policy-id p-xxxx \
  --target-id ou-xxxx-yyyyyyy

# 验证某账户最终生效的 SCP 列表
aws organizations list-policies-for-target \
  --target-id 123456789012 \
  --filter SERVICE_CONTROL_POLICY \
  --output table

如果考虑多组织，可以先在一个新管理账户上初始化：

# 创建新组织（在新管理账户上执行）
aws organizations create-organization \
  --feature-set ALL

# 邀请已有账户加入新组织
aws organizations invite-account-to-organization \
  --target '{"Type":"ACCOUNT","Id":"123456789012"}' \
  --notes "迁移到独立组织以满足合规隔离要求"

被邀请账户需要在自身端接受邀请：

aws organizations accept-handshake \
  --handshake-id h-xxxx

迁移与折中：从多组织走向合并

收购场景下，新公司往往自带一个 Organization。短期保持多组织是务实选择，但长期合并能拿到折扣和治理收益。合并路径的关键步骤：

1. 在目标组织中创建新 OU，对应被收购公司的业务结构。
2. 在目标组织中创建新账户（不要直接迁移旧账户，账户无法跨组织转移），用 AWS CLI 批量创建：

# 在目标组织中批量创建账户
for email in dev-acquired@corp.com staging-acquired@corp.com prod-acquired@corp.com; do
  aws organizations create-account \
    --email "$email" \
    --account-name "acquired-${email%%@*}" \
    --tags '{"Key":"Source","Value":"AcquiredCompany"}'
done

1. 用 CloudFormation StackSets 把旧账户的资源配置复制到新账户。
2. 切换 DNS 和流量，逐步退役旧组织中的账户。
3. 确认旧组织所有账户退出后，删除旧组织。

整个过程可能持续数月，但每一步都可以独立验证，不会中断业务。

最后的检查清单

在做最终决定前，逐项确认：

• [ ] 所有业务线的合规要求是否一致？不一致的必须隔离。
• [ ] 账户总数是否在单组织的可管理范围内（通常 < 200 OU 层级不失控）？
• [ ] 是否需要跨业务线共享 RI / Savings Plans？需要则倾向单组织。
• [ ] 管理账户的安全控制是否到位（MFA、受限访问、CloudTrail 全覆盖）？单组织下管理账户是最高价值目标。
• [ ] 是否有并购计划？有则预留多组织过渡空间。
• [ ] 全局成本和安全的可视化管道是否已建好？多组织下这是额外工程。

选单组织还是多组织，本质是在治理效率和隔离安全之间做权衡。没有万能答案，但上面的框架和命令应该能帮你把决策从"凭感觉"变成"有依据"。