4. AWS Control Tower落地实践

Control Tower 的价值不在于“多了一个控制台页面”，而在于把多账号 AWS 环境中最容易失控的三件事——账户创建、合规基线、集中可见性——收敛成一套可重复的机制。落地时，建议把它理解为一条从组织根到成员账户的“治理信号链”：OU 决定策略作用范围，Guardrails 决定允许与禁止的边界，Account Factory 决定新账户以什么基线出生，Dashboard 则把偏离基线的状态暴露出来。

一、Landing Zone 的搭建顺序

Control Tower 的 Landing Zone 不是“点一下完成”的黑盒，它会在管理账户中创建一组核心资源：AWS Organizations 组织单元、CloudTrail 组织跟踪、AWS Config 聚合器、IAM Identity Center（原 SSO）以及日志归档账户。搭建前需要先确认三件事：管理账户不能是已有成员账户；邮箱不能与现有 AWS 账户重复；区域选择要覆盖业务实际使用的 Region，因为 Guardrails 和 Config 规则是按区域生效的。

实际操作中，登录 Control Tower 控制台后选择 Set up landing zone，指定主区域（例如 ap-southeast-1）和附加区域。系统会自动创建两个共享账户：Audit 用于集中查看日志与合规，Log Archive 用于存放 CloudTrail 和 Config 的归档数据。这两个账户是后续所有合规判断的数据来源，不能随意删除或改 OU。

二、Guardrails：预防、检测与主动预检

Guardrails 是 Control Tower 对合规基线的具体表达，分为三类：Preventive 通过 SCP 直接拒绝违规 API 调用；Detective 通过 AWS Config 规则检测资源是否符合要求；Proactive 通过 CloudFormation Hook 在资源创建前预检。落地时不要一次性启用全部 Guardrails，而应按 OU 分层启用。

例如，对 Prod OU 启用强约束：禁止删除 CloudTrail、禁止关闭 Config Recorder、禁止创建未加密的 S3 桶、禁止开放 0.0.0.0/0 的 SSH。对 Sandbox OU 只保留基础检测类 Guardrail，允许开发者自由试验。启用方式是在 Control Tower 控制台的 Guardrails 页面选择目标 OU，点击 Enable guardrail，系统会自动把 SCP 绑定到该 OU，并把 Config 规则部署到 OU 内所有账户。

判断 Guardrail 是否真正生效，不能只看控制台显示“Enabled”。应进入目标账户，尝试执行一条被禁止的操作，例如删除 CloudTrail 跟踪，观察是否返回 AccessDenied；再进入 Config 控制台，确认对应规则状态为 COMPLIANT。如果 SCP 已绑定但操作仍成功，通常是账户不在该 OU，或 SCP 被更高层级的策略覆盖。

三、Account Factory：把账户创建变成可重复的供给

Account Factory 解决的是“新账户怎么来”的问题。原生 Account Factory 通过 Control Tower 控制台或 Service Catalog 创建账户，输入账户名称、邮箱、SSO 用户、OU 和标签，系统会自动完成账户创建、OU 加入、基线部署。对于需要批量、版本化、可审计的团队，建议使用 Account Factory for Terraform（AFT），把账户供给写成 Terraform 代码。

AFT 的核心结构是：一个 aft-management 账户承载 AFT 管道，一个 aft-account-request 仓库存放账户申请，一个 aft-account-customizations 仓库存放账户级基线。开发者提交一个 Terraform 文件即可申请账户，例如：

module "prod_app_01" {
  source = "./modules/aft-account-request"

  control_tower_parameters = {
    AccountEmail              = "prod-app-01@example.com"
    AccountName               = "prod-app-01"
    ManagedOrganizationalUnit = "Prod"
    SSOUserEmail              = "platform-admin@example.com"
    SSOUserFirstName          = "Platform"
    SSOUserLastName           = "Admin"
  }

  account_tags = {
    Environment = "Prod"
    Owner       = "platform-team"
    CostCenter  = "CC-1024"
  }

  customizations = {
    account_name = "prod-app-01"
  }
}

提交后 AFT 管道会自动执行：创建账户 → 加入 Prod OU → 应用 SCP 与 Config 规则 → 执行账户级自定义（例如创建标准 VPC、IAM 角色、日志转发）。判断供给是否成功，应检查 AFT 管道状态是否为 Succeeded，并在 Control Tower Dashboard 中确认新账户出现在正确 OU 且无红色告警。

四、Dashboard 与合规基线的持续验证

Control Tower Dashboard 提供组织级视图：按 OU 展示账户数量、Guardrail 合规状态、Config 规则违规计数。它适合做日常巡检，但不能替代细粒度排查。建议把 Dashboard 与以下检查结合：

• 每周检查 Non-compliant guardrails 列表，确认是否有账户因手动修改而偏离基线。
• 对新增账户，确认其 CloudTrail 日志已投递到 Log Archive 账户的 S3 桶。
• 对 Prod OU，确认 SCP 中禁止删除 CloudTrail 的策略仍处于绑定状态。
• 对 Sandbox OU，确认没有误启用会阻断实验的强约束 Guardrail。

五、落地检查清单

Control Tower 的落地本质是把“合规基线”从文档变成可执行、可检测、可供给的机制。OU 决定边界，Guardrails 决定约束，Account Factory 决定出生方式，Dashboard 决定可见性。四者形成闭环后，平台团队才能在不牺牲开发者自助效率的前提下，持续守住多账号环境的安全与合规底线。