학습한 교훈 및 모범 사례

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 배치를 제어하고 자동화하는 것이 좋습니다. 다음은 두 가지 시나리오 예제입니다.