기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 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을 사용하여 계정을 배포하는 방법을 설명합니다. 비디오의 오른쪽 하단 모서리에 있는 아이콘을 선택하여 전체 화면으로 확대하면 더 잘 보입니다. 자막을 사용할 수 있습니다. [![AWS Videos](http://img.youtube.com/vi/eDbNvHz02dk/0.jpg)](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)을 참조하세요.