기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# AWS AWS Control Tower 랜딩 존에 대한 다중 계정 전략
<a name="aws-multi-account-landing-zone"></a>

AWS Control Tower 고객은 최상의 결과를 위해 AWS 환경 및 계정을 설정하는 방법에 대한 지침을 찾는 경우가 많습니다. AWS 는 AWS Control Tower 랜딩 존을 포함한 AWS 리소스를 최대한 활용할 수 있도록 *다중 계정 전략*이라고 하는 통합 권장 사항 세트를 만들었습니다.

기본적으로 AWS Control Tower는 AWS 계정 및에 대한 AWS 다중 계정 권장 사항을 구현하는 데 도움이 되는 다른 AWS 서비스와 함께 작동하는 오케스트레이션 계층 역할을 합니다 AWS Organizations. 랜딩 존이 설정되면 AWS Control Tower는 여러 계정 및 워크로드에서 기업 정책 및 보안 관행을 유지하도록 계속 지원합니다.

대부분의 랜딩 존은 시간 경과에 따라 고도화됩니다. AWS Control Tower 랜딩 존의 조직 단위(OU) 및 계정 수가 증가하면 워크로드를 효과적으로 구성하는 데 도움이 되는 방식으로 AWS Control Tower 배포를 확장할 수 있습니다. 이 장에서는 AWS 다중 계정 전략에 따라 AWS Control Tower 랜딩 존을 계획 및 설정하고 시간 경과에 따라 확장하는 방법에 대한 규범적 지침을 제공합니다.

조직 단위의 모범 사례에 대한 일반적인 설명은 [를 사용한 조직 단위의 모범 사례를 참조하세요 AWS Organizations](https://aws.amazon.com//blogs/mt/best-practices-for-organizational-units-with-aws-organizations/).

## AWS 다중 계정 전략: 모범 사례 지침
<a name="multi-account-guidance"></a>

AWS 잘 설계된 환경의 모범 사례에서는 리소스와 워크로드를 여러 AWS 계정으로 분리하는 것이 좋습니다. AWS 계정을 격리된 리소스 컨테이너로 생각할 수 있습니다. 이는 워크로드 분류뿐만 아니라 문제가 발생했을 때 폭발 반경을 줄여줍니다.

** AWS 계정의 정의**  
* AWS 계정은 리소스 컨테이너 및 리소스 격리 경계 역할을 합니다.*

**참고**  
 AWS 계정은 페더레이션 또는 AWS Identity and Access Management (IAM)를 통해 설정된 사용자 계정과 동일하지 않습니다.

** AWS 계정에 대한 추가 정보**

 AWS 계정은 리소스를 격리하고 AWS 워크로드에 대한 보안 위협을 억제할 수 있는 기능을 제공합니다. 또한 이 계정은 워크로드 환경의 결제 및 거버넌스를 위한 메커니즘을 제공합니다.

 AWS 계정은 워크로드에 리소스 컨테이너를 제공하는 기본 구현 메커니즘입니다. 환경이 잘 설계된 경우 여러 AWS 계정을 효과적으로 관리할 수 있으므로 여러 워크로드와 환경을 관리할 수 있습니다.

AWS Control Tower는 Well-Architected 환경을 설정합니다. 여러 AWS 계정에 걸쳐 확장 AWS Organizations할 수 있는 환경의 변경 사항을 관리하는 데 도움이 되는와 함께 계정에 의존합니다.

**Well-Architected 환경의 정의**  
*AWS 는 잘 설계된 환경을 랜딩 존으로 시작하는 환경으로 정의합니다.*

AWS Control Tower는 자동으로 설정된 랜딩 존을 제공합니다. 이는 환경의 여러 계정에서 기업 지침을 준수하도록 제어 기능을 적용합니다.

**랜딩 존의 정의**  
*랜딩 존은 기본 계정, 계정 구조, 네트워크 및 보안 레이아웃 등을 포함하여 권장 시작 지점을 제공하는 클라우드 환경입니다. 랜딩 존에서 솔루션과 애플리케이션을 활용하는 워크로드를 배포할 수 있습니다.*

## Well-Architected 환경 설정 지침
<a name="guidelines-for-multi-account-setup"></a>

다음 섹션에서는 Well-Architected 환경의 세 가지 주요 구성 요소를 다음과 같이 설명합니다.
+ 여러 AWS 계정
+ 여러 조직 단위(OU)
+ 잘 계획된 구조

**여러 AWS 계정 사용**

하나의 계정만으로는 Well-Architected 환경을 설정할 수 없습니다. 여러 계정을 사용하면 보안 목표와 비즈니스 프로세스를 효과적으로 지원할 수 있습니다. 다중 계정 접근 방식을 사용하면 다음과 같은 몇 가지 이점이 있습니다.
+ **보안 제어** - 애플리케이션마다 보안 프로필이 다르기 때문에 서로 다른 제어 정책과 메커니즘이 필요합니다. 예를 들면 감사자와 상담하여 결제 카드 산업(PCI) 워크로드를 호스팅하는 단일 계정을 추천하는 것이 더 쉽습니다.
+ **격리** – 계정은 보안 보호의 단위입니다. 다른 계정이 영향받지 않도록 잠재적 위험과 보안 위협을 특정 계정 내에서 억제할 수 있습니다. 따라서 보안 요구에 따라 계정을 서로 격리해야 할 수 있습니다. 예를 들어 보안 프로필이 다른 팀이 있을 수 있습니다.
+ **다양한 팀** - 팀마다 책임과 리소스 요구 사항이 다릅니다. 여러 개의 계정을 설정하면 같은 계정을 사용할 때처럼 팀에서 서로 간섭할 수 없습니다.
+ **데이터 격리** – 데이터 저장소를 하나의 계정으로 격리하면 데이터에 액세스하고 데이터 저장소를 관리할 수 있는 사람의 수가 제한됩니다. 이러한 격리는 민감한 데이터의 무단 노출을 방지하는 데 도움이 됩니다. 예를 들어 데이터 격리는 일반 데이터 보호 규정(GDPR) 준수를 지원하는 데 도움이 됩니다.
+ **비즈니스 프로세스** – 사업부 또는 제품마다 목적 및 프로세스가 완전히 다를 수 있습니다. 개별 계정을 설정하여 비즈니스별 요구 사항을 충족할 수 있습니다.
+ **청구** – 송금 수수료 등을 포함하여 청구 수준에서 항목을 구분할 수 있는 유일한 방법은 계정입니다. 여러 계정을 사용하면 사업부, 직무 팀 또는 개별 사용자 간에 별도의 청구 가능한 항목을 만들 수 있습니다.
+ **할당량 할당** - AWS 할당량은 계정별로 설정됩니다. 워크로드를 서로 다른 계정으로 분리하면 각 계정(예: 프로젝트)에 잘 정의된 개별 할당량이 부여됩니다.

**여러 조직 단위 사용**

AWS Control Tower 및 기타 계정 오케스트레이션 프레임워크는 계정 경계를 넘어 변경할 수 있습니다. 따라서 AWS 모범 사례는 교차 계정 변경을 해결하며, 이는 잠재적으로 환경을 손상시키거나 보안을 약화시킬 수 있습니다. 경우에 따라 변경 사항이 정책을 넘어 전체 환경에 영향을 미칠 수 있습니다. 따라서 프로덕션 및 스테이징이라는 두 개 이상의 필수 계정을 설정하는 것이 좋습니다.

또한 AWS 계정은 거버넌스 및 제어 목적으로 OUs(조직 단위)로 그룹화되는 경우가 많습니다. OU는 여러 계정에서 정책 적용을 처리하도록 설계되었습니다.

최소한 프로덕션 환경과는 다른 사전 프로덕션(또는 스테이징) 환경을 생성하고, 별도의 제어 및 정책을 적용하는 것이 좋습니다. 프로덕션 환경과 스테이징 환경은 별도의 OU로 생성 및 관리할 수 있으며 별도의 계정으로 청구할 수 있습니다. 또한 코드 테스트를 위해 샌드박스 OU를 설정할 수도 있습니다.

**랜딩 존의 OU에 대해 잘 계획된 구조 사용**

AWS Control Tower는 자동으로 몇 개의 OU를 설정합니다. 시간 경과에 따라 워크로드와 요구 사항이 확장되면 필요에 맞게 원래의 랜딩 존 구성을 확장할 수 있습니다.

**참고**  
예제에 제공된 이름은 다중 계정 AWS 환경을 설정하기 위해 제안된 AWS 이름 지정 규칙을 따릅니다. OU 세부 정보 페이지에서 **편집**을 선택하여 랜딩 존을 설정한 후 OU의 이름을 바꿀 수 있습니다.

**권장 사항**

AWS Control Tower를 통해 첫 번째 필수 OU인 보안 OU가 자동으로 설정되면 랜딩 존에 몇 가지 추가 OU를 생성하는 것을 권장합니다.

AWS Control Tower에서 샌드박스 OU라고 하는 추가 OU를 하나 이상 생성하도록 허용하는 것이 좋습니다. 이 OU는 소프트웨어 개발 환경을 위한 것입니다. 랜딩 존 생성 중에 샌드박스 OU를 선택하면 AWS Control Tower가 이를 설정할 수 있습니다.

직접 설정할 수 있는 다른 권장 OU에는 공유 서비스 및 네트워킹 계정을 포함하는 인프라 OU와 프로덕션 워크로드를 포함하는 워크로드 OU의 두 가지가 있습니다. **조직 단위** 페이지의 AWS Control Tower 콘솔을 통해 랜딩 존에 OU를 추가할 수 있습니다.

**자동으로 설정되는 OU 이외의 권장 OU**
+ **인프라 OU** - 공유 서비스 및 네트워킹 계정을 포함합니다.
**참고**  
AWS Control Tower는 인프라 OU를 자동으로 설정하지 않습니다.
+ **샌드박스 OU** - 소프트웨어 개발 OU입니다. 예를 들어, 이 OU는 지출 한도가 고정되어 있거나 프로덕션 네트워크에 연결되어 있지 않을 수 있습니다.
**참고**  
AWS Control Tower에서는 샌드박스 OU를 설정할 것을 권장하지만 선택 사항입니다. 랜딩 존 구성의 일부로 자동으로 설정할 수 있습니다.
+ **워크로드 OU** - 워크로드를 실행하는 계정이 포함되어 있습니다.
**참고**  
AWS Control Tower는 워크로드 OU를 자동으로 설정하지 않습니다.

자세한 내용은 [Production starter organization with AWS Control Tower](https://docs.aws.amazon.com//whitepapers/latest/organizing-your-aws-environment/production-starter-organization.html#production-starter-organization-with-aws-control-tower)를 참조하세요.

## 완전한 다중 계정 OU 구조를 갖춘 AWS Control Tower의 예
<a name="guidelines-for-full-multi-account"></a>

AWS Control Tower는 중첩된 OU 계층 구조를 지원합니다. 즉, 조직의 요구 사항을 충족하는 계층적 OU 구조를 생성할 수 있습니다. AWS 다중 계정 전략 지침에 맞게 AWS Control Tower 환경을 구축할 수 있습니다.

또한 성능이 우수하고 AWS 다중 계정 지침에 부합하는 더 단순하고 평면적인 OU 구조를 구축할 수 있습니다. 계층적 OU 구조를 구축할 수 있다고 해서 반드시 구축해야 하는 것은 아닙니다.
+  AWS 다중 계정 지침이 있는 확장된 플랫 AWS Control Tower 환경의 예제 OUs 세트를 보여주는 다이어그램을 보려면 [ 예제: 플랫 OU 구조의 워크로드를 참조하세요](https://docs.aws.amazon.com//whitepapers/latest/organizing-your-aws-environment/appendix-e-establish-multi-account.html#example-workloads-flat-structure).
+ AWS Control Tower가 중첩된 OU 구조에서 작동하는 방식에 대한 자세한 내용은 [AWS Control Tower의 중첩된 OU](nested-ous.md) 섹션을 참조하세요.
+ AWS Control Tower가 AWS 지침을 준수하는 방법에 대한 자세한 내용은 AWS 백서인 [여러 계정을 사용하여 AWS 환경 구성을 참조하세요](https://docs.aws.amazon.com//whitepapers/latest/organizing-your-aws-environment/appendix-e-establish-multi-account.html).

연결된 페이지의 다이어그램은 더 많은 기본 OU와 더 많은 추가 OU가 생성되었음을 보여줍니다. 이러한 OU는 대규모 배포의 추가 요구 사항을 충족합니다.

기본 OU 열에서 기본 구조에 두 개의 OU가 추가되었습니다.
+ **Security\_Prod OU** – 보안 정책에 대한 읽기 전용 영역과 비상 접근 보안 감사 영역을 제공합니다.
+ **인프라 OU** - 이전에 권장한 인프라 OU를 Infrastructure\_Test(사전 프로덕션 인프라용)와 Infrastructure\_Prod(프로덕션 인프라용)의 두 가지 OU로 분리할 수 있습니다.

추가 OU 영역에서 기본 구조에 몇 개의 OU가 더 추가되었습니다. 다음은 환경의 성장에 따라 생성할 다음 권장 OU입니다.
+ **워크로드 OU** - 이전에 권장되었지만 선택 사항인 워크로드 OU는 Workloads\_Test(사전 프로덕션 워크로드용)와 Workloads\_Prod(프로덕션 워크로드용)의 두 OU로 분리되었습니다.
+ **PolicyStaging OU** - 시스템 관리자가 제어 및 정책을 완전히 적용하기 전에 변경 사항을 테스트할 수 있습니다.
+ **일시 중지된 OU** - 일시적으로 비활성화되었을 수 있는 계정의 위치를 제공합니다.

## 루트 정보
<a name="about-the-root"></a>

루트는 OU가 아닙니다. 루트는 관리 계정과 조직의 모든 OU 및 계정의 컨테이너입니다. 개념적으로 루트에는 모든 OU가 포함됩니다. 삭제할 수는 없습니다. AWS Control Tower 내의 루트 수준에서는 등록된 계정을 관리할 수 없습니다. 대신 OU 내에서 등록된 계정을 관리합니다. 유용한 다이어그램은 [AWS Organizations 설명서를 참조하세요](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_getting-started_concepts.html).