本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# OU 设计：第 1 阶段
<a name="phase-1"></a>

对于跨国制药公司来说，在我们的例子中，组织的最初设计和 OUs AWS Organizations 严格遵循了设立 AWS 的建议 AWS Control Tower。有关示例，请参阅[医疗保健领域的着陆区加速器](https://github.com/aws-samples/landing-zone-accelerator-on-aws-for-healthcare)。 AWS AWS Control Tower 最初配置了一个具有共同基础的简单 OU 结构 OUs，如博客文章《[组织单位最佳实践](https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/?org_product_gs_bp_OUBlog)》中所述 AWS Organizations，包括安全 OU、平台基础设施 OU 和公司特定的 OU。 OUs

## 架构设计
<a name="p1-arch-design"></a>

以下图表展示了最初的 OU 架构。

![OU 结构第 1 阶段的架构设计](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/ou-structure-landing-zone/images/ou-phase-1.png)


## 安全 OU
<a name="p1-security"></a>

安全 OU 将与安全功能 AWS 账户 相关的广泛分组在一起，并使用两个帐户（审计和日志存档）来存储安全操作数据，以便集中记录和审核对环境的访问。 AWS 诸如 Amazon 之类 GuardDuty 的核心安全服务 AWS Security Hub CSPM 位于审计账户中。

## 基础设施平台 OU
<a name="p1-infra"></a>

基础架构平台 OU 组合在一起 AWS 账户 ，提供基础架构基础。最初部署在此 OU 中的 AWS 账户 是中央网络组件（网关、防火墙、中央网络集线器和类似服务）。 

## 额外 OUs
<a name="p1-additional"></a>

其他公司特定的组织 OUs （例如临床组织单位）增强了低级层次结构 OUs 中的基础。工作负载是通过多账户结构实现的，并在这些 OUs结构中使用不同的环境来实现。

有几个考虑因素促成了这一最初的设计：
+ Nested OUs 当时不可用，需要 AWS Control Tower 进行大量自定义。
+ 最初指定给云的初始工作负载侧重于公司的特定方面，例如临床试验或生产设备分析（功能视角）。
+ 该公司将工作环境分为五种类型（开发、验证、集成、训练和生产）。该公司需要一个在没有生产工作负载所需严格 AWS 控制的情况下开发应用程序的游乐场。为此目的分配了 OUs 诸如制造开发OU之类的开发部门。
+ 工作负载自动化是每个应用程序生态系统的一部分，无需进行分离。
+ 基础设施认证 (IQ) 和 GxP 合规流程不需要区分 OU 级别的 AWS 控制措施。