기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# OU 설계: 1단계
이 예제의 다국적 제약 회사의 경우의 조직 및 OUs의 초기 설계는 설정에 대한 AWS 권장 사항을 AWS Organizations 긴밀히 따랐습니다 AWS Control Tower. 예를 들어, [의 Landing Zone Accelerator AWS for Healthcare](https://github.com/aws-samples/landing-zone-accelerator-on-aws-for-healthcare)를 참조하세요.는 초기에 보안 OU, 플랫폼 인프라 OUs 및 회사별 OU를 포함하여를 사용한 [조직 단위 모범 사례에 설명된 대로 일반적인 기본 OU를 사용하여 AWS Organizations](https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/?org_product_gs_bp_OUBlog) 간단한 OU 구조를 AWS Control Tower 프로비저닝OUs.
## 아키텍처 설계
다음 다이어그램에서는 초기 OU 아키텍처를 보여줍니다.
## 보안 OU
보안 OU는 보안 기능과 AWS 계정 관련된 광범위한 그룹을 구성하고 두 계정(감사 및 로그 아카이브)을 사용하여 Amazon GuardDuty 및와 같은 environment. AWS core 보안 서비스에 대한 중앙 로깅 및 감사 액세스를 위한 보안 운영 데이터를 AWS Security Hub CSPM 감사 계정에 저장합니다.
## 인프라 플랫폼 OU
인프라 플랫폼 OU는 인프라 기반을 AWS 계정 제공하는 그룹입니다. 처음에이 OU 내에 배포된는 중앙 네트워킹 구성 요소(게이트웨이, 방화벽, 중앙 네트워킹 허브 및 유사한 서비스) AWS 계정 의 입니다.
## 추가 OU
다른 회사별 OU(예: 임상 OU)는 하위 수준 계층 구조 내에서 기본 OU를 보강합니다. 워크로드는 다중 계정 구조와 해당 OU 내 분리된 환경으로 구현됩니다.
몇 가지 고려 사항 때문에 초기에 이와 같이 설계되었습니다.
+ 중첩된 OUs 당시에서 사용할 수 없었 AWS Control Tower 기 때문에 광범위한 사용자 지정이 필요했습니다.
+ 클라우드용으로 지정된 초기 워크로드는 임상 시험 또는 제조 장비 분석(기능 보기)과 같은 회사의 특정 측면에 중점을 둡니다.
+ 회사는 다섯 가지 워크로드 환경(개발, 검증, 통합, 교육 및 프로덕션)을 구분합니다. 이 회사는 프로덕션 워크로드에 필요한 AWS 제어를 통한 엄격한 거버넌스 없이 애플리케이션을 개발하기 위한 플레이그라운드가 필요했습니다. 이를 위해 Manufacturing-Dev OU와 같은 개발 OU가 할당되었습니다.
+ 워크로드 자동화는 각 애플리케이션 에코시스템의 일부였으며 분리가 필요하지 않았습니다.
+ 인프라 검증(IQ) 및 GxP 규정 준수 프로세스에서는 OU 수준에서 AWS 제어를 구분할 필요가 없었습니다.