BLOG
AWS Landing Zone 솔루션을 AWS Control Tower로 마이그레이션하기
안전하고 규정을 준수하는 다중 계정 AWS 환경을 빠르게 설정하고자 하는 많은 고객들은 AWS Landing Zone 솔루션(ALZ)을 사용하고 있는데요, AWS는 이 ALZ을 관리하는 부담을 줄이기 위한 관리형 서비스인 AWS Control Tower(Control Tower)를 발표했습니다.
AWS Control Tower는 AWS Organizations를 사용하여 랜딩 존을 생성하여 지속적인 계정 관리 및 거버넌스를 통합하고 수천 명의 고객이 클라우드로 마이그레이션 할 때 NAT과 협력한 경험을 바탕으로 모범 사례를 구현합니다. AWS CT를 사용하면 빌더가 클릭 몇 번으로 새 AWS 계정을 프로비저닝할 수 있으며, 계정이 전사적 정책을 준수한다는 사실을 알고 안심할 수 있습니다. 뿐만 아니라 AWS 고객은 AWS CT를 구현하고, 거버넌스를 신규 또는 기존 계정으로 확장하고, 규정 준수 상태를 신속하게 파악 수 있습니다.
ALZ는 현재 장기 지원 중이며 추가 기능은 제공되지 않습니다. 따라서 ALZ에서 AWS Control Tower 서비스로 마이그레이션하는 것을 권장합니다. 이번 포스팅에서는 해당 마이그레이션에 대한 다양한 고려 사항을 살펴보고 ALZ에서 AWS CT로의 성공적인 마이그레이션을 계획하는 방법을 알아보겠습니다.
전제 조건 및 고려 사항
- AWS 계정에서 사용한 적이 없는 새 이메일 주소
- 로그 아카이브 계정용 1개
- 감사/보안 계정용 1개
- AWS SSO를 사용하는 경우 AWS CT를 배포할 계획과 동일한 리전에 있어야 합니다.
- AWS 관리 계정은 AWS Config 또는 AWS CloudTrail에 대한 AWS Organization 관리 계정에서 신뢰할 수 있는 액세스를 활성화할 수 없습니다. 신뢰할 수 있는 액세스를 비활성화하는 방법에 대한 정보는 신뢰할 수 있는 액세스를 활성화 또는 비활성화하는 방법에 대한 AWS Organizations 설명서를 참조해 주세요.
- ALZ는 구성 레코더, 멤버 계정의 전송 채널을 설정하고 사용자는 AWS CT가 랜딩 존 설정 중에 사용자를 대신하여 AWS Config를 구성할 수 있도록 이러한 설치를 제거해야 합니다.
마이그레이션 프로세스
1단계: AWS Control Tower 배포
Control Tower는 랜딩 존(랜딩 존은 보안 및 규정 준수 모범 사례를 기반으로 잘 설계된 다중 계정 환경임)을 설정하기 전에 여기에 언급된 일련의 사전 검사를 계정에서 자동으로 실행합니다. AWS Single Sign-On(AWS SSO)이 이미 활성화된 경우 AWS Control Tower는 AWS SSO와 동일한 리전에 배포되어야 합니다. Control Tower는 기존 SSO 구성을 삭제하지 않습니다. 다른 디렉터리(외부 자격 증명 공급자, AWS SSO 사용자 스토어, Active Directory)가 설정된 경우 Control Tower는 기존 구성을 변경하지 않습니다. 자세한 내용은 AWS Single Sign-On(AWS SSO) 고객을 위한 고려 사항을 참조하십시오.
AWS SSO와 동일한 AWS 리전에 있는지 확인한 후 시작하기, 2단계에 있는 AWS Control Tower 사용 설명서에 설명된 대로 기존 AWS Organization에 AWS Control Tower를 배포할 수 있습니다.
2단계: 서비스 제어 정책(SCP)
Control Tower는 Control Tower 랜딩 존 리소스를 보호하기 위해 특정 예방 가드레일과 함께 기본적으로 제공됩니다. 이러한 필수 가드레일은 Control Tower에서 등록할 모든 OU (조직 단위) 구성에 적용됩니다. AWS Organizations를 통해 OU에 적용된 외부 SCP는 Control Tower와 함께 공존하게 되는데요, 그러나 가드레일 목록에서 보거나 제어할 수는 없습니다. SCP에는 정책의 크기와 수(OU 또는 계정당 최대 5개 정책)에 제한이 있으므로 Control Tower는 OU에 적용할 단일 정책으로 여러 SCP를 집계합니다. SCP의 최대 수를 초과하는 것은 바람직하지 않습니다. 따라서 정책을 병합하여 OU 또는 계정에 연결해야 합니다.
Control Tower 역할에 계정 및 OU에 대한 액세스 권한이 있고 예상되는 작업을 수행할 수 있는 권한이 있는지 확인해야 합니다. Control Tower 작업을 방해할 수 있는 매우 제한적인 SCP를 적용한 경우 해당 SCP를 제거하거나 이러한 SCP에서 AWS Control Tower 역할을 제외하는 것이 좋습니다.
3단계: AWS 구성
ALZ는 모든 멤버 계정에서 AWS Config를 활성화하여 매니페스트에 지정된 리전에서 구성 레코더 및 전송 채널을 생성합니다. 기존 AWS Config 배포를 처리하는 방법에는 두 가지가 있으며 다음 옵션 중 하나를 선택할 수 있습니다.
- 기존 계정에서 AWS Config 삭제: Control Tower에 등록하려는 멤버 계정을 식별하고 모든 Control Tower 지원 리전에서 구성 레코더 및 전달 채널을 삭제합니다. 기존 계정에서 Config를 삭제하려면 관리 계정으로 이동하여 CloudFormation 콘솔에서 AWS CloudFormation StackSets로 이동하고 AWS-Landing-Zone-Baseline-EnableConfig StackSet의 스택 인스턴스를 삭제합니다.
EnableConfig StackSet 삭제는 멤버 계정이 Control Tower에 등록될 때까지 리소스 변경 기록을 중지합니다. 이 시간을 최소화하려면 변경 사항이 적을 때 이 활동을 계획하고, 계정의 전제 조건이 충족되는 즉시 Control Tower에 계정을 등록해야 합니다. 다음은 구성 레코더 및 전송 채널의 상태를 확인하는 데 사용할 수 있는 몇 가지 AWS Config CLI 명령의 예입니다. <aws-region>을 작업 중인 지역으로 바꿉니다. 배포된 ALZ 리소스가 있는 모든 AWS 멤버 계정 및 리전에 대해 다음 명령을 실행합니다.
- View commands (Optional):
aws configservice describe-delivery-channels –region <aws-region>
aws configservice describe-delivery-channel-status –region <aws-region>
aws configservice describe-configuration-recorders –region <aws-region>
현재 Control Tower에서 지원하지 않는 AWS 리전에서 AWS Config를 활성화한 경우 계정이 Control Tower에 등록되면 나중에 해당 리전에서 Config를 활성화하십시오. 이 블로그에 언급된 방법론을 사용하여 Config Conformance Pack을 Control Tower에 새로 등록된 계정으로 확장할 수 있습니다.
2. 구성 설정 수정: 규정 준수 요구 사항으로 인해 기존 구성 배포를 삭제하지 않으려면 여기에 설명된 단계에 따라 기존 AWS Config 리소스가 있는 Control Tower에 AWS 계정을 등록해 보세요. Config는 AWS-Landing-Zone-Baseline-EnableConfig CloudFormation StackSet을 사용하여 활성화되고 Config IAM 역할은 AWS-Landing-Zone-Baseline-ConfigRole StackSet와 함께 배포됩니다. 따라서 모든 계정에서 Config를 수정하려면 여기에 설명된 Config 리소스의 변경 사항에 따라 CloudFormation 템플릿(aws-landing-zone-enable-config.template & aws-landing-zone-enable-config-role.template)을 수정한 다음 StackSet을 업데이트해야 합니다. 구성 집계 권한 부여(이전 링크의 5c 단계)의 경우 해당 단계에 설명된 대로 AWS CLI 명령도 실행해야 합니다.
Config 기록을 중지하고 싶지 않은 경우에만 2번 방법을 따르고, 그렇지 않은 경우 기존 Config StackSet을 삭제하고 Control Tower에서 다시 배포하도록 하는 1번 방법을 채택하는 것이 좋습니다.
4단계: 계정 및 OU 등록
Control Tower에서 관리할 계정과 OU를 등록하는 방법은 두 가지가 있는데요, Control Tower의 기본 기능에 의존하여 해당 OU 아래의 모든 계정에 OU를 등록하거나 계정별로 계정을 등록하여 수행됩니다. 일반적으로 표준 AVM(계정 자동 판매기)을 사용하고 있고 이에 대한 사용자 지정이 없는 경우 아래에 설명된 OU 등록 프로세스를 사용하는 것이 좋습니다.
이 섹션에서는 메커니즘과 각 메커니즘의 사용 시기에 관해 설명합니다.
- OU 등록:
이는 Control Tower에서 OU 내 여러 기존 계정의 거버넌스를 확장하는 효율적인 방법입니다. OU를 등록하면 해당 멤버 계정이 Control Tower 랜딩 존에 등록됩니다. 이 메커니즘으로 확인해야 할 두 가지 고려 사항은 다음과 같습니다.
- 중첩된 OU가 있는 경우 계층 구조에 따라 상위 OU를 먼저 등록하고 다음으로 하위 OU를 등록해야 합니다.
- OU는 300개 계정을 초과하지 않아야 합니다.
Control Tower 콘솔에서 OU 등록을 진행하는 방법에 대한 자세한 내용은 설명서를 참조하십시오. OU 등록 시 각 계정을 등록하는 데는 시간이 걸립니다. 따라서 계정 내에서 실행 중인 워크로드에 영향을 미치지 않더라도 OU를 등록하기 위한 유지 관리 기간을 예약하는 것이 좋습니다.
현재 OU 등록이 진행되는 동안 알아야 할 두 가지 제한 사항이 있습니다:
- 계정 팩토리를 통해 새 계정을 생성할 수 없습니다.
- 다른 OU를 생성하거나 등록할 수 없습니다.
- 계정별 계정 등록
Control Tower는 서비스 카탈로그 제품인 “AWS Control Tower Account Factory”를 사용하여 계정 생성을 위해 AWS Service Catalog를 활용합니다.
⚠️계정 생성을 위해 AVM CloudFormation 템플릿을 사용자 지정한 경우(예: 동일한 서비스 카탈로그 제품 내에서 연결하거나 계정 판매 리소스 내에서 직접 관련된 사용자 지정), 기존 AWS 서비스 카탈로그 제품과 프로비저닝된 제품을 유지할 수 있습니다. 계정 프로비저닝을 트리거 하는 섹션을 Control Tower Account Factory의 새 섹션으로 업데이트해야 합니다.
예를 들면 다음과 같습니다:
AccountVending:
Type: AWS::ServiceCatalog::CloudFormationProvisionedProduct
Properties:
ProductName: “AWS Control Tower Account Factory”
ProvisionedProductName: !Ref AccountName
ProvisioningArtifactName: “AWS Control Tower Account Factory”
ProvisioningParameters:
– Key: SSOUserEmail
Value: !Ref SSOUserEmail
– Key: AccountEmail
Value: !Ref AccountEmail
– Key: SSOUserFirstName
Value: !Ref SSOUserFirstName
– Key: SSOUserLastName
Value: !Ref SSOUserLastName
– Key: ManagedOrganizationalUnit
Value: !Ref ManagedOrganizationalUnit
– Key: AccountName
Value: !Ref AccountName
이 메커니즘에 대해 고려해야 할 두 가지 주의 사항은 다음과 같습니다:
- Control Tower 서비스 카탈로그 포트폴리오 또는 제품을 업데이트하거나 변경하지 마십시오. 이는 Control Tower에서 관리되며 원래 구성으로 되돌아갑니다.
- 현재 계정 등록 또는 생성은 단일 스레드(시간당 하나의 계정 등록)입니다.
5단계: 보안, Shared Services 및 로그 아카이브 계정
보안 계정:
Control Tower는 ALZ의 보안 계정과 유사한 기능을 제공하는 감사/보안 계정이라는 새 멤버 계정을 생성합니다. Control Tower를 배포할 때 기존 ALZ Security 계정을 유지하거나 선택할 수 없습니다. GuardDuty, Security Hub 및/또는 타사 설치와 같은 추가 서비스를 보안 계정에 배포한 경우 새 Control Tower Audit 계정으로 마이그레이션하는 것을 고려하십시오. 또한 보안 계정에서 Amazon Simple Notification Service(SNS) 주제의 보안 알림에 대한 페이징 또는 알림 시스템을 구성한 경우 이를 감사 계정으로도 이동하십시오.
로그 아카이브 계정:
Control Tower는 ALZ의 Log Archive 계정과 유사한 Log Archive 계정이라는 새 멤버 계정을 생성합니다. Control Tower를 배포하는 동안 기존 ALZ Log Archive 계정을 유지하거나 선택할 수 없습니다. 따라서 ALZ 로그 버킷의 로그를 유지하려는 경우 ALZ 로그 아카이브 Amazon Simple Storage Service(S3) 버킷(aws-landing-zone-*)의 기존 로그를 Control Tower 로그 아카이브 계정의 새 S3 버킷으로 복사할 수 있습니다. 또한 ALZ Log Archive S3 버킷에서 로그를 가져오도록 로그 분석 솔루션을 설정한 경우 해당 로그를 새 Control Tower Log Archive 계정으로 마이그레이션해야 합니다. 이전 로그를 ALZ에서 Control Tower로 가져오지 않으려면 이 단계를 무시하고 ALZ S3 로그 버킷을 비우고 나중에 삭제하면 됩니다.
공유 서비스 계정:
ALZ와 달리 Control Tower는 Shared Services 계정을 생성하지 않습니다. Control Tower에서 이 계정을 있는 그대로 유지하도록 선택할 수 있습니다. 이 경우 계정 팩토리를 사용하여 Control Tower에 이 계정을 등록해야 합니다.
6단계: ALZ 폐기
ALZ 리소스를 해제하기 전에 필요한 모든 리소스를 ALZ에서 Control Tower 환경으로 이동했는지 확인하십시오. 관리 계정에서 ALZ의 AWS CodePipeline 파이프라인에 대한 소스 단계와 빌드 단계 간의 전환을 비활성화합니다. 이렇게 하면 소스 파일의 의도하지 않은 업데이트가 파이프라인 실행을 시작하고 제거하려는 리소스를 재배포하는 것을 방지할 수 있습니다.
⚠️Attention
Landing Zone Add On 제품을 배포한 경우 연결된 AWS Service Catalog 프로비저닝 제품을 종료하지 마십시오. VPC 또는 IAM 역할(사용 중인 경우)과 같이 계정에 기본 인프라를 배포하는 데 사용되는 CloudFormation 스택 또는 StackSets를 제거하지 마십시오.
- 서비스 카탈로그에서 프로비저닝된 제품 삭제
- 워크로드에서 사용하지 않는 경우 제품 옆에 있는 세 개의 점을 클릭하여 접두사가 붙은 다음 프로비저닝 제품을 종료합니다.
lz_core_*
- 서비스 카탈로그의 포트폴리오에서 제품 제거
- “포트폴리오 목록”의 각 포트폴리오, 즉 “AWS Landing Zone – Baseline”, “AWS Landing Zone – Core”(ALZ 1.0) 또는 “AWS Landing Zone – Add-On Products”(ALZ 2.0)
모든 제약 조건 제거
모든 사용자 및 그룹 제거
포트폴리오에서 제품 제거
포트폴리오 목록으로 이동
포트폴리오 삭제
- 서비스 카탈로그에서 제품 삭제
- “제품 목록”의 각 제품, 즉 “AWS-Landing-Zone-Account-Vending-Machine” 및 AWS-Landing-Zone-*이 있는 프로비저닝되지 않은 기타 제품에 대해 선택하고 삭제합니다.
- 설명에 “(SO0045)”가 있는 나머지 CloudFormation AVM 스택을 수동으로 삭제합니다(서비스 카탈로그가 올바르게 정리된 경우 스택이 없을 수 있음).
- 시작 템플릿(SO0044)을 제외한 다른 모든 Landing Zone CloudFormation 스택을 수동으로 삭제합니다.
실행 중인 워크로드에 중요한 기준 인프라를 삭제하고 있지 않은지 확인하십시오.
- 아래 StackSet의 리소스가 워크로드에서 사용되지 않는 경우 삭제하십시오.
AWS-Landing-Zone-Baseline-EnableCloudTrail
AWS-Landing-Zone-Baseline-EnableConfig
AWS-Landing-Zone-Baseline-EnableConfigRules
AWS-Landing-Zone-Baseline-ConfigRole
AWS-Landing-Zone-Baseline-EnableConfigRulesGlobal
AWS-Landing-Zone-Baseline-EnableNotifications
AWS-Landing-Zone-Baseline-IamPasswordPolicy
AWS-Landing-Zone-Baseline-SecurityRoles
AWS-Landing-Zone-Baseline-PrimaryVPC
- 아직 스택 인스턴스가 있을 수 있는 사용되지 않은 나머지 StackSet의 경우 해당 StackSet를 관리해야 할 수 있습니다. 계정을 식별하고 계정 번호, 지역을 입력하고 스택 인스턴스를 삭제합니다. 이러한 StackSet에 현재 워크로드에서 사용 중인 인프라가 없는지 확인하십시오. 확인 후 Stack Instance가 없으면 StackSet을 삭제하면 됩니다.
- 로깅 계정에서 로깅 버킷 삭제
- 기존 로그를 이미 새 AWS CT Log Archive 계정 버킷에 복사한 경우 ALZ 로그 버킷 aws-landing-zone-*을 삭제하십시오.
- 마스터 계정에서 다음 S3 버킷을 삭제합니다.
aws-landing-zone-configuration-*
landingzone-landingzonepipelineartifacts*
- 랜딩 존 시작 템플릿 삭제
CloudFormation 스택을 삭제합니다(삭제를 허용하려면 “종료 보호 변경”이 필요할 수 있음). 리소스 삭제에 문제가 있는 경우 수동으로 삭제하고 성공할 때까지 스택 삭제를 다시 시도하십시오. ALZ StackSets에서 리소스를 유지하는 경우 이 IAM 역할 “AWSCloudformationStacksetExecution”을 유지합니다.
- 조직 정리
- ALZ에서 생성한 핵심 OU를 삭제합니다. AWS CT에서 생성한 다른 OU는 삭제하지 마십시오.
- 정책 탭으로 이동하여 서비스 제어 정책을 삭제합니다. Protect-cloudtrail-config를 선택하고 “정책 삭제”를 선택합니다.
- 모든 착륙 구역 SSM 매개변수 삭제
- Systems Manager -> Parameter Store로 이동하고 모든 랜딩 존 관련 파라미터를 삭제합니다.
- 랜딩 존 KMS 키가 삭제되었는지 확인합니다.
- IAM -> 암호화 키로 이동하여 키가 없는지 확인합니다.
- 키가 있는 경우 CLI를 사용하여 별칭을 삭제합니다:
aws kms delete-alias –alias-name alias/AwsLandingZoneKMSKey
- ALZ 로그 아카이브 및 보안 계정 종료
- 로그와 필요한 설정을 새로 생성된 AWS CT 계정으로 마이그레이션하고 나면 이러한 계정을 닫을 수 있습니다.
결론
이 게시물에서는 AWS Landing Zone(ALZ) 솔루션에서 AWS Control Tower로 마이그레이션 하는 단계와 모범 사례를 간략하게 설명했습니다. Control Tower를 사용하면 고객이 콘솔에서 클릭 몇 번으로 새 AWS 계정을 프로비저닝할 수 있으며 새 계정이 회사 전체 정책을 준수할 것이라는 안심할 수 있습니다. 보고 대시보드는 또한 계정의 규정 준수 상태를 신속하게 파악할 수 있도록 지원합니다.
원문URL: https://aws.amazon.com/ko/blogs/mt/migrate-aws-landing-zone-solution-to-aws-control-tower/
메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글이나 관련 기사 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.