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

# AWS Control Tower 리소스 생성 및 수정 지침
<a name="getting-started-guidance"></a>

AWS Control Tower에서 리소스를 만들고 수정할 때 다음 모범 사례를 권장합니다. 서비스가 업데이트될 경우 이 지침이 변경될 수 있습니다. [공동 책임 모델](https://aws.amazon.com/compliance/shared-responsibility-model/)은 AWS Control Tower 환경에 적용됩니다.

**일반 지침**
+ 관리 계정, 공유 계정 및 멤버 계정의 리소스를 포함하여 AWS Control Tower에서 생성된 리소스를 수정하거나 삭제하지 마세요. 이러한 리소스를 수정하면 랜딩 존을 업데이트하거나 OU를 재등록해야 할 수 있으며, 수정하면 규정 준수 보고가 부정확해질 수 있습니다.

  **중요 사항:**
  + 활성 AWS Config 레코더를 유지합니다. 구성 레코더를 삭제하면 탐지 제어가 드리프트를 탐지 및 보고할 수 없습니다. 불충분한 정보로 인해 규정을 준수하지 않는 리소스가 **규정 준수**로 보고될 수 있습니다.
  + 보안 조직 단위 AWS Identity and Access Management (OU)의 공유 계정 내에서 생성된 (IAM) 역할을 수정하거나 삭제하지 마십시오. 이러한 역할을 수정하려면 랜딩 존을 업데이트해야 합니다.
  + 멤버 계정(등록되지 않은 계정인 경우도 포함)에서 `AWSControlTowerExecution` 역할을 삭제하지 마세요. 그러는 경우 AWS Control Tower에 이러한 계정을 등록하거나 해당 계정의 직계 상위 OU를 등록할 수 없습니다.
+ SCPs 또는 AWS Security Token Service ()를 AWS 리전 통한 사용을 허용하지 마십시오AWS STS. 그러면 AWS Control Tower가 정의되지 않은 상태로 전환됩니다. 에서 리전을 허용하지 않으면 해당 리전에서 인증을 사용할 수 없으므로 해당 리전에서 AWS STS기능이 실패합니다. 대신 제어에 표시된 대로 AWS Control Tower 리전 거부 기능, 랜딩 존 수준에서 작동하는 [요청된에 AWS 따라에 대한 액세스 거부 AWS 리전](https://docs.aws.amazon.com//controltower/latest/userguide/primary-region-deny-policy.html) 또는 [리전에 대한 액세스를 제한하기 위해 OU 수준에서 작동하는 OU에 적용된 제어 리전 거부 제어](https://docs.aws.amazon.com//controltower/latest/userguide/ou-region-deny.html)에 의존합니다.
+ SCP를 AWS Organizations `FullAWSAccess` 적용해야 하며 다른 SCPs. 이 SCP에 대한 변경 사항은 드리프트로 보고되지 않지만 일부 변경 사항은 특정 리소스에 대한 액세스가 거부되는 경우 예측할 수 없는 방식으로 AWS Control Tower 기능에 영향을 미칠 수 있습니다. 예를 들어 SCP가 분리되거나 수정되는 경우 계정이 AWS Config 레코더에 대한 액세스 권한을 잃거나 CloudTrail 로깅에 누락이 발생할 수 있습니다.
+ API를 AWS Organizations `DisableAWSServiceAccess` 사용하여 랜딩 존을 설정한 조직에 대한 AWS Control Tower 서비스 액세스를 끄지 마십시오. 이렇게 하면 AWS Organizations의 메시징 지원 없이는 특정 AWS Control Tower 드리프트 탐지 기능이 제대로 작동하지 않을 수 있습니다. 이러한 드리프트 탐지 기능은 AWS Control Tower가 조직 내 조직 단위, 계정 및 제어의 규정 준수 상태를 정확하게 보고할 수 있도록 보장하는 데 도움이 됩니다. 자세한 내용은 [API\$1DisableAWSServiceAccessAWS Organizations API 참조의 섹션을 참조하세요](https://docs.aws.amazon.com//organizations/latest/APIReference/API_DisableAWSServiceAccess.html).
+ 일반적으로 AWS Control Tower는 한 번에 한 개의 작업을 수행하므로 다른 작업을 시작하기 전에 수행 중인 작업이 완료되어야 합니다. 예를 들어 제어 활성화 프로세스가 이미 사용 중일 때 계정을 프로비저닝하려고 시도하면 계정 프로비저닝이 실패합니다.

  **예외:**
  + AWS Control Tower를 사용하면 동시 작업을 통해 선택적 제어를 배포할 수 있습니다. 자세한 내용은 [선택적 제어를 위한 동시 배포](https://docs.aws.amazon.com//controltower/latest/userguide/enable-controls-on-ou.html#concurrent-optional-controls)를 참조하세요.
  + AWS Control Tower에서는 Account Factory를 통해 계정에 대한 생성, 업데이트, 등록 작업을 최대 10개까지 동시에 수행할 수 있습니다.

**참고**  
AWS Control Tower에서 생성된 리소스에 대한 자세한 내용은 [공유 계정이란?](what-shared.md) 섹션을 참조하세요.

**계정 및 OU에 대한 팁**
+ 거버넌스를 위한 새 리전을 구성하는 등 계정 업데이트가 필요할 때마다 **OU 재등록** 기능을 사용하여 해당 계정을 업데이트할 수 있도록 등록된 각 OU의 계정 수를 최대 1000개로 유지하는 것을 권장합니다.
+ OU를 등록할 때 필요한 시간을 줄이려면 OU당 계정 수 한도가 1000개인 경우에도 OU당 계정 수를 약 680개로 유지하는 것이 좋습니다. 일반적으로 OU를 등록하는 데 필요한 시간은 OU가 운영 중인 리전 수에 OU의 계정 수를 곱한 값으로 결정됩니다.
+ 대략적으로 계정이 680개인 OU는 제어를 등록하고 활성화하는 데 최대 2시간이 걸릴 수 있고 재등록하는 데 최대 1시간이 걸릴 수 있습니다. 또한 제어의 수가 많은 OU는 제어의 수가 적은 OU보다 등록하는 데 시간이 더 오래 걸립니다.
+ OU 등록에 더 긴 기간을 허용하는 것에 대한 한 가지 우려 사항은 이 프로세스가 다른 작업을 차단한다는 것입니다. 일부 고객은 각 OU에 더 많은 계정을 허용하려고 하므로 OU를 등록하거나 재등록하기 위한 시간을 더 늘리고 싶어합니다.