AWS Control Tower 4.0：全新视角审视 Landing Zones

Source: Dev.to

请提供您希望翻译的正文内容，我将为您翻译成简体中文并保留原有的格式、Markdown 语法以及技术术语。谢谢！

概览

AWS Control Tower 长期以来一直是基于 AWS 最佳实践实施治理的首选方案，尽管它在 SRE 和平台工程师之间可能是一个有争议的话题。随着 Landing Zone 4.0 的发布，Control Tower 向前迈出了一步，提供了在管理账户和组织单元（OUs）方面更大的灵活性。这使得全新（greenfield）和已有（brownfield）部署的采纳和运维都更加容易。总体而言，这对 AWS Control Tower 来说是一次积极的进展，尽管仍然存在一些挑战和改进空间。

注意： 本博客文章侧重于 AWS Control Tower 的发展方向，而非 4.0 版本的具体细节。

背景与动机

• 理想情况下，3.3 和 4.0 都能在更长的重叠期间内供新部署使用。
• AWS Control Tower 旨在通过 API 支持部署，但此次发布表明，更结构化的发布流程尚未完全就位，这让许多用户感到意外。

Source: …

Control Tower 4.0 的主要增强

1. 转向以 AWS Organizations 为中心的模型

• 4.0 之前：

  • 部署时必须指定 安全 OU 的名称。
  • Control Tower 会创建该 OU 并管理其中的 所有 账户。

• 现在（4.0）：

  • 可以直接在 Control Tower 中 使用已有的 OU。
  • Organizations 仍然掌控 OU 结构，可集成已有层级，保持命名约定和内部治理实践。

为何重要：

• 对已经存在多账户最佳实践的 棕地部署 特别有利。
• 现有 OU 和账户可以无缝集成，无需围绕传统的 Control Tower 清单和 Account Factory 模型进行重构。

2. 自动注册功能

• 功能说明：

  • 当账户被移动到 已在 Control Tower 中注册的 OU（使用 Control Tower 基线）时，会自动完成注册并配置所需资源。

• 收益：

  • 消除手动工作流或一次性流程来应用防护栏。
  • 从第一天起即强制执行基线安全、日志和合规控制，降低配置漂移。
  • 随着环境扩展（新账户、合并、收购），治理更加简化。

• 使用方法：

  1. 将 AWS 账户移动到 已注册的 Control Tower OU → 自动注册。
  2. 若要 取消注册，将账户移动到 未在 AWS Control Tower 中注册的 OU。

注意： 自动注册同样在 Landing Zone 3.3 中可用。您 不必 升级到 4.0 才能使用——只需在 Control Tower 设置中启用即可。

警告： 自动注册是 异步 过程。在 Web 控制台中移动账户后，请给 Control Tower 足够时间处理注册/取消注册。该功能尚未完美，但正在改进——请耐心等待。

3. 对 Account Factory 的依赖度降低

• 通过自动注册以及能够注册/重新注册整个 OU，Control Tower 不再要求每个 AWS 账户必须通过 Account Factory 进行供应。
• 这消除了为每个账户管理 Service Catalog 产品的需求，简化了工作流。

注意： AWS Config 仍 必须 由 Control Tower 创建。如果您将账户移动到 Control Tower，请确保这些账户 尚未 预先设置 Config。

4. 更自然的 AWS Organizations 工作流

注意： 自动化团队在注册/重新注册 OU 时仍需考虑 Service Catalog 组合访问。即使不使用 Account Factory，Control Tower 仍会对 IAM 角色/用户执行权限检查，以验证对 Service Catalog 组合的访问权限。

• 这种方式可以配合 CloudFormation StackSets、EventBridge 规则 以及其他与 AWS Organizations 关联的服务，在多个账户之间部署和管理资源，使多账户配置更顺畅、手动操作更少。

设置过程的更改

1. Pre‑staging of Organization resources 现在在部署之前是必需的。
2. Logging architecture 已更改：
   • Landing Zone 4.0 在 Log Archive 账户中使用 两个独立的存储桶——一个用于 CloudTrail，另一个用于 AWS Config。
   • 早期版本（3.3 及以下）使用 单个存储桶。
   • 客户必须更新所有引用日志的工具或流水线，以适应此拆分。
   • 原始存储桶仍继续用于 CloudTrail。

最终思考

These enhancements mark a continued shift in operational philosophy toward account vending. By embracing auto‑enrollment and OU registration, Control Tower offers greater flexibility while reducing reliance on Service Catalog and Account Factory.

While the changes bring many benefits, they also introduce new considerations (pre‑staging resources, split logging buckets, permission checks). Understanding and planning for these will help you get the most out of AWS Control Tower 4.0 and future releases.

升级概述

将 Control Tower 3.3 升级到 4.0 通常是顺畅的，只要您考虑下面列出的所有更改。由于需要完成多个异步操作，过程可能需要一些时间，因此请为供应和注册任务中的潜在延迟做好计划。

关键更改

• IAM 角色更新

  • AWSControlTowerCloudTrailRole 现在使用 AWS 管理的策略 而不是内联策略。
  • 即使权限相同，如果未附加管理策略，角色也会失败。

• 清单结构

  • Control Tower 为清单文件引入了 新的数据结构。
  • 清单现在是 可选的。
  • 使用 API 进行更新时，必须审查清单并将现有配置重新映射到新结构。

• 日志更改

  • 日志现在在清单中拆分为 两个独立对象。
  • CloudTrail 在升级期间保留 日志归档账户 中的旧存储桶。
  • AWS Config 在日志归档账户中获得 新的、独立的存储桶。

• 组织单元（OU）假设

  • 您不再需要指定要创建的 安全 OU 名称。
  • 假设 日志归档 和 审计 账户都位于 同一 OU 中。

• AWS Config 聚合器

  • 聚合器使用 AWS Organizations 的 受信任委派 进行设置。

• 基线版本管理

  • 升级后，许多基线从 版本 4.0 升至 5.0，这可能会令人困惑。
  • 您可能需要相应地更新基线。

• API 驱动的升级

  • 升级过程通过 Control Tower API 完全支持，可在以编程方式编排升级、注册和供应任务时降低复杂性并节省时间。
  • 使用 API 时，请确保 审查并重新映射 清单到新结构。

Control Tower 4.0 的优势

• 更大的灵活性，可在组织单元（OU）和账户结构中进行自定义。
• 更容易集成，适用于已有环境的部署。
• 更好地对齐 AWS Organizations 的原生功能。
• 通过以下方式提升运营和安全自动化：
  • StackSets
  • EventBridge
  • Controls Catalog
  • 其他面向组织的服务

别误会——虽然在发布过程中出现了一些问题，仍有少数细节需要完善，但总体而言，Control Tower 4.0 正在朝着正确的方向前进。

其他资源

• 有关更改的详细信息请参阅 此处。（将 # 替换为实际链接。）