기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 다중 계정 아키텍처로 전환을 위한 ID 관리 및 액세스 제어
다중 계정 아키텍처로 전환하는 첫 단계는 조직 내에 새 계정 구조를 설정하는 것입니다. 그런 다음 사용자를 추가하고 계정에 대한 액세스를 구성할 수 있습니다. 이 섹션에서는 여러 AWS 계정에 대한 사용자 액세스를 관리하는 접근 방식을 설명합니다.
**Topics**
+ [조직 설정](set-up-organization.md)
+ [랜딩 존 생성](create-landing-zone.md)
+ [조직 단위 추가](add-organizational-units.md)
+ [초기 사용자 추가](add-initial-users.md)
+ [멤버 계정 관리](manage-member-accounts.md)
# 조직 설정
여러 계정이 있는 경우의 조직을 통해 이러한 계정을 논리적으로 관리할 AWS 계정수 있습니다[AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html). 의 *계정* AWS Organizations 은 리소스와 해당 AWS 리소스에 액세스할 수 있는 자격 증명을 AWS 계정 포함하는 표준입니다. *조직은* 단일 단위로 관리할 수 AWS 계정 있도록를 통합하는 엔터티입니다.
계정을 사용하여 조직을 생성하면 계정이 조직의 **관리 계정(**지급인 계정 또는 **루트 계정이라고도 함)이 됩니다. 조직에 관리 계정은 하나만 있을 수 있습니다. 조직에 AWS 계정 를 추가하면 *멤버 계정이* 됩니다.
**참고**
AWS 계정 또한 각 에는 *루트 사용자*라는 단일 자격 증명이 있습니다. 계정을 생성할 때 사용한 이메일 주소와 암호를 사용하여 루트 사용자로 로그인할 수 있습니다. 그러나 일상적인 작업, 심지어 관리 작업의 경우에도 루트 사용자를 사용하지 않는 것이 좋습니다. 자세한 내용은 [AWS 계정 루트 사용자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)를 참조하세요.
또한 [멤버 계정에 대한 루트 액세스를 중앙 집중화](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-enable-root-access.html)하고 조직의 멤버 계정에서 루트 사용자 자격 증명을 제거하는 것이 좋습니다.
조직 루트, 조직 단위(OU) 및 멤버 계정으로 구성된 계층적 트리 구조로 계정을 구성합니다. **루트는 조직의 모든 계정에 대한 상위 컨테이너입니다. **조직 단위(OU)는 [루트](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#root) 내의 [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#account](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#account)계정에 대한 컨테이너입니다. OU에는 다른 OU 또는 멤버 계정이 포함될 수 있습니다. OU에는 상위 항목이 하나만 있을 수 있으며 각 계정은 하나의 OU에만 속할 수 있습니다. 자세한 내용은 [용어 및 개념](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)(AWS Organizations 문서)을 참조하세요.
[서비스 제어 정책(SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)은 사용자와 역할이 사용할 수 있는 서비스와 작업을 지정합니다. SCPs는 권한을 부여하지 않는다는 점을 제외하면 AWS Identity and Access Management (IAM) 권한 정책과 유사합니다. 대신 SCP는 최대 권한을 정의합니다. 계층의 노드 중 하나에 정책을 연결하면 해당 노드 내의 모든 OU 및 계정에 정책이 적용됩니다. 예를 들어, 루트에 정책을 적용하면 조직의 모든 [OU](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#organizationalunit)와 [계정](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#account)에 정책이 적용되고 OU에 정책을 적용하면 대상 OU의 OU 및 계정에만 정책이 적용됩니다.
[리소스 제어 정책(RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)은 조직의 리소스에 사용할 수 있는 최대 권한을 중앙에서 제어합니다. RCPs 계정의 리소스가 조직의 액세스 제어 지침 내에서 유지되도록 하는 데 도움이 됩니다.
AWS Organizations 콘솔을 사용하여 조직 내 모든 계정을 중앙에서 보고 관리할 수 있습니다. 조직 사용의 이점 중 하나는 관리 및 멤버 계정과 관련된 모든 요금이 표시된 통합 청구서를 받을 수 있다는 것입니다. 자세한 내용은 [통합 결제](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html)(AWS Organizations 문서)를 참조하세요.
## 모범 사례
+ 기존 AWS 계정 를 사용하여 조직을 생성하지 마십시오. 조직의 관리 계정이 되는 새 계정으로 시작합니다. 권한 있는 작업은 조직의 관리 계정 내에서 수행할 수 있으며 SCPs 및 RCPs 관리 계정에 적용되지 않습니다. 그러므로 관리 계정에 포함된 클라우드 리소스와 데이터는 관리 계정에서 관리해야 하는 항목으로만 제한해야 합니다.
+ 관리 계정에 대한 액세스를 새를 프로비저닝 AWS 계정 하고 조직을 관리해야 하는 개인으로만 제한합니다.
+ SCP를 사용하여 루트, 조직 단위 및 멤버 계정에 대한 최대 권한을 정의합니다. 관리 계정에 SCP를 직접 적용할 수는 없습니다.
+ RCPs 사용하여 멤버 계정의 리소스에 대한 최대 권한을 정의합니다. RCPs 관리 계정에 직접 적용할 수 없습니다.
+ 에 [대한 모범 사례 AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices.html)(AWS Organizations 문서)를 준수합니다.
# 랜딩 존 생성
*랜딩 존*은 워크로드와 애플리케이션을 배포할 수 있는 출발점인 잘 설계된 다중 계정 AWS 환경입니다. 다중 계정 아키텍처, ID 및 액세스 관리, 거버넌스, 데이터 보안, 네트워크 설계 및 로깅을 시작할 수 있는 기준선을 제공합니다. [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)는 자동화된 가드레일을 제공하여 다중 계정 환경의 유지 및 거버넌스를 단순화하는 서비스입니다. 일반적으로 계정 AWS 서비스 내 다른를 오케스트레이션하여 all AWS 리전. AWS Control Tower works에서 환경을 관리하는 단일 AWS Control Tower 랜딩 존을 프로비저닝합니다. 자세한 내용은 [랜딩 존을 설정할 때 발생하는 일(문서)을 참조하세요](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#how-it-works-setup).AWS Control Tower
를 사용하여 랜딩 존을 설정할 때 관리 계정 AWS Control Tower, 로그 아카이브 계정, 감사 계정의 세 가지 공유 계정을 식별합니다. 자세한 내용은 [공유 계정이란 무엇입니까](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#what-shared)(AWS Control Tower 문서)를 참조하세요. 관리 계정의 경우 워크로드를 호스팅하지 않는 기존 계정을 사용하여 랜딩 존을 설정해야 합니다. 로그 아카이브 및 감사 계정의 경우 기존 계정을 재사용하거나 자동으로 생성할 AWS 계정 AWS Control Tower 수 있습니다.
AWS Control Tower 랜딩 존을 설정하는 방법에 대한 지침은 [시작하기](https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-with-control-tower.html)(AWS Control Tower 문서)를 참조하세요.
## 모범 사례
+ [다중 계정 전략(백서)에 대한 설계 원칙](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/design-principles-for-your-multi-account-strategy.html)의 모범 사례를 준수합니다.AWS
+ [관리자 모범 사례 AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/best-practices.html)(AWS Control Tower 문서)를 준수합니다.
+ 대부분의 워크로드를 호스팅 AWS 리전 하는에서 랜딩 존을 생성합니다.
**중요**
랜딩 존을 배포한 후이 리전을 변경하기로 결정한 경우의 지원이 필요하며 AWS Support랜딩 존을 폐기해야 합니다. 이 방법은 권장되지 않습니다.
+ 관리할 리전 AWS Control Tower 을 결정할 때는 워크로드를 즉시 배포할 것으로 예상되는 리전만 선택합니다. 이러한 리전을 변경하거나 나중에 더 추가할 수 있습니다. 가 리전을 AWS Control Tower 관리하는 경우 탐지 가드레일을 해당 리전에 로 배포합니다[AWS Config 규칙](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html).
+ 어떤 리전을 관리할 AWS Control Tower 지 결정한 후 관리되지 않는 모든 리전에 대한 액세스를 거부합니다. 그러면 워크로드 및 개발자가 승인된 AWS 리전만 사용할 수 있습니다. 이는 조직의 서비스 제어 정책(SCP)으로 구현됩니다. 자세한 내용은 [AWS 리전 거부 제어 구성](https://docs.aws.amazon.com/controltower/latest/userguide/region-deny.html)(AWS Control Tower 문서)을 참조하세요.
+ 에서 랜딩 존을 설정할 때 다음 OUs 및 계정의 이름을 바꾸는 AWS Control Tower것이 좋습니다.
+ **Security** OU의 이름을 **Security\$1Prod**로 변경하여 이 OU가 프로덕션 보안 관련 AWS 계정에 사용됨을 나타내는 것이 좋습니다.
+ AWS Control Tower 가 추가 OU를 생성한 다음 **샌드박스**에서 **워크로드**로 이름을 변경할 수 있도록 허용하는 것이 좋습니다. 다음 섹션에서는 AWS 계정을 구성하는 데 사용하는 **Workloads** OU 내에 추가 OU를 생성합니다.
+ 중앙 집중식 로깅의 이름을 **로그 아카이브** AWS 계정 에서 **log-archive-prod**로 변경하는 것이 좋습니다.
+ 감사 계정의 이름을 **Audit**에서 **security-tooling-prod**로 바꾸는 것이 좋습니다.
+ 사기를 방지하려면가 사용 기록이 AWS 계정 있는를 AWS AWS Control Tower 랜딩 존에 추가해야 합니다. 사용 내역 AWS 계정 없이 새를 사용하는 경우 새 계정에서 AWS 프리 티어에 없는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 시작할 수 있습니다. 인스턴스를 몇 분 동안 실행한 후 종료합니다.
# 조직 단위 추가
다중 계정 환경을 설정하려면 적절한 조직 구조를 구축하는 것이 중요합니다. 서비스 제어 정책(SCP)을 사용하여 OU와 그 안의 계정에 대한 최대 권한을 정의하므로 조직 구조는 관리, 권한 및 재무 보고 관점에서 논리적이어야 합니다. 조직 단위(OUs)를 포함한 조직의 구조에 대한 자세한 내용은 [용어 및 개념](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)(AWS Organizations 문서)을 참조하세요.
이 섹션에서는 프로덕션, 비 프로덕션 등의 환경을 세분화하고 구조화하는 데 도움이 되는 중첩된 OU를 생성하여 랜딩 영역을 사용자 지정합니다. 이러한 권장 모범 사례는 랜딩 존을 세분화하여 프로덕션 및 비 프로덕션 리소스를 분리하고 인프라를 워크로드와 분리하도록 설계되었습니다.
OUs를 생성하는 방법에 대한 자세한 내용은 [조직 단위 관리](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html)(AWS Organizations 문서)를 참조하세요.
## 모범 사례
+ [랜딩 존 생성](create-landing-zone.md)에서 생성한 **Workloads** OU 내에 다음과 같은 중첩 OU를 생성합니다.
+ **Prod** – 고객 데이터를 포함한 프로덕션 데이터를 저장하고 액세스하는 AWS 계정 에 이 OU를 사용합니다.
+ **NonProd** – 개발, 스테이징, 테스트 환경 등의 비 프로덕션 데이터를 저장하는 AWS 계정 에 이 OU를 사용합니다.
조직 루트 아래에 **Infrastructure\$1Prod** OU를 생성합니다. 이 OU를 사용하여 중앙 집중식 네트워킹 계정을 호스팅할 수 있습니다.
# 초기 사용자 추가
사용자에게 AWS 계정에 대한 액세스 권한을 부여하는 방법은 두 가지입니다.
+ IAM 보안 인증(예: 사용자, 그룹 및 역할)
+ 를 사용한 것과 같은 자격 증명 페더레이션 AWS IAM Identity Center
소규모 회사와 단일 계정 환경에서는 신규 직원이 입사할 때 관리자가 IAM 사용자를 생성하는 것이 일반적입니다. IAM 사용자에게 연결된 액세스 키와 시크릿 키 보안 인증 정보는 만료되지 않기 때문에 **장기 보안 인증 정보라고 합니다. 그러나 공격자가 해당 보안 인증 정보를 손상시킨 경우 사용자에 대한 새로운 보안 인증 정보 세트를 생성해야 하므로 이는 권장되는 보안 모범 사례가 아닙니다. 에 액세스하는 또 다른 방법은 [IAM 역할을](https://aws.amazon.com/blogs/startups/how-setting-up-iam-users-and-iam-roles-can-help-keep-your-startup-secure/) 사용하는 AWS 계정 것입니다. [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html)(AWS STS)를 사용하여 구성 가능한 시간이 지나면 만료되는 **단기 보안 인증 정보를 일시적으로 요청할 수도 있습니다.
[IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)를 AWS 계정 통해에 대한 사용자 액세스를 관리할 수 있습니다. 각 직원 또는 계약자에 대한 개별 사용자 계정을 생성할 수 있으며, 이들은 자신의 암호와 다중 인증(MFA) 솔루션을 관리하고 그룹화하여 액세스를 관리할 수 있습니다. MFA를 구성할 때 인증자 애플리케이션과 같은 소프트웨어 토큰을 사용하거나 YubiKey 디바이스와 같은 하드웨어 토큰을 사용할 수 있습니다.
또한 IAM Identity Center는 Okta, JumpCloud, Ping Identity와 같은 외부 ID 제공업체(idP)와의 페더레이션을 지원합니다. 자세한 내용은 [Supported identity providers](https://docs.aws.amazon.com/singlesignon/latest/userguide/supported-idps.html)(IAM Identity Center 설명서)를 참조하세요. 외부 IdP와 페더레이션하면 애플리케이션 간에 사용자 인증을 관리한 다음 IAM Identity Center를 사용하여 특정에 대한 액세스를 승인할 수 있습니다 AWS 계정.
## 모범 사례
+ 사용자 액세스 구성에 대한 [보안 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)(IAM 설명서)를 준수합니다.
+ 개별 사용자가 아닌 그룹별로 계정 액세스를 관리합니다. IAM Identity Center에서 각 비즈니스 기능을 나타내는 새 그룹을 생성합니다. 예를 들어, 엔지니어링, 재무, 영업, 제품 관리를 위한 그룹을 생성할 수 있습니다.
+ 모든 AWS 계정 에 액세스(대개 읽기 전용 액세스)해야 하는 사용자와 단일 AWS 계정에 액세스해야 하는 사용자를 구분하여 그룹을 정의하는 경우가 많습니다. 그룹과 연결된 AWS 계정 및 권한을 쉽게 식별할 수 있도록 그룹에 다음 이름 지정 규칙을 사용하는 것이 좋습니다.
`--`
+ 예를 들어, `AWS-A-dev-nonprod-DeveloperAccess` 그룹의 경우 `AWS-A`는 단일 계정에 대한 액세스를 나타내는 접두사이고, `dev-nonprod`는 계정 이름이고, `DeveloperAccess`는 그룹에 할당된 권한 세트입니다. `AWS-O-BillingAccess` 그룹의 경우 `AWS-O` 접두사는 전체 조직에 대한 액세스를 나타내고 `BillingAccess`는 그룹에 대한 권한 세트를 나타냅니다. 이 예시에서는 그룹이 전체 조직에 액세스할 수 있기 때문에 그룹 이름에 계정 이름이 표시되지 않습니다.
+ 외부 SAML 기반 IdP와 함께 IAM Identity Center를 사용하고 있고 MFA를 요구하려는 경우 ABAC(속성 기반 액세스 제어)를 사용하여 IdP에서 IAM Identity Center로 인증 방법을 전달할 수 있습니다. 속성은 SAML 어설션을 통해 전송됩니다. 자세한 내용은 [Enable and configure attributes for access control](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html)(IAM Identity Center 설명서)을 참조하세요.
Microsoft Azure Active Directory 및 Okta와 같은 많은 IdP는 SAML 어설션 내의 `amr`(Authentication Method Reference) 클레임을 사용하여 사용자의 MFA 상태를 IAM Identity Center에 전달할 수 있습니다. MFA 상태를 확인하는 데 사용되는 클레임과 해당 형식은 IdP에 따라 다릅니다. 자세한 내용은 IdP 설명서를 참조하세요.
그런 다음 IAM Identity Center에서 AWS 리소스에 액세스할 수 있는 사용자를 결정하는 권한 세트 정책을 생성할 수 있습니다. ABAC를 활성화하고 속성을 지정하면 IAM Identity Center가 정책 평가에 사용할 인증된 사용자의 속성 값을 IAM으로 전달합니다. 자세한 내용은 [Create permission policies for ABAC](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac-policies.html)(IAM Identity Center 설명서)를 참조하세요. 다음 예와 같이 `aws:PrincipalTag` 조건 키를 사용하여 MFA에 대한 액세스 제어 규칙을 생성합니다.
```
"Condition": {
"StringLike": { "aws:PrincipalTag/amr": "mfa" }
}
```
# 멤버 계정 관리
이 섹션에서는 기존 계정을 조직에 초대하고 조직 내에 새 계정을 생성하기 시작합니다. 이 프로세스에서 중요한 부분은 새 계정을 프로비저닝해야 하는지 여부를 결정하는 데 사용할 기준을 정의하는 것입니다.
**Topics**
+ [기존 계정 초대](#invite-account)
+ [에서 VPC 설정 사용자 지정 AWS Control Tower](#customize-vpc-settings)
+ [범위 기준 정의](#define-scoping-criteria)
## 기존 계정 초대
내에서 회사의 기존 계정을 새 조직에 초대할 AWS Organizations수 있습니다. 조직의 관리 계정만 다른 계정을 가입하도록 초대할 수 있습니다. 초대받은 계정의 관리자가 수락하면 계정은 즉시 조직에 가입하고 새 멤버 계정에 의해 발생한 모든 경비를 조직의 관리 계정이 책임지게 됩니다. 자세한 내용은 [조직에 가입하도록 AWS 계정 초대](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html)와 [조직에서 보낸 초대 수락 또는 거부](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html#orgs_manage_accounts_accept-decline-invite)(AWS Organizations 설명서)를 참조하세요.
**참고**
현재 다른 조직에 속해 있지 않은 계정만 조직에 가입하도록 초대할 수 있습니다. 계정이 기존 조직의 멤버인 경우 조직에서 해당 계정을 제거해야 합니다. 계정이 실수로 생성된 다른 조직의 관리 계정인 경우 해당 조직을 삭제해야 합니다.
**중요**
기존 계정의 과거 비용 또는 사용 정보에 액세스해야 하는 경우 AWS Cost and Usage Report 를 사용하여 해당 정보를 Amazon Simple Storage Service(Amazon S3) 버킷으로 내보낼 수 있습니다. 조직 가입 초대를 수락하기 전에 이 작업을 수행하세요. 계정이 조직에 가입하면 해당 계정의 이 기록 데이터에 액세스할 수 없게 됩니다. 자세한 내용은 [Setting up an Amazon S3 bucket for Cost and Usage Reports](https://docs.aws.amazon.com/cur/latest/userguide/cur-s3.html)(AWS Cost and Usage Report documentation)를 참조하세요.
*모범 사례*
+ [조직 단위 추가](add-organizational-units.md)에서 생성한 **워크로드** > **Prod** 조직 단위에 프로덕션 워크로드를 포함할 가능성이 높은 기존 계정을 추가하는 것이 좋습니다.
+ 기본적으로 조직의 관리 계정은 조직에 초대된 멤버 계정에 대한 관리 액세스 권한이 없습니다. 관리 계정이 관리 제어 권한을 갖도록 하려면 멤버 계정에서 **OrganizationAccountAccessRole** IAM 역할을 생성하고, 관리 계정에게 해당 역할을 수임할 권한을 부여해야 합니다. 자세한 내용은 [초대된 멤버 계정에서 OrganizationAccountAccessRole 생성](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html#orgs_manage_accounts_create-cross-account-role)(AWS Organizations 문서)을 참조하세요.
+ 조직에 초대한 기존 계정의 경우 [멤버 계정에 대한 모범 사례](https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html)(AWS Organizations 문서)를 검토하고 계정이 이러한 권장 사항을 준수하는지 확인합니다.
## 에서 VPC 설정 사용자 지정 AWS Control Tower
의 [Account Factory](https://docs.aws.amazon.com/controltower/latest/userguide/account-factory.html)를 AWS 계정 통해 새로 프로비저닝하는 것이 좋습니다 AWS Control Tower. Account Factory를 AWS Control Tower 사용하면 Amazon EventBridge와의 통합을 사용하여 계정이 생성되는 AWS 계정 즉시 새에서 리소스를 프로비저닝할 수 있습니다.
새를 설정하면 AWS 계정[기본 Virtual Private Cloud(VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html)가 자동으로 프로비저닝됩니다. 그러나 Account Factory를 통해 새 계정을 설정하면 AWS Control Tower 가 자동으로 추가 VPC를 프로비저닝합니다. 자세한 내용은 [AWS Control Tower 및 VPCs](https://docs.aws.amazon.com/controltower/latest/userguide/vpc-concepts.html).AWS Control Tower 즉, 기본적으로 AWS Control Tower 는 모든 새 계정에 2개의 기본 VPC를 프로비저닝합니다.
기업에서는 계정 내 VPC에 대한 통제력을 강화하고자 하는 경우가 많습니다. 많은 사람들이 AWS CloudFormation Hashicorp Terraform 또는 Pulumi와 같은 다른 서비스를 사용하여 VPCs. AWS Control Tower에서 프로비저닝한 추가 VPC 생성을 방지하려면 Account Factory 설정을 사용자 지정해야 합니다. 지침은 [Amazon VPC 설정 구성](https://docs.aws.amazon.com/controltower/latest/userguide/configuring-account-factory-with-VPC-settings.html)(AWS Control Tower 문서)을 참조하고 다음 설정을 적용합니다.
1. **인터넷 액세스가 가능한 서브넷** 옵션을 비활성화합니다.
1. **최대 프라이빗 서브넷 수**에서 **0**을 선택합니다.
1. **VPC 생성용 리전**에서 모든 리전을 지웁니다.
1. **가용 영역**에서 **3**을 선택합니다.
*모범 사례*
+ 모든 새 계정에서 자동으로 프로비저닝되는 기본 VPC를 삭제합니다. 이렇게 하면 사용자가 전용 VPC를 명시적으로 생성하지 않고 계정에서 퍼블릭 EC2 인스턴스를 시작할 수 없습니다. 자세한 내용은 [기본 서브넷과 기본 VPC 삭제](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html#deleting-default-vpc)(Amazon Virtual Private Cloud 설명서)를 참조하세요. 새로 생성된 계정에서 기본 VPC를 자동으로 삭제하도록 [AWS Control Tower Account Factory for Terraform](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html)(AFT)을 구성할 수도 있습니다.
+ **dev-nonprod** AWS 계정 라는 새를 **워크로드** > **NonProd** 조직 단위로 프로비저닝합니다. 개발 환경에 이 계정을 사용합니다. 지침은 [를 사용하여 Account Factory 계정 프로비저닝 AWS Service Catalog](https://docs.aws.amazon.com/controltower/latest/userguide/provision-as-end-user.html)(AWS Control Tower 문서)을 참조하세요.
## 범위 기준 정의
새를 프로비저닝할지 여부를 결정할 때 회사에서 사용할 기준을 선택해야 합니다 AWS 계정. 사업부별로 계정을 프로비저닝하거나 프로덕션, 테스트, QA 등의 환경에 따라 계정을 프로비저닝하기로 결정할 수 있습니다. 모든 회사에는 얼마나 커야 하는지 또는 작아 AWS 계정 야 하는지에 대한 자체 요구 사항이 있습니다. 일반적으로 계정 규모 조정 방법을 결정할 때 다음 세 가지 요소를 평가합니다.
+ **서비스 할당량 밸런싱 **- *서비스 할당량은* AWS 서비스 내의 각에 대한 리소스, 작업 및 항목 수의 최대값입니다 AWS 계정. 많은 워크로드가 동일한 계정을 공유하고 한 워크로드가 서비스 할당량의 대부분 또는 전부를 소비하는 경우 동일한 계정의 다른 워크로드에 부정적인 영향을 미칠 수 있습니다. 이러한 경우 해당 워크로드들을 서로 다른 계정으로 분리해야 할 수 있습니다. 자세한 내용은 [AWS 서비스 quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)(AWS 일반 참조)를 참조하세요.
+ **비용 보고** - 워크로드를 별도의 계정으로 격리하면 비용 및 사용 보고서에서 계정 수준의 비용을 확인할 수 있습니다. 여러 워크로드에 동일한 계정을 사용하는 경우 태그를 사용하면 리소스를 관리하고 식별하는 데 도움이 됩니다. 태그 지정에 대한 자세한 내용은 [AWS 리소스 태그 지정](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)(AWS 일반 참조)을 참조하세요.
+ **액세스 제어** - 워크로드가 계정을 공유하는 경우 사용자가 필요 없는 워크로드에 액세스하지 못하도록 계정 리소스에 대한 액세스를 제한하도록 IAM 정책을 구성하는 방법을 고려해야 합니다. 또는 IAM Identity Center에서 여러 계정과 [권한 세트](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)를 사용하여 개별 계정에 대한 액세스를 관리할 수도 있습니다.
*모범 사례*
+ [AWSAWS Control Tower 랜딩 존에 대한 다중 계정 전략](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html)의 모범 사례를 준수합니다(AWS Control Tower 설명서).
+ AWS 리소스를 식별하고 관리하는 데 도움이 되는 효과적인 태깅 전략을 수립합니다. 태그를 사용하여 용도, 사업부, 환경 또는 기타 기준으로 리소스를 분류할 수 있습니다. 자세한 내용은 [태깅 모범 사례](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html#tag-best-practices)(AWS 일반 참조 문서)를 참조하세요.
+ 워크로드가 너무 많아 계정이 오버로드되지 않도록 합니다. 워크로드 수요가 서비스 할당량을 초과하는 경우 성능 문제가 발생할 수 있습니다. 경쟁하는 워크로드를 다른 워크로드로 분리 AWS 계정 하거나 서비스 할당량 증가를 요청할 수 있습니다. 자세한 내용은 [Requesting a quota increase](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)(Service Quotas 문서)를 참조하세요.