运维管理

使用 AWS Control Tower 构建多账户环境 - 着陆区与护栏

通过着陆区的自动构建和护栏的策略应用，建立多账户环境的治理。介绍 Account Factory 的账户自动创建。

約 2 分で読めます

Control Tower 的角色

Control Tower 是自动构建和管理 AWS 多账户环境的服务。通过 Organizations 创建账户、通过 SCP 应用策略、通过 Config 监控合规、通过 CloudTrail 汇总日志等一系列设置作为着陆区自动完成。手动构建需要数天的多账户最佳实践配置，Control Tower 可在数小时内完成。着陆区以管理账户、日志归档账户、审计账户三个账户为基础，自动创建 Security OU 和 Sandbox OU。日志归档账户将所有账户的 CloudTrail 日志和 Config 日志集中到 S3 存储桶中，审计账户配置 Config Aggregator 和 SNS 通知。

护栏的设计

护栏分为必需、强烈推荐和可选三个级别，提供 400 多个。预防性护栏通过 SCP 实现，事前阻止被禁止的操作。例如"禁止变更日志归档账户的 CloudTrail 设置""区域限制（禁止在允许区域以外操作）"等。检测性护栏通过 Config 规则实现，检测不合规设置并通知。主动性护栏通过 CloudFormation Hook 在资源创建前验证合规性。对于组织特定的策略需求，可通过 SCP 或 CloudFormation Guard 规则定义自定义护栏，与托管护栏一样在 OU 级别应用。护栏在 OU 级别应用，可实现分级控制 - 对生产 OU 应用严格的预防性护栏，对开发 OU 仅应用检测性护栏。

Account Factory 与自定义

Account Factory 是与 Service Catalog 集成的账户创建功能。开发者自助申请账户后，数分钟内创建应用了标准化设置（VPC、子网、安全组、IAM 角色）的账户。Customizations for Control Tower（CfCT）可在账户创建时自动应用自定义 CloudFormation 模板，部署安全基线和监控设置。Account Factory Customization（AFC）同时支持 CloudFormation 和 Terraform 自定义模板，用于标准化安全基线和网络设置。Account Factory for Terraform（AFT）可通过 Terraform 工作流以 IaC 方式管理从账户创建到自定义的全过程，实现基于 GitOps 的账户预配置。 关于多账户管理的详细信息，可参考相关书籍 (Amazon)。

设计最佳实践与常见陷阱

Control Tower 的 OU 设计建议以工作负载类型（生产、预发布、开发）和安全边界（网络、共享服务、安全）为轴进行分层。典型配置为三层结构：Security OU（日志归档和审计）、Infrastructure OU（网络和共享服务）、Workloads OU（生产和非生产）。常见陷阱之一是着陆区的主区域在初始设置后无法更改，初始设置时的区域选择需要慎重考虑。另外，当护栏漂移检测标记为"不合规"时，需要从 Control Tower 控制面板执行修复操作；手动直接编辑 SCP 会导致状态不一致。避免在 Control Tower 管理的 OU 下的账户中直接修改 Organizations 的 SCP，务必通过 Control Tower 控制台或 API 进行管理。

Control Tower 的费用

Control Tower 本身不产生额外费用。成本是 Control Tower 内部使用的 AWS 服务（Organizations、Config、CloudTrail、S3、SNS）的使用费用。检测性护栏作为 Config 规则实现，产生 Config 的评估费用（每次评估约 0.003 美元）。护栏数量和账户数量增加时，Config 评估费用也相应增加。建议选择性启用所需的护栏，而非一律启用所有护栏来控制成本。对于大型组织（100 个以上账户），Config 评估成本可能达到每月数百美元，因此按 OU 优化护栏的适用范围非常重要。

与 Organizations 单独构建的比较

虽然可以直接使用 Organizations 和 SCP 构建多账户环境，但 Control Tower 大幅简化了这一过程。仅使用 Organizations 时，需要手动配置 CloudTrail 的多账户日志聚合、Config Aggregator 设置、日志桶访问策略、账户创建时的基线应用。Control Tower 自动化了所有这些操作，并通过漂移检测持续监控治理一致性。但 Control Tower 也有局限性：支持的区域组合有限制、嵌套 OU 层级有限制、着陆区更新时可能出现停机。如果组织已经拥有通过 Terraform 或 CDK 完全管理 SCP 和 Config 规则的自定义治理框架，不使用 Control Tower 的直接 Organizations 管理可能提供更大的灵活性。

总结

Control Tower 是自动化多账户环境设置和治理的服务。着陆区自动构建最佳实践配置，护栏强制安全策略，Account Factory 标准化账户创建。通过将分层 OU 设计与分级护栏应用相结合，可以在安全性和开发者敏捷性之间取得平衡。是组织 AWS 使用扩大时不可或缺的基础。

相关服务

AWS Control Tower自动化多账户环境设置和治理的服务AWS Organizations集中管理多个 AWS 账户的服务AWS Config记录和评估 AWS 资源配置变更并持续监控合规性的服务

相关文章

用 AWS Service Catalog 实现 IT 治理 - 已批准产品的标准化与自助服务将 IT 部门批准的 CloudFormation 模板编入目录，通过启动约束和模板约束安全地为终端用户提供自助服务。使用 AWS Config 实现持续合规监控 - 规则评估与自动修复详解 AWS Config 的资源配置记录、Config 规则的合规评估以及自动修复操作的设置。使用 AWS Organizations 实现多账户管理 - OU 设计与 SCP 治理通过 OU 层级设计和 SCP 访问控制建立多账户环境的治理。同时介绍统一计费的成本管理。

本主题的更多内容

AWS 内部时间同步机制 - Amazon Time Sync Service 与闰秒平滑处理的设计解析 AWS 自主运营的 Amazon Time Sync Service 的工作原理、基于 GPS 和原子钟的高精度时间源、通过平滑处理吸收闰秒的设计决策，以及分布式系统中时间同步的重要性。使用 AWS AppFabric 集中 SaaS 审计日志 - OCSF 标准化与 Security Lake 集成详解 AppFabric 收集 SaaS 应用审计日志、转换为 OCSF 格式标准化，以及构建分析管道的方法。使用 AWS AppConfig 实现功能开关 - 安全的配置部署与回滚通过 Linear 和 Exponential 策略对独立于代码部署的配置变更进行渐进式发布。利用 CloudWatch 告警联动的自动回滚确保安全性。架构评审 - 使用 AWS Well-Architected Tool 系统化评估工作负载详解使用 AWS Well-Architected Tool 进行工作负载架构评审。介绍基于 6 大支柱的评估、改进计划的制定以及自定义透镜的应用。审计日志的设计与运维 - 使用 CloudTrail 完整记录 API 活动详解使用 AWS CloudTrail 设计审计日志的方法，介绍 API 活动记录、S3 长期保存以及与 Config 联动实现合规应对。从 AWS 故障报告 (COE) 中学习分布式系统的教训 - 历次大规模故障如何改变了设计原则从 AWS 公开的 Correction of Errors (COE) 和故障报告中，解析 S3 故障、us-east-1 DNS 故障、Kinesis 故障等历次大规模事件的根本原因，以及它们如何改变了 AWS 的设计原则。标签设计决定运维 - AWS 资源标签策略的冷知识与实践命名规则解析 AWS 资源标签不仅是简单标记，更是成本分配、访问控制、自动化基础的原因，以及标签键命名规则、50 个上限的使用方法、标签策略的治理。AWS 服务配额为何存在 - 保护共享基础设施的多租户设计解析 AWS 服务配额（原服务限制）不仅是简单的约束，而是在多租户环境中保护其他客户的设计，从嘈杂邻居问题、软限制与硬限制的区别、配额提升申请的内部机制进行说明。

相似的文章与服务

AWS Control Tower自动化多账户 AWS 环境的设置和治理，统一管理安全与合规基线的服务AWS 多账户治理的设计能力 - Organizations、Control Tower、SCP 实现的组织治理解析以 AWS Organizations、Control Tower、SCP（Service Control Policies）为核心的多账户治理机制，与 Azure Management Groups 进行比较，阐述企业治理设计能力的差异。使用 AWS Organizations 实现多账户管理 - OU 设计与 SCP 治理通过 OU 层级设计和 SCP 访问控制建立多账户环境的治理。同时介绍统一计费的成本管理。