기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
랜딩 존 구축
AWS 변환은 마이그레이션 프로젝트의 일부로 AWS 랜딩 존을 설계하고 배포하는 과정을 안내합니다. 랜딩 존은 워크로드가 도착하기 전에 조직 경계, 거버넌스 제어 및 계정 구조를 갖춘 워크로드의 기반 역할을 하는 다중 계정 AWS 환경입니다. AWS 변환은 마이그레이션 인벤토리 및 비즈니스 요구 사항을 분석하여 조직 단위(OU) 및 계정 구조를 권장하고, 권장 서비스 제어 정책(SCPs 적용하고, 코드형 인프라(IaC)를 생성 및/또는 배포합니다.
랜딩 존 에이전트는 다음 두 단계를 안내합니다.
-
파운데이션 설정 - 코어 랜딩 존 구조인 AWS Control Tower, 기본 OUs 및 코어 계정을 설정합니다.
-
워크로드 계정 설계 - 마이그레이션 웨이브, 사업부 및 환경 분리 요구 사항에 따라 워크로드 OUs 및 계정을 설계하고 생성합니다.
AWS 변환은 그린필드 환경(기존 랜딩 존 없음)과 브라운필드 환경(기존 OUs 및 계정이 이미 배포됨)을 모두 지원합니다. 브라운필드 시나리오에서 AWS 변환은 기존 조직 구조를 감지하고 AWS 모범 사례와의 격차를 해소하는 데 필요한 변경 사항만 권장합니다.
커넥터 설정
랜딩 존 에이전트는 조직 관리 계정에서 리소스를 프로비저닝하기 위해 대상 AWS 계정 커넥터가 필요합니다. 커넥터에는 다음과 같은 권한이 있습니다.
-
조직 단위 및 계정 생성
커넥터 요청을 승인할 때 다음에 AWS 변환 권한을 부여합니다.
-
대상 및 리전에서 랜딩 존 인프라를 프로비저닝 AWS 계정 하고 관리합니다. 여기에는 해당하는
ATWorkspace:{workspace-id}경우CreatedBy:AWSTransform및 로 태그가 지정된 리소스로 제한된 다음 항목에 대한 권한이 포함됩니다.-
로 시작하는 버킷에 대한 S3 버킷 작업(생성, 읽기, 쓰기, 삭제)
transform-vmware-landing-zone- -
CloudFormation 랜딩 존 스택에 대한 스택 배포 및 변경 세트 관리
-
AWS Control Tower 작업(랜딩 존 관리, 기준 및 제어 활성화)
-
AWS 조직 관리(조직 단위 생성 및 관리, 계정 생성, 계정 이동)
-
AWS Control Tower를 통한 서비스 제어 정책(SCP) 관리
-
AWS Service Catalog 프로비저닝 아티팩트 관리
-
커넥터를 생성할 때 대상을 지정합니다 AWS 리전. 이 리전은 홈 Control Tower 리전과 동일해야 합니다. Control Tower 리전에 대한 자세한 내용은 AWS Control Tower로 작업하는 방법을 AWS 리전참조하세요.
랜딩 존 설정을 시작할 때 AWS 변환은 커넥터 구성을 검색하고 확인을 위해 AWS 조직 관리 계정 ID와 대상 리전을 제공합니다. 자세한 내용은 AWS 커넥터 변환 단원을 참조하십시오.
중요
IAM Identity Center 리전 종속성 - AWS 변환에는 AWS IAM Identity Center(IAM Identity Center)가 필요합니다. 즉, 커넥터 리전이 AWS Control Tower 홈 리전과 IAM Identity Center 리전 모두와 일치해야 합니다. 조직에 AWS IAM Identity Center가 이미 구성되어 있는 경우 커넥터가 다른 리전을 대상으로 하면 Control Tower 초기화가 실패합니다. 자세한 내용은 Control Tower 사용 설명서의 IAM Identity Center 고객에 대한 고려 사항을 참조하세요 AWS .
파운데이션 설정
파운데이션 설정 단계에서는 AWS Control Tower를 사용하여 코어 랜딩 존 인프라를 설정합니다. AWS Control Tower가 랜딩 존을 설정하면 전체 AWS 조직의 거버넌스 기반을 구성하는 관리 계정에 관리형 리소스 세트를 자동으로 프로비저닝합니다.
-
루트 - 랜딩 존의 모든 OUs가 포함된 최상위 상위 항목입니다.
-
보안 OU - Control Tower에서 자동으로 생성됩니다. 로그 아카이브 계정(조직 전체의 모든 AWS API 활동 및 리소스 변경 사항에 대한 변경 불가능한 중앙 집중식 로깅)과 감사 계정(보안 및 규정 준수 검토를 위해 모든 계정에 대한 읽기 전용 액세스)이라는 두 개의 공유 계정이 포함되어 있습니다. 초기 설정 후에는 이러한 계정의 이름을 바꾸거나 바꿀 수 없습니다.
-
필수 제어(가드레일) - Control Tower는 조직 전체에 예방 및 탐지 제어를 자동으로 적용하여 기준 거버넌스 정책을 적용합니다. 비활성화할 수 없습니다.
-
IAM Identity Center 디렉터리 - Control Tower는 랜딩 존 사용자를 위해 미리 구성된 그룹과 Single Sign-On 액세스 권한이 있는 클라우드 네이티브 디렉터리를 생성합니다. 자세한 내용은 AWS IAM Identity Center를 참조하세요.
Control Tower는 CloudFormation StackSets를 사용하여 조직의 모든 계정 및 리전에 이러한 리소스를 일관되게 배포하고 관리합니다. 지원되는 방법 외부에서 Control Tower 관리형 리소스를 수정하거나 삭제하면 랜딩 존이 알 수 없는 상태가 될 수 있으므로 이렇게 하면 안 됩니다.
계정 이메일 규칙
AWS 에는 각 계정에 고유한 이메일 주소가 필요합니다. 이러한 이메일은 계정에 대한 중요한 알림을 받습니다. AWS 변환은 더하기 주소 지정을 사용하여 단일 사서함에서 고유한 계정 이메일을 생성합니다.
형식: prefix+account-name@domain
접두사(예: aws-admin)와 도메인(예: acme.com)을 제공하면 AWS 변환이 모든 계정 이메일을 자동으로 추출합니다. 예제:
-
감사 계정:
aws-admin+audit@acme.com -
로그 아카이브 계정:
aws-admin+log-archive@acme.com -
샌드박스 계정:
aws-admin+sandbox@acme.com
브라운필드 시나리오에서 AWS 변환은 기존 계정 이메일을 검사하여 이미 사용 중인 더하기 주소 지정 규칙을 유추하고 동일한 패턴으로 계속할 것을 제안합니다.
권장 파운데이션 구조
AWS 모범 사례에 따라 AWS Transform은 다음과 같은 파운데이션 OU 구조를 권장합니다. 생성 전에 사용자 지정할 수 있습니다.
| OU | 용도 | 계정 |
|---|---|---|
| 보안 | 중앙 집중식 감사 로깅 및 모니터링. 전용 계정에서 이러한 서비스를 격리하는 것은 감사 추적을 워크로드 팀과 분리하는 데 도움이 되도록 설계되었습니다. | 감사, 로그 아카이브 |
| 인프라 | 공유 네트워킹(전송 게이트웨이, VPN), DNS 및 공통 서비스. 중복을 줄이고 네트워크 팀에 연결을 관리할 수 있는 단일 위치를 제공하는 데 도움이 되도록 이를 중앙 집중화하는 것이 좋습니다. | 없음(비어 있음) |
| 샌드박스 | 지출 한도 및 제한된 액세스를 사용한 개발자 실험. 개발자에게 프로덕션 리소스 위험 없이 실험할 수 있는 공간을 제공하는 것이 좋습니다. | 샌드박스 |
| 워크로드 | 프로덕션, 비프로덕션 및 선택적으로 규제된 하위 OUs 포함합니다. 워크로드 계정은 마이그레이션 요구 사항에 따라 다음 단계에서 설계됩니다. | 없음(비어 있음) |
참고
감사 및 로그 아카이브 계정이 있는 보안 OU는 Control Tower 파운데이션 설정의 일부로 생성됩니다. 인프라, 샌드박스 및 워크로드 OUs는 구조를 확인한 후 별도로 생성됩니다.
브라운필드 시나리오에서 AWS 변환은 기존 기반을이 권장 구조와 비교하고 격차만 보고합니다. 예: “파운데이션에는 보안 및 인프라 OUs 있지만 샌드박스 OU는 없습니다.”
서비스 제어 정책(SCP)
SCPs는 조직의 모든 계정에 대한 최대 권한을 설정하는 조직 수준의 권한 가드레일입니다. AWS 액세스 권한을 부여하지 않습니다. 대신 계정 관리자를 포함하여 계정의 어느 누구도 초과할 수 없는 경계를 정의합니다.
Control Tower 배포의 일부로 기준 가드레일이 자동으로 적용됩니다. AWS Transform은 조직의 태세를 강화하는 데 도움이 되도록 설계된 추가 SCPs도 권장합니다. 이는 실행 가능한 최소 랜딩 존의 AWS 모범 사례를 기반으로 합니다.
SCPs 인프라, 샌드박스 및 워크로드 OUs. 보안 OU는 Control Tower에서 관리하며이 도구를 통해 SCPs가 대상으로 지정할 수 없습니다.
중요
보안 OU는 Control Tower에서 관리하는 파운데이션 OU입니다. 랜딩 존 에이전트를 통해 계정, SCPs 또는 리소스를 추가할 수 없습니다.
브라운필드 시나리오에서 AWS 변환은 이미 적용된 SCPs 확인하고 격차를 메울 수 있는 SCP만 권장합니다.
파운데이션 배포
파운데이션 설계가 완료되면 배포 방법을 선택합니다.
-
내게 배포 - AWS 변환은 파운데이션 OUs, 계정 및 SCPs를 AWS 조직에 배포합니다.
-
직접 배포하겠습니다. AWS 변환은 원하는 형식으로 다운로드할 코드형 인프라(IaC) 아티팩트를 생성합니다( 참조IaC 형식).
-
워크로드 계정 먼저 설계 - 배포를 건너뛰고 워크로드 계정 설계 단계로 진행합니다. 나중에 모든 것을 함께 배포할 수 있습니다.
Control Tower 초기화
AWS 변환이 조직에서 AWS Control Tower가 아직 초기화되지 않았음을 감지하면 사용자에게 AWS 변환 콘솔 페이지에 대한 링크를 제공합니다. 링크에서 작업을 생성하면 Control Tower를 부트스트랩할 CloudFormation 스택이 생성됩니다. 이 프로세스는 대상 리전의 CloudFormation 콘솔에서이 스택을 생성합니다. 스택 생성이 완료되면 AWS 변환은 배포를 계속합니다.
워크로드 계정 설계
워크로드 계정 설계 단계에서 AWS Transform은 마이그레이션 인벤토리, 비즈니스 요구 사항 및 환경 분리 기본 설정을 기반으로 애플리케이션 워크로드에 대한 OU 및 계정 구조를 설계합니다.
마이그레이션 계획 컨텍스트
AWS 변환은 웨이브 계획, server-to-application 매핑, 공유 컨텍스트를 포함하여 마이그레이션 계획 단계에서 데이터를 검색합니다. 마이그레이션 계획 데이터를 사용할 수 있는 경우 AWS 변환은 요약을 표시하고 확인 또는 조정을 요청합니다. 마이그레이션 계획 데이터를 사용할 수 없는 경우 AWS 변환은 검색 질문을 직접 합니다.
Discovery
AWS 변환은 워크로드 요구 사항을 이해하기 위한 질문을 합니다. 질문을 건너뛸 수 있습니다. 포함된 주제:
-
를 사용하는 사업부 또는 팀 수 AWS
-
산업 및 관련 프레임워크(HIPAA, PCI-DSS, SOC2, FedRAMP)
-
워크로드가 민감한 데이터를 처리하는지 여부(PII, PHI, 재무)
-
환경 분리 기본 설정(dev/test/staging/prod를 별도의 계정 또는 공유로 제공)
-
워크로드 격리 요구 사항
-
비즈니스 애플리케이션 및 용도
-
애플리케이션으로 서버 그룹화
-
비용 추적 및 할당 요구 사항(비즈니스 단위, 프로젝트, 환경별)
-
향후 12~24개월 동안 예상 성장률
-
계정 전략 기본 설정(계정당 단일 앱, 그룹화 또는 환경 기반)
제안된 워크로드 구조
답변 및 마이그레이션 계획 데이터를 기반으로 AWS 변환은 워크로드 OU에서 OU 및 계정 구조를 제안합니다. 제안에는 각 설계 결정의 근거가 포함되어 있습니다.
AWS 변환은 다음과 같은 설계 원칙을 따릅니다.
-
마이그레이션 웨이브의 모든 서버는 동일한 계정으로 이동합니다. 웨이브는 계정 간에 분할할 수 없습니다. 이는 웨이브 실행 중 리호스팅 제한입니다.
-
격리된 환경을 요청하는 경우 AWS 변환은 워크로드/프로덕션 및 워크로드/비프로덕션 하위 OUs를 생성합니다.
-
적용 가능한 프레임워크가 식별되면 AWS 변환은 워크로드/규정 및 워크로드/표준 하위 OUs를 생성합니다.
-
여러 사업부에 다른 거버넌스가 필요한 경우 AWS 변환은 워크로드에서 business-unit-specific OUs를 생성합니다.
-
중요 또는 민감한 데이터 애플리케이션은 계정당 단일 앱을 가져옵니다. 이 경우 웨이브 플랜을 반복하라는 메시지가 표시될 수 있습니다.
-
공유 종속성이 있는 긴밀하게 연결된 애플리케이션은 하나의 계정으로 그룹화됩니다.
제안된 각 계정에는 이름, 용도, 대상 OU 및 사업부가 포함됩니다. AWS 변환에는 사용 중인 이름 지정 규칙이 표시됩니다(예: <business-unit>-<environment>-<workload>).
AWS 변환이 변경 사항을 적용하기 전에 제안된 구조를 검토하고 수정할 수 있습니다. 적용 후 반복하여 만족할 때까지 추가로 변경할 수 있습니다.
워크로드 SCP 구성
워크로드 구조가 생성되면 AWS 변환은 사용 가능한 SCPs 제공하고 워크로드 OUs. 적용할 SCPs와 OUs 선택합니다. AWS 변환은 SCPs를 적용하고 SCP 요약 테이블과 함께 업데이트된 조직 트리를 표시합니다.
워크로드 배포
워크로드 설계가 완료되면 배포 방법을 선택합니다.
-
내게 배포 - AWS 변환은 워크로드 OUs, 계정 및 SCPs를 AWS 조직에 배포합니다.
-
직접 배포하겠습니다. AWS 변환은 원하는 형식으로 다운로드할 IaC 아티팩트를 생성합니다( 참조IaC 형식).
IaC 형식
자체 배포를 선택하면 AWS 변환은 다음 형식으로 코드형 인프라 아티팩트를 생성합니다.
-
AWS Cloud Development Kit (AWS CDK) - 프로그래밍 방식의 인프라 배포를 위한 TypeScript 프로젝트입니다.
-
HashiCorp Terraform - 랜딩 존 리소스를 관리하기 위한 HashiCorp 구성 언어(HCL) 템플릿을 생성합니다.
-
Landing Zone Accelerator(LZA) - LZA 범용 구성 버전 1.1.0을 기반으로 YAML 파일을 구성합니다. 이러한 엔터프라이즈 지원 템플릿은의 Landing Zone Accelerator와 함께 작동 AWS 하여 다중 계정 AWS 환경을 설정합니다. 생성된 파일에는 AWS 모범 사례에 맞는 거버넌스, 조직 구조 및 네트워킹에 대해 사전 구성된 설정이 포함되어 있습니다. 자세한 내용은 LZA 범용 구성을 참조하세요.
참고
Landing Zone Accelerator(LZA) 파이프라인을 통해 배포하는 경우 AWS 변환 계정과 LZA 설치가 동일한 AWS 조직에 있어야 합니다. AWS 변환에 사용된 조직 IDs와 LZA 간에 불일치가 있는 경우 배포가 실패합니다. Organizations를 사용하여 LZA 설치를 설정하는 방법을 알아보려면 AWS 조직 기반 설치를 참조하세요.
형식을 선택하면 AWS 변환이 아티팩트를 생성하고 다운로드할 수 있도록 합니다.
다운로드한 파일이 손상되거나 변조되지 않았는지 확인하려면 체크섬을 생성 및 다운로드한 다음 다음을 사용하여 로컬에서 생성된 해시와 비교합니다.
openssl dgst -sha256 -binary <file.zip> | base64
배포 승인 프로세스
랜딩 존 배포 요청은 실행 전에 명시적 승인이 필요합니다. 배포 요청을 제출하면 승인 AWS 변환 탭을 통해 승인된 승인자에게 자동으로 라우팅됩니다.
승인자는 CloudFormation 템플릿과 랜딩 존 구성을 검토합니다. AWS 변환에서 관리자 역할을 가진 사용자만 배포 요청을 승인할 수 있습니다. 각 제출은 새 검토 주기를 트리거하고 배포는 확인을 받은 후에만 진행됩니다.
승인자가 요청을 거부하는 경우 직접 연락하여 필요한 수정 사항에 대해 논의합니다. 시스템은 감사 목적으로 모든 승인 결정을 추적하고 배포 기록을 유지합니다.
랜딩 존 리소스에 태그 지정
AWS 변환은 추적을 위해 로 생성된 모든 리소스에 정의 및 실행 IDs와 "CreatedBy": "AWSTransform" 함께 태그를 자동으로 지정합니다.
자동 태그
모든 랜딩 존 리소스는 다음 태그를 받습니다.
-
CreatedBy- AWSTransform -
ATWorkspace- Workspace 식별자
참고
마이그레이션이 AWS 마이그레이션 가속화 프로그램(MAP 2.0)의 일부인 경우 필요한 MAP 태그: 키: map-migrated 값: migMPE_ID (여기서 MPE_ID는 마이그레이션 포트폴리오 평가 식별자)을 포함할 수 있습니다. 커넥터 설정 단계에서 MAP 태그가 요청됩니다. AWS 변환은 랜딩 존 배포 중에 이러한 태그를 적용합니다.
변경 사항 되돌리기
배포되지 않은 요소만 제거할 수 있습니다. OU 또는 계정이 배포되면 랜딩 존 에이전트를 통해 제거할 수 없습니다.
요소를 제거할 때는 순서가 중요합니다. 상위 요소보다 먼저 하위 요소를 제거해야 합니다.
-
먼저 계정을 제거합니다(이메일).
-
OUs에서 SCPs를 제거합니다.
-
하위 OUs 제거 - 아직 계정 또는 중첩된 OU가 있는 경우 OUs 제거할 수 없습니다.