管理 AWS 多账号安全架构通常有两种方式：传统的手动 Terraform 部署和 AWS 推荐的 Control Tower。本文从实践中总结两者的核心差异。
两种方式概述
传统手动方式
通过 Terraform 自行管理所有资源，包括 AWS Organizations、OU 结构、账号创建、SCP、日志审计等全部基础设施。灵活性最高，但需要从零搭建。
Control Tower 方式
Control Tower 作为托管服务，自动化创建 Landing Zone（组织、默认 OU、日志归档/审计账号、基础 CloudTrail、IAM Identity Center）。在此基础上再通过 Terraform 部署自定义安全服务。
覆盖范围对比
| 能力 | 传统手动 | Control Tower |
|---|---|---|
| AWS Organization 创建 | Terraform 管理 | CT 自动创建 |
| OU 结构 | Terraform 自由定义 | CT 管理，Terraform 只能读取 |
| 成员账号创建 | Terraform 或手动 | Account Factory |
| 基础 CloudTrail | 手动配置 | 自动创建 |
| 审计 S3 桶 | 手动创建，名称自定 | CT 自动创建，名称固定 |
| IAM Identity Center | 手动启用 | 自动集成 |
| GuardRails（强/建议/可选） | 需自行实现 | 开箱即用 |
| AWS Config 基础规则 | 手动配置 | 自动配置 |
| SCP | Terraform 管理 | Terraform 管理（不受 CT 限制） |
| 安全服务（GuardDuty/Security Hub 等） | Terraform 管理 | Terraform 管理 |
| 工作负载（VPC/EC2/ALB） | Terraform 管理 | Terraform 管理 |
Control Tower 的优势
快速落地最佳实践 Landing Zone（基础 CloudTrail + 审计 S3 + Config 规则 + IAM Identity Center）一键部署，无需手动拼装各组件。
内置治理能力 GuardRails 覆盖 S3 加密、公开访问限制、CloudTrail 启用等常见安全基线，分强/建议/可选三级，开箱即用。
账号生命周期管理 Account Factory 提供标准化的账号创建流程，新增账号自动加入对应 OU 并继承 GuardRails。
降低配置漂移风险 CT 持续检测 Landing Zone 配置漂移（如手动改动了 CT 管理的 S3 桶策略），通过 Console 即可修复。
迁移/实施中的注意点
1. OU 管理被 CT 锁定
CT 接管后不能使用 Terraform 的 aws_organizations_organizational_unit 创建或管理 OU。OU 的创建和调整必须在 CT Console 操作或通过 AWS API（需 CT 授权）。
Terraform 中需要将 Organization 模块的 resource 改为 data source：
1
2
3
4
5
# 之前（手动方式）
resource "aws_organizations_organization" "this" { ... }
# 之后（CT 方式）
data "aws_organizations_organization" "this" { }
2. 审计桶名称不一致
CT 自动创建的审计 S3 桶名称遵循固定格式（如 aws-controltower-logs-xxxx-xxxx），和手动定义的不同。如果 SCP 中有针对审计桶的 aws:ResourceArn 条件，需要更新桶名变量。
3. Terraform 代码需适配
大部分安全服务模块（SCP、GuardDuty、Security Hub、Config、Inspector、Cross-Account IAM 等）可以直接复用，只需调整 Organization 相关的 resource→data source 迁移。
4. RCP 兼容性
RCP（Resource Control Policy）在 CT 环境下可能和 IAM Identity Center 冲突，需根据实际情况权衡是否启用。
5. Landing Zone 漂移检测
CT 管理的资源（如审计 S3 桶策略、CloudTrail 配置）如果被外部 Terraform 或其他工具意外修改，CT 会报告漂移。运维时需注意区分哪些资源归 CT 管、哪些归 Terraform 管。
建议
| 场景 | 推荐方式 |
|---|---|
| 新建多账号环境 | Control Tower + Terraform 补充 |
| 已有手动部署，账号少（< 5） | 评估迁移成本，可考虑继续手动 |
| 已有手动部署，账号多 | 逐步迁移到 CT，注意 OU 和审计桶的适配 |
| 需要完全自定义 OU 和账号流程 | 手动方式更灵活 |
Control Tower 不是银弹——它在 Organizations 层做了限制以保障治理一致性，适合”标准化优先”的场景。如果团队需要极高的 OU 灵活度或不希望被 CT 约束，手动方式仍然是合理的选择。