吸取的经验教训和最佳实践

OU 结构设计不是一次性的。随着一家公司加大云采用力度，并将更多的工作负载迁移到 AWS 登录区，其 OU 设计（以及隐含的策略理念）也会自然而然地发生变化。

不要将 OU 误认为是文件夹；请将它们视为策略的目标。OU 及其层次结构为 AWS 账户提供结构元素，应始终将其视为策略的容器。我们建议您将需要相同策略集的所有 AWS 账户放在同一 OU 中。本指南还扩展到嵌套的 OU（OU 内的 OU）。

那些需要集中共享功能以及实现跨工作负载数据共享能力的 AWS 环境（这种需求在企业数据平台中较为常见），在不基于业务线（LOB）功能分类的 OU 结构中更容易得到妥善处理。例如，就 AWS Organizations 中的策略而言，用于制造应用的生产环境与用于临床试验分析应用的生产环境并无不同。

尊重并使用继承。当您将某个策略附加到特定 OU 时，直接位于该 OU 下或任何子 OU 下的 AWS 账户将继承此策略。当您将策略附加到特定 AWS 账户时，该策略仅影响该 AWS 账户。

从一个 OU 结构迁移到另一个 OU 结构的工作，取决于现有策略在该 OU 或 AWS 账户级别上的配置程度。另一个重要的因素在于，在现有的 OU 层级结构中，策略继承的使用程度如何，或者这种继承是否被中断了。随着不规则或偏离常规的继承路径的实施，迁移的复杂性也随之增加。例如，如果在单个 AWS 账户级别实施策略，或者频繁做出策略异常处理（这会中断继承），那么将这些策略迁移到新的结构中将会付出大量额外工作量。在这类复杂度极高的情况下，我们建议您在迁移规划过程中投入时间来审查并重新设计策略继承机制。

同时注意 AWS Organizations 策略和 AWS Control Tower 控件。OU 结构由 AWS Control Tower 和 AWS Organizations 共享。AWS Control Tower 提供自己的一套侦测和预防性控件。这些控件适用于 AWS 账户或 OU 级别。AWS Organizations 在 OU 级别编排策略。在 OU 迁移中，我们建议您先迁移 AWS Organizations 策略，因为这些策略对合规性的影响更大。我们建议您在第二个迁移步骤中对新的 OU 结构应用 AWS Control Tower 控件。

更新 AWS 账户需要时间。您必须使用 AWS Control Tower 将现有 AWS 账户单独重新注册到新的 OU 结构中。此操作较费时。如果您拥有大量的账户，我们建议您通过自动化手段来简化这项工作，从而实现对 AWS 账户 OU 放置的控制和自动化处理。以下是两个示例场景：