이전 글 AWS Transform for VMware — 공공기관 VM을 안전하게 클라우드로에서 서비스가 무엇인지, 왜 안전한지를 다뤘습니다. 이번 글은 그 다음 질문 — "그래서 실제로 어떤 순서로 하면 되는가"에 답하는 실무 가이드입니다. 온프레미스 vCenter 환경의 VM 수백 대를 Amazon EC2로 리호스팅하는 전 과정을 단계별로 따라갈 수 있도록 정리했습니다.
전체 흐름 한눈에 보기
AWS Transform의 End-to-end migration 잡은 다음 6개 스텝으로 구성됩니다. 이 글의 STEP 3~8이 여기에 대응합니다.
[사전 준비] 계정 구조 · Migration Hub 홈 리전 · 네트워크 연결 · IAM Identity Center
│
STEP 1 AWS Transform 활성화 + 워크스페이스 생성
STEP 2 마이그레이션 잡(Job) 생성 — 잡 유형 선택
│
STEP 3 Perform discovery → 인벤토리 · 의존성 맵
STEP 4 Build migration plan → 애플리케이션 그룹 · 웨이브 계획
STEP 5 Connect target accounts→ 타깃 계정/리전 연결
STEP 6 Build landing zone → 멀티 계정 기반 구성
STEP 7 Migrate network → VPC · 서브넷 · 보안 그룹 (IaC 생성)
STEP 8 Migrate servers → MGN 복제 → 테스트 → 컷오버
│
[사후] 검증 · 정리 · 최적화STEP 0. 사전 준비 (Prerequisites)
여기서 빠뜨린 항목은 반드시 중간에 프로젝트를 멈춰 세웁니다. 착수 전에 아래를 확정하세요.
① 계정 구조
AWS는 마이그레이션용으로 디스커버리 계정 / 마이그레이션 계획 계정 / 타깃 계정의 분리를 권장합니다. 소규모라면 단일 계정으로도 가능하지만, 멀티 계정으로 이전할 계획이라면 모든 타깃 계정이 동일한 AWS Organizations 조직에 속해야 합니다.
② 리전 결정
워크스페이스를 만드는 리전이 디스커버리 데이터가 저장되는 리전이고, 타깃 리전은 별도로 지정할 수 있습니다. 서울 리전(ap-northeast-2)은 워크스페이스 생성 가능 리전에 포함되어 있으므로, 국내 데이터 저장 요건이 있는 기관은 워크스페이스와 타깃을 모두 서울로 맞추는 것이 깔끔합니다. 잡 1개당 타깃 리전은 1개이므로, 여러 리전으로 나눠 이전하려면 잡을 분리해야 합니다.
③ Migration Hub 홈 리전 설정
디스커버리 계정에서 AWS Migration Hub의 홈 리전(Home Region)을 먼저 설정합니다. 이 값은 한 번 정하면 변경이 번거로우니 ②에서 정한 리전과 일치시키세요.
④ 온프레미스 → AWS 네트워크 경로와 포트
MGN 복제 트래픽이 흐를 경로(Direct Connect, Site-to-Site VPN, 또는 인터넷)를 먼저 확보합니다. 방화벽에서 열어야 하는 대표 포트는 다음과 같습니다.
| 구간 | 포트 | 용도 |
|---|---|---|
| 소스 서버 → 스테이징 서브넷의 복제 서버 | TCP 1500 | 블록 레벨 복제 데이터 전송 |
소스 서버 → mgn.<region>.amazonaws.com | TCP 443 | MGN 에이전트 등록·제어 |
| 복제 서버 → S3 엔드포인트 | TCP 443 | 에이전트 소프트웨어·설정 다운로드 |
| 소스 서버 → SSM 엔드포인트 | TCP 443 | MGN Connector 사용 시 에이전트 자동 배포 |
복제 대역폭도 미리 계산하세요. 초기 전체 복제(initial sync)는 전체 디스크 용량을 한 번 밀어 넣는 작업이므로, 10TB를 100Mbps로 보내면 산술적으로 9일 이상 걸립니다. 웨이브 계획의 현실성은 대역폭이 결정합니다.
⑤ IAM Identity Center 및 사용자
AWS Transform 웹 애플리케이션은 IAM Identity Center(또는 서드파티 IdP, IAM-only 접근) 기반으로 사용자를 관리합니다. 이 선택은 활성화 시점에 확정되며 이후 변경할 수 없으므로, 기관 표준 IdP 연동 여부를 미리 결정하세요.
⑥ 대상 OS 지원 여부 확인
리호스팅 대상 서버의 OS가 MGN 지원 목록에 있는지 확인합니다. 지원 종료된 구형 OS(예: 오래된 CentOS·Windows Server 버전)는 이전 전 업그레이드하거나, 별도 전략(재구축)을 세워야 합니다.
STEP 1. AWS Transform 활성화 및 워크스페이스 생성
- AWS Management Console에서 AWS Transform을 검색해 서비스로 이동합니다.
- Get started를 선택해 현재 리전에서 서비스를 활성화합니다.
- 암호화 키를 선택합니다 — AWS 관리형 키 또는 고객 관리형 KMS 키(Customize encryption settings). 컴플라이언스 요건이 있다면 고객 관리형 키를 권장합니다.
- 필요 시 자체 S3 버킷을 지정합니다. 기본값은 서비스 관리형 버킷이며, 산출물 보관 정책을 기관이 직접 통제해야 한다면 자체 버킷을 사용하세요.
- Web application 기능을 활성화합니다(에이전트와 대화하는 UI).
- 사용자 접근 방식(IAM Identity Center / 서드파티 IdP / IAM-only)을 선택하고 사용자를 할당합니다.
- 활성화 후 Settings 탭에 표시되는 Web application URL로 접속해 워크스페이스를 생성합니다.
인터페이스 언어는 환경 설정에서 한국어로 바꿀 수 있습니다. 에이전트와의 대화도 한국어로 진행됩니다.
STEP 2. 마이그레이션 잡(Job) 생성 — 유형 선택
워크스페이스 랜딩 페이지에서 Create a job → 마이그레이션 옵션 → 잡 유형을 고릅니다. 채팅 질문에 답한 뒤 Create job을 선택하면 잡이 생성됩니다. 잡 유형은 다음과 같습니다.
| 잡 유형 | 포함 스텝 | 이럴 때 선택 |
|---|---|---|
| End-to-end migration | 디스커버리 → 계획 → 계정 연결 → 랜딩 존 → 네트워크 → 서버 | 처음부터 끝까지 한 번에 |
| Discovery and migration planning | 디스커버리 → 계획 | 실행 확정 전 현황 평가·웨이브 설계만 |
| Landing zone | 계정 연결 → 랜딩 존 | 멀티 계정 기반부터 세팅 |
| Network migration | 계정 연결 → 네트워크 | 랜딩 존은 이미 있고 네트워크만 변환 |
| Landing zone, network, and server migration | 계정 연결 → 랜딩 존 → 네트워크 → 서버 | 디스커버리·계획이 이미 끝난 경우 |
| Migration planning and server migration | 디스커버리 → 계획 → 계정 연결 → 서버 | 네트워크는 이미 구성됨 |
프리셋을 골랐더라도 진행 중에 스텝을 추가·제거해 워크플로를 조정할 수 있습니다. 첫 프로젝트라면 Discovery and migration planning으로 현황을 먼저 파악하고, 결과를 보고 실행 잡을 만드는 방식을 권합니다.
STEP 3. 디스커버리 (Perform discovery)
소스 환경을 파악하는 단계입니다. 세 가지 방식 중 환경에 맞는 것을 고릅니다.
방식 A — AWS Application Discovery Service 콜렉터/에이전트
가장 풍부한 데이터를 얻는 방식입니다. Agentless Collector(OVA)를 vCenter에 배포하거나, 개별 VM에 디스커버리 에이전트를 설치합니다. 에이전트 설치용 IAM 사용자에는 AWSApplicationDiscoveryAgentAccess 정책이 필요합니다. 설치된 서버는 Migration Hub의 Discover 섹션에 나타나며, 약 15분 간격으로 데이터를 전송합니다.
방식 B — Export for vCenter (오픈소스)
에이전트 설치가 어려운 환경에서, awslabs/export-for-vcenter 도구로 vCenter 인벤토리를 추출해 업로드합니다.
방식 C — 기존 수집 데이터 임포트
이미 RVTools 결과(.csv/.xlsx)가 있거나 ModelizeIT·Cloudamize 같은 서드파티 도구를 사용 중이라면 그 데이터를 그대로 임포트할 수 있습니다. 국내 프로젝트에서는 RVTools 익스포트가 가장 빠른 출발점인 경우가 많습니다.
디스커버리가 끝나면 에이전트가 VM 인벤토리, 리소스 사용률, 애플리케이션 간 의존성 맵을 산출합니다. 이 시점에서 이전 대상이 아닌 VM(테스트·폐기 예정·EOL 장비)을 반드시 걸러내세요. 옮기지 않아도 될 서버를 옮기는 것이 마이그레이션 비용 초과의 가장 흔한 원인입니다.
STEP 4. 마이그레이션 계획 수립 (Build migration plan)
에이전트가 의존성을 기준으로 애플리케이션을 그룹핑하고 마이그레이션 웨이브를 자동 제안합니다. 담당자는 결과를 검토·수정·승인합니다.
- 웨이브 계획은 CSV로 다운로드해 검토하고, 그룹핑을 수정한 뒤 다시 반영할 수 있습니다.
- 웨이브 1은 영향도가 낮고 의존성이 단순한 시스템으로 구성하세요. 첫 웨이브의 목적은 이전 자체가 아니라 절차·롤백·검증 체계를 검증하는 것입니다.
- 멀티 계정 이전 시 웨이브 1개당 타깃 계정은 1개입니다. 계정이 다른 애플리케이션은 웨이브를 분리해야 합니다.
- DB·인증 서버처럼 다수가 참조하는 공통 인프라는 의존 서비스보다 먼저 또는 같은 웨이브에 배치합니다.
STEP 5. 타깃 계정 연결 (Connect target accounts)
워크로드가 실제로 들어갈 AWS 계정과 리전을 연결합니다. AWS Transform이 해당 계정에 리소스를 생성할 수 있도록 IAM 역할이 배포됩니다. 이 단계에서 확인할 것:
- 타깃 계정이 AWS Organizations 조직 소속인지 (멀티 계정 이전 시 필수)
- 타깃 리전이 지원 대상인지, 서비스 쿼터(EC2 vCPU, EBS 볼륨, VPC 수)가 충분한지 — 쿼터 증설은 리드타임이 있으므로 미리 신청하세요
- 복제 데이터는 리전 간 전송되지 않고 소스 환경에서 타깃 계정·리전으로 직접 전송됩니다
STEP 6. 랜딩 존 구축 (Build landing zone)
멀티 계정 기반(계정 분리, 조직 단위, 공통 가드레일)을 구성하는 단계입니다. 이미 Control Tower 등으로 랜딩 존을 운영 중이라면 이 스텝을 건너뛰고 Network migration이나 Migration planning and server migration 잡 유형을 사용하면 됩니다.
STEP 7. 네트워크 마이그레이션 (Migrate network)
AWS Transform이 가장 큰 시간을 절약해주는 구간입니다. 온프레미스 네트워크 구성을 분석해 프로덕션 수준의 VPC 아키텍처로 변환합니다.
- 입력 — VMware NSX 구성(Import/Export for AWS 유틸리티), RVTools의 네트워크 토폴로지(.csv/.xlsx), Cisco ACI·Palo Alto·Fortinet 방화벽 정책
- 설계 모델 선택 — Transit Gateway 기반 허브 앤 스포크 또는 격리형 VPC 중 선택
- 산출물 — VPC·서브넷·라우팅·보안 그룹 설계와 함께 CloudFormation / AWS CDK 템플릿이 생성되며, 자동 배포하거나 다운로드해 수동 배포할 수 있습니다
any-any 성격의 느슨한 룰이 있었다면 그 느슨함이 그대로 넘어옵니다. 마이그레이션은 과다 허용 정책을 정리할 좋은 기회입니다. 생성된 IaC 템플릿을 코드 리뷰 대상으로 삼으면 검토가 훨씬 수월합니다.
STEP 8. 서버 마이그레이션 (Migrate servers)
실제 데이터가 움직이는 단계로, 내부적으로 AWS Application Migration Service(MGN)가 동작합니다.
8-1. 타깃 계정에서 MGN 초기화
타깃 계정·리전에서 MGN 서비스를 초기화(Initialize)합니다. 최초 1회만 필요하며, MGN 관련 IAM 역할이 자동 생성됩니다.
8-2. 복제 설정(Replication settings) 지정
- 스테이징 서브넷 — 복제 서버가 기동될 서브넷을 지정합니다. 이전 대상 워크로드와 분리된 전용 서브넷을 쓰는 것이 관리상 유리합니다.
- IP 할당 방식 — DHCP를 쓸지, 소스의 고정 IP를 유지할지 선택합니다. 방화벽 정책이 IP 기반으로 촘촘히 잡혀 있는 환경이라면 고정 IP 유지가 컷오버 리스크를 크게 줄입니다.
- 사이징 기준 — CPU/RAM 기준 사이징 선호도를 선택하면 Migration Hub의 EC2 추천이 인벤토리 파일에 반영됩니다.
- 제외할 인스턴스 타입 — 기관 표준에 맞지 않는 패밀리를 제외할 수 있습니다.
8-3. 복제 에이전트 배포
두 가지 방법이 있습니다.
(권장) MGN Connector로 자동 배포 — 소스 환경에 Linux VM 한 대를 두고 커넥터를 설치하면, SSM 하이브리드 활성화를 통해 다수 서버에 에이전트를 자동 배포합니다. 소스 서버 자격 증명은 AWS Secrets Manager에 등록해 사용합니다. 필요한 IAM 역할은 MGNConnectorInstallerRole, AWSApplicationMigrationConnectorManagementRole, AWSApplicationMigrationConnectorSharingRole_<ACCOUNT_ID>입니다. 수십~수백 대 규모에서는 이 자동화가 사실상 필수입니다.
수동 설치 — 소수 서버라면 직접 설치가 빠릅니다.
# Linux
wget -O ./aws-replication-installer-init \
https://aws-application-migration-service-<region>.s3.<region>.amazonaws.com/latest/linux/aws-replication-installer-init
sudo chmod +x aws-replication-installer-init
sudo ./aws-replication-installer-init
# Windows (PowerShell, 관리자 권한)
Invoke-WebRequest -Uri "https://aws-application-migration-service-<region>.s3.<region>.amazonaws.com/latest/windows/AwsReplicationWindowsInstaller.exe" `
-OutFile "AwsReplicationWindowsInstaller.exe"
.\AwsReplicationWindowsInstaller.exe설치 시 리전, 액세스 키(또는 IAM 역할), 복제할 디스크를 지정합니다. 페이지 파일·스왑·임시 볼륨은 복제 대상에서 제외하면 초기 동기화 시간과 비용을 줄일 수 있습니다.
8-4. 인벤토리 파일 검토
AWS Transform이 생성하는 인벤토리 CSV(*-subnet_augmented_mgn-inventory.csv 형태)를 다운로드해, 서버별 타깃 서브넷 ID·계정 ID·보안 그룹·인스턴스 타입을 확인하고 필요한 값을 채웁니다. 이 파일이 곧 컷오버 시 EC2가 어떤 모습으로 뜰지를 결정하는 설계 확정 문서입니다. 대충 넘기지 마세요.
8-5. 복제 상태 확인
모든 대상 서버의 복제 상태가 Healthy가 되고 초기 동기화가 완료될 때까지 기다립니다. 이후에는 변경분만 지속적으로 복제되므로 원본 VM은 컷오버 직전까지 정상 운영됩니다. 복제 지연(lag)이 계속 늘어난다면 대역폭이나 소스 디스크 I/O를 점검해야 합니다.
8-6. 테스트 인스턴스 기동 및 검증
운영 VM을 건드리지 않은 채 테스트 인스턴스를 최신 복제 시점 기준으로 기동합니다. 여기서 확인할 항목:
- OS 부팅, 드라이버, 네트워크 인터페이스 인식 여부
- 애플리케이션 기동 및 DB 연결 — 하드코딩된 IP·호스트명이 가장 흔한 실패 원인입니다
- 라이선스 재활성화 필요 여부 (하드웨어 정보 변경에 따른)
- 보안 그룹 룰이 실제 통신을 막지 않는지
- 모니터링·백업 에이전트의 정상 동작
테스트는 웨이브별로 반복합니다. 검증이 끝나면 서버를 Ready for cutover로 표시하며, 이 시점에 테스트 인스턴스는 자동 종료됩니다.
8-7. 컷오버 (Cutover)
사전에 합의한 일시에 컷오버를 수행합니다. 실무 순서는 다음과 같습니다.
- 서비스 공지 및 변경 승인 완료 확인
- 소스 애플리케이션·서비스 정지 (마지막 변경분 복제 완료 대기)
- Launch cutover instances 실행 — 타깃 EC2 기동
- DNS 전환 또는 로드밸런서 타깃 변경 — 사전에 TTL을 짧게(예: 60초) 낮춰두세요
- 기능·성능 검증 (스모크 테스트 체크리스트 기준)
- 정상 확인 후 Finalize cutover 선택 — 해당 웨이브 완료
STEP 9. 사후 작업 (Post-migration)
- 복제 리소스 정리 — 컷오버 완료 후 MGN 커넥터 CloudFormation 스택 삭제, 콘솔에서 커넥터 제거, Secrets Manager의 자격 증명 삭제, 소스 환경의 커넥터 VM 종료
- 디스커버리 데이터 정리 — AWS CLI로 디스커버리된 서버 정보를 정리
- 비용 최적화 — 이전 직후 1~2주 실사용 지표를 보고 인스턴스 타입을 재조정합니다. 안정화 후 Savings Plans / Reserved Instances를 적용하세요. 마이그레이션 직후 바로 약정하면 사이징 변경 여지를 잃습니다.
- 운영 체계 이관 — CloudWatch 모니터링·알람, AWS Backup 정책, 패치 관리(Systems Manager), 태깅 표준 적용
- 보안 기준선 적용 — GuardDuty, Security Hub, Config 룰 활성화 및 이전한 보안 그룹의 과다 허용 룰 정리
- 산출물 확보 — 워크스페이스 요약 리포트(PDF)를 생성해 보관합니다. 채팅으로 "모든 잡의 마이그레이션 진행 상황을 요약해줘"라고 요청하면 잡 상태, 사용자 승인 이력, 웨이브 계획, 네트워크 토폴로지, 랜딩 존 구성, 리호스트 진행 상황이 담긴 PDF를 받을 수 있습니다. 감사·검수 증빙으로 그대로 활용할 수 있습니다.
- 온프레미스 정리 — 안정화 기간(보통 2~4주)을 두고 원본 VM을 보존한 뒤 회수합니다. VMware 라이선스 절감 효과는 이 시점부터 발생합니다.
자주 부딪히는 문제와 대응
| 증상 | 원인 | 대응 |
|---|---|---|
| 복제가 시작되지 않음 / Stalled | TCP 1500 또는 443 차단 | 방화벽·보안 그룹·NACL에서 소스 → 스테이징 서브넷 경로 확인 |
| 초기 동기화가 계획보다 오래 걸림 | 대역폭 부족, 불필요한 볼륨 포함 | 복제 제외 디스크 재조정, 대역폭 스로틀 설정 검토, 웨이브 재분할 |
| 테스트 인스턴스에서 앱 기동 실패 | 하드코딩된 IP·호스트명, DNS 미변경 | 설정 파일·hosts 파일 점검, 고정 IP 유지 옵션 활용 |
| 부팅은 되나 네트워크 불통 | 보안 그룹 변환 누락, 서브넷 지정 오류 | 인벤토리 CSV의 서브넷·보안 그룹 값 재확인 |
| 구형 OS 에이전트 설치 실패 | MGN 미지원 OS·커널 | OS 업그레이드 또는 재구축(replatform) 전환 |
| EC2 기동 시 쿼터 초과 | vCPU·EBS 쿼터 부족 | 웨이브 실행 전 Service Quotas에서 증설 신청 |
진행 체크리스트
- ☐ 계정 구조와 Organizations 소속 확정
- ☐ Migration Hub 홈 리전 설정 (워크스페이스 리전과 일치)
- ☐ 온프레미스 → AWS 네트워크 경로 및 포트(1500/443) 개방
- ☐ 복제 대역폭 산정 및 웨이브별 소요 시간 추정
- ☐ IAM Identity Center / IdP 방식 결정 (변경 불가)
- ☐ 대상 서버 OS의 MGN 지원 여부 확인
- ☐ 최소 2주 이상 성능 데이터 확보 후 사이징
- ☐ 이전 제외 대상 VM 선별
- ☐ 변환된 보안 그룹에 대한 보안 담당자 검토 절차 정의
- ☐ 서비스 쿼터 사전 증설
- ☐ DNS TTL 사전 단축
- ☐ 웨이브별 롤백 기준·결정권자 문서화
- ☐ 컷오버 후 스모크 테스트 체크리스트 준비
- ☐ 워크스페이스 요약 리포트 보관
맺음말
AWS Transform for VMware는 디스커버리·계획·네트워크 변환처럼 과거에 수개월이 걸리던 설계 작업을 크게 단축해 줍니다. 하지만 여전히 사람이 책임져야 하는 영역이 명확히 남아 있습니다 — 대역폭 산정, 웨이브 순서 판단, 보안 그룹 검토, 컷오버 시점 결정, 롤백 기준입니다. 도구가 실행을 맡고 사람이 의사결정을 맡는 구조로 프로젝트를 설계하면, 대규모 VMware 이전도 예측 가능한 일정 안에서 수행할 수 있습니다.
보안·컴플라이언스 관점의 고려사항은 AWS Transform for VMware 보안 기능 — CSAP·ISMS-P 관점에서 본 인증 범위에서 이어서 다뤘습니다. VMware 전환 평가(Cloud Readiness Assessment)나 마이그레이션 실행이 필요하시면 JC Cloud로 문의해 주세요.
참고 자료
- AWS Transform 사용자 가이드 — Migrations (including VMware)
- AWS Transform 사용자 가이드 — Migration jobs (잡 유형·제한사항)
- AWS Transform 사용자 가이드 — Getting started (활성화 절차)
- AWS Transform — Supported Regions
- AWS 블로그 — Simplify server migration to AWS with AWS Transform for VMware
- AWS 블로그 — New capabilities in AWS Transform for VMware
- AWS Application Migration Service — 지원 운영체제
- AWS MGN 사용자 가이드 — Launching a cutover instance
- Export for vCenter (오픈소스 디스커버리 도구)
- Guidance for Automated Setup of AWS Transform (AWS Solutions Library)