기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# AWS Control Tower에서 계정 프로비저닝 및 관리
이 장에는 다음 내용이 포함되어 있습니다.
+ AWS Control Tower에서 새 멤버 계정을 프로비저닝하고 관리하기 위한 개요와 절차.
+ AWS Control Tower에 기존 AWS 계정을 등록하기 위한 개요 및 절차입니다.
AWS Control Tower의 계정에 대한 일반 정보는 [AWS Control Tower AWS 계정 의 정보](accounts.md) 섹션을 참조하세요. AWS Control Tower에 여러 계정을 등록하는 방법에 대한 내용은 [AWS Control Tower에 기존 조직 단위 등록](importing-existing.md) 섹션을 참조하세요.
**참고**
단일 계정 프로비저닝, 업데이트 및 사용자 지정은 AWSControlTowerBaseline이 활성화된 조직 단위(OU)를 대상으로 해야 합니다. OU에 AWSControlTowerBaseline이 활성화되어 있지 않은 경우 계정 자동 등록을 활성화하거나 해당 OU의 EnabledBaselines 및 EnabledControls에서 ResetEnabledBaseline 및 ResetEnabledControl EnabledControls APIs를 사용하여 계정을 등록할 수 있습니다. EnabledBaselines AWSControlTowerBaseline에 대한 자세한 내용은 섹션을 참조하세요[OU 수준에서 적용되는 기준 유형](types-of-baselines.md#ou-baseline-types).
**참고**
프로비저닝, 업데이트 및 등록을 포함하여 최대 5개의 계정 관련 작업을 동시에 수행할 수 있습니다.
## 계정 프로비저닝에 필요한 권한
프로비저닝 담당자는 적절한 사용자 그룹 권한을 사용하여 조직의 모든 계정에 대해 표준화된 기준 및 네트워크 구성을 지정할 수 있습니다.
Account Factory를 사용하여 AWS Control Tower 콘솔에서 계정을 생성할 때는 AWS Control Tower 콘솔을 사용할 수 있는 권한과 함께 `AWSServiceCatalogEndUserFullAccess` 정책이 활성화된 IAM 사용자의 계정으로 로그인해야 하며 **루트** 사용자로 로그인할 수 없습니다.
**참고**
계정을 프로비저닝할 때 계정 요청자에게는 항상 `CreateAccount` 권한과 `DescribeCreateAccountStatus` 권한이 있어야 합니다. 이 권한 세트는 **관리자** 역할의 일부이며 요청자가 **관리자** 역할을 맡으면 자동으로 부여됩니다. 계정을 프로비저닝할 권한을 위임하는 경우 계정 요청자에 대해 이러한 권한을 직접 추가해야 할 수 있습니다.
AWS Control Tower에 필요한 권한에 대한 일반 정보는 [AWS Control Tower를 위한 ID 기반 정책(IAM 정책) 사용](access-control-managing-permissions.md) 섹션을 참조하세요. AWS Control Tower의 역할 및 계정에 대한 내용은 [역할 및 계정](https://docs.aws.amazon.com//controltower/latest/userguide/roles.html) 섹션을 참조하세요.
# AWS Control Tower 내에서 계정 프로비저닝
AWS Control Tower는 멤버 계정을 생성하고 업데이트하는 몇 가지 방법을 제공합니다. 어떤 방법은 기본적으로 콘솔 기반이며, 어떤 방법은 기본적으로 자동화 기반입니다.
**개요**
AWS Control Tower에서 멤버 계정을 생성하는 일반적인 방법은 Service Catalog에 속하는 콘솔 기반 제품인 Account Factory를 사용하는 것입니다. 또한, 랜딩 존이 드리프트 상태가 아닌 경우 AWS Control Tower 콘솔에서 **계정 생성**을 사용하여 새 계정을 프로비저닝할 수 있으며 **계정 등록**을 통해 AWS Control Tower에 기존 AWS 계정을 등록할 수 있습니다.
Account Factory를 사용하면 AWS Control Tower 기본 설정에 따라 기본 계정을 프로비저닝할 수 있습니다. 특수 사용 사례에 대한 요구 사항을 충족하는 *사용자 지정* 계정을 프로비저닝할 수도 있습니다.
[Account Factory 사용자 지정(AFC)](https://docs.aws.amazon.com//controltower/latest/userguide/af-customization-page.html)은 AWS Control Tower 콘솔에서 사용자 지정 계정을 프로비저닝하는 방법으로, 계정의 사용자 지정 및 배포를 자동화합니다. 일부 일회성 설정 단계 후 콘솔 기반 자동 프로비저닝이 가능하므로 스크립트를 작성하거나 파이프라인을 설정할 필요가 없습니다. 자세한 내용은 [Account Factory 사용자 지정(AFC)을 사용하여 계정 사용자 지정](af-customization-page.md) 단원을 참조하십시오.
**자동 등록**
또한 랜딩 존 **설정**의 **자동 계정 등록** 기능을 옵트인하는 경우 상속 드리프트를 생성하지 않고 AWS 계정 *외부* AWS Control Tower를 생성하고 AWS Control Tower에 등록된 OU로 이동할 수 있습니다. 자세한 내용은 [자동 등록을 사용하여 계정 이동 및 등록](account-auto-enrollment.md) 단원을 참조하십시오.
**콘솔 기반 방법:**
+ 기본 또는 사용자 지정 계정의 경우 AWS Service Catalog의 일부인 Account Factory 콘솔을 통해. 세부 정보 및 지침은 [Account Factory로 계정 프로비저닝 및 관리](account-factory.md) 섹션을 참조하세요.
+ 자동 등록을 통해 콘솔에서 계정을 OU로 이동. [자동 등록을 사용하여 계정 이동 및 등록](account-auto-enrollment.md) 섹션을 참조하세요.
+ 랜딩 존이 드리프트 상태가 아닌 경우 AWS Control Tower의 **계정 등록** 기능을 통해. [AWS Control Tower 콘솔에서 기존 계정 등록](quick-account-provisioning.md) 섹션을 참조하세요.
+ AWS Control Tower 콘솔에서 Account Factory를 사용하여 동시에 최대 5개의 계정을 생성, 업데이트 또는 등록할 수 있습니다.
**자동화된 메서드:**
+ **Lambda 코드: **AWS Control Tower 랜딩 존의 관리 계정에서 Lambda 코드와 적절한 IAM 역할 사용. [IAM 역할을 사용한 자동화된 계정 프로비저닝](https://docs.aws.amazon.com//controltower/latest/userguide/roles-how.html#stacksets-and-roles)을 참조하세요.
+ **Terraform: **계정 프로비저닝 및 업데이트를 자동화할 수 있도록 Account Factory 및 GitOps 모델에 의존하는 AWS Control Tower Account Factory for Terraform(AFT)에서. [AWS Control Tower Account Factory for Terraform(AFT)을 사용하여 계정 프로비저닝](taf-account-provisioning.md) 섹션을 참조하세요.
+ 자동 등록을 통해 API를 사용하여 기존 계정을 OU로 이동. [자동 등록을 사용하여 계정 이동 및 등록](account-auto-enrollment.md) 섹션을 참조하세요.
+ **AWS Control Tower 콘솔의 Account Factory 사용자 지정:** 설정 단계 후 사용자 지정 계정을 나중에 프로비저닝할 때 추가 구성이나 파이프라인 유지 관리가 필요하지 않습니다. 계정은 *블루프린*트라는 AWS Service Catalog 제품을 통해 프로비저닝됩니다. 블루프린트는 CloudFormation 템플릿 또는 Terraform 템플릿을 사용할 수 있습니다.
**참고**
CloudFormation 블루프린트는 리소스를 여러 리전에 배포할 수 있습니다. Terraform 블루프린트는 리소스를 단일 리전에만 배포할 수 있습니다. 기본적으로 이 리전은 홈 리전입니다.
# AWS Control Tower에서 계정 프로비저닝
다음 절차에서는 AWS Control Tower를 통해 IAM Identity Center에서 사용자로 계정을 생성하고 프로비저닝하는 방법을 설명합니다. 이 절차를 *수동 계정 프로비저닝*이라고도 합니다. 선택적으로AWS CLI, Service Catalog APIs 또는 AWS Control Tower Account Factory for Terraform(AFT)을 사용하여 프로그래밍 방식으로 AWS Control Tower 계정을 프로비저닝하거나 기존 계정을 등록된 OU에 자동으로 등록할 수 있습니다. 이전에 사용자 지정 블루프린트를 설정한 경우 콘솔에서 사용자 지정 계정을 프로비저닝할 수 있습니다. 사용자 지정에 대한 자세한 내용은 [Account Factory 사용자 지정(AFC)을 사용하여 계정 사용자 지정](af-customization-page.md)을 참조하세요.
**AWS Control Tower 콘솔에서 사용자로 계정을 개별적으로 프로비저닝하는 방법**
1. 에 로그인AWS하고 AWS Control Tower 콘솔로 이동합니다.
1. 왼쪽 탐색에서 **조직**을 선택하여 **조직** 페이지를 확인합니다.
1. 오른쪽 상단에서 **리소스 생성**을 선택합니다.
1. 드롭다운 메뉴에서 **계정 생성**을 선택합니다.
1. 페이지에서 정보를 입력합니다. 이때 다음 사항에 유의하세요.
+ **계정 이메일**은 기존에AWS 계정에 연결되지 않은 이메일 주소여야 합니다.
+ 표시 이름은 이 계정에 대해 보려는 이름입니다.
1. 필드를 입력하여 IAM Identity Center 이메일 주소 및 사용자 이름으로 **액세스 구성**을 정의합니다.
1. 드롭다운 목록에서 등록된 OU를 선택하여 계정을 프로비저닝하려는 OU를 표시합니다.
1. 선택적으로 사전 정의된 블루프린트를 사용하여 사용자 지정 리소스를 이용하여 계정을 프로비저닝합니다. 이 작업을 나중에 수행할 수도 있습니다.
1. 계정 선택을 검토한 다음 오른쪽 하단에서 **계정 생성**을 선택합니다.
1. 이제 계정이 프로비저닝됩니다. 이 작업은 완료하는 데 몇 분 정도 걸릴 수 있습니다. 페이지를 새로 고쳐 표시된 상태 정보를 업데이트할 수 있습니다.
**참고**
한 번에 최대 5개의 계정을 프로비저닝할 수 있습니다.
# 계정 보기
**조직** 페이지에는 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에서 완전히 관리됩니다.
+ **등록 실패** - AWS Control Tower에 계정을 등록할 수 없습니다. 자세한 내용은 [등록 실패의 일반적인 원인](quick-account-provisioning.md#common-causes-for-enrollment-failure) 단원을 참조하십시오.
+ **업데이트 사용 가능** - 계정에 사용 가능한 업데이트가 있습니다. 이 상태의 계정은 여전히 **등록됨** 상태이지만 환경에 대한 최근 변경 사항을 반영하도록 계정을 업데이트해야 합니다. 단일 계정을 업데이트하려면 계정 세부 정보 페이지로 이동하여 **계정 업데이트**를 선택합니다.
단일 OU에 이 상태의 계정이 여러 개 있는 경우 OU를 **재등록**하고 해당 계정들을 함께 업데이트하도록 선택할 수 있습니다.
# 기존 계정 등록 정보
AWS Control Tower 거버넌스를 AWS Control Tower에서 이미 관리하는 조직 단위(OU)에 *등록할* AWS 계정 때 존재하는 개별 로 확장할 수 있습니다. 적격 계정은 AWS Control Tower *OUs와 동일한 AWS Organizations 조직의 일부인 등록되지 않은* OU에 존재합니다.
AWS Control Tower에 계정을 등록하는 몇 가지 방법이 있습니다. **이 페이지의 정보는 모든 등록 방법에 적용됩니다.**
**참고**
초기 랜딩 존 설정 중에만 기존 AWS 계정을 등록하여 감사 또는 로그 아카이브 계정으로 사용할 수 있습니다.
## 계정 등록 중에 발생하는 일
등록 프로세스 중에 AWS Control Tower는 다음 작업을 수행합니다.
+ 다음 스택 세트의 배포를 포함하여 계정에 기준을 설정합니다.
+ `AWSControlTowerBP-BASELINE-CLOUDTRAIL`
+ `AWSControlTowerBP-BASELINE-CLOUDWATCH`
+ `AWSControlTowerBP-BASELINE-CONFIG`
+ `AWSControlTowerBP-BASELINE-ROLES`
+ `AWSControlTowerBP-BASELINE-SERVICE-ROLES`
+ `AWSControlTowerBP-BASELINE-SERVICE-LINKED-ROLES`
+ `AWSControlTowerBP-VPC-ACCOUNT-FACTORY-V1`
이러한 스택 세트의 템플릿을 검토하고 기존 정책과 충돌하지 않도록 하는 것이 좋습니다.
+ AWS IAM Identity Center 또는를 통해 계정을 식별합니다 AWS Organizations.
+ 지정한 OU에 계정을 배치합니다. 보안 상태가 일관되게 유지되도록 현재 OU에 적용된 모든 SCP를 적용해야 합니다.
+ 선택한 OU 전체에 적용되는 SCP를 통해 계정에 필수 제어를 적용합니다.
+ 계정의 모든 리소스를 기록하도록 활성화 AWS Config 하고 구성합니다.
+ AWS Control Tower 탐지 제어를 계정에 적용하는 AWS Config 규칙을 추가합니다.
**계정 및 조직 수준 CloudTrail 추적**
랜딩 존 버전이 3.1 이상이고 랜딩 존 설정에서 선택적 AWS CloudTrail 통합을 선택한 경우:
OU의 모든 멤버 계정은 등록 여부에 관계없이 OU의 AWS CloudTrail 추적에 의해 관리됩니다.
AWS Control Tower에 계정을 등록하면 새 조직의 AWS CloudTrail 추적이 계정에 적용됩니다. 기존에 배포된 CloudTrail 추적이 있는 경우 AWS Control Tower에 계정을 등록하기 전에 계정에 대한 기존 추적을 삭제하지 않으면 중복 요금이 부과될 수 있습니다.
예를 들어 AWS Organizations 콘솔 또는 APIs를 사용하여 계정을 등록된 OU로 이동하는 경우 계정에 대한 나머지 계정 수준 추적을 제거할 수 있습니다. CloudTrail 추적을 기존에 배포한 경우 CloudTrail 요금이 중복 부과됩니다.
랜딩 존을 업데이트하고 조직 수준 추적을 옵트아웃하도록 선택하거나 랜딩 존이 버전 3.0보다 오래된 경우 조직 수준 CloudTrail 추적이 계정에 적용되지 않습니다.
## VPC에 기존 계정 등록
AWS Control Tower는 사용자가 Account Factory에서 새 계정을 프로비저닝할 때 기존 계정을 등록할 때와 다르게 VPC를 처리합니다.
+ 새 계정을 만들면 AWS Control Tower에서 자동으로 AWS 기본 VPC를 제거하고 해당 계정에 대한 새 VPC를 생성합니다.
+ 기존 계정을 등록하면 AWS Control Tower에서 해당 계정에 대한 새 VPC를 생성하지 않습니다.
+ 기존 계정을 등록할 때 AWS Control Tower는 계정과 연결된 기존 VPC 또는 AWS 기본 VPC를 제거하지 않습니다.
**작은 정보**
Account Factory를 구성하여 새 계정의 기본 동작을 변경할 수 있으므로, AWS Control Tower에서 조직의 계정에 대해 기본적으로 VPC가 설정되지 않습니다. 자세한 내용은 [AWS Control Tower에서 VPC 없이 계정 생성](configure-without-vpc.md#create-without-vpc) 단원을 참조하십시오.
## AWS Config 리소스에 계정 등록
등록할 계정에 기존 AWS Config 리소스가 없어야 합니다. [기존 AWS Config 리소스가 있는 계정 등록을](https://docs.aws.amazon.com//controltower/latest/userguide/existing-config-resources.html) 참조하세요.
다음은 구성 레코더 및 전송 채널과 같은 기존 계정 AWS Config 리소스의 상태를 확인하는 데 사용할 수 있는 몇 가지 AWS Config CLI 명령의 예입니다.
**보기 명령:**
+ `aws configservice describe-delivery-channels`
+ `aws configservice describe-delivery-channel-status`
+ `aws configservice describe-configuration-recorders`
일반적인 응답은 `"name": "default"`와 같습니다.
**삭제 명령:**
+ `aws configservice stop-configuration-recorder --configuration-recorder-name NAME-FROM-DESCRIBE-OUTPUT`
+ `aws configservice delete-delivery-channel --delivery-channel-name NAME-FROM-DESCRIBE-OUTPUT`
+ `aws configservice delete-configuration-recorder --configuration-recorder-name NAME-FROM-DESCRIBE-OUTPUT`
# 등록을 위한 사전 조건
*이 섹션에서는 랜딩 존 **설정** 페이지에서 선택적 자동 등록 기능을 선택하지 않았거나 3.1 이전 랜딩 존 버전으로 작업하는 경우 기존 AWS 계정을 AWS Control Tower에 등록하는 방법을 설명합니다.*
AWS Control Tower AWS 계정 에 기존를 등록하려면 다음 사전 조건이 필요합니다.
**참고**
랜딩 존 **설정** 페이지에서 AWS Control Tower 자동 등록 기능을 활성화했거나 **OU** 등록 프로세스의 일부로 계정을 등록하는 경우 `AWSControlTowerExecution` 역할을 추가하기 위한 사전 조건은 필요하지 않습니다. 그러나 모든 경우에 등록할 계정에 기존 AWS Config 리소스가 없을 수 있습니다. [기존 AWS Config 리소스가 있는 계정 등록](https://docs.aws.amazon.com//controltower/latest/userguide/existing-config-resources.html)을 참조하세요.
1. 기존를 등록하려면 등록하려는 계정에 AWS 계정`AWSControlTowerExecution` 역할이 있어야 합니다. [계정 등록](https://docs.aws.amazon.com//controltower/latest/userguide/quick-account-provisioning.html)에서 세부 정보 및 지침을 확인할 수 있습니다.
1. `AWSControlTowerExecution` 역할 외에도 등록하려는 기존 AWS 계정 에는 다음과 같은 권한과 신뢰 관계가 있어야 합니다. 그러지 않으면 등록이 실패합니다.
역할 권한: `AdministratorAccess` (AWS 관리형 정책)
**역할 신뢰 관계:**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
1. 계정에 AWS Config 구성 레코더 또는 전송 채널이 없어야 합니다. 계정을 등록하기 전에 AWS CLI 를 통해 삭제하거나 수정할 수 있습니다. 그렇지 않으면 [기존 AWS Config 리소스를 수정하는 방법에 대한 지침은 기존 리소스가 있는 계정 등록](https://docs.aws.amazon.com//controltower/latest/userguide/existing-config-resources.html)을 검토하세요.
1. 등록하려는 계정은 AWS Control Tower 관리 계정과 동일한 AWS Organizations 조직 내에 있어야 합니다. 존재하는 계정은 AWS Control Tower에 이미 등록된 OU의 AWS Control Tower 관리 계정과 동일한 *조직에만* 등록할 수 있습니다.
등록을 위한 다른 사전 조건을 확인하려면 [AWS Control Tower 시작하기](https://docs.aws.amazon.com//controltower/latest/userguide/getting-started-with-control-tower.html)를 참조하세요.
**참고**
AWS Control Tower에 계정을 등록하면 해당 계정이 AWS Control Tower 조직의 AWS CloudTrail 추적에 의해 관리됩니다. 기존에 배포된 CloudTrail 추적이 있는 경우 AWS Control Tower에 계정을 등록하기 전에 계정에 대한 기존 추적을 삭제하지 않으면 중복 요금이 부과될 수 있습니다.
**`AWSControTowerExecution` 역할을 사용한 신뢰할 수 있는 액세스 정보**
AWS Control Tower AWS 계정 에 기존를 등록하려면 먼저 AWS Control Tower가 계정을 관리하거나 *관리할* 수 있는 권한을 부여해야 합니다. 특히 AWS Control Tower는가 선택한 조직의 계정에 스택을 자동으로 배포할 수 있도록 AWS CloudFormation 와 간에 AWS Organizations 사용자를 대신하여 신뢰할 CloudFormation 수 있는 액세스를 설정할 수 있는 권한이 필요합니다. 이 신뢰할 수 있는 액세스를 통해 `AWSControlTowerExecution` 역할은 각 계정을 관리하는 데 필요한 활동을 수행합니다. 따라서 등록하기 전에 각 계정에 이 역할을 추가해야 합니다.
신뢰할 수 있는 액세스가 활성화되면는 단일 작업 AWS 리전 으로 여러 계정에서 스택을 생성, 업데이트 또는 삭제할 수 CloudFormation 있습니다. AWS Control Tower는 이러한 신뢰 기능을 활용하여 기존 계정에 역할과 권한을 적용한 후 계정을 등록된 조직 단위로 옮기고, 이를 통해 계정을 관리할 수 있습니다.
신뢰할 수 있는 액세스 및에 대한 자세한 내용은 [AWS CloudFormationStackSets 및 AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudformation.html) AWS CloudFormation StackSets섹션을 참조하세요.
# 자동 등록을 사용하여 계정 이동 및 등록
계정 자동 등록 기능은 버전 3.1 이상의 랜딩 존에서 사용할 수 있습니다.
선택적으로이 기능을 활성화하면 [https://docs.aws.amazon.com//controltower/latest/userguide/governance-drift.html](https://docs.aws.amazon.com//controltower/latest/userguide/governance-drift.html)를 생성하지 않고도 AWS Organizations APIs 및 콘솔을 사용하여 계정을 AWS Control Tower로 이동할 수 있습니다. 계정은 AWS Control Tower의 대상 조직 단위(OU)로부터 기준 리소스 및 제어 구성을 자동으로 수신합니다. 또한 이 선택적 기능을 사용하면 두 OU에 동일한 기준 구성이 있고 동일한 제어가 활성화된 경우 상속 드리프트를 생성하지 않고 AWS Control Tower 내의 OU 간에 계정을 이동할 수 있습니다.
**자동 등록 활성화:** AWS Control Tower 콘솔의 랜딩 존 **설정** 페이지에서 또는 AWS Control Tower `CreateLandingZone` 또는 `UpdateLandingZone` API를 직접적으로 호출하여 계정 자동 등록을 선택할 수 있으며 `RemediationType` 파라미터 값은 **상속 드리프트**로 설정됩니다.
**자동 등록 적용:** **설정** 페이지에서이 옵션을 선택한 후 AWS Organizations 콘솔 AWS Organizations `MoveAccount`, API 또는 AWS Control Tower 콘솔을 사용하여 계정을 이동할 수 있습니다.
**자동 등록으로 계정 등록 취소:** 계정이 등록된 OU 외부로 계정을 이동하는 경우 AWS Control Tower는 배포된 모든 기준 리소스를 자동으로 제거하고 제어합니다.
**참고**
AWS Control Tower의 소스 및 대상 OU 구성이 다른 경우 계정에 [이동된 멤버 계정](governance-drift.md#drift-account-moved) 드리프트가 표시될 수 있습니다.
## 사전 조건: 자동 등록을 위한 구성
+ AWS Control Tower 랜딩 존 버전 3.1 이상을 실행해야 합니다.
+ 콘솔의 랜딩 존 **설정** 페이지 또는 AWS Control Tower 랜딩 존 API를 통해 `RemediationTypes` 파라미터 값을 `Inheritance Drift`로 설정하여 AWS Control Tower 자동 등록 기능을 옵트인합니다. 옵트인하면 AWS Control Tower는에 대한 `move account` 이벤트에 응답 AWS Organizations하고 사용자를 대신하여 이동된 계정의 상속 드리프트를 즉시 해결합니다.
## 필수 권한
`CreateAccount` API 및 `MoveAccount` API를 AWS Organizations 사용하려면 특정 역할과 권한이 필요합니다. AWS Control Tower AWS Organizations 에서를 사용하는 방법에 대한 자세한 내용은 [AWS Control Tower 및 AWS Organizations](https://docs.aws.amazon.com//organizations/latest/userguide/services-that-can-integrate-CTower.html) 섹션을 참조하세요.
## API 사용 예제
이러한 API에 대한 자세한 내용과 예제는 *AWS Organizations API 참조*의 [https://docs.aws.amazon.com//organizations/latest/APIReference/API_CreateAccount.html](https://docs.aws.amazon.com//organizations/latest/APIReference/API_CreateAccount.html) 및 [https://docs.aws.amazon.com//organizations/latest/APIReference/API_MoveAccount.html](https://docs.aws.amazon.com//organizations/latest/APIReference/API_MoveAccount.html) 섹션을 참조하세요.
## 고려 사항
+ **등록 타임라인:** AWS Control Tower에 등록된 OU로 이동된 계정이 *최종 일관성* 모델에 등록됩니다. 이 프로세스는 이동 중인 계정 수에 따라 일반적으로 몇 분, 최대 몇 시간이 걸립니다.
+ **등록 취소 프로세스:** 동일한 프로세스를 사용하여 계정을 AWS Control Tower 외부의 OU로 이동하여 AWS Control Tower에서 계정을 등록 취소할 수 있습니다. 이 프로세스는 AWS Control Tower에서 배포한 모든 역할 및 리소스와 AWS Control Tower에서 활성화된 모든 제어를 제거합니다.
# AWS Control Tower 콘솔에서 기존 계정 등록
AWS Control Tower에 개인을 등록 AWS 계정 하는 두 가지 일반적인 방법이 있습니다.
1. **설정** 페이지에서 *자동 등록* 기능을 선택한 후 AWS Control Tower AWS 계정 외부에서를 생성하고 등록된 OU로 직접 이동할 수 있습니다. 자세한 내용은 [자동으로 계정 이동 및 등록](https://docs.aws.amazon.com//controltower/latest/userguide/account-auto-enroll.html)을 참조하세요. 이 옵션은 랜딩 존 버전 3.1 이상에서 사용할 수 있습니다.
1. AWS Control Tower 콘솔에서 기존 계정을 수동으로 등록할 수 있습니다.
다음 섹션에서는 AWS Control Tower 환경의 이전 구성이 필요 없는 **두 번째 옵션**에 대해 설명합니다. 는 필수 [사전 조건을](https://docs.aws.amazon.com//controltower/latest/userguide/enrollment-prerequisites.html) 충족해야 AWS 계정 합니다.
**콘솔에서 적격 계정 확인:**
1. AWS Control Tower의 **조직** 페이지로 이동합니다.
1. 등록하려는 계정의 이름을 찾습니다. 계정 이름을 찾으려면 오른쪽 상단의 드롭다운 메뉴에서 **계정만**을 선택한 다음 필터링된 표에서 찾으면 됩니다.
다음으로, [수동 계정 등록 단계](#enrollment-steps) 섹션에 표시된 대로 개별 계정을 등록하는 단계를 따릅니다.
## 콘솔에서 등록 시 고려 사항
+ AWS Control Tower 콘솔에서 사용할 수 있는 **계정 등록** 기능은 AWS Control Tower에서 관리 AWS 계정 하도록 기존를 등록하기 위한 것입니다. 자세한 내용은 [기존 AWS 계정등록](https://docs.aws.amazon.com/controltower/latest/userguide/enroll-account.html)을 참조하세요.
+ 콘솔 기반의 **계정 등록** 기능은 랜딩 존이 [드리프트](https://docs.aws.amazon.com//controltower/latest/userguide/drift.html) 상태가 아닐 때 사용할 수 있습니다. 랜딩 존이 드리프트 상태인 경우 **계정 등록** 기능을 사용하지 못할 수 있습니다. 랜딩 존 드리프트가 해결될 때까지 Account Factory 또는 다른 방법을 통해 새 계정을 프로비저닝해야 합니다.
+ AWS Control Tower 콘솔에서 계정을 등록할 때는 AWS Control Tower 콘솔을 사용할 수 있는 **관리자** 액세스 권한과 함께 `AWSServiceCatalogEndUserFullAccess` 정책이 활성화된 사용자로 계정에 로그인해야 하며, 루트 사용자로 로그인할 수 없습니다.
+ 등록하는 계정은 다른 계정과 마찬가지로 AWS Control Tower Account Factory를 통해 업데이트될 수 있습니다. 업데이트 절차는 [AWS Control Tower를 사용하여 계정 업데이트 및 이동](updating-account-factory-accounts.md) 섹션에 나와 있습니다.
**참고**
기존를 등록할 때는 기존 이메일 주소를 확인해야 AWS 계정합니다. 그러지 않으면 새 계정이 생성될 수 있습니다.
## 수동 계정 등록 단계
기존 AWS 계정 계정에 **AdministratorAccess** 액세스 권한(정책)이 적용되면 다음 단계에 따라 계정을 등록합니다.
**AWS Control Tower에 개별 계정을 등록하는 방법**
+ AWS Control Tower **조직** 페이지로 이동합니다.
+ **조직** 페이지에서 등록할 수 있는 계정의 경우 섹션 상단의 **작업** 드롭다운 메뉴에서 **등록**을 선택할 수 있습니다. 이러한 계정은 **계정 세부 정보 페이지에서 볼 때 계정 등록** 버튼도 표시합니다. ****
+ **계정 등록**을 선택하면 **계정 등록** 페이지가 나타나 계정에 `AWSControlTowerExecution` 역할을 추가하라는 메시지가 표시됩니다. 지침은 [필요한 IAM 역할을 기존에 수동으로 추가 AWS 계정 하고 등록합니다.](enroll-manually.md) 섹션을 참조하세요.
+ 그런 다음 드롭다운 목록에서 등록된 OU를 선택합니다. 계정이 이미 등록된 OU에 있는 경우 이 목록에 OU가 표시됩니다.
+ **계정 등록**을 선택합니다.
+ `AWSControlTowerExecution` 역할을 추가하고 작업을 확인하는 모달 알림이 표시됩니다.
+ **등록**을 선택합니다.
+ AWS Control Tower가 등록 프로세스를 시작하면 **계정 세부 정보** 페이지로 돌아갑니다.
## 등록 실패의 일반적인 원인
+ 기존 계정을 등록하려면 등록하려는 계정에 `AWSControlTowerExecution` 역할이 있어야 합니다.
+ IAM 위탁자에는 계정을 프로비저닝하는 데 필요한 권한이 부족할 수 있습니다.
+ AWS Security Token Service (AWS STS)는 홈 리전 또는 AWS Control Tower에서 지원하는 모든 리전의 AWS 계정 에서 비활성화됩니다.
+ AWS Service Catalog의 Account Factory 포트폴리오에 추가해야 하는 계정에 로그인되어 있을 수 있습니다. AWS Control Tower에서 계정을 만들거나 등록할 수 있도록 Account Factory에 액세스하려면 먼저 계정을 추가해야 합니다. 적절한 사용자 또는 역할이 Account Factory 포트폴리오에 추가되지 않은 경우, 계정을 추가하려고 하면 오류가 발생합니다. AWS Service Catalog 포트폴리오에 대한 액세스 권한을 부여하는 방법에 대한 지침은 [사용자에게 액세스 권한 부여를](https://docs.aws.amazon.com//servicecatalog/latest/adminguide/catalogs_portfolios_users.html) 참조하세요.
+ 루트로 로그인되어 있을 수 있습니다.
+ 등록하려는 계정에 남은 AWS Config 설정이 있을 수 있습니다. 특히, 계정에는 구성 레코더 또는 전송 채널이 있을 수 있습니다. 계정을 등록 AWS CLI 하려면 먼저를 통해 삭제하거나 수정해야 합니다. 자세한 내용은 [기존 AWS Config 리소스가 있는 계정 등록](existing-config-resources.md) 및 [를AWS Control Tower통해와 상호 작용AWS CloudShell](cshell-examples.md) 섹션을 참조하세요.
+ 계정이 다른 AWS Control Tower OU를 포함하여 관리 계정이 있는 다른 OU에 속하는 경우 다른 OU에 조인하기 전에 현재 OU에서 계정을 종료해야 합니다. 기존 리소스는 원래 OU에서 제거해야 합니다. 그러지 않으면 등록이 실패합니다.
+ 대상 OU의 SCP에서 해당 계정에 필요한 모든 리소스를 생성할 수 없는 경우 계정 프로비저닝 및 등록이 실패합니다. 예를 들어, 대상 OU의 SCP는 특정 태그 없이 리소스 생성을 차단할 수 있습니다. 이 경우 AWS Control Tower는 리소스 태그 지정을 지원하지 않으므로, 계정 프로비저닝 또는 등록이 실패합니다. 도움이 필요하면 계정 담당자 또는 지원에 문의하세요.
새 계정을 만들거나 기존 계정을 등록할 때 AWS Control Tower에서 역할이 작동하는 방식에 대한 자세한 내용은 [역할 및 계정](https://docs.aws.amazon.com//controltower/latest/userguide/roles.html)을 참조하세요.
**작은 정보**
기존가 등록 사전 조건을 AWS 계정 충족하는지 확인할 수 없는 경우 **등록 OU**를 설정하고 해당 OU에 계정을 등록할 수 있습니다. 등록에 성공하면 계정을 원하는 OU로 이동할 수 있습니다. 등록이 실패해도 다른 계정이나 OU가 실패로 인해 영향을 받지 않습니다.
기존 계정 및 해당 구성이 AWS Control Tower와 호환되는지 확실하지 않은 경우 다음 섹션에서 권장하는 모범 사례를 따를 수 있습니다.
**권장 사항: 계정 등록에 대한 2단계 접근 방식을 설정할 수 있습니다.**
+ 먼저 AWS Config *적합성 팩*을 사용하여 계정이 일부 AWS Control Tower 제어의 영향을 받을 수 있는 방법을 평가합니다. AWS Control Tower 등록이 계정에 미치는 영향을 확인하려면 [AWS Config 적합성 팩을 사용하여 AWS Control Tower 거버넌스 확장](https://aws.amazon.com//blogs/mt/extend-aws-control-tower-governance-using-aws-config-conformance-packs/)을 참조하세요.
+ 그런 다음 계정을 등록할 수 있습니다. 규정 준수 결과가 만족스럽다면 예기치 않은 결과 없이 계정을 등록할 수 있으므로 마이그레이션 과정이 더 원활해집니다.
+ 평가를 완료한 후 AWS Control Tower 랜딩 존을 설정하기로 결정한 경우 평가를 위해 생성된 AWS Config 전송 채널 및 구성 레코더를 제거해야 할 수 있습니다. 그러면 AWS Control Tower를 성공적으로 설정할 수 있습니다.
**참고**
적합성 팩은 계정이 AWS Control Tower에 등록된 OUs에 있지만 워크로드가 AWS Control Tower가 지원되지 않는 AWS 리전 내에서 실행되는 경우에도 작동합니다. 적합성 팩을 사용하여 AWS Control Tower가 배포되지 않은 리전에 있는 계정의 리소스를 관리할 수 있습니다.
# 계정이 사전 조건을 충족하지 않는 경우
AWS Control Tower 거버넌스에 등록할 수 있는 계정은 동일한 전체 조직의 일부여야 한다는 사전 조건을 염두에 두세요. 계정 등록 시 이 사전 조건을 충족하려면 다음 준비 단계에 따라 계정을 AWS Control Tower와 동일한 조직으로 이동합니다.
**AWS Control Tower와 동일한 조직에 계정을 가져오는 준비 단계**
1. 기존 조직에서 계정을 삭제합니다. 이 접근 방식을 사용하는 경우 별도의 결제 방법을 제공해야 합니다.
1. 계정을 AWS Control Tower 조직에 조인하도록 초대합니다. 자세한 내용은 *AWS Organizations 사용 설명서*의 [조직에 가입하도록 AWS 계정 초대를 참조하세요](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_manage_accounts_invites.html).
1. 초대를 수락합니다. 계정이 조직의 루트에 표시됩니다. 이 단계에서는 계정을 AWS Control Tower와 동일한 조직으로 이동하고 SCP 및 통합 결제를 설정합니다.
**작은 정보**
계정이 이전 조직에서 삭제되기 전에 새 조직에 대한 초대를 보낼 수 있습니다. 초대는 계정이 공식적으로 기존 조직에서 삭제될 때까지 기다립니다.
**나머지 사전 조건을 충족하는 단계:**
1. 필요한 `AWSControlTowerExecution` 역할을 만듭니다.
1. 기본 VPC를 지웁니다. (이 부분은 선택 사항입니다. AWS Control Tower는 기존 기본 VPC를 변경하지 않습니다.)
1. AWS CLI 또는를 통해 기존 AWS Config 구성 레코더 또는 전송 채널을 삭제하거나 수정합니다 AWS CloudShell. 자세한 내용은 [AWS Config 리소스에 계정 등록](enroll-account.md#example-config-cli-commands) 및 [기존 AWS Config 리소스가 있는 계정 등록](existing-config-resources.md) 섹션을 참조하세요.
이러한 준비 단계를 완료한 후 AWS Control Tower에 계정을 등록할 수 있습니다. 자세한 내용은 [수동 계정 등록 단계](quick-account-provisioning.md#enrollment-steps) 섹션을 참조하세요. 이 단계에서는 계정을 전체 AWS Control Tower 거버넌스로 가져옵니다.
**계정을 등록하고 스택을 유지할 수 있도록 계정 프로비저닝을 취소하는 선택적 단계**
1. 적용된 CloudFormation 스택을 유지하려면 스택 세트에서 스택 인스턴스를 삭제하고 인스턴스에 대한 **스택 유지**를 선택합니다.
1. AWS Service Catalog Account Factory에서 계정 프로비저닝된 제품을 종료합니다. (이 단계는 AWS Control Tower에서 프로비저닝된 제품만 제거합니다. 계정은 삭제되지 않습니다.)
1. 조직에 속하지 않은 모든 계정에 필요한 필수 결제 세부 정보로 계정을 설정합니다. 그런 다음 조직에서 계정을 제거합니다. (이 작업을 수행하면 계정이 AWS Organizations 할당량의 합계에 포함되지 않습니다.)
1. 리소스가 남아 있는 경우 계정을 정리한 다음 [계정 등록 취소](unmanage-account.md)의 계정 종료 단계에 따라 계정을 닫습니다.
1. 제어가 정의된 **일시 중지된** OU가 있는 경우 1단계를 수행하는 대신 해당 OU로 계정을 이동할 수 있습니다.
# 필요한 IAM 역할을 기존에 수동으로 추가 AWS 계정 하고 등록합니다.
AWS Control Tower 랜딩 존을 설정해 둔 경우 AWS Control Tower에 등록된 OU에 조직의 계정을 등록할 수 있습니다. 랜딩 존을 설정하지 않은 경우 *AWS Control Tower 사용 설명서*의 [Getting Started, 2단계](https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-with-control-tower.html#step-two)에 설명된 단계를 따릅니다. 랜딩 존이 준비되면 다음 단계를 완료하여 AWS Control Tower에서 기존 계정을 거버넌스로 수동으로 가져옵니다.
**이 장의 앞부분에서 언급한 [등록을 위한 사전 조건](enrollment-prerequisites.md)를 반드시 검토하세요.**
AWS Control Tower에 계정을 등록하기 전에 AWS Control Tower에 해당 계정을 관리할 수 있는 권한을 부여해야 합니다. 이렇게 하려면 다음 단계에 표시된 대로 계정에 대한 전체 액세스 권한이 있는 역할을 추가해야 합니다. 등록하는 각 계정에 대해 이러한 단계를 수행해야 합니다.
**각 계정의 경우:**
**1단계: 현재 등록하려는 계정이 포함된 조직의 관리 계정에 대한 관리자 액세스 권한으로 로그인합니다.**
예를 들어에서이 계정을 생성하고 교차 계정 IAM 역할을 AWS Organizations 사용하여 로그인하는 경우 다음 단계를 수행할 수 있습니다.
1. 조직의 관리 계정에 로그인합니다.
1. **AWS Organizations**로 이동합니다.
1. **계정**에서 등록할 계정을 선택하고 계정 ID를 복사합니다.
1. 상단 탐색 모음에서 계정 드롭다운 메뉴를 열고 **역할 전환**을 선택합니다.
1. **역할 전환** 양식에서 다음 필드를 입력합니다.
+ **계정**에서 복사한 계정 ID를 입력합니다.
+ **역할**에서 이 계정에 대한 교차 계정 액세스를 활성화하는 IAM 역할의 이름을 입력합니다. 이 역할의 이름은 계정이 생성될 때 정의되었습니다. 계정을 만들 때 역할 이름을 지정하지 않은 경우 기본 역할 이름인 `OrganizationAccountAccessRole`을 입력합니다.
1. **역할 전환**을 선택합니다.
1. 이제 하위 계정으로 AWS Management Console 에 로그인해야 합니다.
1. 완료되면 절차의 다음 부분을 수행하기 위해 하위 계정을 그대로 사용합니다.
1. 다음 단계에서 입력해야 하므로 관리 계정 ID를 기록해 둡니다.
**2단계: AWS Control Tower에 계정을 관리할 수 있는 권한을 부여합니다.**
1. **IAM**으로 이동합니다.
1. **역할**로 이동합니다.
1. **역할 생성**을 선택합니다.
1. 역할이 어떤 서비스를 위한 것인지 선택하라는 메시지가 표시되면 **사용자 지정 신뢰 정책**을 선택합니다.
1. 여기에 표시된 코드 예제를 복사하여 정책 문서에 붙여넣습니다. *`Management Account ID`* 문자열을 관리 계정의 실제 관리 계정 ID로 바꿉니다. 붙여넣을 정책은 다음과 같습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
```
------
1. 정책을 연결하라는 메시지가 표시되면 **AdministratorAccess**를 선택합니다.
1. **다음: 태그**를 선택합니다.
1. **태그 추가**라는 선택적 화면이 표시될 수 있습니다. **다음:검토**를 선택하여 지금 이 화면을 건너뜁니다.
1. **검토** 화면에서 **역할 이름** 필드에 `AWSControlTowerExecution`을 입력합니다.
1. *등록을 위한 전체 계정 액세스 허용*과 같은 간단한 설명을 **설명** 상자에 입력합니다.
1. **역할 생성**을 선택합니다.
**3단계: 계정을 등록된 OU로 이동하여 계정을 등록하고 등록을 확인합니다.**
역할을 만들어 필요한 권한을 설정한 후 다음 단계에 따라 계정을 등록하고 등록을 확인합니다.
1. **관리자로 다시 로그인하고 AWS Control Tower로 이동합니다.**
1.
**계정을 등록하세요.**
+ AWS Control Tower의 **조직** 페이지에서 계정을 선택한 다음 오른쪽 상단의 **작업** 드롭다운 메뉴에서 **등록**을 선택합니다.
+ [수동 계정 등록 단계](quick-account-provisioning.md#enrollment-steps) 페이지에 표시된 대로 개별 계정을 등록하는 단계를 따릅니다.
1.
**등록을 확인합니다.**
+ AWS Control Tower에서 왼쪽 탐색 메뉴에 있는 **조직**을 선택합니다.
+ 최근에 등록한 계정을 찾습니다. 초기 상태는 **등록 중** 상태로 표시됩니다.
+ 상태가 **등록됨**으로 변경되면 이동이 성공한 것입니다.
이 프로세스를 계속하려면 AWS Control Tower에 등록하려는 조직의 각 계정에 로그인합니다. 각 계정에 대해 사전 조건 단계와 등록 단계를 반복합니다.
**`AWSControlTowerExecution` 역할을 추가하는 예**
다음 YAML 템플릿은 계정에서 필요한 역할을 만들어 프로그래밍 방식으로 등록할 수 있도록 지원합니다.
```
AWSTemplateFormatVersion: 2010-09-09
Description: Configure the AWSControlTowerExecution role to enable use of your
account as a target account in AWS CloudFormation StackSets.
Parameters:
AdministratorAccountId:
Type: String
Description: AWS Account Id of the administrator account (the account in which
StackSets will be created).
MaxLength: 12
MinLength: 12
Resources:
ExecutionRole:
Type: AWS::IAM::Role
Properties:
RoleName: AWSControlTowerExecution
AssumeRolePolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Principal:
AWS:
- !Ref AdministratorAccountId
Action:
- sts:AssumeRole
Path: /
ManagedPolicyArns:
- !Sub arn:${AWS::Partition}:iam::aws:policy/AdministratorAccess
```
# 기존 AWS Config 리소스가 있는 계정 등록
이 주제에서는 기존 AWS Config 리소스가 있는 계정을 등록하는 방법에 대한 단계별 접근 방식을 제공합니다. 기존 리소스를 확인하는 방법의 예는 [AWS Config 리소스에 계정 등록](enroll-account.md#example-config-cli-commands) 섹션을 참조하세요.
**AWS Config 리소스의 예**
다음은 계정에 이미 있을 수 있는 몇 가지 유형의 AWS Config 리소스입니다. AWS Control Tower에 계정을 등록하려면 이러한 리소스를 수정해야 할 수 있습니다.
+ AWS Config 레코더
+ AWS Config 전송 채널
+ AWS Config 집계 권한 부여
**제한 사항**
+ 랜딩 존에 구성된 관리 계정 또는 서비스 통합 계정(들)에는 기존 AWS Config 리소스에 계정 등록이 지원되지 않습니다.
+ 계정은를 활성화하는 OU 등록 또는 재등록 워크플로를 사용해야만 등록할 수 있습니다`AWSControlTowerBaseline`. 를 활성화하거나 재설정하여 계정을 등록할 수 없습니다`ConfigBaseline`.
+ 기존 AWS Config 리소스가 있는 계정은에서 지원되지 않습니다[자동 등록을 사용하여 계정 이동 및 등록](account-auto-enrollment.md).
+ 리소스가 수정되고 계정에 드리프트를 생성하는 경우 AWS Control Tower는 리소스를 업데이트하지 않습니다.
+ AWS Config AWS Control Tower에서 관리하지 않는 리전의 리소스는 변경되지 않습니다.
**가정**
+ AWS Control Tower 랜딩 존을 배포했습니다.
+ 계정이 AWS Control Tower에 아직 등록되지 않았습니다.
+ 계정에 AWS Control Tower에서 관리하는 리전 중 하나 이상에 기존 AWS Config 리소스가 하나 이상 있습니다.
+ 계정이 거버넌스 드리프트에 있지 않습니다.
**참고**
허용 목록에 계정을 추가하지 않고 기존 Config 리소스가 있는 계정을 등록하려고 하면 등록이 실패합니다. 이후 동일한 계정을 허용 목록에 추가하려고 하면 AWS Control Tower에서 계정이 올바르게 프로비저닝되었는지 확인할 수 없습니다. 허용 목록을 요청한 다음 등록하려면 먼저 AWS Control Tower에서 계정 프로비저닝을 취소해야 합니다. 계정을 다른 AWS Control Tower OU로 옮기기만 하면 거버넌스 드리프트가 발생하므로, 계정이 허용 목록에 추가되지 않습니다.
기존 AWS Config 리소스에 계정을 등록하는 자동화된 접근 방식을 설명하는 블로그는 [AWS Control Tower에 기존 AWS Config 리소스가 있는 계정 등록 자동화를](https://aws.amazon.com//blogs/mt/automate-enrollment-of-accounts-with-existing-aws-config-resources-into-aws-control-tower/) 참조하세요.
**이 프로세스에는 5가지 주요 단계가 있습니다.**
1. AWS Control Tower 허용 목록에 계정(들)을 추가합니다.
1. 계정에서 새 IAM 역할을 만듭니다.
1. 기존 AWS Config 리소스를 수정합니다.
1. 리소스가 없는 AWS 리전에서 AWS Config 리소스를 생성합니다.
1. 계정을 AWS Control Tower에 등록합니다.
**계속하기 전에 이 프로세스에서 어떤 점을 기대할 수 있는지 살펴보세요.**
+ AWS Control Tower는이 계정에 AWS Config 리소스를 생성하지 않습니다.
+ 등록 후 AWS Control Tower 제어는 새 IAM 역할을 포함하여 생성한 AWS Config 리소스를 자동으로 보호합니다.
+ 등록 후 AWS Config 리소스가 변경된 경우 계정을 다시 등록하려면 먼저 AWS Control Tower 설정에 맞게 해당 리소스를 업데이트해야 합니다.
## 1단계: 지원 센터에 문의하여 허용 목록에 계정(들) 추가
**티켓 제목 줄에 다음 문구를 포함합니다.**
*AWS Control Tower에 기존 AWS Config 리소스가 있는 계정 등록*
**티켓 본문에 다음 세부 정보를 포함합니다.**
+ 관리 계정 번호
+ 기존 AWS Config 리소스가 있는 멤버 계정의 계정 번호입니다. 등록하려는 모든 계정에 대한 지원 사례를 생성할 수 있습니다.
+ AWS Control Tower 설정을 위해 선택한 홈 리전
**참고**
허용 목록에 계정을 추가하는 데 필요한 시간은 영업일 기준 2일입니다.
## 2단계: 멤버 계정에서 새 IAM 역할 생성
1. 멤버 계정의 CloudFormation 콘솔을 엽니다.
1. 다음 템플릿을 사용하여 새 스택을 만듭니다.
```
AWSTemplateFormatVersion: 2010-09-09
Description: Configure AWS Config
Resources:
CustomerCreatedConfigRecorderRole:
Type: AWS::IAM::Role
Properties:
RoleName: aws-controltower-ConfigRecorderRole-customer-created
AssumeRolePolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Principal:
Service:
- config.amazonaws.com
Action:
- sts:AssumeRole
Path: /
ManagedPolicyArns:
- arn:aws:iam::aws:policy/service-role/AWS_ConfigRole
- arn:aws:iam::aws:policy/ReadOnlyAccess
```
1. 스택의 이름을 **CustomerCreatedConfigRecorderRoleForControlTower**로 입력합니다.
1. 스택을 생성합니다.
**참고**
직접 만든 모든 SCP는 `aws-controltower-ConfigRecorderRole*` 역할을 제외해야 합니다. AWS Config 규칙이 평가를 수행하는 기능을 제한하는 권한을 수정하지 마십시오.
Config를 직접 호출하는 `aws-controltower-ConfigRecorderRole*`을 차단하는 SCP가 있는 경우 `AccessDeniedException`을 받지 않도록 다음 지침을 따르세요.
## 3단계: 기존 리소스가 있는 AWS 리전 식별
계정의 각 관리형 리전(AWS Control Tower 관리형)에 대해 이전에 표시된 기존 AWS Config 리소스 예제 유형 중 하나 이상이 있는 리전을 식별하고 기록해 둡니다.
## 4단계: AWS Config 리소스가 없는 AWS 리전 식별
계정의 각 관리형 리전(AWS Control Tower 관리형)에 대해 이전에 표시된 예제 유형의 AWS Config 리소스가 없는 리전을 식별하고 기록해 둡니다.
## 5단계: 각 AWS 리전의 기존 리소스 수정
이 단계에서는 AWS Control Tower 설정에 대한 다음 정보가 필요합니다.
+ `AUDIT_ACCOUNT` - AWS Config 서비스 통합 계정(이전에는 Audit 계정이라고 함) ID
+ `CONFIG_BUCKET` - AWS Config가 구성 스냅샷 및 구성 기록 파일을 제공하는 AWS S3 버킷입니다. 다음 단계로 진행하기 전에 AWS S3 버킷을 찾아 확인합니다.
+ 랜딩 존 버전 3.3 이하의 경우 AWS S3 버킷의 이름은 로깅 계정에 `aws-controltower-logs-LOGGING_ACCOUNT-HOME_REGION`있는 입니다.
+ 랜딩 존 버전 4.0 이상의 경우 AWS S3 버킷의 이름은 이며`aws-controltower-config-logs-AUDIT_ACCOUNT--`, AWS Config 서비스 통합 계정(이전에는 Audit 계정이라고 함)에 있습니다.
+ `IAM_ROLE_ARN` - 2단계에서 생성된 IAM 역할 ARN
+ `ORGANIZATION_ID` - 관리 계정의 조직 ID
+ `MEMBER_ACCOUNT_NUMBER` - 수정 중인 멤버 계정
+ `HOME_REGION` - AWS Control Tower 설정을 위한 홈 리전
다음 섹션 5a\$15c에 제공된 지침에 따라 각 기존 리소스를 수정합니다.
## 5a단계. AWS Config recorder 리소스
AWS 리전당 하나의 AWS Config 레코더만 존재할 수 있습니다. 있는 경우 그림과 같이 설정을 수정합니다. `GLOBAL_RESOURCE_RECORDING` 항목을 홈 리전에서 **true**로 교체합니다. AWS Config 레코더가 있는 다른 리전의 경우 항목을 **false**로 바꿉니다.
+ **이름:** 변경 금지
+ **RoleARN:**` IAM_ROLE_ARN`
+ **RecordingGroup:**
+ **AllSupported:** true
+ **IncludeGlobalResourceTypes:** `GLOBAL_RESOURCE_RECORDING`
+ **ResourceTypes:** 비어 있음
이 수정은 다음 명령을 사용하여 AWS CLI를 통해 수행할 수 있습니다. 문자열을 기존 AWS Config 레코더 이름으로 바꿉`RECORDER_NAME`니다.
```
aws configservice put-configuration-recorder --configuration-recorder name=RECORDER_NAME,roleARN=arn:aws:iam::MEMBER_ACCOUNT_NUMBER:role/aws-controltower-ConfigRecorderRole-customer-created --recording-group allSupported=true,includeGlobalResourceTypes=GLOBAL_RESOURCE_RECORDING --region CURRENT_REGION
```
## 5b단계. AWS Config 전송 채널 리소스 수정
리전당 하나의 AWS Config 전송 채널만 존재할 수 있습니다. 다른 설정이 있는 경우 그림과 같이 설정을 수정합니다.
+ **이름:** 변경 금지
+ **ConfigSnapshotDeliveryProperties:** TwentyFour\$1Hours
+ **S3BucketName:***CONFIG\$1BUCKET*
+ **S3KeyPrefix: ***ORGANIZATION\$1ID*
+ **SnsTopicARN: **감사 계정의 SNS 주제 ARN으로, 형식은 다음과 같습니다.
`arn:aws:sns:CURRENT_REGION:AUDIT_ACCOUNT:aws-controltower-AllConfigNotifications`
이 수정은 다음 명령을 사용하여 AWS CLI를 통해 수행할 수 있습니다. 문자열을 기존 AWS Config 레코더 이름으로 바꿉`DELIVERY_CHANNEL_NAME`니다.
```
aws configservice put-delivery-channel --delivery-channel name=DELIVERY_CHANNEL_NAME,s3BucketName=CONFIG_BUCKET,s3KeyPrefix="ORGANIZATION_ID",configSnapshotDeliveryProperties={deliveryFrequency=TwentyFour_Hours},snsTopicARN=arn:aws:sns:CURRENT_REGION:AUDIT_ACCOUNT:aws-controltower-AllConfigNotifications --region CURRENT_REGION
```
## 5c단계. AWS Config 집계 권한 부여 리소스 수정
**참고**
랜딩 존 버전 4.0 이상에는이 단계가 필요하지 않습니다.
리전당 여러 집계 권한 부여가 존재할 수 있습니다. AWS Control Tower에는 감사 계정을 권한 있는 계정으로 지정하고 AWS Control Tower의 홈 리전을 권한 있는 리전으로 사용하는 집계 권한 부여가 필요합니다. 없는 경우 다음 설정으로 새 설정을 만듭니다.
+ **AuthorizedAccountId: **감사 계정 ID
+ **AuthorizedAwsRegion:** AWS Control Tower 설정을 위한 홈 리전
이 수정은 다음 명령을 사용하여 AWS CLI를 통해 수행할 수 있습니다.
`aws configservice put-aggregation-authorization --authorized-account-id AUDIT_ACCOUNT_ID --authorized-aws-region HOME_REGION --region CURRENT_REGION`
## 6단계: AWS Control Tower에서 관리하는 리전에서 존재하지 않는 리소스 생성
다음 예제와 `GLOBAL_RESOURCE_RECORDING`같이 홈 리전에서 **IncludeGlobalResourcesTypes** 파라미터의 값이가 되도록 CloudFormation 템플릿을 수정합니다. 또한, 이 섹션에 지정된 대로 템플릿의 필수 필드를 업데이트합니다.
`GLOBAL_RESOURCE_RECORDING` 항목을 홈 리전에서 **true**로 교체합니다. AWS Config 레코더가 없는 다른 리전의 경우 항목을 **false**로 바꿉니다.
1. 관리 계정의 CloudFormation 콘솔로 이동합니다.
1. **CustomerCreatedConfigResourcesForControlTower**라는 이름으로 새 StackSets를 만듭니다.
1. 다음 템플릿을 복사하고 업데이트합니다.
**참고**
템플릿의 `CustomerCreatedAggregationAuthorization` 리소스는 랜딩 존 버전 4.0 이상에는 필요하지 않습니다.
```
AWSTemplateFormatVersion: 2010-09-09
Description: Configure AWS Config
Resources:
CustomerCreatedConfigRecorder:
Type: AWS::Config::ConfigurationRecorder
Properties:
Name: aws-controltower-BaselineConfigRecorder-customer-created
RoleARN: !Sub arn:aws:iam::${AWS::AccountId}:role/aws-controltower-ConfigRecorderRole-customer-created
RecordingGroup:
AllSupported: true
IncludeGlobalResourceTypes: GLOBAL_RESOURCE_RECORDING
ResourceTypes: []
CustomerCreatedConfigDeliveryChannel:
Type: AWS::Config::DeliveryChannel
Properties:
Name: aws-controltower-BaselineConfigDeliveryChannel-customer-created
ConfigSnapshotDeliveryProperties:
DeliveryFrequency: TwentyFour_Hours
S3BucketName: CONFIG_BUCKET
S3KeyPrefix: ORGANIZATION_ID
SnsTopicARN: !Sub arn:aws:sns:${AWS::Region}:AUDIT_ACCOUNT:aws-controltower-AllConfigNotifications
CustomerCreatedAggregationAuthorization:
Type: "AWS::Config::AggregationAuthorization"
Properties:
AuthorizedAccountId: AUDIT_ACCOUNT
AuthorizedAwsRegion: HOME_REGION
```
**필수 필드로 템플릿을 업데이트합니다.**
1. **S3BucketName** 필드에서 *CONFIG\$1BUCKET*
1. **S3KeyPrefix** 필드에서 *ORGANIZATION\$1ID*를 바꿉니다.
1. **SnsTopicARN** 필드에서 *AUDIT\$1ACCOUNT*를 바꿉니다.
1. **AuthorizedAccountId** 필드에서 *AUDIT\$1ACCOUNT*를 바꿉니다.
1. **AuthorizedAwsRegion** 필드에서 *HOME\$1REGION*을 바꿉니다.
1. CloudFormation 콘솔에서 배포하는 동안 멤버 계정 번호를 추가합니다.
1. 4단계에서 식별된 AWS 리전을 추가합니다.
1. 스택 세트를 배포합니다.
## 7단계: AWS Control Tower에 OU 등록
AWS Control Tower 대시보드에서 OU를 등록합니다.
**참고**
이 작업에서는 **계정 등록** 워크플로가 성공하지 않습니다. **OU 등록** 또는 **OU 재등록**을 선택해야 합니다.
# Account Factory로 계정 프로비저닝 및 관리
**참고**
단일 계정 프로비저닝, 업데이트 및 사용자 지정은 AWSControlTowerBaseline이 활성화된 조직 단위(OU)를 대상으로 해야 합니다. OU에 AWSControlTowerBaseline이 활성화되어 있지 않은 경우 계정 자동 등록을 활성화하거나 해당 OU의 EnabledBaselines 및 EnabledControls에서 ResetEnabledBaseline 및 ResetEnabledControl EnabledControls APIs를 사용하여 계정을 등록할 수 있습니다. EnabledBaselines AWSControlTowerBaseline에 대한 자세한 내용은 섹션을 참조하세요[OU 수준에서 적용되는 기준 유형](types-of-baselines.md#ou-baseline-types).
이 장에서는 Account Factory를 사용하여 AWS Control Tower 랜딩 존에서 새 멤버 계정을 프로비저닝하는 방법에 대한 개요와 절차를 설명합니다.
## 계정 구성 및 프로비저닝을 위한 권한
AWS Control Tower Account Factory를 사용하면의 클라우드 관리자와 사용자가 랜딩 존에서 계정을 프로비저닝 AWS IAM Identity Center 할 수 있습니다. 기본적으로 계정을 프로비저닝하는 IAM Identity Center 사용자는 `AWSAccountFactory` 그룹 또는 관리 그룹에 있어야 합니다.
**참고**
조직에서 권한이 있는 계정을 사용할 때와 마찬가지로 관리 계정에서 작업할 때는 주의해야 합니다.
AWS Control Tower 관리 계정은 `AWSControlTowerExecution` 역할과 신뢰 관계가 있으며, 이를 통해 일부 자동화된 계정 설정을 포함하여 관리 계정에서 계정을 설정할 수 있습니다. `AWSControlTowerExecution` 역할에 대한 자세한 내용은 [역할 및 계정](https://docs.aws.amazon.com//controltower/latest/userguide/roles-how.html) 섹션을 참조하세요.
**참고**
기존를 AWS Control Tower AWS 계정 에 등록하려면 해당 계정에 `AWSControlTowerExecution` 역할이 활성화되어 있어야 합니다. 기존 계정을 등록하는 방법에 대한 자세한 내용은 [기존 계정 등록 정보](enroll-account.md) 섹션을 참조하세요.
권한에 대한 자세한 내용은 [계정 프로비저닝에 필요한 권한](provision-and-manage-accounts.md#permissions) 섹션을 참조하세요.
## Account Factory에서 계정을 관리하기 위한 고려 사항
Account Factory를 통해 생성하고 프로비저닝하는 계정을 업데이트, 등록 취소 및 해지할 수 있습니다. 용도를 변경하려는 계정의 사용자 파라미터를 업데이트하여 계정을 재활용할 수 있습니다. 계정의 조직 단위(OU)를 변경할 수도 있습니다.
**참고**
Account Factory가 제공하는 계정과 연결된 프로비저닝된 제품을 업데이트할 때 새 사용자 이메일 주소를 지정하면 AWS IAM Identity Center AWS Control Tower가 IAM Identity Center에 새 사용자를 생성합니다. 이전에 생성된 계정은 제거되지 않습니다. IAM Identity Center에서 이전 IAM Identity Center 사용자 이메일 주소를 제거하는 방법에 대한 자세한 내용은 [사용자 비활성화](https://docs.aws.amazon.com//singlesignon/latest/userguide/disableuser.html)를 참조하세요.
# AWS Control Tower를 사용하여 계정 업데이트 및 이동
등록된 계정을 업데이트하는 가장 쉬운 방법은 AWS Control Tower 콘솔을 사용하는 것입니다. 개별 계정 업데이트는 [이동된 멤버 계정](governance-drift.md#drift-account-moved)과 같은 드리프트를 해결하는 데 유용합니다. 또한 계정 업데이트는 전체 랜딩 존 업데이트의 일부로도 필요합니다.
## 콘솔에서 계정 업데이트
**AWS Control Tower 콘솔에서 계정을 업데이트하려면**
1. AWS Control Tower에 로그인하면 **조직** 페이지로 이동합니다.
1. OU 및 계정 목록에서 업데이트하려는 계정의 이름을 선택합니다. 업데이트할 수 있는 계정에는 **업데이트 사용 가능** 상태가 표시됩니다.
1. 다음으로 선택한 계정의 **계정 세부 정보** 페이지가 표시됩니다.
1. 오른쪽 상단에서 **계정 업데이트**를 선택합니다.
한 조직 단위(OU)에서 다른 조직 단위로 계정을 이동하는 경우 새 OU에서 적용되는 제어가 이전 OU에서의 제어와 다를 수 있다는 점을 기억해야 합니다. 새 OU의 제어가 계정에 대한 정책 요구 사항을 충족하는지 확인합니다.
AWS Control Tower 계정은 계정 자동 등록을 옵트인했는지 여부에 따라 다르게 수정됩니다. 자동 등록에 대한 자세한 내용은 [선택적으로 자동 계정 등록 구성](configure-auto-enroll.md) 섹션을 참조하세요.
**자동 등록이 활성화된 상태에서 OU 간 계정 이동 시 제어 동작**
계정을 새 OU로 이동하면 AWS Control Tower는 OU의 활성화된 기준 및 제어를 계정에 적용합니다. 이전 OU의 제어 및 기준이 제거됩니다. 등록된 OU 외부로 계정을 이동하면 AWS Control Tower는 배포된 모든 기준 및 제어를 제거합니다.
**자동 등록이 비활성화된 상태에서 OU 간 계정 이동 시 제어 동작**
OU 간에 계정을 이동하면 대상 OU에 대한 제어가 계정에 적용됩니다. 하지만 이전 OU에서 계정에 적용된 제어는 제거되지 않습니다. 제어의 정확한 동작은 이전 OU와 대상 OU에서 활성화된 제어의 구현에 따라 다릅니다.
+ * AWS Config 규칙으로 구현된 제어의 경우:* 이전 OU의 제어
는 제거되지 않습니다. 이러한 제어는 수동으로 제거해야 합니다.
+ *SCP로 구현된 제어의 경우:* 이전 OU의 SCP 기반 제어가 제거됩니다. 대상 OU에 대한 SCP 기반 제어가 이 계정에 적용됩니다.
+ * CloudFormation 후크로 구현된 제어의 경우:* 이 동작은 새 OU의 제어 상태에 따라 달라집니다.
+ *대상 OU에 활성화된 후크 기반 제어가 없는 경우:* 이전 제어는 수동으로 제거하지 않는 한 이동한 계정에 대해 활성 상태로 유지됩니다.
+ *대상 OU에 활성화된 후크 제어가 있는 경우:* 이전 제어가 제거되고 대상 OU의 제어가 계정에 적용됩니다.
# 등록된 계정의 이메일 주소 변경
AWS Control Tower에서 등록된 멤버 계정의 이메일 주소를 변경하려면 이 섹션의 절차를 따르세요.
**참고**
다음 절차에서는 **관리 계정,** **로그 아카이브 계정** 또는 **감사 계정**의 이메일 주소를 변경할 수 없습니다. 이에 대한 자세한 내용은 [내 AWS 계정과 연결된 이메일 주소를 변경하려면 어떻게 해야 합니까?를 참조](https://aws.amazon.com//premiumsupport/knowledge-center/change-email-address/)하거나 Support에 문의 AWS 하세요.
**AWS Control Tower에서 생성되는 계정의 이메일 주소를 변경하려면**
1. 계정의 루트 사용자 암호를 복구합니다. [분실했거나 잊어버린 AWS 암호를 복구하려면 어떻게 해야 합니까?](https://aws.amazon.com//premiumsupport/knowledge-center/recover-aws-password/) 문서의 단계를 따를 수 있습니다.
1. 루트 사용자 암호로 계정에 로그인합니다.
1. 다른 이메일 주소와 마찬가지로 이메일 주소를 변경 AWS 계정하고 변경 사항이 반영될 때까지 기다립니다 AWS Organizations. 이메일 주소 변경에 따른 업데이트가 완료될 때까지 지연이 발생할 수 있습니다.
1. 이전에 계정에 속해 있던 이메일 주소를 사용하여 Service Catalog에서 프로비저닝된 제품을 업데이트합니다. 프로비저닝된 제품을 업데이트하는 프로세스에는 새 이메일 주소를 프로비저닝된 제품과 연결하는 작업이 포함됩니다. 이렇게 하면 이메일 주소 변경이 AWS Control Tower에 적용됩니다. 이후에 프로비저닝된 제품에 대한 업데이트에는 새 이메일 주소를 사용합니다.
AWS Organizations으로 생성한 멤버 계정의 암호 또는 이메일 주소를 변경하려면 *AWS Organizations 사용자 안내서*에서 [루트 사용자로 멤버 계정 액세스](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_manage_accounts_access.html#orgs_manage_accounts_access-as-root)를 참조하세요.
또는 루트 사용자로 로그인하지 않고 AWS Organizations 콘솔에서 Account Factory 또는 기타 멤버 계정의 이메일 주소를 업데이트할 수 있습니다. 자세한 내용은 *AWS Organizations 사용자 안내서*에서 [AWS Organizations를 사용하여 멤버 계정의 루트 사용자 이메일 주소 업데이트](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_update_primary_email.html)를 참조하세요.
# 등록된 계정의 이름 변경
이 섹션의 절차에 따라 등록된 AWS Control Tower 계정의 이름을 변경합니다.
**참고**
AWS *관리자* 계정의 이름을 변경하려면 관리자 권한이 있어야 하며 계정의 루트 사용자로 로그인해야 합니다.
**AWS Organizations 콘솔 또는 APIs를 사용하여 AWS Control Tower에서 생성한 계정의 이름을 변경하려면**
+ *AWS 계정 관리 참조 안내서*의 [지침을](https://docs.aws.amazon.com//accounts/latest/reference/manage-acct-update-acct-name.html#update-account-name-orgs) 따릅니다.
**AWS Control Tower에서 생성된 계정의 이름을 변경하는 또 다른 방법**
1. 계정의 루트 암호를 복구합니다. 이 문서의 [분실하거나 잊어버린 AWS 암호를 복구하려면 어떻게 해야 합니까?](https://aws.amazon.com//premiumsupport/knowledge-center/recover-aws-password/)에 설명된 단계를 따를 수 있습니다.
1. 루트 암호로 계정에 로그인합니다.
1. AWS Billing 콘솔에서 **계정 설정** 페이지로 이동합니다.
1. 다른 AWS 계정의 경우와 마찬가지로 **계정 설정**에서 이름을 변경합니다.
1. AWS Control Tower는 이름 변경을 반영하도록 자동으로 업데이트됩니다. 이 업데이트는 AWS Service Catalog의 프로비저닝된 제품에는 반영되지 않습니다.
# Amazon Virtual Private Cloud 설정을 사용하여 Account Factory 구성
Account Factory를 사용하면 조직의 계정에 대해 미리 승인된 기준과 구성 옵션을 생성할 수 있습니다. AWS Service Catalog를 통해 새 계정을 구성 및 프로비저닝할 수 있습니다.
Account Factory 페이지에서 조직 단위(OU)의 목록 및 해당 **허용 목록** 상태를 볼 수 있습니다. 기본적으로 모든 OU는 허용 목록에 있으므로 해당 OU 아래에서 계정을 프로비저닝할 수 있습니다. 를 통한 계정 프로비저닝을 위해 특정 OUs를 비활성화할 수 있습니다 AWS Service Catalog.
최종 사용자가 새 계정을 프로비저닝할 때 사용할 수 있는 Amazon VPC 구성 옵션을 볼 수 있습니다.
**Account Factory에서 Amazon VPC 설정을 구성하려면**
1. 중앙 클라우드 관리자는 관리 계정에서 관리자 권한으로 AWS Control Tower 콘솔에 로그인합니다.
1. 대시보드의 왼쪽에서 **Account Factory**를 선택하여 Account Factory 네트워크 구성 페이지로 이동합니다. 여기에 기본 네트워크 설정이 표시됩니다. 편집하려면 **편집**을 선택하고 Account Factory 네트워크 구성 설정의 편집 가능한 버전을 확인합니다.
1. 필요에 따라 기본 설정의 각 필드를 수정할 수 있습니다. 최종 사용자가 생성할 수 있는 모든 새로운 Account Factory 계정에 대해 설정하려는 VPC 구성 옵션을 선택하고 다음 설정을 필드에 입력합니다.
+ Amazon VPC에서 퍼블릭 서브넷을 생성하려면 **비활성화됨** 또는 **활성화됨**을 선택합니다. 기본적으로 인터넷 액세스가 가능한 서브넷은 허용되지 않습니다.
**참고**
새 계정을 프로비저닝할 때 퍼블릭 서브넷이 **활성화**되도록 Account Factory VPC 구성을 설정하면 Account Factory에서 Amazon VPC를 구성하여 [NAT 게이트웨이](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-nat-gateway.html)를 생성합니다. 따라서 Amazon VPC 사용에 대한 요금이 청구됩니다. 자세한 내용은 [VPC 요금](https://aws.amazon.com//vpc/pricing/)을 참조하세요.
+ 목록에서 Amazon VPC에 있는 프라이빗 서브넷의 최대 수를 선택합니다. 기본적으로 1이 선택됩니다. 허용된 프라이빗 서브넷의 최대 수는 가용 영역당 2개입니다.
+ 계정 VPC를 생성하기 위한 IP 주소 범위를 입력합니다. 이 값은 CIDR(Classless Inter-Domain Routing) 블록 형식이어야 합니다(기본값 `172.31.0.0/16`). 이 CIDR 블록은 Account Factory가 계정에 대해 생성하는 VPC의 전체 서브넷 IP 주소 범위를 제공합니다. VPC 내에서 서브넷은 지정한 범위에서 자동으로 할당되고 크기는 동일합니다. 기본적으로 VPC 내의 서브넷은 중첩되지 않습니다. 그러나 프로비저닝한 모든 계정의 VPC에서 서브넷 IP 주소 범위는 중첩될 수 있습니다.
+ 계정이 프로비저닝될 때 VPC를 생성하기 위해 한 리전 또는 모든 리전을 선택합니다. 사용 가능한 모든 리전이 기본적으로 선택되어 있습니다.
+ 목록에서 각 VPC의 서브넷을 구성할 가용 영역 수를 선택합니다. 기본값으로 권장되는 수는 3개입니다.
+ **저장**을 선택합니다.
또한 이러한 구성 옵션을 설정하여 VPC가 포함되지 않은 새 계정을 만들 수도 있습니다. [시연](https://docs.aws.amazon.com//controltower/latest/userguide/configure-without-vpc.html)을 참조하세요.
# 계정 등록 취소
Account Factory에서 계정을 생성했거나를 등록했는데 AWS 계정더 이상 랜딩 존의 AWS Control Tower에서 계정을 관리하지 않으려면 AWS Control Tower 콘솔에서 계정을 *등록 취소할* 수 있습니다.
AWS Control Tower 계정의 등록을 취소하면 제어 및 블루프린트를 포함하여 AWS Control Tower에서 프로비저닝된 모든 리소스가 제거됩니다. 계정이 AWS Control Tower OU에서 **루트** 영역으로 이동됩니다. 계정은 더 이상 등록된 OU의 일부가 아니며 더 이상 AWS Control Tower SCP의 적용을 받지 않습니다. 계정을 해지할 수 있습니다 AWS Organizations.
**AWS Control Tower 콘솔에서 등록된 계정의 등록을 취소하는 방법**
1. [https://console.aws.amazon.com/controltower](https://console.aws.amazon.com/controltower)로 이동해 웹 브라우저에서 AWS Control Tower 콘솔을 엽니다.
1. 왼쪽 창 탐색 메뉴에서 **조직**을 선택합니다.
1. **조직** 페이지에서 OU 근처의 **\$1** 버튼을 선택하여 계정이 포함된 OU를 펼칩니다.
1. 계정을 선택한 다음 **관리 취소**를 선택합니다.
**참고**
계정 상태가 **등록되지 않음**으로 표시될 때까지 기다립니다.
계정이 더 이상 필요하지 않은 경우 계정을 해지합니다. AWS 계정 해지에 대한 자세한 내용은 *AWS Billing 사용자 안내서*에서 [계정 해지](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/close-account.html)를 참조하세요.
**자동 등록이 활성화된 경우 계정 등록 취소**
**설정** 페이지에서 자동 등록 기능이 활성화된 경우 AWS Control Tower에 등록되지 않은 OU로 계정을 이동하여 계정 등록을 취소할 수도 있습니다. 취소하면 모든 AWS Control Tower 리소스가 제거됩니다. 이때 계정을 실수로 등록 취소하지 않도록 하세요. 물론 계정을 OU로 되돌려서 다시 등록할 수 있습니다.
사용자 지정 계정의 등록을 취소하면 AWS Control Tower는 랜딩 존이 배포한 리소스와 계정 내에서 AWS Control Tower가 생성한 기타 리소스를 제거합니다. 또한 AWS Control Tower는 수동으로 추가된 **AWSControlTowerExecution** 역할도 제거합니다. 서비스 실행 역할이 관리되지 않는 계정에 남아서는 안 되므로 이 역할을 제거하는 것이 최소 권한 원칙에 부합합니다.
계정을 등록 취소한 후 계정을 해지할 수 있습니다 AWS Organizations.
**참고**
계정을 등록 취소해도 해지되거나 삭제되지 않습니다. 계정이 등록 취소된 경우에도 Account Factory에서 계정을 생성할 때 선택한 IAM Identity Center 사용자는 여전히 계정에 대한 관리 액세스 권한을 가집니다. 이 사용자에게 관리 액세스 권한을 부여하지 않으려면 Account Factory에서 계정을 업데이트하고 계정의 IAM Identity Center 사용자 이메일 주소를 변경하여 IAM Identity Center에서 이 설정을 변경해야 합니다. 자세한 내용은 [AWS Control Tower를 사용하여 계정 업데이트 및 이동](updating-account-factory-accounts.md) 단원을 참조하십시오.
## 비디오 시연
이 비디오(3:25)에서는 AWS Control Tower에서 계정을 제거하고, 계정에 대한 루트 액세스 권한을 얻고, 마지막으로 AWS 계정을 해지하는 방법을 설명합니다. [AWS Organizations API](https://docs.aws.amazon.com//controltower/latest/userguide/delete-account.html)를 사용하여 계정을 해지할 수도 있습니다. 비디오의 오른쪽 하단 모서리에 있는 아이콘을 선택하여 전체 화면으로 확대하면 더 잘 보입니다. 자막을 사용할 수 있습니다.
[](http://www.youtube.com/watch?v=n3eALEKZaHc)
AWS Control Tower의 일반적인 작업을 설명하는 AWS [YouTube 비디오](https://www.youtube.com/playlist?list=PLhr1KZpdzukdS9skEXbY0z67F-wrcpbjm) 목록을 볼 수 있습니다.
# Account Factory에서 생성된 계정 해지
Account Factory에서 생성된 계정은 입니다 AWS 계정. AWS 계정해지에 대한 자세한 내용은 [https://docs.aws.amazon.com//accounts/latest/reference/manage-acct-closing.html ](https://docs.aws.amazon.com//accounts/latest/reference/manage-acct-closing.html )에서 [계정 해지](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/close-account.html)를 참조하세요.
**참고**
를 닫 AWS 계정 는 것은 AWS Control Tower에서 계정을 등록 취소하는 것과 같지 않습니다. 이는 별도의 작업입니다. 계정을 해지하려면 우선 등록을 취소해야 합니다.
## 를 통해 AWS Control Tower 멤버 계정 닫기 AWS Organizations
루트 자격 증명으로 각 멤버 계정에 개별적으로 로그인할 필요 없이 조직의 관리 계정에서 AWS Control Tower 멤버 계정을 해지할 수 있습니다 AWS Organizations. 하지만 관리 계정은 이러한 방식으로 해지할 수 없습니다.
AWS Organizations [CloseAccount API](https://docs.aws.amazon.com//organizations/latest/APIReference/API_CloseAccount.html)를 호출하거나 AWS Organizations 콘솔에서 계정을 닫으면 멤버 계정이 AWS 계정 90일 동안 격리됩니다. 계정은 AWS Control Tower 및 AWS Organizations에서 **일시 중지됨** 상태를 표시합니다. 이 90일 동안 계정에 대한 작업을 시도하면 AWS Control Tower에서 오류 메시지를 표시합니다.
**참고**
OU에 계정이 일시 중지된 경우 대상에 대한 리전별 제어에 대해 EnabledControl 작업이 실패합니다.
90일이 만료되기 전에 멤버 계정을 복원할 수 있습니다 AWS 계정. 90일이 지나면 계정의 레코드가 제거됩니다.
가장 좋은 방법은 계정을 해지하기 전에 멤버 계정의 등록을 취소하는 것입니다. 멤버 계정을 먼저 관리 해제하지 않은 상태에서 해지하면 AWS Control Tower에서 계정의 상태를 **일시 중지됨**으로 표시하는 동시에 **등록됨**으로도 표시합니다. 따라서 해당 90일 동안 계정의 OU를 **재등록**하려고 하면 AWS Control Tower가 오류 메시지를 생성합니다. 일시 중지된 계정은 기본적으로 사전 확인 실패와 함께 재등록 작업을 차단합니다. OU에서 계정을 제거하면 OU를 **다시 등록할** 수 있지만 계정에 대한 결제 방법이 누락되어 오류가 발생할 AWS 수 있습니다. 이 제약 조건을 해결하려면 재등록하기 전에 다른 OU를 생성하고 계정을 해당 OU로 이동합니다. 이 OU의 이름을 **일시 중지된** OU로 지정하는 것이 좋습니다.
**참고**
계정을 해지하기 전에 등록을 취소하지 않으면 해당 90일이 완료된 AWS Service Catalog 후에서 계정의 프로비저닝된 제품을 삭제해야 합니다.
자세한 내용은 [CloseAccount API](https://docs.aws.amazon.com//organizations/latest/APIReference/API_CloseAccount.html)에 대한 AWS Organizations 설명서를 참조하세요.
# Account Factory에 대한 리소스 고려 사항
Account Factory로 계정을 프로비저닝하면 계정 내에 다음 AWS 리소스가 생성됩니다.
| AWS 서비스 | 리소스 유형 | 리소스 이름 |
| --- | --- | --- |
| AWS CloudFormation | 스택 | StackSet-AWSControlTowerBP-BASELINE-CLOUDTRAIL-\$1 StackSet-AWSControlTowerBP-BASELINE-CLOUDWATCH-\$1 StackSet-AWSControlTowerBP-BASELINE-CONFIG-\$1 StackSet-AWSControlTowerBP-BASELINE-ROLES-\$1 StackSet-AWSControlTowerBP-BASELINE-SERVICE-ROLES-\$1 |
| AWS CloudTrail | 추적 | aws-controltower-BaselineCloudTrail |
| Amazon CloudWatch | CloudWatch Events 규칙 | aws-controltower-ConfigComplianceChangeEventRule |
| Amazon CloudWatch | CloudWatch Logs | aws-controltower/CloudTrailLogs /aws/lambda/aws-controltower-NotificationForwarder |
| AWS Identity and Access Management | 역할 | aws-controltower-AdministratorExecutionRole aws-controltower-CloudWatchLogsRole aws-controltower-ConfigRecorderRole aws-controltower-ForwardSnsNotificationRole aws-controltower-ReadOnlyExecutionRole AWSControlTowerExecution |
| AWS Identity and Access Management | 정책 | AWSControlTowerServiceRolePolicy |
| Amazon Simple Notification Service | 주제 | aws-controltower-SecurityNotifications |
| AWS Lambda | 애플리케이션 | StackSet-AWSControlTowerBP-BASELINE-CLOUDWATCH-\$1 |
| AWS Lambda | 함수 | aws-controltower-NotificationForwarder |
| Amazon EventBridge | 규칙 | AWSControlTowerManagedRule |
| Amazon EventBridge | 규칙 | aws-controltower-ConfigComplianceChangeEventRule |
# Account Factory 사용자 지정(AFC)을 사용하여 계정 사용자 지정
**참고**
단일 계정 프로비저닝, 업데이트 및 사용자 지정은 AWSControlTowerBaseline이 활성화된 조직 단위(OU)를 대상으로 해야 합니다. OU에 AWSControlTowerBaseline이 활성화되어 있지 않은 경우 계정 자동 등록을 활성화하거나 해당 OU의 EnabledBaselines 및 EnabledControls에서 ResetEnabledBaseline 및 ResetEnabledControl EnabledControls APIs를 사용하여 계정을 등록할 수 있습니다. EnabledBaselines AWSControlTowerBaseline에 대한 자세한 내용은 섹션을 참조하세요[OU 수준에서 적용되는 기준 유형](types-of-baselines.md#ou-baseline-types).
AWS Control Tower를 사용하면 AWS Control Tower 콘솔에서 리소스를 프로비저닝할 AWS 계정 때 신규 및 기존를 사용자 지정할 수 있습니다. Account Factory 사용자 지정을 설정하면 향후 프로비저닝을 위해 AWS Control Tower가 이 프로세스를 자동화하므로 파이프라인을 유지 관리할 필요가 없습니다. 사용자 지정 계정은 리소스가 프로비저닝된 직후에 사용할 수 있습니다.
**블루프린트를 사용하여 새 계정 프로비저닝**
사용자 지정 계정은 AWS Control Tower Account Factory, CloudFormation 템플릿을 통해 또는 Terraform을 사용하여 프로비저닝됩니다. 사용자 지정 계정 *블루프린트* 역할을 하는 템플릿을 정의합니다. 블루프린트는 계정이 프로비저닝될 때 필요한 특정 리소스 및 구성을 설명합니다. AWS 파트너가 구축하고 관리하는 사전 정의된 블루프린트도 사용할 수 있습니다. 파트너 관리형 블루프린트에 대한 자세한 내용은 [AWS Service Catalog 시작하기 라이브러리](https://docs.aws.amazon.com//servicecatalog/latest/adminguide/getting-started-library.html)를 참조하세요.
**기존 계정에 블루프린트 적용**
AWS Control Tower 콘솔의 **계정 업데이트** 단계에 따라 기존 계정에 사용자 지정 블루프린트를 적용할 수도 있습니다. 자세한 내용은 [콘솔에서 계정 업데이트](updating-account-factory-accounts.md#update-account-in-console) 섹션을 참조하세요.
**정의: 허브 계정**
계정 블루프린트는에 저장되며 AWS 계정, 이를 허브 *계정*이라고 합니다. 블루프린트는 Service Catalog 제품의 형태로 저장됩니다. 다른 Service Catalog 제품과 구분하기 위해 이 제품을 블루프린트라고 부릅니다. Service Catalog 제품을 생성하는 방법에 대한 자세한 내용은 *AWS Service Catalog 관리자 안내서*의 [제품 생성](https://docs.aws.amazon.com//servicecatalog/latest/adminguide/productmgmt-cloudresource.html)을 참조하세요.
**참고**
AWS Control Tower에는 AWS Control Tower의 CloudFormation 리소스를 모니터링하는 *선제적 제어*가 포함되어 있습니다. 선택적으로 랜딩 존에서 이러한 제어를 활성화할 수 있습니다. 선제적 제어를 적용하면 계정에 배포하려는 리소스가 조직의 정책 및 절차를 준수하는지 확인합니다. 선제적 제어에 대한 자세한 내용은 [선제적 제어](https://docs.aws.amazon.com//controltower/latest/userguide/proactive-controls.html)를 참조하세요.
AFC 작업에 대한 자세한 내용은 [AWS Control Tower에서 Account Factory 사용자 지정을 사용하여 계정 사용자 지정 자동화](https://aws.amazon.com//blogs/mt/automate-account-customization-using-account-factory-customization-in-aws-control-tower/)를 참조하세요.
**사전 조건**
AWS Control Tower Account Factory에서 사용자 지정 계정을 생성하려면 우선 AWS Control Tower 랜딩 존 환경이 배포되어 있어야 하며 새로 생성된 계정이 배치될 AWS Control Tower에 등록된 조직 단위(OU)가 있어야 합니다.
**사용자 지정 준비**
+ *허브 계정 지정:* 허브 계정으로 사용할 새 계정을 생성하거나 기존 계정을 사용할 수 있습니다 AWS 계정. AWS Control Tower 관리 계정을 블루프린트 허브 계정으로 사용하지 않는 것이 좋습니다.
+ *필요한 역할 추가:* AWS Control Tower AWS 계정 에 등록하고 사용자 지정하려는 경우 먼저 AWS Control Tower에 등록하는 다른 계정과 마찬가지로 해당 계정에 `AWSControlTowerExecution` 역할을 추가해야 합니다.
+ *파트너 블루프린트 구성(선택 사항): *마켓플레이스 구독 요구 사항이 있는 파트너 블루프린트를 사용하려는 경우 파트너 블루프린트를 Account Factory 사용자 지정 블루프린트로 배포하기 전에 AWS Control Tower 관리 계정에서 이를 구성해야 합니다.
**Topics**
+ [사용자 지정 설정](afc-setup-steps.md)
+ [블루프린트에서 사용자 지정 계정 생성](create-afc-customized-account.md)
+ [계정 등록 시 AFC를 사용하여 계정을 사용자 지정](enroll-and-customize.md)
+ [AWS Control Tower 계정에 블루프린트 추가](add-blueprint-to-account.md)
+ [블루프린트 업데이트](update-a-blueprint.md)
+ [계정에서 블루프린트 제거](remove-a-blueprint.md)
+ [파트너 블루프린트](partner-blueprints.md)
+ [Account Factory 사용자 지정(AFC) 고려 사항](#af-limitations)
+ [블루프린트 오류가 발생할 때](#af-error)
+ [CloudFormation을 기반으로 AFC 블루프린트에 대한 정책 문서 사용자 지정](#custom-policy-document)
+ [Terraform 기반 Service Catalog 제품을 생성하는 데 필요한 추가 권한](#custom-policy-document-tf)
+ [AWS Service Catalog 외부 제품 유형으로 전환](#service-catalog-external-product-type)
# 사용자 지정 설정
다음 섹션에서는 사용자 지정 프로세스를 위해 Account Factory를 설정하는 단계를 설명합니다. 이 단계를 시작하기 전에 허브 계정에 대한 [위임된 관리자](https://docs.aws.amazon.com//accounts/latest/reference/using-orgs-delegated-admin.html)를 설정하는 것이 좋습니다.
**요약**
+ **1단계. 필요한 역할을 생성합니다.** 블루프린트라고도 하는 Service Catalog 제품이 저장되는 (허브) 계정에 액세스할 수 있는 권한을 AWS Control Tower에 부여하는 IAM 역할을 생성합니다.
+ **2단계. AWS Service Catalog 제품을 생성합니다.** 사용자 지정 계정의 기준을 설정하는 데 필요한 AWS Service Catalog 제품(“블루프린트 제품”이라고도 함)을 생성합니다.
+ **3단계. 사용자 지정 블루프린트를 검토합니다.** 생성한 AWS Service Catalog 제품(블루프린트)을 검사합니다.
+ **4단계. 블루프린트를 직접 호출하여 사용자 지정 계정을 생성합니다.** 계정을 생성하는 동안 AWS Control Tower 콘솔에서 Account Factory의 적절한 필드에 블루프린트 제품 정보와 역할 정보를 입력합니다.
# 1단계. 필요한 역할 생성
계정 사용자 지정을 시작하기 전에 AWS Control Tower와 허브 계정 간 신뢰 관계가 포함된 역할을 설정해야 합니다. 이 역할은 허브 계정의 리소스를 관리할 수 있는 액세스 권한을 AWS Control Tower에 부여합니다. 이 역할의 이름은 **AWSControlTowerBlueprintAccess**여야 합니다.
AWS Control Tower는이 역할을 수임하여 사용자를 대신하여 포트폴리오 리소스를 생성한 다음 AWS Service Catalog, 블루프린트를이 포트폴리오에 서비스 카탈로그 제품으로 추가한 다음, 계정 프로비저닝 중에이 포트폴리오와 블루프린트를 멤버 계정과 공유합니다.
다음 섹션에 설명된 대로 `AWSControlTowerBlueprintAccess` 역할을 생성합니다. 등록된 계정 또는 등록되지 않은 계정에서 역할을 설정할 수 있습니다.
**IAM 콘솔로 이동하여 필요한 역할을 설정합니다.**
**등록된 AWS Control Tower 계정에서 AWSControlTowerBlueprintAccess 역할을 설정하는 방법**
1. AWS Control Tower 관리 계정의 위탁자로 페더레이션하거나 로그인합니다.
1. 관리 계정의 페더레이션 위탁자에서, 블루프린트 허브 계정으로 사용하기 위해 선택한 등록된 AWS Control Tower 계정의 `AWSControlTowerExecution` 역할을 수임하거나 이 역할로 전환합니다.
1. 등록된 AWS Control Tower 계정의 `AWSControlTowerExecution` 역할을 통해 적절한 권한과 신뢰 관계를 가진 `AWSControlTowerBlueprintAccess` 역할을 생성합니다.
**중요**
AWS 모범 사례 지침을 준수하려면 `AWSControlTowerExecution` 역할을 생성한 후 즉시 `AWSControlTowerBlueprintAccess` 역할에서 로그아웃하는 것이 중요합니다.
리소스에 대한 의도하지 않은 변경을 방지하기 위해 `AWSControlTowerExecution` 역할은 AWS Control Tower에서만 사용할 수 있습니다.
블루프린트 허브 계정이 AWS Control Tower에 등록되지 않은 경우 `AWSControlTowerExecution` 역할은 계정에 존재하지 않으므로 `AWSControlTowerBlueprintAccess` 역할 설정을 계속하기 전에 이를 수임할 필요가 없습니다.
**등록되지 않은 멤버 계정에서 AWSControlTowerBlueprintAccess 역할을 설정하는 방법**
1. 원하는 방법을 사용하여 허브 계정으로 지정하려는 계정에 위탁자로 페더레이션하거나 로그인합니다.
1. 계정에 위탁자로 로그인한 경우 적절한 권한과 신뢰 관계를 포함하는 `AWSControlTowerBlueprintAccess` 역할을 생성합니다.
**AWSControlTowerBlueprintAccess** 역할은 다음 두 위탁자에게 신뢰를 부여하도록 설정해야 합니다.
+ AWS Control Tower 관리 계정에서 AWS Control Tower를 실행하는 위탁자(사용자)입니다.
+ 이름이 `AWSControlTowerAdmin`인 AWS Control Tower 관리 계정의 역할입니다.
다음은 역할에 포함해야 하는 것과 유사한 신뢰 정책의 예제입니다. 이 정책은 최소 권한 액세스를 부여하는 모범 사례를 보여줍니다. 자체 정책을 만들 때 *YourManagementAccountId*라는 용어를 AWS Control Tower 관리 계정의 실제 계정 ID로 바꾸고, *YourControlTowerUserRole*이라는 용어를 관리 계정의 IAM 역할 식별자로 바꿉니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/service-role/AWSControlTowerAdmin",
"arn:aws:iam::111122223333:role/YourControlTowerUserRole"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
**필요한 권한 정책**
AWS Control Tower에서는 `AWSServiceCatalogAdminFullAccess`이라는 관리형 정책을 `AWSControlTowerBlueprintAccess` 역할에 연결해야 합니다. 이 정책은 AWS Control Tower가 포트폴리오 및 AWS Service Catalog 제품 리소스를 관리할 수 있도록 허용하는 시기를 AWS Service Catalog 찾는 권한을 제공합니다. IAM 콘솔에서 역할을 생성할 때 이 정책을 연결할 수 있습니다.
**추가 권한이 필요할 수 있음**
Amazon S3에 블루프린트를 저장하는 경우 AWS Control Tower에는 `AWSControlTowerBlueprintAccess` 역할에 대한 `AmazonS3ReadOnlyAccess` 권한 정책도 필요합니다.
기본 **관리자** 정책을 사용하지 않는 경우 AWS Service Catalog Terraform 유형의 제품을 사용하려면 AFC 사용자 지정 IAM 정책에 몇 가지 추가 권한을 추가해야 합니다. Terraform 템플릿에서 정의하는 리소스를 생성하는 데 필요한 권한 외에도 이러한 권한이 필요합니다.
# 2단계. AWS Service Catalog 제품 생성
AWS Service Catalog 제품을 생성하려면 *AWS Service Catalog 관리자 안내서*의 [제품 생성](https://docs.aws.amazon.com//servicecatalog/latest/adminguide/productmgmt-cloudresource.html) 단계를 따르세요. AWS Service Catalog 제품을 생성할 때 계정 블루프린트를 템플릿으로 추가합니다.
**중요**
HashiCorp의 Terraform 라이선스 업데이트로 인해 *Terraform 오픈 소스* 제품 및 프로비저닝된 제품에 대한 지원이 *외부*라는 새로운 제품 유형으로 AWS Service Catalog 변경되었습니다. 기존 계정 블루프린트를 외부 제품 유형으로 업데이트하는 방법을 포함하여 이 변경이 AFC에 미치는 영향에 대해 자세히 알아보려면 [외부 제품 유형으로 전환](af-customization-page.md#service-catalog-external-product-type)을 검토하세요.
**블루프린트 생성 단계 요약**
+ 계정 블루프린트가 될 CloudFormation 템플릿 또는 Terraform tar.gz 구성 파일을 생성하거나 다운로드합니다. 일부 템플릿 예제는 이 섹션의 뒷부분에 나와 있습니다.
+ Account Factory 블루프린트( 허브 계정이라고도 함)를 저장하는 AWS 계정 에 로그인합니다.
+ AWS Service Catalog 콘솔로 이동합니다. **제품 목록**을 선택한 다음 **새 제품 업로드**를 선택합니다.
+ **제품 세부 정보** 창에서 이름 및 설명과 같은 블루프린트 제품의 세부 정보를 입력합니다.
+ **템플릿 파일 사용**을 선택한 다음 **파일 선택**을 선택합니다. 블루프린트로 사용하기 위해 개발하거나 다운로드한 템플릿 또는 구성 파일을 선택하거나 붙여넣습니다.
+ 콘솔 페이지 하단에서 **제품 생성**을 선택합니다.
AWS Service Catalog 참조 아키텍처 리포지토리에서 CloudFormation 템플릿을 다운로드할 수 있습니다. [해당 리포지토리의 한 가지 예제는 리소스에 대한 백업 계획을 설정하는 데 도움이 됩니다](https://github.com/aws-samples/aws-service-catalog-reference-architectures/blob/master/backup/backup-tagoptions.yml).
다음은 **Best Pets**라는 가상 회사에 대한 예제 템플릿입니다. 이 템플릿은 반려동물 데이터베이스에 대한 연결을 설정하는 데 도움이 됩니다.
```
Resources:
ConnectionStringGeneratorLambdaRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Principal:
Service:
- lambda.amazonaws.com
Action:
- "sts:AssumeRole"
ConnectionStringGeneratorLambda:
Type: AWS::Lambda::Function
Properties:
FunctionName: !Join ['-', ['ConnectionStringGenerator', !Select [4, !Split ['-', !Select [2, !Split ['/', !Ref AWS::StackId]]]]]]
Description: Retrieves the connection string for this account to access the Pet Database
Role: !GetAtt ConnectionStringGeneratorLambdaRole.Arn
Runtime: nodejs22.x
Handler: index.handler
Timeout: 5
Code:
ZipFile: >
export const handler = async (event, context) => {
const awsAccountId = context.invokedFunctionArn.split(“:”)[4]
const connectionString= “fake connection for account ” + awsAccountId;
const response = {
statusCode: 200,
body: connectionString
};
return response;
};
ConnectionString:
Type: Custom::ConnectionStringGenerator
Properties:
ServiceToken: !GetAtt ConnectionStringGeneratorLambda.Arn
PetDatabaseConnectionString:
DependsOn: ConnectionString
# For example purposes we're using SSM parameter store.
# In your template, use secure alternatives to store
# sensitive values such as connection strings.
Type: AWS::SSM::Parameter
Properties:
Name: pet-database-connection-string
Description: Connection information for the BestPets pet database
Type: String
Value: !GetAtt ConnectionString.Value
```
# 3단계. 사용자 지정 블루프린트 검토
AWS Service Catalog 콘솔에서 블루프린트를 볼 수 있습니다. 자세한 내용은 *Service Catalog 관리자 안내서*의 [제품 관리](https://docs.aws.amazon.com//servicecatalog/latest/adminguide/catalogs_products.html#productmgmt-menu)를 참조하세요.
# 4단계. 블루프린트를 직접 호출하여 사용자 지정 계정을 생성합니다.
AWS Control Tower 콘솔에서 **계정 생성** 워크플로를 따르면 계정 사용자 지정에 사용할 블루프린트에 대한 정보를 입력할 수 있는 선택적 섹션이 표시됩니다.
**사전 조건**
AWS Control Tower 콘솔에 해당 정보를 입력하고 사용자 지정 계정 프로비저닝을 시작하려면 사용자 지정 허브 계정을 설정하고 블루프린트(Service Catalog 제품)를 하나 이상 추가해야 합니다.
**AWS Control Tower 콘솔에서 사용자 지정 계정을 생성하거나 업데이트합니다.**
1. 블루프린트가 포함된 계정의 계정 ID를 입력합니다.
1. 해당 계정에서 기존 Service Catalog 제품(기존 블루프린트)을 선택합니다.
1. 버전이 두 개 이상인 경우 블루프린트(Service Catalog 제품)의 적절한 버전을 선택합니다.
1. (선택 사항) 프로세스의 이 시점에서 블루프린트 프로비저닝 정책을 추가하거나 변경할 수 있습니다. 블루프린트 프로비저닝 정책은 JSON으로 작성되어 IAM 역할에 연결되므로 블루프린트 템플릿에 지정된 리소스를 프로비저닝할 수 있습니다. AWS Control Tower는 멤버 계정에이 역할을 생성하여 Service Catalog가 CloudFormation 스택 세트를 사용하여 리소스를 배포할 수 있도록 합니다. 이 역할의 이름은 `AWSControlTower-BlueprintExecution-bp-xxxx`입니다. `AdministratorAccess` 정책은 기본적으로 여기에 적용됩니다.
1. 이 블루프린트를 기반으로 계정을 배포하려는 AWS 리전 또는 리전을 선택합니다.
1. 블루프린트에 파라미터가 포함된 경우 AWS Control Tower 워크플로의 추가 필드에 파라미터 값을 입력할 수 있습니다. 추가 값에는 GitHub 리포지토리 이름, GitHub 브랜치, Amazon ECS 클러스터 이름 및 리포지토리 소유자의 GitHub ID가 포함될 수 있습니다.
1. 허브 계정 또는 블루프린트가 아직 준비되지 않은 경우 **계정 업데이트** 프로세스에 따라 나중에 계정을 사용자 지정할 수 있습니다.
자세한 내용은 [블루프린트에서 사용자 지정 계정 생성](create-afc-customized-account.md) 섹션을 참조하세요.
# 블루프린트에서 사용자 지정 계정 생성
사용자 지정 블루프린트를 생성한 후 AWS Control Tower Account Factory에서 사용자 지정 계정 생성을 시작할 수 있습니다.
**새 AWS 계정을 생성할 때 사용자 지정 블루프린트를 배포하려면 다음 단계를 따르세요.**
1. 에서 AWS Control Tower로 이동합니다 AWS Management Console.
1. **Account Factory** 및 **계정 생성**을 선택합니다.
1. 계정 이름, 이메일 주소와 같은 계정 세부 정보를 입력합니다.
1. 이메일 주소와 사용자 이름으로 IAM Identity Center 세부 정보를 구성합니다.
1. 계정을 추가할 등록된 OU를 선택합니다.
1. **Account Factory 사용자 지정** 섹션을 확장합니다.
1. Service Catalog 제품이 포함된 블루프린트 허브 계정의 계정 ID를 입력하고 **검증**을 선택합니다. 블루프린트 허브 계정에 대한 자세한 내용은 [Account Factory 사용자 지정(AFC)을 사용하여 계정 사용자 지정](af-customization-page.md) 섹션을 참조하세요.
1. Service Catalog 제품 목록의 모든 블루프린트(모든 사용자 지정 블루프린트 및 파트너 블루프린트)가 포함된 드롭다운 메뉴를 선택합니다. 배포할 블루프린트와 해당 버전을 선택합니다.
1. 블루프린트에 파라미터가 포함된 경우 입력할 수 있도록 해당 필드가 표시됩니다. 기본값은 미리 채워집니다.
1. 마지막으로 **홈 리전** 또는 **모든 관리형 리전** 중에서 블루프린트를 배포할 위치를 선택합니다. Route 53 또는 IAM과 같은 글로벌 리소스는 단일 리전에만 배포해야 할 수 있습니다. Amazon EC2 인스턴스 또는 Amazon S3 버킷과 같은 리전 리소스는 모든 관리형 리전에 배포할 수 있습니다.
1. 모든 필드를 완료한 후 **계정 생성**을 선택합니다.
**참고**
Terraform으로 생성된 블루프린트는 여러 리전이 아닌 한 리전에만 배포할 수 있습니다.
**조직** 페이지에서 계정 프로비저닝 진행 상황을 볼 수 있습니다. 계정 프로비저닝이 완료되면 블루프린트에 지정된 리소스가 이미 해당 계정 내에 배포됩니다. 계정 및 블루프린트의 세부 정보를 보려면 **계정 세부 정보** 페이지로 이동합니다.
# 계정 등록 시 AFC를 사용하여 계정을 사용자 지정
AWS Control Tower 콘솔에서 계정을 등록 및 사용자 지정하려면
1. AWS Control Tower 콘솔로 이동하여 왼쪽 탐색 창에서 **조직**을 선택합니다.
1. 사용 가능한 계정 목록이 표시됩니다. 사용자 지정 블루프린트로 등록하려는 계정을 식별합니다. 해당 계정의 **상태** 열에 계정 상태가 **등록되지 않음**으로 표시되어야 합니다.
1. 계정 왼쪽의 라디오 버튼을 선택하고 화면 오른쪽 상단에서 **작업** 드롭다운 메뉴를 선택합니다. 여기서 **등록** 옵션을 선택합니다.
1. 계정의 IAM Identity Center 정보로 **액세스 구성** 섹션을 완료합니다.
1. 계정이 멤버로 포함될 등록된 OU를 선택합니다.
1. **계정 생성** 절차의 7\$112단계와 동일한 단계를 사용하여 **Account Factory 사용자 지정** 섹션을 완료합니다. 자세한 내용은 [를 사용하여 Account Factory 계정 프로비저닝 AWS Service Catalog](https://docs.aws.amazon.com/controltower/latest/userguide/provision-as-end-user.html)을 참조하세요.
**조직** 페이지에서 계정 진행 상황을 볼 수 있습니다. 계정 등록이 완료되면 블루프린트에 지정된 리소스가 이미 해당 계정 내에 배포됩니다.
# AWS Control Tower 계정에 블루프린트 추가
기존 AWS Control Tower 멤버 계정에 블루프린트를 추가하려면 AWS Control Tower 콘솔에서 **계정 업데이트** 워크플로를 따르고 계정에 추가할 새 블루프린트를 선택합니다. 자세한 내용은 [AWS Control Tower 또는 AWS Service Catalog를 사용하여 Account Factory 계정 업데이트 및 이동](https://docs.aws.amazon.com/controltower/latest/userguide/updating-account-factory-accounts.html#update-account-in-console)을 참조하세요.
**참고**
계정에 새 블루프린트를 추가하면 기존 블루프린트를 덮어씁니다.
**참고**
AWS Control Tower 계정당 하나의 블루프린트를 배포할 수 있습니다.
# 블루프린트 업데이트
다음 절차에서는 사용자 지정 블루프린트를 업데이트하고 배포하는 방법을 설명합니다.
**사용자 지정 블루프린트를 업데이트하려면**
1. CloudFormation 템플릿 또는 Terraform tar.gz 파일(블루프린트)을 새 구성으로 업데이트합니다.
1. 업데이트된 블루프린트를 AWS Service Catalog에 새 버전으로 저장합니다.
**업데이트된 블루프린트를 배포하려면**
1. AWS Control Tower 콘솔에서 **조직** 페이지로 이동합니다.
1. 블루프린트 이름 및 버전으로 **조직** 페이지를 필터링합니다.
1. **계정 업데이트** 프로세스를 따르고 계정에 최신 블루프린트 버전을 배포합니다.
**블루프린트 업데이트에 실패한 경우**
AWS Control Tower는 프로비저닝된 제품이 `AVAILABLE` 상태에 있을 때 블루프린트 업데이트를 허용합니다. 프로비저닝된 제품이 `TAINTED` 상태라면 업데이트가 실패합니다. 다음과 같은 방법을 사용할 수 있습니다.
1. AWS Service Catalog 콘솔에서 `TAINTED` 프로비저닝된 제품을 수동으로 업데이트하여 상태를 로 변경합니다`AVAILABLE`. 자세한 내용은 [프로비저닝된 제품 업데이트](https://docs.aws.amazon.com//servicecatalog/latest/userguide/enduser-update.html)를 참조하세요.
1. 그런 다음 AWS Control Tower의 계정 업데이트 프로세스에 따라 블루프린트 배포 오류를 수정합니다.
*이 수동 단계를 권장하는 이유:* 블루프린트를 제거하면 멤버 계정의 리소스가 제거될 수 있으며 리소스가 제거되면 기존 워크로드에 영향을 미칠 수 있습니다. 이러한 이유로 원래 블루프린트를 제거하고 교체하는 블루프린트 업데이트 방식보다는 이 방법을 사용하는 것이 좋습니다(특히 프로덕션 워크로드를 실행하는 경우).
# 계정에서 블루프린트 제거
계정에서 블루프린트를 제거하려면 **계정 업데이트** 워크플로에 따라 블루프린트를 제거하고 계정을 AWS Control Tower 기본 구성으로 되돌립니다.
콘솔에서 **계정 업데이트** 워크플로로 들어가면 모든 계정 세부 정보는 채워져 있고 사용자 지정 세부 정보는 비어 있는 것을 볼 수 있습니다. 이러한 AFC 세부 정보를 비워 두면 AWS Control Tower가 계정에서 블루프린트를 제거합니다. 작업이 시작되기 전에 경고 메시지가 표시됩니다.
**참고**
AWS Control Tower는 **계정 생성** 또는 **계정 업데이트** 프로세스 중에 블루프린트를 선택한 경우에만 계정에 블루프린트를 추가합니다.
# 파트너 블루프린트
AWS Control Tower Account Factory Customization(AFC)은 AWS 파트너가 구축하고 관리하는 사전 정의된 사용자 지정 블루프린트에 대한 액세스를 제공합니다. 이러한 파트너 블루프린트는 특정 사용 사례에 맞게 계정을 사용자 지정하는 데 도움이 됩니다. 각 파트너의 블루프린트는 특정 파트너의 제품 제공과 함께 작동하도록 사전 구성된 사용자 지정 계정을 구축하는 데 도움이 됩니다.
AWS Control Tower 파트너 블루프린트의 전체 목록을 보려면 콘솔에서 Service Catalog **시작하기 라이브러리**로 이동합니다. 소스 유형 **AWS Control Tower 블루프린트**를 검색합니다.
## Account Factory 사용자 지정(AFC) 고려 사항
+ AFC는 단일 AWS Service Catalog 블루프린트 제품만 사용하여 사용자 지정을 지원합니다.
+ AWS Service Catalog 블루프린트 제품은 허브 계정과 AWS Control Tower 랜딩 존 홈 리전과 동일한 리전에서 생성해야 합니다.
+ `AWSControlTowerBlueprintAccess` IAM 역할은 적절한 이름, 권한 및 신뢰 정책을 사용하여 생성해야 합니다.
+ AWS Control Tower는 블루프린트에 대해 두 가지 배포 옵션을 지원합니다. 즉, 홈 리전에만 배포하거나 AWS Control Tower가 관리하는 모든 리전에 배포할 수 있습니다. 리전을 선택할 수는 없습니다.
+ 멤버 계정에서 블루프린트를 업데이트하면 블루프린트 허브 계정 ID와 AWS Service Catalog 블루프린트 제품을 변경할 수 없습니다.
+ AWS Control Tower는 단일 블루프린트 업데이트 작업에서 기존 블루프린트 제거 및 새 블루프린트 추가를 지원하지 않습니다. 블루프린트를 제거한 다음 별도의 작업에 새 블루프린트를 추가할 수 있습니다.
+ AWS Control Tower는 생성 또는 등록할 계정이 사용자 지정 계정인지 아니면 사용자 지정되지 않은 계정인지에 따라 동작을 변경합니다. 블루프린트를 사용하여 사용자 지정 계정을 생성 또는 등록하지 않는 경우 AWS Control Tower는 AWS Control Tower 관리 계정에서 Service Catalog를 통해 Account Factory에서 프로비저닝된 제품을 생성합니다. 블루프린트로 계정을 생성 또는 등록할 때 사용자 지정을 지정하는 경우 AWS Control Tower는 AWS Control Tower 관리 계정에서 Account Factory에서 프로비저닝된 제품을 생성하지 않습니다.
## 블루프린트 오류가 발생할 때
**블루프린트 적용 중 오류 발생**
계정에 블루프린트를 적용하는 과정에서 오류가 발생하는 경우, 해당 계정이 새 계정이든 AWS Control Tower에 등록 중인 기존 계정이든 복구 절차는 동일합니다. 계정이 존재하지만 사용자 지정되지 않았으며 AWS Control Tower에 등록되지 않았습니다. 계속하려면 단계에 따라 AWS Control Tower에 계정을 등록하고 등록 시 블루프린트를 추가합니다.
**`AWSControlTowerBlueprintAccess` 역할 및 해결 방법 생성 중 오류 발생**
AWS Control Tower 계정에서 `AWSControlTowerBlueprintAccess` 역할을 생성할 때는 `AWSControlTowerExecution` 역할을 사용하여 위탁자로 로그인해야 합니다. 다른 계정으로 로그인한 경우 다음 아티팩트에 표시된 것처럼 SCP에 의해 `CreateRole` 작업이 방지됩니다.
```
{
"Condition": {
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::*:role/AWSControlTowerExecution",
"arn:aws:iam::*:role/stacksets-exec-*"
]
}
},
"Action": [
"iam:AttachRolePolicy",
"iam:CreateRole",
"iam:DeleteRole",
"iam:DeleteRolePermissionsBoundary",
"iam:DeleteRolePolicy",
"iam:DetachRolePolicy",
"iam:PutRolePermissionsBoundary",
"iam:PutRolePolicy",
"iam:UpdateAssumeRolePolicy",
"iam:UpdateRole",
"iam:UpdateRoleDescription"
],
"Resource": [
"arn:aws:iam::*:role/aws-controltower-*",
"arn:aws:iam::*:role/*AWSControlTower*",
"arn:aws:iam::*:role/stacksets-exec-*"
],
"Effect": "Deny",
"Sid": "GRIAMROLEPOLICY"
}
```
다음 해결 방법을 사용할 수 있습니다.
+ (가장 권장됨) `AWSControlTowerExecution` 역할을 수임하고 `AWSControlTowerBlueprintAccess` 역할을 생성합니다. 이 해결 방법을 선택하는 경우 리소스에 의도하지 않은 변경 사항이 발생하지 않도록 즉시 `AWSControlTowerExecution` 역할에서 로그아웃해야 합니다.
+ AWS Control Tower에 등록되지 않아 이 SCP의 적용을 받지 않는 계정에 로그인합니다.
+ 작업을 허용하려면 이 SCP를 일시적으로 편집합니다.
+ (매우 권장하지 않음) SCP의 적용을 받지 않도록 AWS Control Tower 관리 계정을 허브 계정으로 사용합니다.
## CloudFormation을 기반으로 AFC 블루프린트에 대한 정책 문서 사용자 지정
Account Factory를 통해 블루프린트를 활성화하면 AWS Control Tower는 사용자를 대신하여 StackSet를 생성 CloudFormation 하도록에 지시합니다.는 StackSet에서 스택을 생성 CloudFormation 하려면 관리형 계정에 대한 액세스 권한이 CloudFormation 필요합니다. CloudFormation 는 `AWSControlTowerExecution` 이미 역할을 통해 관리형 계정에 관리자 권한을 가지고 있지만이 역할은에서 수임할 수 없습니다 CloudFormation.
블루프린트 활성화의 일부로 AWS Control Tower는 CloudFormation 에서 StackSet 관리 작업을 완료하기 위해 수임할 수 역할을 멤버 계정에 생성합니다. Account Factory를 통해 사용자 지정 블루프린트를 활성화하는 가장 간단한 방법은 *모두 허용* 정책을 사용하는 것입니다. 이러한 정책은 모든 블루프린트 템플릿과 호환되기 때문입니다.
그러나 모범 사례에서는 대상 계정 CloudFormation 에서에 대한 권한을 제한해야 한다고 제안합니다. 사용자 지정 정책을 제공할 수 있습니다.이 정책은 AWS Control Tower가가 사용하기 CloudFormation 위해 생성한 역할에 적용됩니다. 예를 들어 블루프린트에서 *something-important*라는 SSM 파라미터를 생성하는 경우 다음 정책을 제공할 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCloudFormationActionsOnStacks",
"Effect": "Allow",
"Action": "cloudformation:*",
"Resource": "arn:aws:cloudformation:*:*:stack/*"
},
{
"Sid": "AllowSsmParameterActions",
"Effect": "Allow",
"Action": [
"ssm:PutParameter",
"ssm:DeleteParameter",
"ssm:GetParameter",
"ssm:GetParameters"
],
"Resource": "arn:*:ssm:*:*:parameter/something-important"
}
]
}
```
------
`AllowCloudFormationActionsOnStacks` 문은 모든 AFC 사용자 지정 정책에 필요합니다.는이 역할을 CloudFormation 사용하여 스택 인스턴스를 생성하므로 스택에서 CloudFormation 작업을 수행할 수 있는 권한이 필요합니다. 이 `AllowSsmParameterActions` 섹션은 활성화되는 템플릿에 따라 다릅니다.
**권한 문제 해결**
제한된 정책으로 블루프린트를 활성화하면 블루프린트를 활성화할 권한이 부족할 수 있습니다. 이러한 문제를 해결하려면 정책 문서를 수정하고 수정된 정책을 사용하도록 멤버 계정의 블루프린트 기본 설정을 업데이트합니다. 정책이 블루프린트를 활성화하기에 충분한지 확인하려면 CloudFormation 권한이 부여되고 해당 역할을 사용하여 직접 스택을 생성할 수 있는지 확인합니다.
## Terraform 기반 Service Catalog 제품을 생성하는 데 필요한 추가 권한
AFC용 Terraform 구성 파일을 사용하여 AWS Service Catalog 외부 제품을 생성할 때 AWS Service Catalog 는 템플릿에 정의된 리소스를 생성하는 데 필요한 권한 외에도 AFC 사용자 지정 IAM 정책에 특정 권한을 추가해야 합니다. 기본 전체 **관리자** 정책을 선택하는 경우에는 이러한 추가 권한을 추가하지 않아도 됩니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"resource-groups:CreateGroup",
"resource-groups:ListGroupResources",
"resource-groups:DeleteGroup",
"resource-groups:Tag"
],
"Resource": "*",
"Effect": "Allow"
},
{
"Action": [
"tag:GetResources",
"tag:GetTagKeys",
"tag:GetTagValues",
"tag:TagResources",
"tag:UntagResources"
],
"Resource": "*",
"Effect": "Allow"
},
{
"Action": "s3:GetObject",
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringEquals": {
"s3:ExistingObjectTag/servicecatalog:provisioning": "true"
}
}
}
]
}
```
------
에서 외부 제품 유형을 사용하여 Terraform 제품을 생성하는 방법에 대한 자세한 내용은 Service Catalog 관리자 안내서의 [5단계: 시작 역할 생성을](https://docs.aws.amazon.com//servicecatalog/latest/adminguide/getstarted-launchrole-Terraform.html) AWS Service Catalog참조하세요.
## AWS Service Catalog 외부 제품 유형으로 전환
AWS Service Catalog 는 *Terraform Open Source* 제품 및 프로비저닝된 제품에 대한 지원을 *외부*라는 새 제품 유형으로 변경했습니다. 이 전환에 대해 자세히 알아보려면 *AWS Service Catalog 관리자 안내서*의 [기존 Terraform Open Source 제품 및 프로비저닝된 제품을 외부 제품 유형으로 업데이트](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/update_terraform_open_source_to_external.html)를 참조하세요.
이 변경 사항은 AWS Control Tower Account Factory 사용자 지정을 통해 생성하거나 등록한 기존 계정에 영향을 미칩니다. 이러한 계정을 *외부* 제품 유형으로 전환하려면 AWS Service Catalog 및 AWS Control Tower 모두에서 변경해야 합니다.
**외부 제품 유형으로 전환하려면**
1. *외부* 및 Terraform 오픈 소스 제품 유형에 대한 지원을 모두 AWS Service Catalog 포함하도록 용 기존 Terraform 참조 엔진을 업그레이드합니다. ** Terraform 참조 엔진 업데이트에 대한 지침은 [AWS Service Catalog GitHub 리포지토리](https://github.com/aws-samples/service-catalog-engine-for-terraform-os)를 검토하세요.
1. 에서 새 *외부* 제품 유형을 사용하여 AWS Service Catalog기존 *Terraform 오픈 소스* 제품(블루프린트)을 복제합니다. **기존 Terraform Open Source 블루프린트를 종료하지 마세요**.
1. AWS Control Tower에서 *Terraform Open Source* 블루프린트를 사용하여 각 계정을 업데이트하고 새 *외부* 블루프린트를 사용합니다.
1. 블루프린트를 업데이트하려면 먼저 *Terraform Open Source* 블루프린트를 완전히 제거해야 합니다. 자세한 내용은 [계정에서 블루프린트 제거](https://docs.aws.amazon.com/controltower/latest/userguide/remove-a-blueprint.html)를 검토하세요.
1. 새 *외부* 블루프린트를 동일한 계정에 추가합니다. 자세한 내용은 [AWS Control Tower 계정에 블루프린트 추가](https://docs.aws.amazon.com/controltower/latest/userguide/add-blueprint-to-account.html)를 참조하세요.
1. *Terraform Open Source* 블루프린트를 사용하는 모든 계정이 *외부* 블루프린트로 업데이트된 후 *Terraform Open Source*를 제품 유형으로 사용하는 모든 제품을 로 돌아가서 AWS Service Catalog 종료합니다.
1. 앞으로 AWS Control Tower Account Factory 사용자 지정을 사용하여 생성되거나 등록된 모든 계정은 *CloudFormation* 또는 *외부* 제품 유형을 사용하여 블루프린트를 참조해야 합니다.
*외부* 제품 유형을 사용하여 생성된 블루프린트의 경우 AWS Control Tower는 Terraform 템플릿과 Terraform 참조 엔진을 사용하는 계정 사용자 지정만 지원합니다. 자세한 내용은 [사용자 지정 설정](https://docs.aws.amazon.com/controltower/latest/userguide/afc-setup-steps.html)을 참조하세요.
**참고**
AWS Control Tower는 새 계정을 생성할 때 *Terraform Open Source*를 제품 유형으로 지원하지 않습니다. 이러한 변경 사항에 대해 자세히 알아보려면 *AWS Service Catalog 관리자 안내서*의 [*외부* 제품 유형으로 기존 Terraform 오픈 소스 제품 및 프로비저닝된 제품 업데이트를](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/update_terraform_open_source_to_external.html) 검토하세요. AWS Service Catalog 는 필요에 따라이 제품 유형 전환을 통해 고객을 지원합니다. 지원을 요청하려면 계정 담당자에게 문의하세요.
# AWS Control Tower Account Factory for Terraform(AFT)을 사용하여 계정 프로비저닝
AWS Control Tower Account Factory for Terraform(AFT)은 AWS Control Tower에서 계정 프로비저닝 및 업데이트 프로세스를 자동화하는 GitOps 모델을 채택하고 있습니다.
AFT를 사용하면 AFT 워크플로를 호출하는 입력이 포함된 계정 요청 Terraform 파일을 생성합니다. 계정 프로비저닝 및 업데이트가 완료되면 AFT 계정 프로비저닝 프레임워크 및 계정 사용자 지정 단계를 실행하여 AFT 워크플로를 계속 진행합니다.
AFT는 AWS Control Tower의 워크플로 성능에 영향을 주지 않습니다. AFT 또는 Account Factory를 통해 계정을 프로비저닝하면 동일한 백엔드 워크플로가 발생합니다.
## 사전 조건
**참고**
AFT 계정 프로비저닝은 AWS Control Tower에서 AWSControlTowerBaseline이 활성화된 조직 단위(OU)를 대상으로 해야 합니다. AWSControlTowerBaseline에 대한 자세한 내용은 섹션을 참조하세요[OU 수준에서 적용되는 기준 유형](types-of-baselines.md#ou-baseline-types).
AFT를 시작할 때 다음을 생성해야 합니다.
+ AWS Control Tower에서 AFT 환경에 대한 OU를 생성한 다음 AFT 관리 계정을 생성합니다. Terraform 모듈로 AFT를 배포할 때 나중에 `main.tf` 파일에 입력할 수 있도록 계정 ID를 기록해 둡니다. AWS Control Tower **Control 세부 정보** 페이지에서 이 계정 ID를 볼 수 있습니다. 자세한 내용은 [Terraform 설명서](https://developer.hashicorp.com/terraform/tutorials/aws/aws-control-tower-aft)를 참조하세요.
+ 완전히 배포된 AFT 환경에 있는 하나 이상의 `git` 리포지토리. 자세한 내용은 [AFT의 배포 후 단계](https://docs.aws.amazon.com/controltower/latest/userguide/aft-post-deployment.html)를 참조하세요.
+ 완전히 배포된 AFT 환경. 자세한 내용은 [AWS Control Tower Account Factory for Terraform(AFT) 개요](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) 및 [AWS Control Tower Account Factory for Terraform(AFT) 배포](https://docs.aws.amazon.com/controltower/latest/userguide/aft-getting-started.html)를 참조하세요. [Terraform 설명서](https://developer.hashicorp.com/terraform/tutorials/aws/aws-control-tower-aft)도 참조하세요.
**작은 정보**
**계정 생성**을 사용하여 AWS Control Tower 콘솔에서 AFT 관리 계정을 생성할 수 있습니다. 자세한 내용은 [프로비저닝 방법](https://docs.aws.amazon.com//controltower/latest/userguide/methods-of-provisioning.html)을 참조하세요.
선택적으로 **aft-account-customizations** 리포지토리에 계정 템플릿 폴더를 생성할 수도 있습니다.
자동 등록을 통해 등록된 계정의 경우:
+ AFT를 통한 새 계정 생성은 계속 정상적으로 작동합니다.
+ 기존 계정 가져오기에는 추가 단계가 필요합니다.
+ 가져오기 전에 OU를 등록하여 필요한 프로비저닝된 제품을 생성합니다.
+ OU 등록은 `CreateManagedAccount` 및 `UpdateManagedAccount` 이벤트를 생성하여 AFT 사용자 지정을 활성화합니다.
AFT에 배포 제한이 있는 AWS 리전 위치에 대한 자세한 내용은 [AWS Control Tower의 제한 사항 및 할당량](limits.md) 및 섹션을 참조하세요[제어 제한 사항](control-limitations.md).
[Terraform 설명서](https://developer.hashicorp.com/terraform/tutorials/aws/aws-control-tower-aft)에는 AWS Control Tower Account Factory for Terraform(AFT)을 설정하는 방법에 대한 유용한 개요가 포함되어 있습니다.
# AWS Control Tower Account Factory for Terraform(AFT) 개요
Account Factory for Terraform(AFT)은 AWS Control Tower에서 계정을 프로비저닝하고 사용자 지정하는 데 도움이 되는 Terraform 파이프라인을 설정합니다. AFT는 Terraform 기반 계정 프로비저닝의 이점을 제공하는 동시에 AWS Control Tower로 계정을 관리할 수 있도록 합니다.
AFT를 사용하여 *계정 요청 Terraform 파일*을 생성하고 계정 프로비저닝을 위한 AFT 워크플로를 트리거하는 입력을 가져옵니다. 계정 프로비저닝 단계가 완료되면 AFT는 계정 사용자 지정 단계가 시작되기 전에 일련의 단계를 자동으로 실행합니다. 자세한 내용은 [AFT 계정 프로비저닝 파이프라인](https://docs.aws.amazon.com/controltower/latest/userguide/aft-provisioning-framework.html)을 참조하세요.
AFT는 Terraform Cloud, Terraform Enterprise 및 Terraform Community Edition을 지원합니다. AFT를 사용하면 입력 파일과 간단한 `git push` 명령을 사용하여 계정 생성을 시작하고 새 계정 또는 기존 계정을 사용자 지정할 수 있습니다. 계정 생성에는 조직의 표준 보안 절차 및 규정 준수 지침을 충족하는 데 도움이 되는 모든 AWS Control Tower 거버넌스 이점과 계정 사용자 지정이 포함됩니다.
AFT는 계정 사용자 지정 요청 추적을 지원합니다. 계정 사용자 지정 요청을 제출할 때마다 AFT는 AFT 사용자 지정 AWS Step Functions 상태 시스템을 통과하는 고유한 추적 토큰을 생성하며,이 토큰은 실행의 일부로 토큰을 로깅합니다. 그런 다음 Amazon CloudWatch Logs Insights 쿼리를 사용하여 타임스탬프 범위를 검색하고 요청 토큰을 검색할 수 있습니다. 따라서 토큰과 함께 제공되는 페이로드를 볼 수 있으므로 전체 AFT 워크플로에서 계정 사용자 지정 요청을 추적할 수 있습니다. CloudWatch Logs 및 Step Functions에 대한 자세한 내용은 다음을 참조하세요.
+ *Amazon CloudWatch Logs 사용자 안내서*의 [Amazon CloudWatch Logs란?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ AWS Step Functions 개발자 안내서의 [AWS Step Functions란?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)**
AFT는 다른 AWS 서비스의 기능을 로 결합하여 프레임워크[구성 요소 서비스](aft-components.md)를 구축하고 Terraform 코드형 인프라(IaC)를 배포하는 파이프라인을 구축합니다. AFT를 사용하여 다음을 수행할 수 있습니다.
+ GitOps 모델에서 계정 프로비저닝 및 업데이트 요청 제출
+ 계정 메타데이터 및 감사 기록 저장
+ 계정 수준 태그 적용
+ 모든 계정, 계정 집합 또는 개별 계정에 사용자 지정 추가
+ 기능 옵션 활성화
AFT는 *AFT 관리 계정*이라는 별도의 계정을 생성하여 AFT 기능을 배포합니다. AFT를 설정하려면 먼저 기존 AWS Control Tower 랜딩 존이 있어야 합니다. AFT 관리 계정은 AWS Control Tower 관리 계정과 동일하지 않습니다.
**AFT는 유연성을 제공함**
+ **플랫폼의 유연성:** AFT는 초기 배포 및 지속적인 작업을 위한 모든 Terraform 배포, 즉 Community Edition, Cloud 및 Enterprise를 지원합니다.
+ **버전 관리 시스템의 유연성:** AFT는 AWS CodeCommit및를 통한 대체 버전 관리 소스를 지원합니다 AWS CodeConnections.
**AFT는 기능 옵션을 제공함**
모범 사례에 따라 여러 기능 옵션을 활성화할 수 있습니다.
+ 데이터 이벤트를 로깅하기 위한 조직 수준 CloudTrail 생성
+ 계정의 AWS 기본 VPC 삭제
+ 프로비저닝된 계정을 AWS Enterprise Support 플랜에 등록
**참고**
AFT 파이프라인은 계정에서 애플리케이션을 실행하는 데 필요한 Amazon EC2 인스턴스와 같은 리소스를 배포하는 데 사용할 수 없습니다. AWS Control Tower 계정의 자동 프로비저닝 및 사용자 지정 전용입니다.
## 비디오 안내
이 비디오(7:33)에서는 AWS Control Tower Account Factory for Terraform을 사용하여 계정을 배포하는 방법을 설명합니다. 비디오의 오른쪽 하단 모서리에 있는 아이콘을 선택하여 전체 화면으로 확대하면 더 잘 보입니다. 자막을 사용할 수 있습니다.
[](http://www.youtube.com/watch?v=eDbNvHz02dk)
# AFT 아키텍처
## 작업 순서
AFT 관리 계정에서 AFT 작업을 실행합니다. 전체 계정 프로비저닝 워크플로의 경우 단계 순서는 다음과 같습니다(다이어그램의 왼쪽에서 오른쪽으로).
1. 계정 요청이 생성되어 파이프라인에 제출됩니다. 한 번에 두 개 이상의 계정 요청을 생성하고 제출할 수 있습니다. Account Factory는 선입선출 순서로 요청을 처리합니다. 자세한 내용은 [여러 계정 요청 제출](https://docs.aws.amazon.com/controltower/latest/userguide/aft-multiple-account-requests.html)을 참조하세요.
1. 각 계정이 프로비저닝됩니다. 이 단계는 AWS Control Tower 관리 계정에서 실행됩니다.
1. 글로벌 사용자 지정은 제공된 각 계정에 대해 생성된 파이프라인에서 실행됩니다.
1. 초기 계정 프로비저닝 요청에 사용자 지정이 지정된 경우 사용자 지정은 대상 계정에서만 실행됩니다. 이미 프로비저닝된 계정이 있는 경우 계정의 파이프라인에서 수동으로 추가 사용자 지정을 시작해야 합니다.
**AWS Control Tower Account Factory for Terraform - 계정 프로비저닝 워크플로 **
![\[그림: AFT 워크플로 다이어그램\]](http://docs.aws.amazon.com/ko_kr/controltower/latest/userguide/images/high-level-aft-diagram.png)
# 비용
AFT에 대한 추가 요금은 없습니다. AFT에서 배포한 리소스, AFT에서 활성화한 AWS 서비스 및 AFT 환경에 배포한 리소스에 대해서만 비용을 지불합니다.
기본 AFT 구성에는 향상된 데이터 보호 및 보안을 위한 AWS PrivateLink 엔드포인트 할당과 AWS CodeBuild를 지원하는 데 필요한 NAT 게이트웨이가 포함됩니다. 이 인프라의 요금에 대한 자세한 내용은 [AWS PrivateLink 요금](https://aws.amazon.com//privatelink/pricing/) 및 [NAT 게이트웨이에 대한 Amazon VPC 요금](https://aws.amazon.com//vpc/pricing/)을 참조하세요. 이러한 비용 관리에 대한 자세한 내용은 AWS 계정 담당자에게 문의하십시오. AFT에 대한 이러한 기본 설정을 변경할 수 있습니다.
# AWS Control Tower Account Factory for Terraform(AFT) 배포
이 섹션은 기존 환경에서 Account Factory for Terraform(AFT)을 설정하려는 AWS Control Tower 환경의 관리자를 위한 것입니다. 여기에서는 새로운 전용 AFT 관리 계정을 사용하여 Account Factory for Terraform(AFT) 환경을 설정하는 방법을 설명합니다.
**참고**
Terraform 모듈은 AFT를 배포합니다. 이 모듈은 GitHub의 [AFT 리포지토리](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main)에서 사용할 수 있으며 전체 AFT 리포지토리가 모듈로 간주됩니다.
AFT 리포지토리를 복제하는 대신 GitHub의 AFT 모듈을 참조하는 것이 좋습니다. 이렇게 하면 사용 가능한 대로 모듈에 대한 업데이트를 제어하고 사용할 수 있습니다.
AWS Control Tower Account Factory for Terraform(AFT) 기능의 최신 릴리스에 대한 자세한 내용은 이 GitHub 리포지토리[릴리스 파일](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/releases)을 참조하세요.
**배포 사전 조건**
AFT 환경을 구성하고 시작하기 전에 다음 리소스가 있어야 합니다.
+ AWS Control Tower 랜딩 존의 홈 리전. 자세한 내용은 [AWS 리전 이 AWS Control Tower에서 작동하는 방식](https://docs.aws.amazon.com/controltower/latest/userguide/region-how.html)을 참조하세요.
+ AWS Control Tower 랜딩 존. 자세한 내용은 [AWS Control Tower 랜딩 존 계획](https://docs.aws.amazon.com/controltower/latest/userguide/planning-your-deployment.html)을 참조하세요.
+ AWS Control Tower에서 프로비저닝하거나 다른 방법으로 프로비저닝하고 AWS Control Tower에 등록할 수 있는 AFT 관리 계정.
+ Terraform 버전 및 배포. 자세한 내용은 [Terraform 및 AFT 버전](https://docs.aws.amazon.com/controltower/latest/userguide/version-supported.html)을 참조하세요.
+ 코드 및 기타 파일의 변경 사항을 추적하고 관리하기 위한 VCS 공급자. 기본적으로 AFT는를 사용합니다 AWS CodeCommit. 자세한 내용은 *AWS CodeCommit 사용 설명서*의 [What is AWS CodeCommit?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)를 참조하세요.
AFT를 처음 배포하고 기존 CodeCommit 리포지토리가 없는 경우 GitHub 또는 BitBucket과 같은 외부 VCS 공급자를 선택해야 합니다. 자세한 내용은 [AFT에서 소스 코드의 버전 관리를 위한 대안](https://docs.aws.amazon.com/controltower/latest/userguide/aft-alternative-vcs.html)을 참조하세요.
+ AFT를 설치하는 Terraform 모듈을 실행할 수 있는 런타임 환경.
+ AFT 기능 옵션. 자세한 내용은 [기능 옵션 활성화](https://docs.aws.amazon.com/controltower/latest/userguide/aft-feature-options.html)를 참조하세요.
## AWS Control Tower Account Factory for Terraform 구성 및 시작
다음 단계는 사용자가 Terraform 워크플로를 잘 알고 있다고 가정합니다. AWS 워크숍 스튜디오 웹 사이트의 AFT 랩 [소개를 따라 AFT](https://catalog.workshops.aws/control-tower/en-US/customization/aft) 배포에 대해 자세히 알아볼 수도 있습니다.
**1단계: AWS Control Tower 랜딩 존 시작**
[AWS Control Tower 시작하기](https://catalog.workshops.aws/control-tower/en-US/customization/aft)의 단계를 완료합니다. 여기에서 AWS Control Tower 관리 계정을 생성하고 AWS Control Tower 랜딩 존을 설정합니다.
**참고**
**AdministratorAccess** 자격 증명이 있는 AWS Control Tower 관리 계정에 대한 역할을 생성해야 합니다. 자세한 내용은 다음을 참조하세요.
*AWS Identity and Access Management 사용자 안내서*의 [IAM ID(사용자, 사용자 그룹 및 역할)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html)
*AWS 관리형 정책 참조 안내서*의 [AdministratorAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html)
**2단계: AFT에 대한 새 조직 단위 생성(매우 권장)**
AWS Control Tower 랜딩 존에 별도의 OU를 생성하는 것이 좋습니다. 이 OU는 AFT 관리 계정을 프로비저닝하는 곳입니다. AWS Control Tower 관리 계정에서 새 OU 및 AFT 관리 계정을 생성합니다. 자세한 내용은 [새 OU 생성](https://docs.aws.amazon.com/controltower/latest/userguide/create-new-ou.html)을 참조하세요.
**3단계: AFT 관리 계정 프로비저닝**
AFT를 사용하려면 AFT 관리 작업 전용 AWS 계정을 프로비저닝해야 합니다. AWS Control Tower 랜딩 존과 연결된 AWS Control Tower 관리 계정에 로그인할 때 AFT 관리 계정을 생성합니다. AWS Control Tower 콘솔에서 **조직** 페이지에서 **계정 생성**을 선택하거나 다른 방법을 사용하여 AFT 관리 계정을 프로비저닝할 수 있습니다. 자세한 내용은 [AWS Service Catalog Account Factory로 계정 프로비저닝](https://docs.aws.amazon.com/controltower/latest/userguide/provision-as-end-user.html)을 참조하세요.
**참고**
AFT용 OU를 별도로 생성한 경우 AFT 관리 계정을 생성할 때 이 OU를 선택해야 합니다.
AFT 관리 계정을 완전히 프로비저닝하는 데 최대 30분이 걸릴 수 있습니다.
**4단계: Terraform 환경을 배포할 수 있는지 확인**
이 단계는 사용자가 Terraform에 대한 경험이 있고 Terraform을 실행하기 위한 절차가 마련되어 있다고 가정합니다. 자세한 내용은 HashiCorp 개발자 웹 사이트에서 [Command: init](https://developer.hashicorp.com/terraform/cli/commands/init)를 참조하세요.
**참고**
AFT는 Terraform 버전 `1.6.0` 이상을 지원합니다.
**5단계: 선택적 구성**
+ **선택적으로 가상 프라이빗 클라우드(VPC) 구성 설정**
AFT 모듈에는 AWS Control Tower가 중앙 AFT 관리 계정의 VPC 내에서 계정 리소스를 프로비저닝할지 여부를 지정하는 `aft_enable_vpc` 파라미터가 포함되어 있습니다. 기본적으로 이 파라미터는 `true`로 설정됩니다. 이 파라미터를 `false`로 설정하는 경우 AWS Control Tower는 VPC 및 NAT 게이트웨이 또는 VPC 엔드포인트와 같은 프라이빗 네트워킹 리소스를 사용하지 *않고* AFT를 배포합니다. `aft_enable_vpc`를 비활성화하면 *일부 사용 패턴*에 대한 AFT 운영 비용을 줄이는 데 도움이 될 수 있습니다. VPC 구성을 추가하면 `false`로 설정되는 `aft_enable_vpc` 파라미터가 재정의됩니다.
**참고**
`aft_enable_vpc` 파라미터를 다시 활성화(값을 `false`에서 `true`로 전환)하려면 `terraform apply` 명령을 연속으로 두 번 실행해야 할 수 있습니다.
새 VPC를 프로비저닝하는 대신 계정의 기존 VPC를 사용하도록 AFT를 구성할 수 있습니다. 자체 VPC를 사용하려면 다음 VPC 구성 파라미터를 제공합니다.
+ `aft_customer_vpc_id` - 기존 VPC의 ID
+ `aft_customer_private_subnets` - VPC의 프라이빗 서브넷 ID 목록
구성 예제:
```
module "aft" {
source = "github.com/aws-ia/terraform-aws-control_tower_account_factory"
# VPC configuration
aft_customer_vpc_id = "vpc-0123456789abcdef0"
aft_customer_private_subnets = ["subnet-0123456789abcdef0", "subnet-0123456789abcdef1"]
# Other AFT parameters...
}
```
**중요**
기존 AFT 배포가 있는 경우 사용자 지정 VPC 옵션을 사용하지 않는 것이 좋습니다. Lambda 함수 또는 CodePipeline에 기존의 기본 VPC의 리소스를 사용하는 종속성이 있을 수 있습니다.
+ **선택적으로 Terraform 프로젝트 이름 구성**
`terraform_project_name` 파라미터를 설정하여 AFT에서 사용하는 Terraform 프로젝트 이름을 사용자 지정할 수 있습니다. 기본적으로 AFT는 배포를 Terraform Cloud 또는 Terraform Enterprise의 '기본' 프로젝트에 넣습니다.
구성 예제:
```
module "aft" {
source = "github.com/aws-ia/terraform-aws-control_tower_account_factory"
# Project name configuration
terraform_project_name = "my-organization-aft"
# Other AFT parameters...
}
```
**참고**
이 파라미터는 Terraform Enterprise 또는 Terraform Cloud 배포에만 적용됩니다.
+ **선택적으로 AFT 리소스에 사용자 지정 태그 적용**
`tags` 파라미터를 사용하여 모든 AFT 리소스에 사용자 지정 태그를 적용할 수 있습니다. 이러한 태그는 리소스 구성, 비용 할당, 액세스 제어에 도움이 됩니다.
구성 예제:
```
module "aft" {
source = "github.com/aws-ia/terraform-aws-control_tower_account_factory"
# Custom tags configuration
tags = {
Environment = "Production"
CostCenter = "IT-12345"
Project = "AFT-Deployment"
Owner = "platform-team@example.com"
}
# Other AFT parameters...
}
```
이러한 태그는 AFT 모듈에서 생성한 모든 리소스에 적용됩니다. AFT는 사용자 지정 태그로 재정의할 수 없는 모든 리소스에 `managed_by = "AFT"` 태그를 자동으로 추가합니다.
**참고**
사용자 지정 태그는 처음 배포할 때뿐만 아니라 언제든지 추가할 수 있습니다.
+ **선택적으로 AWS KMS 고객 관리형 암호화 키(CMK)를 CloudWatch 로그 그룹 및 SNS 주제에 적용**
로그 그룹 및 SNS 주제에 대해 KMS CMK 암호화를 활성화하려면 `cloudwatch_log_group_enable_cmk_encryption` 및 `sns_topic_enable_cmk_encryption` 변수를 설정합니다.
이러한 설정을 옵트인하면 AFT는 기존 CMK인 *alias/aft*를 사용하여 CloudWatch 로그 및 SNS 주제를 암호화합니다. 이 CMK는 AFT 관리 계정에 AFT가 배포될 때 생성되며 로그 그룹 및 SNS 주제에 적용될 수 있습니다.
+ `cloudwatch_log_group_enable_cmk_encryption` 변수가 **true**로 설정된 경우 AFT에 대한 CloudWatch 로그 그룹은 CMK를 사용하여 암호화됩니다. 변수가 기본값인 **false**로 설정된 경우 [CloudWatch 로그 기본값으로 서버 측 암호화](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html)를 사용하여 로그가 암호화됩니다.
+ `sns_topic_enable_cmk_encryption` 변수가 **true**로 설정된 경우 AFT SNS 주제로 전송된 알림(*aft-notifications* 및 *aft-failure-notifications*)은 CMK를 사용하여 암호화됩니다. 변수가 기본값인 **false**로 설정된 경우 SNS 메시지는 AWS 관리형 키인 *alias/aws/sns*로 암호화됩니다. 자세한 내용은 [SSE 주요 용어](https://docs.aws.amazon.com//sns/latest/dg/sns-server-side-encryption.html#sse-key-terms)를 참조하세요.
+ **선택적으로 CodeBuild 컴퓨팅 유형 변경**
배포 중에 AFT가 CodeBuild에 사용하는 컴퓨팅 유형을 변경하려면 `aft_codebuild_compute_type` 변수를 설정합니다.
허용되는 컴퓨팅 유형에 대한 자세한 내용은 [온디맨드 환경 유형 정보](https://docs.aws.amazon.com//codebuild/latest/userguide/build-env-ref-compute-types.html#environment.types)를 참조하세요. 기본 컴퓨팅 유형은 `BUILD_GENERAL1_MEDIUM`입니다.
+ **선택적으로 Terraform용 OpenID Connect(OIDC) 구성**
Terraform Enterprise 또는 HCP Terraform(이전 Terraform Cloud)을 사용하는 고객은 OIDC 프로토콜을 기반으로 구축된 Terraform의 워크로드 자격 증명 토큰(또는 동적 공급자 자격 증명)을 사용하여 AFT로 워크스페이스를 안전하게 연결하고 인증할 수 있습니다.
`terraform_oidc_integration` 파라미터를 로 설정하여 AFT 워크스페이스에 대해 OIDC 통합을 활성화할 수 있습니다`true`. 이 파라미터는 기본적으로 `false`로 설정되어 있습니다. 이 파라미터를 활성화할 때 기본값(`aws.workload.identity``app.terraform.io`각각 `terraform_oidc_aws_audience` 및 )이 환경과 일치하지 않는 경우 및 `terraform_oidc_hostname` 파라미터를 검토하고 구성해야 합니다.
구성 예제:
```
module "aft" {
source = "github.com/aws-ia/terraform-aws-control_tower_account_factory"
# Terraform distribution must be "tfc" or "tfe" for OIDC
terraform_distribution = "tfc"
# Terraform OIDC Configuration
terraform_oidc_integration = true
terraform_oidc_aws_audience = "aws.workload.identity" # default
terraform_oidc_hostname = "app.terraform.io" # default; set to your TFE hostname if applicable
# Other AFT parameters...
}
```
**참고**
이 파라미터는 Terraform Enterprise 또는 HCP Terraform 배포에만 적용됩니다.
**참고**
현재 AFT 관리 계정에서 Terraform용 OIDC 공급자를 활용하는 경우이 통합에 옵트인하기 전에 해당 공급자를 삭제해야 합니다. AFT는 배포 시 해당 공급자를 다시 생성합니다.
**6단계: Account Factory for Terraform 모듈을 직접 호출하여 AFT 배포**
**AdministratorAccess** 자격 증명이 있는 AWS Control Tower 관리 계정에 대해 생성한 역할로 AFT 모듈을 직접 호출합니다. AWS Control Tower는 AWS Control Tower Account Factory 요청을 오케스트레이션하는 데 필요한 모든 인프라를 설정하는 AWS Control Tower 관리 계정을 통해 Terraform 모듈을 프로비저닝합니다.
GitHub의 [AFT 리포지토리](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main)에서 AFT 모듈을 볼 수 있습니다. 전체 GitHub 리포지토리가 AFT 모듈로 간주됩니다. AFT 모듈을 실행하고 AFT를 배포하는 데 필요한 입력에 대한 자세한 내용은 [README 파일](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/blob/main/README.md)을 참조하세요. 또는 [Terraform 레지스트리](https://registry.terraform.io/modules/aws-ia/control_tower_account_factory/aws/latest) 에서 AFT 모듈을 볼 수 있습니다.
환경에 Terraform 관리를 위해 설정된 파이프라인이 있는 경우 AFT 모듈을 기존 워크플로에 통합할 수 있습니다. 그렇지 않으면 필요한 자격 증명으로 인증된 모든 환경에서 AFT 모듈을 실행합니다.
제한 시간을 초과하면 배포가 실패합니다. 전체 배포에 충분한 제한 시간이 있는지 확인하려면 AWS Security Token Service (STS) 자격 증명을 사용하는 것이 좋습니다. AWS STS 자격 증명의 최소 제한 시간은 60분입니다. 자세한 내용은 *AWS Identity and Access Management 사용자 안내서*의 [IAM의 임시 보안 자격 증명](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)을 참조하세요.
**참고**
AFT가 Terraform 모듈을 통해 배포를 완료할 때까지 최대 30분까지 기다릴 수 있습니다.
**7단계: Terraform 상태 파일 관리**
AFT를 배포할 때 Terraform 상태 파일이 생성됩니다. 이 아티팩트는 Terraform이 생성한 리소스의 상태를 설명합니다. AFT 버전을 업데이트하려는 경우 Terraform 상태 파일을 미리 설치하거나 Amazon S3 및 DynamoDB를 사용하여 Terraform 백엔드를 설정해야 합니다. AFT 모듈은 백엔드 Terraform 상태를 관리하지 않습니다.
**참고**
Terraform 상태 파일을 보호할 책임은 사용자에게 있습니다. 일부 입력 변수에는 프라이빗 `ssh` 키 또는 Terraform 토큰과 같은 민감한 값이 포함될 수 있습니다. 배포 방법에 따라 이러한 값은 Terraform 상태 파일에서 일반 텍스트로 볼 수 있습니다. 자세한 내용은 HashiCorp 웹 사이트에서 [상태 내 민감한 데이터](https://www.terraform.io/docs/language/state/sensitive-data.html)를 참조하세요.
# 배포 후 단계
AFT 인프라 배포가 완료되면 다음 추가 단계에 따라 설정 프로세스를 완료하고 계정을 프로비저닝할 준비를 합니다.
**1단계: 원하는 VCS 공급자와 CodeConnections 완료**
타사 VCS 공급자를 선택하면 AFT가 CodeConnections를 설정하고 사용자가 이를 확인합니다. 기본 VCS로 AFT를 설정하는 방법은 [AFT 내 소스 코드의 버전 관리를 위한 대안](aft-alternative-vcs.md) 섹션을 참조하세요.
AWS CodeStar 연결을 설정하는 초기 단계는 AFT에서 수행합니다. 연결을 확인해야 합니다.
**2단계: 각 리포지토리 채우기**
AFT를 사용하려면 [다음 4개의 리포지토리](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos)를 관리해야 합니다.
1. 계정 요청 - 이 리포지토리에서는 계정 요청 배치 또는 업데이트를 처리합니다. [사용 가능한 예제](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-request) . AFT 계정 요청에 대한 자세한 내용은 [AFT를 사용하여 새 계정 프로비저닝](aft-provision-account.md) 섹션을 참조하세요.
1. AFT 계정 프로비저닝 사용자 지정 - 이 리포지토리는 글로벌 사용자 지정 단계를 시작하기 전에 AFT에서 생성 및 관리하는 모든 계정에 적용되는 사용자 지정을 관리합니다. [사용 가능한 예제](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-provisioning-customizations) . AFT 계정 프로비저닝 사용자 지정을 생성하려면 [AFT 계정 프로비저닝 사용자 지정 상태 시스템 생성](aft-provisioning-framework.md#aft-create-customizations) 섹션을 참조하세요.
1. 글로벌 사용자 지정 - 이 리포지토리는 AFT에서 생성하고 관리하는 모든 계정에 적용되는 사용자 지정을 관리합니다. [사용 가능한 예제](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-global-customizations) . AFT 글로벌 사용자 지정을 생성하려면 [글로벌 사용자 지정 적용](aft-account-customization-options.md#aft-global-customizations) 섹션을 참조하세요.
1. 계정 사용자 지정 - 이 리포지토리는 AFT에서 생성 및 관리하는 특정 계정에만 적용되는 사용자 지정을 관리합니다. [사용 가능한 예제](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-customizations) . AFT 계정 사용자 지정을 생성하려면 [계정 사용자 지정 적용](aft-account-customization-options.md#aft-account-customizations) 섹션을 참조하세요.
AFT는 이러한 각 리포지토리가 특정 디렉터리 구조를 따를 것으로 기대합니다. 리포지토리를 채우는 데 사용되는 템플릿과 템플릿을 채우는 방법을 설명하는 지침은 [AFT github 리포지토리](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos)의 Account Factory for Terraform 모듈에서 사용할 수 있습니다.
# AFT를 사용하여 새 계정 프로비저닝
*이 섹션에서는 AFT 및 AFT 관리 계정을 이미 설정했고 추가 계정을 프로비저닝하고 있다고 가정합니다.*
AFT로 새 계정을 프로비저닝하려면 계정 요청 Terraform 파일을 생성합니다. 이 파일에는 **aft-account-request** 리포지토리의 파라미터에 대한 입력이 포함되어 있습니다. 계정 요청 Terraform 파일을 생성한 후 `git push`를 실행하여 계정 요청 처리를 시작합니다. 이 명령 AWS CodePipeline은 계정 프로비저닝이 완료된 후 AFT 관리 계정에 생성되는에서 `ct-aft-account-request` 작업을 호출합니다. 자세한 내용은 [AFT 계정 프로비저닝 파이프라인](https://docs.aws.amazon.com/controltower/latest/userguide/aft-provisioning-framework.html)을 참조하세요.
## 계정 요청 Terraform 파일 파라미터
계정 요청 Terraform 파일에 다음 파라미터를 포함해야 합니다. GitHub에서 [계정 요청 Terraform 파일 예제](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-request)를 볼 수 있습니다.
+ `module name`의 값은 AWS 계정 요청에 따라 고유해야 합니다.
+ `module source`의 값은 AFT가 제공하는 계정 요청 Terraform 모듈의 경로입니다.
+ `control_tower_parameters`의 값은 AWS Control Tower 계정을 생성하는 데 필요한 입력을 캡처합니다. 값에는 다음 입력 필드가 포함됩니다.
+ `AccountEmail`
+ `AccountName`
+ `ManagedOrganizationalUnit`
+ `SSOUserEmail`
+ `SSOUserFirstName`
+ `SSOUserLastName`
**참고**
`control_tower_parameters`에 제공하는 입력은 계정 프로비저닝 중에 변경할 수 없습니다.
**aft-account-request** 리포지토리에서 `ManagedOrganizationalUnit` 지정에 지원되는 형식에는 `OUName` 및 `OUName (OU-ID)`이 포함됩니다.
+ `account_tags`는 비즈니스 기준에 AWS 계정 따라 태그를 지정할 수 있는 사용자 정의 키와 값을 캡처합니다. 자세한 내용은 *AWS Organizations 사용자 안내서*의 [AWS Organizations 리소스에 태그 지정](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_tagging.html)을 참조하세요.
+ `change_management_parameters`의 값은 계정 요청이 생성된 이유 및 계정 요청을 시작한 사용자와 같은 추가 정보를 캡처합니다. 값에는 다음 입력 필드가 포함됩니다.
+ `change_reason`
+ `change_requested_by`
+ `custom_fields`는 **/aft/account-request/custom-fields/**의 제공된 계정에서 SSM 파라미터로 배포되는 키 및 값으로 추가 메타데이터를 캡처합니다. 계정 사용자 지정 중에 이 메타데이터를 참조하여 적절한 제어를 배포할 수 있습니다. 예를 들어, 규정 준수가 적용되는 계정은 추가로 배포될 수 있습니다 AWS Config 규칙. `custom_fields`로 수집하는 메타데이터는 계정 프로비저닝 및 업데이트 중에 추가 처리를 간접 호출할 수 있습니다. 계정 요청에서 사용자 지정 필드가 제거되면, 사용자 지정 필드는 제공된 계정의 SSM Parameter Store에서 제거됩니다.
+ (선택 사항) `account_customizations_name`은 **aft-account-customizations** 리포지토리에서 계정 템플릿 폴더를 캡처합니다. 자세한 내용은 [계정 사용자 지정](https://docs.aws.amazon.com/controltower/latest/userguide/aft-account-customization-options.html)을 참조하세요.
# 여러 계정 요청 제출
AFT는 계정 요청을 한 번에 하나씩 처리하지만 AFT 파이프라인에 여러 계정 요청을 제출할 수 있습니다. AFT 파이프라인에 여러 계정 요청을 제출하면 AFT는 선입선출 순서로 계정 요청을 대기열에 넣고 처리합니다.
**참고**
AFT를 통해 프로비저닝할 각 계정에 대해 계정 요청 Terraform 파일을 생성하거나 단일 계정 요청 Terraform 파일에 여러 계정 요청을 캐스케이드할 수 있습니다.
# 기존 계정 업데이트
**자동 등록 호환성**
조직에서 자동 계정 등록에 자동 등록을 사용하는 경우 AFT에는 이러한 계정을 가져올 때 제한이 있습니다. 자동 등록을 통해 등록된 계정에는 AFT의 가져오기 워크플로에 필요한 서비스 카탈로그 프로비저닝 제품이 없습니다.
**해결 방법:** OU 등록 기능을 사용하여 자동으로 등록된 계정에 대해 프로비저닝된 제품을 생성합니다. 이렇게 하면 AFT 사용자 지정에 필요한 수명 주기 이벤트가 활성화됩니다.
이전에 제출한 계정 요청을 편집하고 `git push`를 실행하여 AFT가 프로비저닝하는 계정을 업데이트할 수 있습니다. 이 명령은 계정 프로비저닝 워크플로를 호출하고 계정 업데이트 요청을 처리할 수 있습니다. `control_tower_parameters`에 필요한 값의 일부인 `ManagedOrganizationalUnit`에 대한 입력을 업데이트할 수 있습니다.
`ManagedOrganizationalUnit`은 모든 `control_tower_parameters` 중에서 업데이트할 수 있는 유일한 파라미터입니다. 그러나 `custom_fields`와 같이 계정 요청 Terraform 파일의 일부인 다른 파라미터는 업데이트할 수 있습니다. 자세한 내용은 [AFT를 사용하여 새 계정 프로비저닝](https://docs.aws.amazon.com/controltower/latest/userguide/aft-provision-account.html)을 참조하세요.
예를 들어 AFT 계정의 이름 또는 이메일 주소를 업데이트하려면 계정 요청 파일에서 세부 정보를 `custom_fields`로 정의하면 됩니다. 이렇게 하면 글로벌 사용자 지정 중에 `aws_account_alternate_contact` 리소스에 전달할 수 있는 SSM 파라미터를 생성합니다.
```
resource "aws_account_alternate_contact" "operations" {
alternate_contact_type = "OPERATIONS"
name = "Example"
title = "Example"
email_address = "someone@example.com"
phone_number = "+1234567890"
}
```
작업 및 보안과 같은 다른 고객 응대 유형에 유사한 필드를 추가할 수 있습니다. 글로벌 사용자 지정에서 각 사용자 지정 필드에 대한 데이터 조회를 추가하여 계정 요청에서 생성한 모든 필드를 조회합니다.
```
data "aws_ssm_parameter" "billing_name" {
name = "/aft/account-request/custom-fields/billing_name"
}
data "aws_ssm_parameter" "billing_title" {
name = "/aft/account-request/custom-fields/billing_title"
}
data "aws_ssm_parameter" "billing_email_address" {
name = "/aft/account-request/custom-fields/billing_email_address"
}
data "aws_ssm_parameter" "billing_phone_number" {
name = "/aft/account-request/custom-fields/billing_phone_number"
}
```
마지막으로 Global Customizations 파일에서도 대체 연락처 리소스를 생성합니다. 계정 요청에서 생성한 모든 연락처 유형에 대해 다음 블록 중 하나를 정의해야 합니다.
```
resource "aws_account_alternate_contact" "billing" {
alternate_contact_type = "BILLING"
name = data.aws_ssm_parameter.billing_name.value
title = data.aws_ssm_parameter.billing_title.value
email_address = data.aws_ssm_parameter.billing_email_address.value
phone_number = data.aws_ssm_parameter.billing_phone_number.value
}
```
**참고**
`control_tower_parameters`에 제공하는 입력은 계정 프로비저닝 중에 변경할 수 없습니다.
**aft-account-request** 리포지토리에서 `ManagedOrganizationalUnit` 지정에 지원되는 형식에는 `OUName` 및 `OUName (OU-ID)`이 포함됩니다.
## AFT가 프로비저닝하지 않는 계정 업데이트
**aft-account-request** 리포지토리에서 계정을 지정하여 AFT 외부에서 생성된 AWS Control Tower 계정을 업데이트할 수 있습니다.
**참고**
모든 계정 세부 정보가 올바르고 AWS Control Tower 조직 및 해당 AWS Service Catalog 프로비저닝된 제품과 일치하는지 확인합니다.
**AWS 계정 AFT로 기존를 업데이트하기 위한 사전 조건**
+ 는 AWS Control Tower에 등록해야 AWS 계정 합니다.
+ 는 AWS Control Tower 조직의 일부여야 AWS 계정 합니다.
# Terraform 및 AFT 버전
Account Factory for Terraform(AFT)은 Terraform 버전 `1.6.0` 이상을 지원합니다. 다음 예제와 같이, AFT 배포 프로세스를 위해 Terraform 버전을 입력 파라미터로 제공해야 합니다.
```
terraform_version = "1.6.0"
```
## Terraform 배포
AFT는 다음의 세 가지 Terraform 배포를 지원합니다.
+ Terraform Community Edition
+ Terraform Cloud
+ Terraform Enterprise
이러한 배포는 이후 섹션에서 설명합니다. AFT 부트스트랩 프로세스 중에 선택한 Terraform 배포를 입력 파라미터로 제공합니다. AFT 배포 및 입력 파라미터에 대한 자세한 내용은 [AWS Control Tower Account Factory for Terraform(AFT) 배포](aft-getting-started.md) 섹션을 참조하세요.
Terraform Cloud 또는 Terraform Enterprise 배포를 선택하는 경우 `terraform_token `에 지정한 [API 토큰](https://www.terraform.io/cloud-docs/users-teams-organizations/api-tokens)은 사용자 또는 팀 API 토큰이어야 합니다. 필요한 모든 API에 대해 조직 토큰이 지원되는 것은 아닙니다. 보안상의 이유로 다음 예제와 같이 [테라폼 변수](https://www.terraform.io/cloud-docs/workspaces/variables/managing-variables)를 할당하여 이 토큰의 값이 버전 관리 시스템(VCS)에 체크인되지 않도록 해야 합니다.
```
# Sensitive variable managed in Terraform Cloud:
terraform_token = var.terraform_cloud_token
```
### Terraform Community Edition
배포로 Terraform Community Edition을 선택하면 AFT가 AFT 관리 계정에서 Terraform 백엔드를 대신 관리합니다. AFT는 지정된 Terraform 버전의 `terraform-cli`를 다운로드하여 AFT 배포 및 AFT 파이프라인 단계 동안 실행합니다. 그 결과로 생성된 Terraform 상태 구성은 다음과 같은 형식으로 명명된 Amazon S3 버킷에 저장됩니다.
```
aft-backend-[account_id]-primary-region
```
또한 AFT는 재해 복구를 위해 다른 AWS 리전에서 Terraform 상태 구성을 복제하는, 다음과 같은 형식으로 명명된 Amazon S3 버킷을 생성합니다.
```
aft-backend-[account_id]-secondary-region
```
이러한 Terraform 상태 Amazon S3 버킷에서 삭제 함수에 대해 다중 인증(MFA)을 활성화하는 것이 좋습니다. Terraform Community Edition에 대한 자세한 내용은 [Terraform 설명서](https://www.terraform.io/docs/cli/index.html)를 참조하세요.
배포로 Terraform OSS를 선택하려면 다음 입력 파라미터를 제공합니다.
```
terraform_distribution = "oss"
```
### Terraform Cloud
배포로 Terraform Cloud를 선택하면 AFT는 Terraform Cloud 조직에 다음 구성 요소에 대한 워크스페이스를 생성하여 API 기반 워크플로를 시작합니다.
+ 계정 요청
+ AFT가 프로비저닝하는 계정에 대한 AFT 사용자 지정
+ AFT가 프로비저닝하는 계정에 대한 계정 사용자 지정
+ AFT가 프로비저닝하는 계정에 대한 글로벌 사용자 지정
Terraform Cloud는 그 결과로 생성된 Terraform 상태 구성을 관리합니다.
배포로 Terraform Cloud를 선택하는 경우 다음 입력 파라미터를 제공합니다.
+ `terraform_distribution = "tfc"`
+ `terraform_token` – 이 파라미터에는 Terraform Cloud 토큰의 값이 포함됩니다. AFT는 이 값을 민감한 것으로 표시하고 AFT 관리 계정의 SSM Parameter Store에 보안 문자열로 저장합니다. 회사의 보안 정책 및 규정 준수 지침에 따라 Terraform 토큰의 값을 주기적으로 교체하는 것이 좋습니다. Terraform 토큰은 사용자 또는 팀 수준 API 토큰이어야 합니다. 조직 토큰은 지원되지 않습니다.
+ `terraform_org_name` - 이 파라미터에는 Terraform Cloud 조직의 이름이 포함됩니다.
**참고**
단일 Terraform Cloud 조직에서 여러 AFT 배포는 지원되지 않습니다.
Terraform Cloud를 설정하는 방법에 대한 자세한 내용은 [Terraform 설명서](https://www.terraform.io/docs/cloud/index.html)를 참조하세요.
### Terraform Enterprise
Terraform Enterprise를 배포로 선택하면 AFT는 Terraform Enterprise 조직에서 다음 구성 요소에 대한 워크스페이스를 생성하고, 그 결과 테라폼 실행을 위해 API 기반 워크플로를 트리거합니다.
+ 계정 요청
+ AFT에서 프로비저닝한 계정에 대한 AFT 계정 프로비저닝 사용자 지정
+ AFT에서 프로비저닝한 계정에 대한 계정 사용자 지정
+ AFT에서 프로비저닝한 계정에 대한 글로벌 사용자 지정
그 결과로 생성된 Terraform 상태 구성은 Terraform Enterprise 설정에서 관리됩니다.
배포로 Terraform Enterprise를 선택하려면 다음 입력 파라미터를 제공합니다.
+ `terraform_distribution = "tfe"`
+ `terraform_token` - 이 파라미터에는 Terraform Enterprise 토큰의 값이 포함됩니다. AFT는 이 값을 민감한 것으로 표시하고 AFT 관리 계정의 SSM Parameter Store에 보안 문자열로 저장합니다. 회사의 보안 정책 및 규정 준수 지침에 따라 Terraform 토큰의 값을 주기적으로 교체하는 것이 좋습니다.
+ `terraform_org_name` - 이 파라미터에는 Terraform Enterprise 조직의 이름이 포함됩니다.
+ `terraform_api_endpoint` - 이 파라미터에는 Terraform Enterprise 환경의 URL이 포함되어 있습니다. 이 파라미터 값은 다음 형식이어야 합니다.
```
https://{fqdn}/api/v2/
```
Terraform Enterprise를 설정하는 방법에 대한 자세한 내용은 [Terraform 설명서](https://www.terraform.io/docs/enterprise/index.html)를 참조하세요.
# AFT 버전 확인
AWS SSM Parameter Store 키를 쿼리하여 배포된 AFT 버전을 확인할 수 있습니다.
```
/aft/config/aft/version
```
레지스트리 메서드를 사용하는 경우 버전을 고정할 수 있습니다.
```
module "control_tower_account_factory" {
source = "aws-ia/control_tower_account_factory/aws"
version = "1.3.2"
# insert the 6 required variables here
}
```
[AFT 리포지토리](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main)에서 AFT 버전에 대한 자세한 내용을 볼 수 있습니다.
# AFT 버전 업데이트
AWS Control Tower 관리 계정에 로그인하여 이 AFT 업데이트를 시작합니다.
배포된 AFT 버전을 `main` 리포지토리 브랜치에서 가져와서 업데이트할 수 있습니다.
```
terraform get -update
```
풀이 완료되면 Terraform 계획을 다시 실행하거나 적용을 실행하여 AFT 인프라를 최신 변경 사항으로 업데이트할 수 있습니다.
# 기능 옵션 활성화
AFT는 모범 사례를 기반으로 기능 옵션을 제공합니다. AFT 배포 중에 기능 플래그를 사용하여 이러한 기능을 옵트인할 수 있습니다. AFT 입력 구성 파라미터에 대한 자세한 내용은 [AFT를 사용하여 새 계정 프로비저닝](aft-provision-account.md) 섹션을 참조하세요.
이러한 기능은 기본적으로 활성화되어 있지 않습니다. 환경에서 각 항목을 명시적으로 활성화해야 합니다.
**Topics**
+ [AWS CloudTrail 데이터 이벤트](#cloudtrail-data-event-option)
+ [AWS Enterprise Support 플랜](#enterprise-support-option)
+ [AWS 기본 VPC 삭제](#delete-default-vpc-option)
## AWS CloudTrail 데이터 이벤트
활성화되면 AWS CloudTrail 데이터 이벤트 옵션이 이러한 기능을 구성합니다.
+ CloudTrail용 AWS Control Tower 관리 계정에 조직 추적을 생성합니다.
+ Amazon S3 및 Lambda 데이터 이벤트에 대한 로깅을 켭니다.
+ 암호화를 사용하여 모든 CloudTrail 데이터 이벤트를 암호화하고 AWS Control Tower Log Archive 계정의 `aws-aft-logs-*` S3 버킷으로 내보냅니다 AWS KMS .
+ **로그 파일 검증** 설정을 켭니다.
이 옵션을 활성화하려면 AFT 배포 입력 구성에서 다음 기능 플래그를 **True**로 설정합니다.
```
aft_feature_cloudtrail_data_events
```
**사전 조건**
이 기능 옵션을 활성화하기 전에 조직에서에 대한 신뢰할 수 있는 액세스 AWS CloudTrail 가 활성화되어 있는지 확인합니다.
**CloudTrail에 대한 신뢰할 수 있는 액세스 상태를 확인하려면:**
1. AWS Organizations 콘솔로 이동합니다.
1. **서비스 > CloudTrail**을 선택합니다.
1. 필요한 경우 오른쪽 상단에서 **신뢰할 수 있는 액세스 활성화**를 선택합니다.
AWS CloudTrail 콘솔을 사용하도록 알리는 경고 메시지가 표시될 수 있지만이 경우 경고를 무시합니다. AFT는 신뢰할 수 있는 액세스를 허용한 후 이 기능 옵션 활성화의 일환으로 추적을 생성합니다. 신뢰할 수 있는 액세스가 활성화되지 않은 경우 AFT가 데이터 이벤트에 대한 추적을 생성하려고 할 때 오류 메시지가 표시됩니다.
**참고**
이 설정은 조직 수준에서 작동합니다. 이 설정을 활성화하면 AFT에서 관리하는지 여부에 AWS Organizations관계없이의 모든 계정에 영향을 줍니다. 활성화 시 AWS Control Tower 로그 아카이브 계정의 모든 버킷은 Amazon S3 데이터 이벤트에서 제외됩니다. CloudTrail에 대한 자세한 내용은 [AWS CloudTrail 사용 설명서](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)를 참조하세요.
## AWS Enterprise Support 플랜
이 옵션을 활성화하면 AFT 파이프라인이 AFT에서 프로비저닝한 계정에 대한 AWS Enterprise Support 플랜을 켭니다.
AWS 계정은 기본적으로 AWS 기본 지원 플랜이 활성화된 상태로 제공됩니다. AFT는 AFT가 프로비저닝하는 계정에 대해 엔터프라이즈 지원 수준에 자동으로 등록할 수 있는 기능을 제공합니다. 프로비저닝 프로세스는 계정에 대한 지원 티켓을 열어 AWS Enterprise Support 플랜에 추가하도록 요청합니다.
Enterprise Support 옵션을 활성화하려면 AFT 배포 입력 구성에서 다음 기능 플래그를 **True**로 설정합니다.
```
aft_feature_enterprise_support=false
```
[AWS 지원 플랜에 대한 자세한 내용은 지원 플랜 비교](https://aws.amazon.com/premiumsupport/plans/)를 참조하세요. AWS
**참고**
이 기능을 작동하려면 지급인 계정을 Enterprise Support 플랜에 등록해야 합니다.
## AWS 기본 VPC 삭제
이 옵션을 활성화하면가 해당에 AWS Control Tower 리소스를 배포하지 AWS 리전않은 경우에도 AFT는 AFT 관리 계정의 모든 AWS 기본 VPCs와 모든 기본 VPC를 삭제합니다 AWS 리전.
AFT는 AFT가 프로비저닝하는 AWS Control Tower 계정 또는 AFT를 통해 AWS Control Tower에 등록한 기존 AWS 계정에 대해 AWS 기본 VPCs를 자동으로 삭제하지 않습니다.
새 AWS 계정은 AWS 리전기본적으로 각에 설정된 VPC로 생성됩니다. 엔터프라이즈에는 AWS 기본 VPCs를 삭제하고 특히 AFT 관리 계정의 경우 활성화하지 않도록 요구하는 VPC 생성에 대한 표준 관행이 있을 수 있습니다.
이 옵션을 활성화하려면 AFT 배포 입력 구성에서 다음 기능 플래그를 **True**로 설정합니다.
```
aft_feature_delete_default_vpcs_enabled
```
다음은 AFT 배포 입력 구성의 예입니다.
```
module "aft" {
source = "github.com/aws-ia/terraform-aws-control_tower_account_factory"
ct_management_account_id = var.ct_management_account_id
log_archive_account_id = var.log_archive_account_id
audit_account_id = var.audit_account_id
aft_management_account_id = var.aft_management_account_id
ct_home_region = var.ct_home_region
tf_backend_secondary_region = var.tf_backend_secondary_region
vcs_provider = "github"
account_request_repo_name = "${var.github_username}/learn-terraform-aft-account-request"
account_provisioning_customizations_repo_name = "${var.github_username}/learn-terraform-aft-account-provisioning-customizations"
global_customizations_repo_name = "${var.github_username}/learn-terraform-aft-global-customizations"
account_customizations_repo_name = "${var.github_username}/learn-terraform-aft-account-customizations"
# Optional Feature Flags
aft_feature_delete_default_vpcs_enabled = true
aft_feature_cloudtrail_data_events = false
aft_feature_enterprise_support = false
}
```
기본 VPC에 대한 자세한 내용은 [기본 VPC 및 기본 서브넷](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html)을 참조하세요.
# AWS Control Tower Account Factory for Terraform 리소스 관련 고려 사항
AWS Control Tower Account Factory for Terraform을 사용하여 랜딩 존을 설정하면 AWS 계정 내에 여러 유형의 AWS 리소스가 생성됩니다.
**리소스 검색**
+ 태그를 사용하여 가장 업데이트된 AFT 리소스 목록을 검색할 수 있습니다. 검색의 키-값 페어는 다음과 같습니다.
```
Key: managed_by | Value: AFT
```
+ 태그를 지원하지 않는 구성 요소 서비스의 경우 리소스 이름에서 `aft`를 검색하여 리소스를 찾을 수 있습니다.
**참고**
AFT는 관리 계정에 AWS 백업 리소스를 생성하지 않습니다.
**계정별로 처음 생성된 리소스 테이블**
**AWS Control Tower Account Factory for Terraform 관리 계정**
| **AWS 서비스** | **리소스 유형** | **리소스 이름** |
| --- | --- | --- |
| AWS Identity and Access Management | 역할 | AWSAFTAdmin AWSAFTExecution AWSAFTService ct-aft-\$1 aft-\$1 codebuild\$1trigger\$1role python-layer-builder-aft-common-\$1 |
| AWS Identity and Access Management | 정책 | aft-\$1 |
| CodeCommit | 리포지토리 | aft-\$1 |
| CodeBuild | 빌드 프로젝트 | aft-\$1 ct-aft-\$1 python-layer-builder-aft-common-\$1 |
| 코드 파이프라인 | 파이프라인 | **YourAccountId**-customizations-pipeline |
| Amazon S3 | 버킷 | aft-\$1 |
| Lambda | 함수 | aft-\$1 |
| Lambda | 계층 | aft-common-\$1 |
| DynamoDB | 테이블 | aft-request aft-request-audit aft-request-metadata aft-controltower-events |
| 단계 함수 | 상태 시스템 | aft-account-provisioning-customizations aft-account-provisioning-framework aft-feature-options aft-invoke-customizations |
| VPC | VPC | aft-management-vpc |
| Amazon SNS | 주제 | aft-notifications aft-failure-notifications |
| Amazon EventBridge | 이벤트 버스 | aft-events-from-ct-management |
| Amazon EventBridge | 이벤트 규칙 | aft-account-provisioning-customizations-trigger aft-account-request-codepipeline-trigger aft-lambda-account-request-processor aft-controltower-event-logger |
| Key Management Service(KMS) | 고객 관리형 키 | aft-backend-\$1-kms-key aft |
| AWS Systems Manager | Parameter Store | /aft/\$1 |
| Amazon SQS | Queues | aft-account-request.fifo aft-account-request-dlg.fifo |
| CloudWatch | 로그 그룹 | /aws/\$1/ct-aft-\$1 /aws/\$1/aft-\$1 /aws/codebuild/python-layer-builder-aft-common-\$1 |
| AWS 백업 | 저장소 | aft-controltower-backup-vault |
| AWS 백업 | 계획 | aft-controltower-backup-plan |
| AWS 지원 센터(선택 사항) | 지원 플랜 | Enterprise |
**AWS AWS Control Tower Account Factory for Terraform을 통해 프로비저닝된 계정**
| **AWS 서비스** | **리소스 유형** | **리소스 이름** |
| --- | --- | --- |
| AWS Identity and Access Management | 역할 | AWSAFTExecution |
| AWS 지원 센터(선택 사항) | 지원 플랜 | Enterprise |
**AWS Control Tower 관리 계정**
| **AWS 서비스** | **리소스 유형** | **리소스 이름** |
| --- | --- | --- |
| AWS Identity and Access Management | 역할 | AWSAFTExecution AWSAFTService aft-controltower-events-rule |
| AWS Systems Manager | Parameter Store | /aft/\$1 |
| EventBridge | 이벤트 규칙 | aft-capture-ct-events |
| CloudTrail(선택 사항) | 추적 | aws-aft-CustomizationsCloudTrail |
| AWS Support Center(선택 사항) | 지원 플랜 | Enterprise |
**AWS Control Tower 로그 아카이브 계정**
| **AWS 서비스** | **리소스 유형** | **리소스 이름** |
| --- | --- | --- |
| AWS Identity and Access Management | 역할 | AWSAFTExecution AWSAFTService |
| Key Management Service(KMS) | 고객 관리형 키 | aft |
| Amazon S3 | 버킷 | aws-aft-logs-\$1 aws-aft-s3-access-logs-\$1 |
| AWS 지원 센터(선택 사항) | 지원 플랜 | Enterprise |
**AWS Control Tower 감사 계정**
| **AWS 서비스** | **리소스 유형** | **리소스 이름** |
| --- | --- | --- |
| AWS Identity and Access Management | 역할 | AWSAFTExecution AWSAFTService |
| AWS 지원 센터(선택 사항) | 지원 플랜 | Enterprise |
# 필요한 역할
일반적으로 역할 및 정책은 AWS에서 Identity and Access Management(IAM)의 일부입니다. 자세한 내용은 [https://docs.aws.amazon.com//IAM/latest/UserGuide/introduction.html](https://docs.aws.amazon.com//IAM/latest/UserGuide/introduction.html)를 참조하세요.
AFT는 AFT 관리 및 AWS Control Tower 관리 계정에 여러 IAM 역할 및 정책을 생성하여 AFT 파이프라인의 운영을 지원합니다. 이러한 역할은 최소 권한 액세스 모델을 기반으로 생성되며, 이는 각 역할 및 정책에 필요한 최소 작업 및 리소스 세트로 권한을 제한합니다. 이러한 역할 및 정책에는 식별을 ` managed_by:AFT` 위해 AWS 태그 `key:value` 페어가 할당됩니다.
이러한 IAM 역할 외에도 AFT는 세 가지 필수 역할을 생성합니다.
+ `AWSAFTAdmin` 역할
+ `AWSAFTExecution` 역할
+ `AWSAFTService` 역할
이러한 역할에 대해서는 다음 섹션에서 설명합니다.
**AWSAFTAdmin 역할 설명**
AFT를 배포하면 AFT 관리 계정에 `AWSAFTAdmin` 역할이 생성됩니다. 이 역할을 통해 AFT 파이프라인은 AWS Control Tower 및 AFT 프로비저닝 계정의 `AWSAFTExecution` 역할을 수임하여 계정 프로비저닝 및 사용자 지정과 관련된 작업을 수행할 수 있습니다.
`AWSAFTAdmin` 역할에 연결된 인라인 정책(JSON 아티팩트)은 다음과 같습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::*:role/AWSAFTExecution",
"arn:aws:iam::*:role/AWSAFTService"
]
}
]
}
```
------
다음 JSON 아티팩트는 `AWSAFTAdmin` 역할에 대한 신뢰 관계를 보여줍니다. 자리 표시자 번호 `012345678901`은 AFT 관리 계정 ID 번호로 대체됩니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::012345678901:root"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
**AWSAFTExecution 역할 설명**
AFT를 배포하면 AFT 관리 및 AWS Control Tower 관리 계정에 `AWSAFTExecution` 역할이 생성됩니다. 나중에 AFT 파이프라인은 AFT 계정 프로비저닝 단계에서 각 AFT로 프로비저닝된 계정에 `AWSAFTExecution` 역할을 생성합니다.
AFT는 처음에 `AWSControlTowerExecution` 역할을 활용하여 지정된 계정에서 `AWSAFTExecution` 역할을 생성합니다. 이 `AWSAFTExecution` 역할을 통해 AFT 파이프라인은 AFT 프레임워크의 프로비저닝 및 프로비저닝 사용자 지정 단계, AFT 프로비저닝 계정 및 공유 계정에서 수행되는 단계를 실행할 수 있습니다.
**고유 역할은 범위를 제한하는 데 도움이 됩니다.**
사용자 지정 권한은 리소스의 초기 배포 중에 허용되는 권한과 분리하는 것이 가장 좋습니다. `AWSAFTService` 역할은 계정 프로비저닝을 위한 것이며 `AWSAFTExecution` 역할은 계정 사용자 지정을 위한 것임을 기억해야 합니다. 이러한 구분은 파이프라인의 각 단계에서 허용되는 권한 범위를 제한합니다. AWS Control Tower 공유 계정을 사용자 지정하는 경우 공유 계정에 결제 세부 정보 또는 사용자 정보와 같은 민감한 정보가 포함될 수 있으므로 이러한 구분이 특히 중요합니다.
`AWSAFTExecution` 역할에 대한 권한: **AdministratorAccess** – AWS 관리형 정책
다음 JSON 아티팩트는 `AWSAFTExecution` 역할에 연결된 IAM 정책(신뢰 관계)을 보여줍니다. 자리 표시자 번호 `012345678901`은 AFT 관리 계정 ID 번호로 대체됩니다.
`AWSAFTExecution`에 대한 신뢰 정책
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::012345678901:role/AWSAFTAdmin"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
**AWSAFTService 역할 설명**
`AWSAFTService` 역할은 공유 계정 및 관리 계정을 포함하여 등록된 모든 관리 계정에 AFT 리소스를 배포합니다. 이전에 리소스는 `AWSAFTExecution` 역할에 의해서만 배포되었습니다.
`AWSAFTService` 역할은 서비스 인프라에서 프로비저닝 단계 중에 리소스를 배포하는 데 사용되며, `AWSAFTExecution` 역할은 사용자 지정 배포에만 사용됩니다. 이러한 방식으로 역할을 수임하면 각 단계에서 보다 세분화된 액세스 제어를 유지할 수 있습니다.
`AWSAFTService` 역할에 대한 권한: **AdministratorAccess** – AWS 관리형 정책
다음 JSON 아티팩트는 `AWSAFTService` 역할에 연결된 IAM 정책(신뢰 관계)을 보여줍니다. 자리 표시자 번호 `012345678901`은 AFT 관리 계정 ID 번호로 대체됩니다.
`AWSAFTService`에 대한 신뢰 정책
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::012345678901:role/AWSAFTAdmin"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
# 구성 요소 서비스
AFT를 배포하면 이러한 각AWS서비스에서 구성 요소가AWS환경에 추가됩니다.
+ **[AWS Control Tower](https://docs.aws.amazon.com//controltower/latest/userguide/what-is-control-tower.html)** - AFT는 AWS Control Tower 관리 계정의 AWS Control Tower Account Factory를 사용하여 계정을 프로비저닝합니다.
+ **[Amazon DynamoDB](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/Introduction.html)** – AFT는 AFT 관리 계정에 Amazon DynamoDB 테이블을 생성하여 계정 요청, 계정 업데이트 감사 기록, 계정 메타데이터 및 AWS Control Tower 수명 주기 이벤트를 저장합니다. 또한 AFT는 DynamoDB Lambda 트리거를 생성하여 AFT 계정 프로비저닝 워크플로 시작과 같은 다운스트림 프로세스를 시작합니다.
+ **[Amazon Simple Storage Service](https://docs.aws.amazon.com//AmazonS3/latest/userguide/Welcome.html)** - AFT는 AFT 파이프라인에 필요한AWS서비스에서 생성된 로그를 저장하는 Amazon Simple Storage Service(S3) 버킷을 AFT 관리 계정 및 AWS Control Tower 로그 아카이브 계정에 생성합니다. 또한 AFT는 기본 및 보조에 Terraform 백엔드 S3 버킷을 생성AWS 리전하여 AFT 파이프라인 워크플로 중에 생성된 Terraform 상태를 저장합니다.
+ **[Amazon Simple Notification Service](https://docs.aws.amazon.com//sns/latest/dg/welcome.html)** - AFT는 AFT 관리 계정에 Amazon Simple Notification Service(SNS) 주제를 생성하고 모든 AFT 계정 요청을 처리한 후 성공 및 실패 알림을 저장합니다. 선택한 프로토콜을 사용하여 이러한 메시지를 받을 수 있습니다.
+ **[Amazon Simple Queuing Service](https://docs.aws.amazon.com//AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)** - AFT는 AFT 관리 계정에 Amazon Simple Queuing Service(Amazon SQS) FIFO 대기열을 생성합니다. 대기열을 사용하면 여러 계정 요청을 병렬로 제출할 수 있지만 순차적 처리를 위해 AWS Control Tower Account Factory에 한 번에 하나의 요청을 보냅니다.
+ **[AWS CodeBuild](https://docs.aws.amazon.com//codebuild/latest/userguide/welcome.html)** – AFT는 AFT 관리 계정에 AWS CodeBuild 빌드 프로젝트를 생성하여 다양한 빌드 단계에서 AFT 소스 코드에 대한 Terraform 계획을 초기화, 컴파일, 테스트 및 적용합니다.
+ **[AWS CodePipeline](https://docs.aws.amazon.com//codepipeline/latest/userguide/welcome.html)** - AFT는 AFT 소스 코드에 대해 선택한 지원되는 AWS CodeStar 연결 공급자와 통합하고 AWS CodeBuild에서 빌드 작업을 트리거하기 위해 AFT 관리 계정에 AWS CodePipeline 파이프라인을 생성합니다.
+ **[AWS Lambda](https://docs.aws.amazon.com//lambda/latest/dg/welcome.html)** – AFT는 AFT 관리 계정에 AWS Lambda 함수 및 계층을 생성하여 계정 요청, AFT 계정 프로비저닝 및 계정 사용자 지정 프로세스 중에 단계를 수행합니다.
+ **[AWS Systems Manager Parameter Store](https://docs.aws.amazon.com//systems-manager/latest/userguide/systems-manager-parameter-store.html)** - AFT는 AFT 파이프라인 프로세스에 필요한 구성 파라미터를 저장하기 위해 AFT 관리 계정에 AWS Systems Manager Parameter Store를 설정합니다.
+ **[Amazon CloudWatch](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)** – AFT는 AFT 관리 계정에 Amazon CloudWatch 로그 그룹을 생성하여 AFT 파이프라인에서 사용하는 AWS 서비스에서 생성된 로그를 저장합니다. CloudWatch 로그의 보존 기간은 `Never Expire`로 설정됩니다.
+ **[Amazon VPC](https://docs.aws.amazon.com//vpc/latest/userguide/what-is-amazon-vpc.html)** – AFT는 Amazon Virtual Private Cloud(VPC)를 생성하여 AFT 관리 계정의 서비스 및 리소스를 별도의 네트워킹 환경으로 격리하고 보안을 강화합니다.
+ **[AWS KMS](https://docs.aws.amazon.com//kms/latest/developerguide/overview.html)** – AFT는 AFT 관리 계정과 AWS Control Tower 로그 아카이브 계정에서 AWS Key Management Service(KMS)를 사용합니다. AFT는 Terraform 상태, DynamoDB 테이블에 저장된 데이터 및 SNS 주제를 암호화하는 키를 생성합니다. 이러한 로그 및 아티팩트는 AWS 리소스 및 서비스가 AFT에 의해 배포될 때 생성됩니다. AFT에서 생성한 KMS 키는 기본적으로 1년 주기로 교체가 활성화됩니다.
+ **[AWS Identity and Access Management(IAM)](https://docs.aws.amazon.com//IAM/latest/UserGuide/introduction.html)** - AFT는 권장 최소 권한 모델을 따릅니다. AFT 파이프라인 워크플로 중에 필요한 작업을 수행하기 위해 필요에 따라 AFT 관리 계정, AWS Control Tower 계정 및 AFT 프로비저닝 계정에AWS Identity and Access Management(IAM) 역할 및 정책을 생성합니다.
+ **[AWS Step Functions](https://docs.aws.amazon.com//step-functions/latest/dg/welcome.html)** - AFT는 AFT 관리 계정에AWS Step Functions 상태 시스템을 생성합니다. 이러한 상태 시스템은 AFT 계정 프로비저닝 프레임워크 및 사용자 지정을 위한 프로세스와 단계를 오케스트레이션하고 자동화합니다.
+ **[Amazon EventBridge](https://docs.aws.amazon.com//eventbridge/latest/userguide/eb-what-is.html)** - AFT는 AFT 및 AWS Control Tower 관리 계정에 Amazon EventBridge 이벤트 버스를 생성하여 AFT 관리 계정의 DynamoDB 테이블에 AWS Control Tower 수명 주기 이벤트를 장기간 캡처하고 저장합니다. AFT는 AFT 관리 및 AWS Control Tower 관리 계정에 Amazon CloudWatch Events 규칙을 생성하여 AFT 파이프라인 워크플로를 실행하는 동안 필요한 여러 단계를 트리거합니다.
+ **[AWS CloudTrail(선택 사항)](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/cloudtrail-user-guide.html)** -이 기능이 활성화되면 AFT는 Amazon S3 버킷 및AWS Lambda 함수에 대한 데이터 이벤트를 로깅하기 위해 AWS Control Tower 관리 계정에AWS CloudTrail조직 추적을 생성합니다. AFT는 이러한 로그를 AWS Control Tower 로그 아카이브 계정의 중앙 S3 버킷으로 보냅니다.
+ **[AWS지원(선택 사항)](https://aws.amazon.com//premiumsupport/)** -이 기능을 활성화하면 AFT가 AFT에서 프로비저닝한 계정에 대한AWS엔터프라이즈 지원 플랜을 켭니다. 기본적으로AWS계정은AWS기본 지원 플랜이 활성화된 상태에서 생성됩니다.
# AFT 계정 프로비저닝 파이프라인
파이프라인의 계정 프로비저닝 단계가 완료되면 AFT 프레임워크가 계속됩니다. [계정 사용자 지정](aft-account-customization-options.md) 단계가 시작되기 전에 새로 프로비저닝된 계정에 세부 정보가 있는지 확인하기 위해 일련의 단계를 자동으로 실행합니다.
**다음은 AFT 파이프라인이 실행하는 다음 단계입니다.**
1. 계정 요청 입력을 검증합니다.
1. 프로비저닝된 계정, 예를 들어 계정 ID에 대한 정보를 검색합니다.
1. AFT 관리 계정의 DynamoDB 테이블에 계정 메타데이터를 저장합니다.
1. 새로 프로비저닝된 계정에서 **AWSAFTExecution** IAM 역할을 생성합니다. 이 역할은 Account Factory 포트폴리오에 대한 액세스 권한을 부여하므로 AFT가 이 역할을 수임하여 계정 사용자 지정 단계를 수행합니다.
1. 계정 요청 입력 파라미터의 일부로 제공한 계정 태그를 적용합니다.
1. AFT 배포 시 선택한 AFT 기능 옵션을 적용합니다.
1. 제공한 AFT 계정 프로비저닝 사용자 지정을 적용합니다. 다음 섹션에서는 `git` 리포지토리에서 AWS Step Functions 상태 시스템을 사용하여 이러한 사용자 지정을 설정하는 방법에 대해 자세히 설명합니다. 이 단계를 *계정 프로비저닝 프레임워크* 단계라고도 합니다. 이는 코어 프로비저닝 프로세스의 일부이지만 이전에 계정 프로비저닝 워크플로의 일부로 사용자 지정 통합을 제공하는 프레임워크를 설정한 후 다음 단계에서 계정에 추가 사용자 지정을 추가합니다.
1. 프로비저닝된 각 계정에 대해 AWS CodePipeline AFT 관리 계정에를 생성하여 (다음, 글로벌) [계정 사용자 지정](aft-account-customization-options.md) 단계를 수행하기 위해 실행됩니다.
1. 프로비저닝(및 대상 지정)된 각 계정에 대한 계정 사용자 지정 파이프라인을 호출합니다.
1. 메시지를 검색할 수 있는 SNS 주제로 성공 또는 실패 알림을 보냅니다.
## 상태 시스템을 사용하여 계정 프로비저닝 프레임워크 사용자 지정 설정
계정을 프로비저닝하기 전에 Terraform 이외의 사용자 지정 통합을 설정한 경우 이러한 사용자 지정은 AFT 계정 프로비저닝 워크플로에 포함됩니다. 예를 들어 AFT에서 생성한 모든 계정이 보안 표준과 같은 조직의 표준 및 정책을 준수하는지 확인하기 위해 특정 사용자 지정이 필요할 수 있으며, 이러한 표준은 추가 사용자 지정 전에 계정에 추가될 수 있습니다. 이러한 *계정 프로비저닝 프레임워크* 사용자 지정은 글로벌 계정 사용자 지정 단계가 시작되기 전에 모든 프로비저닝된 계정에 구현됩니다.
**참고**
이 섹션에 설명된 AFT 기능은 AWS Step Functions의 기능을 이해하는 고급 사용자를 위한 것입니다. 또는 계정 사용자 지정 단계에서 글로벌 헬퍼를 사용하는 것을 권장합니다.
AFT 계정 프로비저닝 프레임워크는 사용자 지정을 구현하기 위해 사용자가 정의한 AWS Step Functions 상태 시스템을 호출합니다. 가능한 상태 시스템 통합에 대한 자세한 내용은 [AWS Step Functions 설명서](https://docs.aws.amazon.com//step-functions/latest/dg/welcome.html)를 참조하세요.
다음은 몇 가지 일반적인 통합입니다.
+ 선택한 언어로 제공되는 AWS Lambda 함수
+ AWS ECS 또는 AWS Fargate 태스크, Docker 컨테이너 사용
+ AWS 또는 온프레미스에서 호스팅되는 사용자 지정 작업자를 사용한 AWS Step Functions 작업
+ Amazon SNS 또는 SQS 통합
AWS Step Functions 상태 시스템이 정의되지 않은 경우 해당 단계는 아무런 작업 없이 통과됩니다. AFT 계정 프로비저닝 사용자 지정 상태 시스템을 생성하려면 [AFT 계정 프로비저닝 사용자 지정 상태 시스템 생성](#aft-create-customizations)의 지침을 따릅니다. 사용자 지정을 추가하기 전에 사전 조건이 있는지 확인합니다.
이러한 유형의 통합은 AWS Control Tower의 일부가 아니며 AFT 계정 사용자 지정의 글로벌 API 호출 전 단계 중에는 추가할 수 없습니다. 대신 AFT 파이프라인을 사용하면 프로비저닝 프로세스의 일부로 이러한 사용자 지정을 설정할 수 있으며 프로비저닝 워크플로에서 실행됩니다. 다음 섹션에 설명된 대로 AFT 계정 프로비저닝 단계를 시작하기 전에 상태 시스템을 미리 생성하여 이러한 사용자 지정을 구현해야 합니다.
**상태 시스템 생성을 위한 사전 조건**
+ 완전히 배포된 AFT. AFT 배포에 대한 자세한 내용은 [AWS Control Tower Account Factory for Terraform(AFT) 배포](aft-getting-started.md) 섹션을 참조하세요.
+ AFT 계정 프로비저닝 사용자 지정을 위해 환경에 `git` 리포지토리를 설정합니다. 자세한 내용은 [배포 후 단계](aft-post-deployment.md) 섹션을 참조하세요.
## AFT 계정 프로비저닝 사용자 지정 상태 시스템 생성
**1단계: 상태 시스템 정의 수정**
예제 `customizations.asl.json` 상태 시스템 정의를 수정합니다. 이 예제는 [배포 후 단계](https://docs.aws.amazon.com//controltower/latest/userguide/aft-post-deployment.html)의 AFT 계정 프로비저닝 사용자 지정을 저장하기 위해 설정한 `git` 리포지토리에서 사용할 수 있습니다. 상태 시스템 정의에 대해 자세히 알려면 [AWS Step Functions 개발자 안내서](https://docs.aws.amazon.com//step-functions/latest/dg/welcome.html)를 참조하세요.
**2단계: 해당 Terraform 구성 포함**
사용자 지정 통합을 위한 상태 시스템 정의와 동일한 `git` 리포지토리에 확장자가 `.tf`인 Terraform 파일을 포함합니다. 예를 들어 상태 시스템 작업 정의에서 Lambda 함수를 호출하도록 선택한 경우 동일한 디렉터리에 `lambda.tf` 파일을 포함하면 됩니다. 사용자 지정 구성에 필요한 IAM 역할과 권한을 포함해야 합니다.
적절한 입력을 제공하면 AFT 파이프라인은 상태 시스템을 자동으로 호출하고 AFT 계정 프로비저닝 프레임워크 단계의 일부로 사용자 지정을 배포합니다.
## AFT 계정 프로비저닝 프레임워크 및 사용자 지정을 다시 시작하려면
AFT는 AFT 파이프라인을 통해 제공된 모든 계정에 대해 계정 프로비저닝 프레임워크 및 사용자 지정 단계를 실행합니다. 계정 프로비저닝 사용자 지정을 다시 시작하려는 경우 다음 두 가지 방법 중 하나를 사용할 수 있습니다.
1. 계정 요청 리포지토리에서 기존 계정을 변경합니다.
1. AFT를 사용하여 새 계정을 프로비저닝합니다.
# 계정 사용자 지정
AFT는 프로비저닝된 계정에 표준 또는 사용자 지정 구성을 배포할 수 있습니다. AFT 관리 계정에서 AFT는 각 계정에 대해 하나의 파이프라인을 제공합니다. 이 파이프라인을 사용하면 모든 계정, 계정 집합 또는 개별 계정에서 사용자 지정을 구현할 수 있습니다. Python 스크립트, Bash 스크립트 및 Terraform 구성을 실행하거나 계정 사용자 지정 단계의 일부로 AWS CLI와 상호 작용할 수 있습니다.
## 개요
글로벌 사용자 지정을 저장하는 리포지토리 또는 계정 사용자 지정을 저장하는 리포지토리 중 선택한 `git` 리포지토리에 사용자 지정이 지정되면 AFT 파이프라인에 의해 계정 사용자 지정 단계가 자동으로 완료됩니다. 계정을 소급하여 사용자 지정하려면 [사용자 지정 다시 호출](#aft-re-invoke-customizations) 섹션을 참조하세요.
**글로벌 사용자 지정(선택 사항)**
AFT에서 프로비저닝한 모든 계정에 특정 사용자 지정을 적용하도록 선택할 수 있습니다. 예를 들어 특정 IAM 역할을 생성하거나 모든 계정에 사용자 지정 제어를 배포해야 하는 경우 AFT 파이프라인의 글로벌 사용자 지정 단계를 사용하면 자동으로 이를 수행할 수 있습니다.
**계정 사용자 지정(선택 사항)**
개별 계정 또는 계정 세트를 다른 AFT로 프로비저닝된 계정과 다르게 사용자 지정하려면 AFT 파이프라인의 계정 사용자 지정 부분을 활용하여 계정별 구성을 구현할 수 있습니다. 예를 들어 특정 계정만 인터넷 게이트웨이에 액세스해야 할 수 있습니다.
## 사용자 지정 사전 조건
계정 사용자 지정을 시작하기 전에 이러한 사전 조건이 충족되었는지 확인합니다.
+ 완전히 배포된 AFT. 배포 방법에 대한 자세한 내용은 [AWS Control Tower Account Factory for Terraform 구성 및 시작](aft-getting-started.md#aft-configure-and-launch) 섹션을 참조하세요.
+ 환경의 글로벌 사용자 지정 및 계정 사용자 지정을 위한 미리 채워진 `git` 리포지토리. 자세한 내용은 *[배포 후 단계](aft-post-deployment.md)의 3단계: 각 리포지토리 채우기*를 참조하세요.
## 글로벌 사용자 지정 적용
글로벌 사용자 지정을 적용하려면 선택한 리포지토리에 특정 폴더 구조를 푸시해야 합니다.
+ 사용자 지정 구성이 Python 프로그램 또는 스크립트 형식인 경우 리포지토리의 **api\$1helpers/python** 폴더 아래에 배치합니다.
+ 사용자 지정 구성이 Bash 스크립트 형식인 경우 리포지토리의 **api\$1helpers** 폴더 아래에 배치합니다.
+ 사용자 지정 구성이 Terraform 형식인 경우 리포지토리의 **terraform** 폴더 아래에 배치합니다.
+ 사용자 지정 구성 생성에 대한 자세한 내용은 글로벌 사용자 지정 README 파일을 참조하세요.
**참고**
글로벌 사용자 지정은 AFT 파이프라인의 AFT 계정 프로비저닝 프레임워크 단계 후에 자동으로 적용됩니다.
## 계정 사용자 지정 적용
****
선택한 리포지토리에 특정 폴더 구조를 푸시하여 계정 사용자 지정을 적용할 수 있습니다. 계정 사용자 지정은 AFT 파이프라인에서 그리고 글로벌 사용자 지정 단계 이후에 자동으로 적용됩니다. 계정 사용자 지정 리포지토리에서 다양한 계정 사용자 지정이 포함된 여러 폴더를 생성할 수도 있습니다. 필요한 각 계정 사용자 지정에 대해 다음 단계를 사용합니다.
**계정 사용자 지정을 적용하려면**
1. ** 1단계: 계정 사용자 지정을 위한 폴더 생성 **
선택한 리포지토리에서 AFT가 제공하는 `ACCOUNT_TEMPLATE` 폴더를 새 폴더에 복사합니다. 새 폴더의 이름은 계정 요청 시 제공한 `account_customizations_name`과 일치해야 합니다.
1. ** 특정 계정 사용자 지정 폴더에 구성 추가 **
구성 형식에 따라 계정 사용자 지정 폴더에 구성을 추가할 수 있습니다.
+ 사용자 지정 구성이 Python 프로그램 또는 스크립트 형식인 경우 리포지토리에 있는 ***[account\$1customizations\$1name]*/api\$1helpers/python** 폴더 아래에 배치합니다.
+ 사용자 지정 구성이 Bash 스크립트 형식인 경우 리포지토리에 있는 ***[account\$1customizations\$1name]*/api\$1helpers** 폴더 아래에 배치합니다.
+ 사용자 지정 구성이 Terraform 형식인 경우 리포지토리에 있는 ***[account\$1customizations\$1name]*/terraform** 폴더 아래에 배치합니다.
사용자 지정 구성 생성에 대한 자세한 내용은 계정 사용자 지정 README 파일을 참조하세요.
1. ** 계정 요청 파일의 특정 `account_customizations_name` 파라미터를 참조 **
AFT 계정 요청 파일에는 입력 파라미터 `account_customizations_name`이 포함됩니다. 계정 사용자 지정의 이름을 이 파라미터의 값으로 입력합니다.
**참고**
환경의 계정에 대해 여러 계정 요청을 제출할 수 있습니다. 다른 계정 사용자 지정 또는 유사한 계정 사용자 지정을 적용하려면 계정 요청의 `account_customizations_name` 입력 파라미터를 사용하여 계정 사용자 지정을 지정합니다. 자세한 내용은 [여러 계정 요청 제출](https://docs.aws.amazon.com/controltower/latest/userguide/aft-multiple-account-requests.html)을 참조하세요.
## 사용자 지정 다시 호출
AFT는 AFT 파이프라인에서 사용자 지정을 다시 호출할 수 있는 방법을 제공합니다. 이 방법은 새 사용자 지정 단계를 추가하거나 기존 사용자 지정을 변경할 때 유용합니다. 다시 호출하면 AFT가 사용자 지정 파이프라인을 시작하여 AFT로 프로비저닝된 계정을 변경합니다. 이벤트 소스 기반 다시 호출을 사용하면 개별 계정, 모든 계정, OU에 따른 계정 또는 태그에 따라 선택된 계정에 사용자 지정을 적용할 수 있습니다.
다음 세 단계에 따라 AFT로 프로비저닝된 계정에 대한 사용자 지정을 다시 호출합니다.
**1단계: 글로벌 또는 계정 사용자 지정 `git` 리포지토리에 변경 사항 푸시**
필요에 따라 글로벌 및 계정 사용자 지정을 업데이트하고 변경 사항을 `git` 리포지토리로 푸시할 수 있습니다. 이 시점에서는 아무 일도 일어나지 않습니다. 다음 두 단계에 설명된 대로 사용자 지정 파이프라인을 이벤트 소스에서 호출해야 합니다.
**2단계: 사용자 지정을 다시 호출하기 위한 AWS Step Functions 실행 시작**
AFT는 AFT 관리 계정에서 `aft-invoke-customizations`라는 AWS Step Functions를 제공합니다. 이 함수의 목적은 AFT 프로비저닝 계정에 대한 사용자 지정 파이프라인을 다시 호출하는 것입니다.
다음은 `aft-invoke-customizations` AWS Step Functions에 입력을 전달하기 위해 생성할 수 있는 이벤트 스키마(JSON 형식)의 예제입니다.
```
{
"include": [
{
"type": "all"
},
{
"type": "ous",
"target_value": [ "ou1","ou2"]
},
{
"type": "tags",
"target_value": [ {"key1": "value1"}, {"key2": "value2"}]
},
{
"type": "accounts",
"target_value": [ "acc1_ID","acc2_ID"]
}
],
"exclude": [
{
"type": "ous",
"target_value": [ "ou1","ou2"]
},
{
"type": "tags",
"target_value": [ {"key1": "value1"}, {"key2": "value2"}]
},
{
"type": "accounts",
"target_value": [ "acc1_ID","acc2_ID"]
}
]
}
```
예제 이벤트 스키마는 다시 호출 프로세스에서 포함하거나 제외할 계정을 선택할 수 있음을 보여줍니다. 조직 단위(OU), 계정 태그 및 계정 ID를 기준으로 필터링할 수 있습니다. 필터를 적용하지 않고 `"type":"all"` 문을 포함하면 모든 AFT 프로비저닝 계정에 대한 사용자 지정이 다시 호출됩니다.
**참고**
AWS Control Tower Account Factory for Terraform(AFT) 버전이 1.6.5 이상인 경우 `OU Name (ou-id-1234` 구문을 사용하여 중첩된 OU를 대상으로 지정할 수 있습니다. 자세한 내용은 [GitHub](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/issues/280)의 다음 주제를 참조하세요.
이벤트 파라미터를 입력하면 Step Functions가 해당 사용자 지정을 실행하고 호출합니다. AFT는 한 번에 최대 5개의 사용자 지정을 호출할 수 있습니다. Step Functions는 이벤트 기준과 일치하는 모든 계정이 완료될 때까지 대기하고 반복합니다.
**3단계: AWS Step Functions 출력을 모니터링하고 AWS CodePipeline 실행을 관찰합니다.**
+ 결과 Step Functions 출력에는 Step Functions 입력 이벤트 소스와 일치하는 계정 ID가 포함되어 있습니다.
+ **개발자 도구**에서 AWS CodePipeline으로 이동하여 계정 ID에 해당하는 사용자 지정 파이프라인을 확인합니다.
## AFT 계정 사용자 지정 요청 추적 문제 해결
AWS Lambda 를 기반으로 하는 계정 사용자 지정 워크플로는 대상 계정 및 사용자 지정 요청 ID가 포함된 로그를 내보냅니다. AFT를 사용하면 대상 계정 또는 사용자 지정 요청 ID별로 사용자 지정 요청과 관련된 CloudWatch Logs를 필터링하는 데 사용할 수 있는 CloudWatch Logs Insights 쿼리를 제공하여 Amazon CloudWatch Logs로 사용자 지정 요청을 추적하고 문제를 해결할 수 있습니다. 자세한 내용은 *Amazon CloudWatch Logs 사용 설명서*의 [Amazon CloudWatch Logs를 사용한 로그 데이터 분석](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)을 참조하세요.
**AFT에 CloudWatch Logs Insights를 사용하려면**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **Logs**를 선택한 다음 **Logs Insights**를 선택합니다.
1. **쿼리**를 선택합니다.
1. **샘플 쿼리**에서 **Account Factory for Terraform**을 선택한 후 다음 쿼리 중 하나를 선택합니다.
+ **계정 ID별 사용자 지정 로그**
**참고**
*'YOUR-ACCOUNT-ID'*를 대상 계정 ID로 바꿔야 합니다.
```
fields @timestamp, log_message.account_id as target_account_id, log_message.customization_request_id as customization_request_id, log_message.detail as detail, @logStream
| sort @timestamp desc
| filter log_message.account_id == "YOUR-ACCOUNT-ID" and @message like /customization_request_id/
```
+ **사용자 지정 요청 ID별 사용자 지정 로그**
**참고**
*'YOUR-CUSTOMIZATION-REQUEST-ID'*를 사용자 지정 요청 ID로 바꿔야 합니다. 사용자 지정 요청 ID는 AFT 계정 프로비저닝 프레임워크 AWS Step Functions 상태 시스템의 출력에서 찾을 수 있습니다. AFT 계정 프로비저닝 프레임워크에 대한 자세한 내용은 [AFT 계정 프로비저닝 파이프라인](https://docs.aws.amazon.com/controltower/latest/userguide/aft-provisioning-framework.html)을 참조하세요.
```
fields @timestamp, log_message.account_id as target_account_id, log_message.customization_request_id as customization_request_id, log_message.detail as detail, @logStream
| sort @timestamp desc
| filter log_message.customization_request_id == "YOUR-CUSTOMIZATION-REQUEST-ID"
```
1. 쿼리를 선택하고 시간 간격을 선택한 다음 **쿼리 실행**을 선택합니다.
# AFT 내 소스 코드의 버전 관리를 위한 대안
AFT는 소스 코드 버전 제어 시스템(VCS) AWS CodeCommit 에를 사용하며 비즈니스 요구 사항 또는 기존 아키텍처를 충족하는 다른 [CodeConnections](https://docs.aws.amazon.com//dtconsole/latest/userguide/supported-versions-connections.html)를 허용합니다.
AFT를 처음 배포하고 기존 CodeCommit 리포지토리가 없는 경우 AFT 배포 사전 조건의 일부로 외부 VCS 공급자를 지정해야 합니다.
**AFT는 다음과 같은 소스 코드 관리 대안을 지원합니다.**
+ GitHub
+ GitHub Enterprise Server
+ BitBucket
+ GitLab
+ GitLab 자체 관리형
**참고**
를 VCS AWS CodeCommit 로 지정하는 경우 추가 단계가 필요하지 않습니다. AFT는 사용자 환경에 필요한 `git` 리포지토리를 기본 이름으로 생성합니다. 하지만 필요에 따라 조직 표준을 준수하기 위해 CodeCommit의 기본 리포지토리 이름을 재정의할 수 있습니다.
## AFT를 사용하여 대체 소스 코드 버전 관리 시스템(사용자 지정 VCS) 설정
AFT 배포를 위한 대체 소스 코드 버전 관리 시스템을 설정하려면 다음 단계를 따르세요.
**1단계: 지원되는 타사 버전 관리 시스템(VCS)에서 `git` 리포지토리를 생성합니다.**
를 사용하지 않는 경우 다음 항목에 대해 AFT 지원 타사 VCS 공급자 환경에서 `git`리포지토리를 생성 AWS CodeCommit해야 합니다.
+ **AFT 계정 요청.** [사용 가능한 샘플 코드](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-request). AFT 계정 요청에 대한 자세한 내용은 [AFT를 사용하여 새 계정 프로비저닝](aft-provision-account.md) 섹션을 참조하세요.
+ **AFT 계정 프로비저닝 사용자 지정.** [사용 가능한 샘플 코드](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-provisioning-customizations). AFT 계정 프로비저닝 사용자 지정에 대한 자세한 내용은 [AFT 계정 프로비저닝 사용자 지정 상태 시스템 생성](aft-provisioning-framework.md#aft-create-customizations) 섹션을 참조하세요.
+ **AFT 글로벌 사용자 지정.** [사용 가능한 샘플 코드](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-global-customizations). AFT 글로벌 사용자 지정에 대한 자세한 내용은 [계정 사용자 지정](aft-account-customization-options.md) 섹션을 참조하세요.
+ **AFT 계정 사용자 지정.** [사용 가능한 샘플 코드](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-customizations). AFT 계정 사용자 지정에 대한 자세한 내용은 [계정 사용자 지정](aft-account-customization-options.md) 섹션을 참조하세요.
**2단계: AFT 배포에 필요한 VCS 구성 파라미터 지정**
다음 입력 파라미터는 AFT 배포의 일부로 VCS 공급자를 구성하는 데 필요합니다.
+ **vcs\$1provider**:를 사용하지 않는 경우 사용 사례에 따라 VCS 공급자를 `"bitbucket"`, `"gitlab"`, `"github"` `"githubenterprise"`또는 로 AWS CodeCommit지정합니다.
+ **github\$1enterprise\$1url**: GitHub Enterprise 고객의 경우에만 GitHub URL을 지정합니다.
+ **account\$1request\$1repo\$1name**: AWS CodeCommit 사용자의 경우이 값은 로 설정됩니다`aft-account-request`. AFT 지원 타사 VCS 공급자 환경에서 이 입력 값을 실제 리포지토리 이름으로 업데이트합니다. BitBucket, Github, GitHub Enterprise, GitLab 및 GitLab 자체 관리형의 경우 리포지토리 이름은 `[Org]/[Repo]` 형식이어야 합니다.
+ **account\$1customizations\$1repo\$1name**: AWS CodeCommit 사용자의 경우이 값은 로 설정됩니다`aft-account-customizations`. AFT 지원 타사 VCS 공급자 환경에서 이 입력 값을 리포지토리 이름으로 업데이트합니다. BitBucket, Github, GitHub Enterprise, GitLab 및 GitLab 자체 관리형의 경우 리포지토리 이름은 `[Org]/[Repo]` 형식이어야 합니다.
+ **account\$1provisioning\$1customizations\$1repo\$1name**: AWS CodeCommit 사용자의 경우 이 값은 `aft-account-provisioning-customizations`로 설정됩니다. AFT 지원 타사 VCS 공급자 환경에서 이 입력 값을 리포지토리 이름으로 업데이트합니다. BitBucket, Github, GitHub Enterprise, GitLab 및 GitLab 자체 관리형의 경우 리포지토리 이름은 `[Org]/[Repo]` 형식이어야 합니다.
+ **global\$1customizations\$1repo\$1name**: AWS CodeCommit 사용자의 경우이 값은 로 설정됩니다`aft-global-customizations`. AFT 지원 타사 VCS 공급자 환경에서 이 입력 값을 리포지토리 이름으로 업데이트합니다. BitBucket, Github, GitHub Enterprise, GitLab 및 GitLab 자체 관리형의 경우 리포지토리 이름은 `[Org]/[Repo]` 형식이어야 합니다.
+ **account\$1request\$1repo\$1branch**: 브랜치는 기본적으로 `main`이지만 값을 재정의할 수 있습니다.
기본적으로 AFT는 각 `git` 리포지토리의 `main` 브랜치에서 소스를 가져옵니다. 추가 입력 파라미터를 사용하여 브랜치 이름 값을 재정의할 수 있습니다. 입력 파라미터에 대한 자세한 내용은 [AFT Terraform 모듈](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/blob/main/README.md#inputs)의 README 파일을 참조하세요.
**기존 AWS CodeCommit 고객의 경우**
AFT의 새 이름으로 CodeCommit 리포지토리를 생성하는 경우 이러한 입력 파라미터의 값을 업데이트하여 리포지토리 이름을 업데이트할 수 있습니다.
**3단계: 타사 VCS 공급자에 대한 AWS CodeCommit 연결 완료**
배포가 실행되면 AFT는 필요한 AWS CodeCommit 리포지토리를 생성하거나 선택한 타사 VCS 공급자에 대한 AWS CodeCommit 연결을 생성합니다. 후자의 경우 AFT 관리 계정의 콘솔에 수동으로 로그인하여 보류 중인 CodeCommit 연결을 완료해야 합니다. CodeCommit 연결을 완료하는 방법에 대한 자세한 지침은 [AWS CodeCommit 설명서](https://docs.aws.amazon.com//dtconsole/latest/userguide/connections-update.html)를 참조하세요.
# AFT를AWS CodeCommit에서 다른 VCS 공급자로 이동
이 섹션에서는 AWS Control Tower Account Factory for Terraform(AFT)을 버전 관리 시스템(VCS)으로AWS CodeCommit에서 다른 VCS 공급자로 이동하는 방법에 대한 개요를 제공합니다.
**1단계.** 선택한 VCS에서 새 리포지토리를 설정합니다.
**2단계.** `git`에서 이러한 리포지토리를 새 원격으로 추가합니다.
**3단계.** 새 VCS 제공업체로 `git push`를 실행합니다.
**참고**
생성하는 리포지토리 구조는 in AWS CodeCommit과 동일해야 합니다. 구조를 변경하면 원하는 코드를 AFT가 실행할 수 없게 됩니다.
aft-account-request
aft-account-customizations
aft-global-customizations
aft-account-provisioning-customizations
**4단계.** AWS Control Tower 관리 계정에서 다음 예제와 같이 VCS 제공업체를 가리키도록 Terraform 모듈(부트스트랩)을 업데이트합니다.
**예: **[Terraform OSS를 사용하는 GitLab](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/blob/main/examples/gitlab%2Btf_oss/main.tf)
- `terraform plan`을 실행하여 변경 사항을 미리 본 다음 `terraform apply`를 실행합니다.
**5단계.** 다음과 같이 CodeConnection(이전 CodeStar) 설정을 마치기 위한 단계를 완료합니다.
1. AFT 관리 계정에 로그인합니다.
1. 보류 중인 [연결 업데이트](https://docs.aws.amazon.com/dtconsole/latest/userguide/connections-update.html) 또는AWS콘솔 []에 설명된 대로 새 VCS 공급자에 대한 pending AWS CodeConnections를 찾아 완료합니다`https://us-east-1.console.aws.amazon.com/codesuite/settings/connections`.
1. 참조: [배포 후 단계](https://docs.aws.amazon.com//controltower/latest/userguide/aft-post-deployment.html)
**참고**
계정 파이프라인은 `aft-invoke-customizations` *Step Functions*가 간접적으로 호출될 때까지 이전 소스를 유지합니다. 이 간접 호출은 업그레이드의 일부 또는 다음 사용자 지정의 간접 호출의 일부로 수행됩니다.
자세한 내용은이 블로그: [How to migration your AWS CodeCommit repository to other Git provider를 참조하세요](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider).
# 데이터 보호
[AWS공동 책임 모델](https://aws.amazon.com//compliance/shared-responsibility-model/)은 AFT의 데이터 보호에 적용됩니다. 데이터 보호를 위해 다음과 같은 보안 모범 사례를 권장합니다.
+ AWS Control Tower에서 제공하는 데이터 보호 지침을 따릅니다. 자세한 내용은 [AWS Control Tower의 데이터 보호](controltower-console-encryption.md) 섹션을 참조하세요.
+ AFT 배포 시 생성된 Terraform 상태 구성을 보존합니다. 자세한 내용은 [AWS Control Tower Account Factory for Terraform(AFT) 배포](aft-getting-started.md) 섹션을 참조하세요.
+ 조직의 보안 정책에 따라 민감한 자격 증명을 주기적으로 교체합니다. 보안 암호의 예로는 Terraform 토큰, `git` 토큰 등이 있습니다.
**저장된 데이터 암호화**
AFT는AWS Key Management Service 키로 저장 시 암호화된 Amazon S3 버킷, Amazon SNS 주제, Amazon SQS 대기열 및 Amazon DynamoDB 데이터베이스를 생성합니다. AFT에서 생성한 KMS 키는 기본적으로 1년 주기로 교체가 활성화됩니다. Terraform의 Terraform Cloud 또는 Terraform Enterprise 배포를 선택하면 AFT에는 민감한 Terraform 토큰 값을 저장하는AWS Systems Manager SecureString 파라미터가 포함됩니다.
AFT[구성 요소 서비스](aft-components.md)는 기본적으로 저장 시 암호화된에 설명된AWS서비스를 사용합니다. 자세한 내용은 AFT의 각 구성 요소AWS서비스에 대한AWS설명서를 참조하고 각 서비스가 따르는 데이터 보호 사례에 대해 알아봅니다.
**전송 중 데이터 암호화**
AFT는 기본적으로 전송 중 암호화[구성 요소 서비스](aft-components.md)를 사용하는에 설명된AWS서비스를 사용합니다. 자세한 내용은 AFT의 각 구성 요소AWS서비스에 대한AWS설명서를 참조하고 각 서비스가 따르는 데이터 보호 사례에 대해 알아봅니다.
Terraform Cloud 또는 Terraform Enterprise 배포의 경우 AFT는 Terraform 조직에 액세스하기 위해 HTTPS 엔드포인트 API를 직접 호출합니다.AWS CodeStar 연결에서 지원하는 타사 VCS 공급자를 선택하면 AFT는 VCS 공급자 조직에 액세스하기 위해 HTTPS 엔드포인트 API를 호출합니다.
# AFT에서 계정 제거
이 주제에서는 AFT 파이프라인이 계정 배포 및 업데이트를 중지하도록 AFT에서 계정을 제거하는 방법을 설명합니다.
**중요**
AFT 파이프라인에서 계정을 제거하면 되돌릴 수 없으며 상태가 손실될 수 있습니다.
사용 중지된 애플리케이션의 계정을 해지하거나, 손상된 계정을 격리하거나, 한 조직에서 다른 조직으로 계정을 이동하려는 경우 AFT에서 계정을 제거할 수 있습니다.
**참고**
AFT에서 계정을 제거하는 것은 AWS Control Tower 계정 또는 AWS 계정을 삭제하는 것과 다릅니다. AFT에서 계정을 제거해도 AWS Control Tower는 여전히 계정을 관리합니다. AWS Control Tower 계정 또는를 삭제하려면 다음을 AWS 계정참조하세요.
*AWS Control Tower 사용자 안내서*의 [계정 관리 중지](https://docs.aws.amazon.com/controltower/latest/userguide/unmanage-account.html).
*AWS Billing 사용자 안내서*의 [계정 해지](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/close-account.html).
**AFT 파이프라인에서 계정을 제거하는 방법**
다음 절차에서는 AFT에서 계정을 제거하는 방법에 대해 설명합니다.
1. ** 계정 요청을 저장하는 `git` 리포지토리에서 계정 제거 **
계정 요청을 저장하는 `git` 리포지토리에서 AFT에서 제거하려는 계정에 대한 계정 요청을 삭제합니다.
계정 요청 리포지토리에서 계정 요청을 제거하면 AFT가 사용자 지정 파이프라인과 계정 메타데이터를 삭제합니다. 자세한 내용은 GitHub의 AFT에 대한 [1.8.0 릴리스 정보](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/releases/tag/1.8.0)를 참조하세요.
1. ** Terraform 워크스페이스 삭제(Terraform Cloud 및 Terraform Enterprise 고객만 해당) **
AFT에서 제거하려는 계정의 글로벌 사용자 지정 및 계정 사용자 지정 워크스페이스를 삭제합니다.
1. ** Amazon S3 백엔드에서 Terraform 상태 삭제 **
AFT 관리 계정에서, AFT에서 제거하려는 계정의 Amazon S3 버킷 내부의 모든 관련 폴더를 삭제합니다.
**작은 정보**
다음 예제에서는 `012345678901`을 AFT 관리 계정 ID 번호로 바꿉니다.
**예: Terraform OSS**
Terraform OSS를 선택하면 `aft-backend-012345678901-primary-region` 및 `aft-backend-012345678901-secondary-region` Amazon S3 버킷에서 각 계정에 대해 3개의 폴더를 찾을 수 있습니다. 이러한 폴더는 *계정 사용자 지정 상태*, *사용자 지정 파이프라인 상태* 및 *글로벌 사용자 지정 상태*와 관련이 있습니다.
**예: Terraform Cloud 또는 Terraform Enterprise**
Terraform Cloud 또는 Terraform Enterprise를 선택하면 `aft-backend-012345678901-primary-region` 및 `aft-backend-012345678901-secondary-region` Amazon S3 버킷에서 각 계정의 폴더를 찾을 수 있습니다. 이러한 폴더는 *사용자 지정 파이프라인 상태*와 관련이 있습니다.
# 운영 지표
기본적으로 *Account Factory for Terraform(AFT)*은 AWS로 익명의 운영 지표를 전송합니다. 이 데이터를 사용하면 고객이 AFT를 사용하는 방식을 이해할 수 있으므로 솔루션의 품질과 기능을 개선할 수 있습니다. AFT 배포 중에 파라미터를 변경하여 데이터 수집을 옵트아웃할 수 있습니다. 수집이 활성화되면 다음 데이터가 AWS로 전송됩니다.
+ **솔루션:** AFT별 식별자
+ **버전:** AFT 버전
+ **범용 고유 ID(UUID):** 각 AFT 배포에 대해 무작위로 생성되는 고유 식별자
+ **타임스탬프:** 데이터 수집 타임스탬프
+ **데이터:** 고객이 수행한 AFT 구성 및 작업
AWS는 수집된 데이터를 소유합니다. 데이터 수집에는 [AWS 개인정보 보호정책](https://aws.amazon.com/privacy/)이 적용됩니다.
**참고**
1.6.0 이전의 AFT 버전은 사용 지표를 AWS에 보고하지 않습니다.
지표 보고를 옵트아웃하려면:
+ 다음 예제와 같이 Terraform 입력 구성 파일에서 `aft_metrics_reporting`의 입력 값을 `false`로 설정하고 AFT를 재배포합니다. 명시적으로 설정하지 않은 경우 이 값은 기본적으로 `true`로 설정됩니다.
예제를 복사하는 경우 `x`가 포함된 문자열 항목을 실제 ID 및 리전 값으로 대체해야 합니다.
```
module "control_tower_account_factory" {
source = "aws-ia/control_tower_account_factory/aws"
# Required Vars
ct_management_account_id = "xxxxxxxxxxx"
log_archive_account_id = "xxxxxxxxxxx"
audit_account_id = "xxxxxxxxxxx"
aft_management_account_id = "xxxxxxxxxxx"
ct_home_region = "xx-xxxx-x"
tf_backend_secondary_region = "xx-xxxx-x"
# Optional Vars
aft_metrics_reporting = false # to opt out, set this value to false
}
```
# Account Factory for Terraform(AFT) 문제 해결 가이드
이 섹션은 Account Factory for Terraform(AFT)을 사용할 때 발생할 수 있는 일반적인 문제를 해결하는 데 도움을 줍니다.
**Topics**
+ [일반 문제](#w2aac44c33c45b7)
+ [계정 프로비저닝/등록과 관련된 문제](#w2aac44c33c45b9)
+ [사용자 지정 간접 호출과 관련된 문제](#w2aac44c33c45c11)
+ [계정 사용자 지정 워크플로와 관련된 문제](#w2aac44c33c45c13)
## 일반 문제
+ ** AWS 리소스 할당량 초과**
로그 그룹에 AWS 리소스 할당량을 초과한 것으로 표시되면 [AWS Support](https://aws.amazon.com/premiumsupport/)에 문의하십시오. Account Factory는 AWS CodeBuild AWS Organizations및를 포함하는 리소스 할당량과 AWS 서비스 함께를 사용합니다 AWS Systems Manager. 자세한 내용은 다음을 참조하세요.
+ *CodeBuild 사용자 안내서*의 [AWS CodeBuild란?](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ *Organizations 사용 설명서*의 [란 무엇입니까 AWS Organizations?](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)
+ *Systems Manager 사용 설명서*의 [란 무엇입니까 AWS Systems Manager?](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html)
+ **오래된 Account Factory 버전**
문제가 발생했을 때 해당 문제가 버그라고 생각된다면 최신 버전의 Account Factory를 사용하고 있는지 확인합니다. 자세한 내용은 [Account Factory 버전 업데이트](https://docs.aws.amazon.com/controltower/latest/userguide/update-aft-version.html)를 참조하세요.
+ **Account Factory 소스 코드가 로컬에서 변경됨**
Account Factory는 오픈 소스 프로젝트입니다. AWS Control Tower는 Account Factory 코어 코드를 지원합니다. Account Factory 코어 코드를 로컬에서 변경하는 경우 AWS Control Tower는 최선의 노력으로 Account Factory 배포를 지원합니다.
+ **Account Factory 역할 권한 부족**
Account Factory는 IAM 역할 및 정책을 생성하여 제공된 계정 배포 및 사용자 지정을 관리합니다. 이러한 역할 또는 정책을 변경하면 Account Factory 파이프라인이 특정 작업을 수행하지 못할 수 있습니다. 자세한 내용은 [필요한 역할](https://docs.aws.amazon.com/controltower/latest/userguide/aft-required-roles.html)을 참조하세요.
+ **계정 리포지토리가 올바르게 채워지지 않음 **
계정을 프로비저닝하기 전에 [배포 후 단계](https://docs.aws.amazon.com/controltower/latest/userguide/aft-post-deployment.html)를 따라야 합니다.
+ **OU를 수동으로 변경한 후 드리프트를 탐지하지 못함**
**참고**
AWS Control Tower는 드리프트를 자동으로 감지합니다. 드리프트 해결에 대한 자세한 내용은 [AWS Control Tower의 드리프트 탐지 및 해결](https://docs.aws.amazon.com/controltower/latest/userguide/drift.html#resolving-drift)을 참조하세요.
조직 단위(OU)를 수동으로 변경하면 드리프트가 탐지되지 않습니다. 이는 Account Factory의 이벤트 기반 특성 때문입니다. 계정 요청이 제출되면 Terraform이 관리하는 리소스는 직접 계정이 아닌 Amazon DynamoDB 항목입니다. 항목이 변경되면 요청은 대기열에 배치되고, 여기서 AWS Control Tower는 Service Catalog(계정 세부 정보를 관리하는 서비스)를 통해 요청을 처리합니다. OU를 수동으로 변경하면 계정 요청이 변경되지 않았기 때문에 드리프트가 탐지되지 않습니다.
## 계정 프로비저닝/등록과 관련된 문제
+ **계정 요청(이메일 주소/이름)이 이미 존재함**
이 문제는 일반적으로 프로비저닝 중에 또는 `ConditionalCheckFailedException`으로 Service Catalog 제품 실패를 초래합니다.
다음 중 하나를 수행하여 문제에 대한 자세한 정보를 찾을 수 있습니다.
+ Terraform 또는 CloudWatch Logs 로그 그룹을 검토합니다.
+ Amazon SNS 주제(`aft-failure-notifications`)로 전달되는 실패를 검토합니다.
+ ** 잘못된 계정 요청 **
계정 요청이 예상 스키마를 따르는지 확인합니다. 예제는 GitHub의 [terraform-aws-control\$1tower\$1account\$1factory](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-request/examples)를 참조하세요.
+ ** AWS Organizations 리소스 할당량 초과**
계정 요청이 AWS Organizations 리소스 할당량을 초과하지 않는지 확인합니다. 자세한 내용은 [AWS 조직 할당량을 참조하세요](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_reference_limits.html).
## 사용자 지정 간접 호출과 관련된 문제
+ ** 대상 계정이 Account Factory에 온보딩되지 않음 **
사용자 지정 요청에 포함된 모든 계정이 Account Factory에 온보딩되었는지 확인합니다. 자세한 내용은 [기존 계정 업데이트](https://docs.aws.amazon.com/controltower/latest/userguide/aft-update-account.html)를 참조하세요.
+ **사용자 지정 요청 대상 계정이 DynamoDB 테이블 `aft-request-metadata`에는 존재하지만 계정 요청 리포지토리에는 존재하지 않음 **
다음 중 하나를 수행하여 잘못된 계정을 제외하도록 사용자 지정 호출 요청의 형식을 지정합니다.
+ DynamoDB 테이블 `aft-request-metadata`에서 계정 요청 리포지토리에 더 이상 없는 계정을 참조하는 항목을 삭제합니다.
+ '모두'를 대상으로 사용하지 않습니다.
+ 계정이 속한 OU를 대상으로 지정하지 않습니다.
+ 계정을 직접 대상으로 지정하지 않습니다.
+ ** Terraform Cloud에 잘못된 토큰 사용 **
올바른 토큰을 설정했는지 확인합니다. Terraform Cloud는 조직 기반 토큰이 아닌 팀 기반 토큰만 지원합니다.
+ **계정 사용자 지정 파이프라인이 생성되기 전에 계정을 생성하지 못함. 계정을 사용자 지정할 수 없음**
계정 요청 리포지토리에서 계정 사양을 변경합니다. 계정의 태그 값 변경과 같이 변경을 수행하면 Account Factory는 파이프라인이 없더라도 파이프라인을 생성하려고 시도하는 경로를 따릅니다.
## 계정 사용자 지정 워크플로와 관련된 문제
계정 사용자 지정 워크플로와 관련된 문제가 발생하는 경우 AFT 버전이 1.8.0 이상인지 그리고 DynamoDB 요청 테이블에서 계정 관련 메타데이터의 모든 인스턴스를 삭제했는지 확인합니다.
AFT 버전 1.8.0에 대한 자세한 내용은 GitHub의 [릴리스 1.8.0](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/releases/tag/1.8.0)을 참조하세요.
AFT 버전을 확인하고 업데이트하는 방법에 대한 자세한 내용은 다음을 참조하세요.
+ [AFT 버전 확인](https://docs.aws.amazon.com/controltower/latest/userguide/check-aft-version.html)
+ [AFT 버전 업데이트](https://docs.aws.amazon.com/controltower/latest/userguide/update-aft-version.html)
또한 Amazon CloudWatch Logs Insights 쿼리를 통해 대상 계정 및 사용자 지정 요청 ID가 포함된 로그를 필터링하여 사용자 지정 요청을 추적하고 문제를 해결할 수 있습니다. 자세한 내용은 [AFT 계정 사용자 지정 요청 추적을 통한 문제 해결](https://docs.aws.amazon.com/controltower/latest/userguide/aft-account-customization-options.html)을 참조하세요.