Oracle VirtualBox의 VM을 AWS Transform MGN으로 EC2에 옮겨보기

안녕하세요 클래스메소드의 이수재입니다.

이전 글에서는 온프레미스 서버를 AWS로 옮기는 방법 중 하나로 AWS Transform MGN을 소개했습니다.

VM 이미지를 한 번 가져오는 방식도 있지만, 원본 서버를 계속 운영하면서 변경되는 데이터까지 반영하려면 지속적으로 복제하는 방식이 필요합니다. 그렇다면 별도의 온프레미스 서버가 없어도 로컬 PC의 가상 머신으로 이 과정을 확인해볼 수 있을까요?

이번 글에서는 Oracle VirtualBox에서 실행 중인 Ubuntu VM에 AWS Replication Agent를 설치하고, AWS Transform MGN을 통해 EC2 테스트 인스턴스로 실행해보겠습니다. MGN의 동작 방식과 장단점을 먼저 살펴본 뒤 실제 테스트 절차로 이어가겠습니다.

AWS Transform MGN은 어떤 서비스인가?

AWS Transform MGN은 물리 서버, 가상 서버 또는 다른 클라우드의 서버를 Amazon EC2로 이전할 때 사용할 수 있는 서비스입니다. 이전에는 AWS Application Migration Service라는 이름으로 제공되었으며, 2026년 6월부터 AWS Transform MGN이라는 이름을 사용하고 있습니다.

이번에 사용하는 에이전트 기반 방식에서는 소스 서버의 디스크를 블록 단위로 AWS에 지속 복제합니다. 초기 동기화가 끝난 뒤에는 변경된 블록을 계속 전송하고, 필요할 때 복제한 데이터를 변환해 EC2 테스트 또는 컷오버 인스턴스로 실행합니다. 컷오버는 운영 서비스를 AWS 쪽으로 전환하는 단계입니다.

흐름을 간단히 나타내면 다음과 같습니다.

VirtualBox의 Ubuntu VM
        ↓ AWS Replication Agent
AWS의 스테이징 영역
        ↓ 변환 및 실행
EC2 테스트 또는 컷오버 인스턴스

스테이징 영역에는 복제 데이터를 받는 Replication Server와 EBS 볼륨 등이 생성됩니다. 테스트 인스턴스를 실행하더라도 원본 VM은 계속 동작하며, 원본에서 발생한 새로운 변경분은 기존 테스트 인스턴스가 아니라 스테이징 영역으로 복제됩니다.

테스트 인스턴스에는 실행에 사용한 복제 데이터의 상태가 담깁니다. 이후 변경분까지 확인하려면 새 테스트 인스턴스를 실행해야 하며, 이때 기존 테스트 인스턴스는 교체됩니다.

지원되는 VMware vCenter 환경에는 스냅샷을 전송하는 에이전트리스 방식도 있습니다. VirtualBox 실습에서는 게스트 OS에 에이전트를 설치합니다. AWS가 VirtualBox를 별도 지원 플랫폼으로 명시한 것은 아니지만, 물리·가상 서버를 OS 수준에서 복제한다는 지원 범위를 바탕으로 구성한 실습입니다.

장점과 고려할 점

VM Import/Export는 VM 이미지를 S3에 업로드해 AMI로 변환하는 방식으로, 이미지를 만든 이후의 변경분은 자동으로 반영되지 않습니다. MGN은 변경분을 계속 복제하면서 테스트와 컷오버를 준비할 수 있다는 점이 장점입니다. 원본 서버를 운영하는 동안 EC2에서 부팅과 애플리케이션 동작을 여러 번 확인할 수 있습니다.

기존 OS와 설치된 애플리케이션을 함께 옮기므로, 새 서버에 모든 설정을 다시 구성하는 부담도 줄일 수 있습니다. 이런 방식은 기존 구성을 가능한 한 유지한 채 실행 환경을 옮기는 리호스트 마이그레이션에 잘 맞습니다.

다만 에이전트 기반 방식에서는 소스 서버마다 관리자 권한으로 AWS Replication Agent를 설치해야 합니다. 지원되는 OS와 아키텍처, 부트로더, 디스크 구성 등의 조건도 확인해야 하며, Linux 소스 서버에서는 Secure Boot를 지원하지 않습니다.

복제 중에는 소스 서버에서 MGN API로 TCP 443, AWS의 Replication Server로 TCP 1500 통신이 필요합니다. 스테이징 영역에도 Replication Server와 EBS 볼륨 같은 리소스가 생성되므로 네트워크 구성과 비용을 함께 생각해야 합니다.

MGN 서비스 요금은 소스 서버당 연속 사용 기준 90일 동안 무료이지만, 복제 과정에서 생성되는 EC2와 EBS, 스냅샷, 테스트 인스턴스 등의 비용은 별도로 발생합니다. 에이전트를 설치한 시점부터 무료 사용 기간이 시작된다는 점도 알아둘 필요가 있습니다.

마지막으로 지속 복제가 무중단 전환을 보장하는 것은 아닙니다. 실제 컷오버에서는 원본 애플리케이션의 쓰기를 중지하고 마지막 변경분이 반영되었는지 확인한 뒤, EC2 인스턴스의 기동과 애플리케이션 검증까지 진행해야 합니다.

그리고 MGN은 기본적으로 기존 서버를 EC2로 옮기는 리호스트 방식입니다. 서버가 정상적으로 기동하더라도 IP 주소와 DNS, 외부 시스템 연결, 라이선스와 운영 방식까지 자동으로 해결되는 것은 아닙니다.

사용해보기

이번 테스트에서는 VirtualBox VM을 AWS에 지속 복제하고 EC2 테스트 인스턴스를 실행하는 데까지 확인합니다. 실제 운영 전환이 목적은 아니므로 컷오버는 진행하지 않습니다.

테스트에 사용한 환경은 다음과 같습니다.

VM과 SSH 준비하기

Ubuntu Server 22.04 LTS의 x86_64 설치 ISO로 VirtualBox VM을 준비합니다. 이번 실습에서는 2 vCPU, 4GB 메모리와 20GB 가상 디스크를 사용하며, VM의 부트로더는 GRUB으로 구성하고 Secure Boot는 사용하지 않습니다. 이 사양은 MGN의 최소 요구 사항이 아니라 실습용 구성입니다.

Ubuntu에는 OpenSSH 서버를 준비하고, Windows에서 사용할 SSH 공개 키를 일반 사용자 계정의 ~/.ssh/authorized_keys에 등록합니다. 개인 키는 Windows에 보관합니다.

네트워크는 NAT를 사용합니다. Windows에서 접속할 수 있도록 TCP 127.0.0.1:2222를 게스트의 22번 포트로 연결하는 포트 포워딩 규칙을 추가합니다. 게스트가 NAT의 DHCP를 사용한다면 게스트 IP는 비워둡니다.

VM 생성과 SSH 설정의 상세 절차는 생략하고, Windows에서 공개 키 인증으로 Ubuntu에 접속할 수 있는 상태부터 진행하겠습니다. 이후 EC2 테스트 인스턴스에도 같은 Ubuntu 계정과 SSH 키로 접속합니다.

확인할 웹 서버 만들기

이제 Ubuntu VM에 SSH로 접속해 간단한 Nginx 웹 서버를 만들어보겠습니다. 확인용 페이지를 준비해두면, 이후 EC2에서도 같은 파일 내용과 서비스 동작을 확인할 수 있습니다.

다음 명령은 Windows PowerShell이 아니라 SSH로 접속한 Ubuntu에서 실행합니다.

# Nginx를 설치하고 소스 VM의 상태를 변경합니다.
sudo apt update
sudo apt install -y nginx curl

echo 'MGN test page - version 1' | sudo tee /var/www/html/index.html
sudo systemctl enable --now nginx
curl http://127.0.0.1

마지막 명령에서 다음 내용이 표시되는지 확인합니다.

MGN test page - version 1

AWS Transform MGN 초기 설정하기

AWS Management Console에서 도쿄 리전(ap-northeast-1)의 AWS Transform MGN 콘솔을 엽니다. 처음 사용하는 리전이라면 Get started에서 초기 설정을 진행하며, 필요한 IAM 역할을 생성할 권한이 있는 사용자 또는 역할로 진행합니다.

복제 환경은 Settings → Replication template → Edit에서 설정할 수 있습니다. 소스 서버를 추가하기 전에, AWS 쪽에서 복제 데이터를 받을 환경을 정하는 단계입니다.

Staging area subnet에는 인터넷 게이트웨이로 향하는 기본 경로가 있는 퍼블릭 서브넷을 선택합니다. Target storage type은 기본값인 Amazon EBS를 사용합니다.

보안 그룹은 Always use AWS Transform MGN security group을 켜서 MGN이 관리하도록 합니다. 복제 데이터를 받는 TCP 1500 규칙도 서비스가 관리하므로, 이번 실습에서는 사용자 지정 보안 그룹을 추가하지 않습니다.

이어서 Data routing and throttling에서는 다음과 같이 설정합니다.

이렇게 설정하면 Replication Server에 공인 IPv4 주소가 할당되고, 원본 VM은 인터넷을 통해 복제 데이터를 전송합니다. 이번에는 VPN이나 Direct Connect 같은 사설 연결을 구성하지 않으므로, Private IPv4 address를 복제에 사용하는 나머지 옵션은 선택하지 않습니다.

같은 회선의 다른 작업에 영향을 준다면 Throttle network bandwidth를 켜고 서버당 전송 대역폭의 상한을 Mbps 단위로 지정할 수 있습니다.

스테이징 영역의 서버가 MGN·EC2 API와 필요한 S3 버킷에 HTTPS(TCP 443)로 접근할 수 있는지도 확인한 뒤 설정을 저장합니다.

에이전트 설치용 AWS 자격 증명 준비하기

에이전트를 설치할 때는 서버를 MGN에 등록할 수 있는 AWS 자격 증명이 필요합니다. 여기서는 설치용 IAM 역할을 만들고 STS로 임시 자격 증명을 발급합니다.

IAM 콘솔의 Roles → Create role에서 신뢰할 엔터티 유형을 AWS account, 계정은 This account로 선택합니다. 권한 정책으로 AWSApplicationMigrationAgentInstallationPolicy를 연결하고, 역할 이름은 예를 들어 MgnVirtualBoxAgentInstall로 지정합니다.

이 역할을 사용할 작업자에게도 해당 역할의 sts:AssumeRole 권한이 있어야 합니다. 기존 권한에 없다면 아래 정책을 작업자의 IAM 사용자 또는 역할에 부여합니다. <account-id>는 실습용 AWS 계정 ID로 교체합니다. IAM Identity Center를 사용한다면 해당 권한 세트를 통해 부여합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::<account-id>:role/MgnVirtualBoxAgentInstall"
    }
  ]
}

같은 작업자 계정으로 AWS CloudShell을 열고 다음 명령을 실행합니다. CloudShell에서는 AWS CLI를 사용할 수 있으므로, 이 단계를 위해 Ubuntu VM에 AWS CLI를 설치할 필요는 없습니다.

# 설치에 사용할 임시 자격 증명을 발급합니다. 출력에 비밀 정보가 포함됩니다.
aws sts assume-role \
  --role-arn 'arn:aws:iam::<account-id>:role/MgnVirtualBoxAgentInstall' \
  --role-session-name mgn-virtualbox-install \
  --duration-seconds 3600 \
  --query Credentials \
  --output json

결과의 AccessKeyId, SecretAccessKey, SessionToken을 다음 설치 단계의 입력값으로 사용합니다. Expiration 이전에 설치를 진행하고, 만료되었다면 다시 발급합니다. 역할의 신뢰 정책에 MFA 조건을 추가한 경우에는 AssumeRole 호출에도 그 조건에 맞는 MFA 정보를 전달해야 합니다.

AWS Replication Agent 설치하기

설치에 앞서 Ubuntu VM의 아키텍처와 디스크 여유 공간을 확인합니다. uname -m의 결과는 x86_64여야 하며, 루트 디렉터리에 최소 2GB, 설치 중 /tmp에 최소 1GB의 여유 공간이 필요합니다.

uname -m
df -h / /tmp

실행 중인 커널과 같은 버전의 헤더와 DHCP 클라이언트도 필요합니다. Python과 설치 파일 다운로드에 사용할 도구를 함께 준비합니다.

# 에이전트 설치에 필요한 패키지를 소스 VM에 설치합니다.
sudo apt update
sudo apt install -y "linux-headers-$(uname -r)" isc-dhcp-client python3 wget

소스 VM에서 MGN API로 TCP 443, Replication Server로 TCP 1500 아웃바운드 통신이 가능해야 합니다. 이 통신은 VM에서 AWS로 시작하므로 SSH 접속과 달리 NAT 포트 포워딩은 필요하지 않습니다.

또한 MGN은 MAC 주소를 이용해 소스 서버를 식별하므로, 에이전트를 설치한 뒤에는 VirtualBox에서 VM의 MAC 주소를 새로 생성하지 않도록 합니다.

준비가 끝나면 Ubuntu VM에서 도쿄 리전용 설치 파일을 다운로드합니다.

wget -O aws-replication-installer-init \
  https://aws-application-migration-service-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/latest/linux/aws-replication-installer-init

실행 권한을 추가한 뒤 설치 프로그램을 실행합니다.

# AWS Replication Agent를 소스 VM에 설치합니다.
sudo chmod +x aws-replication-installer-init
sudo ./aws-replication-installer-init --region ap-northeast-1

복제할 디스크를 묻는 화면에서는 Ubuntu의 부팅과 루트 파일시스템을 포함하는 가상 디스크를 선택합니다. 이 실습처럼 디스크가 하나인 구성에서는 해당 디스크 전체가 대상입니다. 설치가 끝나면 MGN 콘솔의 Source servers에 새로운 서버가 등록되고 초기 동기화가 시작됩니다.

에이전트 설치가 성공하면 아래와 같은 메시지를 확인할 수 있습니다. 이 메시지는 에이전트 설치가 완료되었다는 뜻이며, 초기 복제가 끝났다는 의미는 아닙니다.

 sudo ./aws-replication-installer-init --region ap-northeast-1
[sudo] password for sujae:
The installation of the AWS Replication Agent has started.
AWS Access Key ID: 
AWS Secret Access Key: 
AWS Session Token: 
Identifying volumes for replication.
Choose the disks you want to replicate. Your disks are: /dev/sda
To replicate some of the disks, type the path of the disks, separated with a comma (for example, ...
The AWS Replication Agent was successfully installed.

초기 복제 확인하기

에이전트 설치 후 초기 복제가 시작되면 콘솔의 대시보드에 다음과 같이 표시됩니다.

위 대시보드의 1 server, 100%는 등록된 서버 중 해당 상태인 서버의 비율이며, 초기 복제의 진행률은 아닙니다.

MGN 콘솔에서 소스 서버의 Data replication status를 확인합니다. 처음에는 Initial sync 등이 표시되고, 초기 복제가 끝나면 Healthy 상태로 변경됩니다.

테스트 인스턴스를 실행하기 전에는 다음 상태인지 확인합니다.

• Migration lifecycle: Ready for testing
• Data replication status: Healthy
• Next step: Launch test instance

초기 복제에 걸리는 시간은 디스크의 데이터 양과 네트워크 대역폭 등에 따라 달라집니다.

EC2 실행 설정 확인하기

소스 서버의 Launch settings에서 테스트 인스턴스가 실행될 VPC와 서브넷, 인스턴스 유형과 보안 그룹을 확인합니다. 복제 데이터를 어느 환경에서 어떤 EC2 구성으로 실행할지는 복제 설정과 별도로 관리됩니다.

이번 테스트에서는 SSH와 웹 페이지를 확인할 수 있도록 테스트 인스턴스의 보안 그룹에 다음 통신만 허용합니다.

• TCP 22: 현재 접속 중인 공인 IP 주소
• TCP 80: 현재 접속 중인 공인 IP 주소

EC2를 인터넷에서 직접 확인하려면 인터넷 게이트웨이로 향하는 경로가 있는 퍼블릭 서브넷과 공인 IP도 필요합니다. 사설 서브넷에서 실행한다면 VPN, Session Manager 또는 별도의 접속 경로를 준비해야 합니다.

MGN은 EC2 Launch Template의 default 버전만을 사용하기 때문에 설정을 변경하더라도 default 버전이 아니라면 적용되지 않습니다.

또한 Instance type right-sizing이 켜져 있으면 EC2 Launch Template에 지정한 인스턴스 유형보다 MGN이 선택한 값이 우선합니다.

위 화면의 Public IP: No는 공인 IP 자동 할당이 꺼진 상태입니다. 이번 실습처럼 공인 IP로 직접 접속하려면 EC2 Launch Template의 네트워크 인터페이스에서 Auto-assign public IP를 Enable로 설정하고, 변경한 버전을 default로 지정한 뒤 테스트 인스턴스를 실행합니다.

테스트 인스턴스 실행하기

Source servers에서 대상 서버를 선택하고 Test and cutover 메뉴에서 Launch test instances를 실행합니다.

이 과정에서는 복제된 데이터를 기준으로 스냅샷과 변환 작업이 진행되고 EC2 테스트 인스턴스가 생성됩니다.
EC2 콘솔에서 인스턴스가 실행 중이며 상태 검사를 통과했는지 확인한 뒤, Windows PowerShell에서 SSH로 접속합니다.
이번에는 포트 포워딩을 거치지 않고 EC2 공인 IP의 기본 SSH 포트인 22번으로 접속합니다.

$mgnSshKeyPath = '<private-key-path>'
ssh -o IdentitiesOnly=yes -o PreferredAuthentications=publickey -i $mgnSshKeyPath '<source-user>@<test-instance-public-ip>'

<private-key-path>는 원본 VM 접속에 사용한 Windows의 개인 키 파일 전체 경로로, <source-user>는 Ubuntu 계정명으로 바꿉니다. <test-instance-public-ip>에는 이번에 생성된 EC2의 공인 IP를 입력합니다.

접속 후 Nginx와 디스크 상태를 확인합니다.

sudo systemctl is-active nginx
curl http://127.0.0.1
lsblk

웹 브라우저에서도 테스트 인스턴스의 공인 IP로 접속해 다음 내용이 표시되는지 확인합니다.

여기까지 확인하면 VirtualBox의 VM 디스크가 AWS로 복제되었고, EC2에서 부팅 가능한 형태로 변환되었다는 것을 확인할 수 있습니다.

변경분도 복제되는지 확인하기

MGN의 지속 복제를 확인하기 위해 원본 VirtualBox VM의 페이지를 변경합니다.

# 원본 VM의 파일을 변경합니다.
echo 'MGN test page - version 2' | sudo tee /var/www/html/index.html
curl http://127.0.0.1

MGN 콘솔에서 Data replication status가 Healthy인지 확인하고, 소스 서버의 Migration dashboard에서 Lag와 Backlog가 없는지도 확인합니다. 작은 변경은 Healthy가 유지된 채 복제될 수 있으므로, 다른 상태로 바뀌었다가 돌아오는 것을 기다릴 필요는 없습니다.

이미 실행해둔 첫 번째 테스트 인스턴스에도 다시 접속해 페이지가 version 1로 남아 있는지 확인합니다. 새로운 변경분은 테스트 인스턴스가 아니라 스테이징 영역으로 전송되기 때문입니다.

첫 번째 테스트를 Ready for testing 상태로 되돌리면서 기존 테스트 인스턴스를 종료한 뒤, 새로운 테스트 인스턴스를 실행합니다.

공인 IP가 달라질 수 있으므로 EC2 콘솔에서 새 인스턴스의 주소를 확인하고 접속합니다. 두 번째 테스트 인스턴스에서 다음 내용이 표시되는지 확인합니다.

테스트 리소스 정리하기

테스트가 끝났다면 먼저 MGN 콘솔에서 테스트 상태를 되돌리고, 테스트 인스턴스를 종료하는 옵션을 선택합니다. EC2 콘솔에서도 테스트 인스턴스가 남아 있지 않은지 확인합니다.

이후 Source servers에서 해당 서버를 선택하고 Disconnect from service를 실행하면 복제가 중지됩니다. 원본 VM을 켜두고 AWS와 통신할 수 있게 유지하면 에이전트가 제거 명령을 받습니다. 연결 해제는 실행된 테스트 인스턴스를 자동으로 종료하지 않으므로 앞 단계에서 별도로 정리해야 합니다.

복제용 리소스는 비동기로 정리되며, 공식 API 문서에서는 서비스 연결 해제 후 90분 이내에 삭제된다고 안내합니다. 정리가 진행된 뒤 스테이징용 Replication Server와 EBS 볼륨, 스냅샷 등이 남아 있는지 확인합니다.

더 사용할 계획이 없다면 실습용으로 새로 만든 MgnVirtualBoxAgentInstall 역할과 작업자에게 추가한 해당 역할의 AssumeRole 권한도 정리합니다. 기존 VPC나 보안 그룹처럼 테스트 전부터 사용하던 리소스는 유지합니다.

MGN이 생성한 EC2 인스턴스 구분하기

복제와 테스트를 진행하는 동안 EC2 콘솔에는 직접 실행한 테스트 인스턴스 외에도 MGN이 관리하는 인스턴스가 표시됩니다. 이번 실습에서도 AWS Application Migration Service Replication Server와 AWS Application Migration Service Conversion Server라는 이름의 인스턴스를 확인할 수 있습니다.

Replication Server는 소스 VM에서 전송된 블록 데이터를 받아 스테이징 영역의 스토리지에 기록합니다. Replication template에서 지정한 서브넷과 인스턴스 유형, 보안 그룹 등의 설정이 이 서버에 적용됩니다.

Conversion Server는 Test 또는 Cutover 인스턴스를 실행하는 과정에서 복제된 부팅 디스크를 EC2에서 부팅할 수 있도록 변환하는 임시 서버입니다. Replication Server와 같은 보안 그룹을 사용하며 MGN이 자동으로 관리하므로, 두 서버 모두 직접 접속하거나 중지하지 않습니다.

실제로 확인할 대상은 MGN의 Migration dashboard에서 View in EC2 console로 연결되는 Test instance입니다. 소스 서버의 Launch settings와 EC2 Launch Template은 이 Test instance와 이후의 Cutover instance에 적용됩니다.

참고: Test instance와 Cutover instance의 차이

Launch test instances와 Launch cutover instances는 모두 최신 복제 데이터를 기준으로 스냅샷과 변환 작업을 거쳐 EC2를 실행합니다. 같은 Launch settings를 사용한다는 점도 같지만, MGN에서 사용하는 목적과 이후 처리가 다릅니다.

따라서 Test instance에서 확인이 끝났다고 그 인스턴스를 그대로 운영용으로 바꾸는 것은 아닙니다. Launch cutover instances를 실행하면 기존 Test instance와 그에 종속된 리소스가 삭제되고, 원본의 복제 데이터를 바탕으로 새로운 Cutover instance가 생성됩니다. Test instance에서만 변경한 내용은 Cutover instance에 이어지지 않습니다.

이번 실습에서는 Cutover를 실행하지 않지만, 실제로 진행한다면 앞에서 수행한 Disconnect from service 대신 다음 흐름으로 전환합니다.

Test instance 검증
→ Mark as "Ready for cutover"
→ 원본 애플리케이션의 쓰기 중지
→ Healthy 상태와 Lag·Backlog 확인
→ Launch cutover instances
→ Cutover instance 접속 및 애플리케이션 검증
→ DNS·로드 밸런서 등 트래픽 경로 전환
→ 전환된 경로에서 서비스 동작 확인
→ Finalize cutover

MGN이 원본 애플리케이션의 쓰기 중지나 트래픽 전환까지 자동으로 처리하지는 않습니다. 원본의 쓰기를 중지하고 마지막 변경분이 복제되었는지 확인한 뒤 Cutover instance를 실행해야 합니다. 이후 환경에 맞게 DNS나 로드 밸런서 설정 등을 변경하고, 실제 요청이 새 인스턴스에서 정상적으로 처리되는지 확인합니다.

서비스 전환까지 검증한 뒤 Finalize cutover를 실행하면 데이터 복제가 중지되고 Replication Server와 스테이징 스토리지 등 복제용 리소스가 정리됩니다. Cutover instance 자체는 종료되지 않으며, 이후 운영 인스턴스로 계속 사용할 수 있습니다.

마무리

Oracle VirtualBox는 MGN의 에이전트리스 복제 대상은 아니지만, 지원되는 게스트 OS에 AWS Replication Agent를 설치하는 방식으로 MGN의 주요 흐름을 테스트할 수 있습니다.

이번 구성에서는 초기 복제와 EC2 테스트 실행, 원본에서 발생한 변경분을 반영한 재실행까지 확인했습니다. 작은 VM을 이용하더라도 MGN이 데이터를 어떻게 복제하고 테스트 인스턴스를 만드는지 살펴볼 수 있습니다.

다만 실제 마이그레이션에서는 서버 한 대의 부팅 여부만 보는 것으로 끝나지 않습니다. 애플리케이션 간 의존 관계와 데이터 정합성, 네트워크, DNS, 인증서, 라이선스와 컷오버 후 운영까지 별도로 검증해야 합니다.

MGN을 이용한 서버 마이그레이션을 검토하고 계신 분들께 도움이 되었으면 합니다.

긴 글 읽어주셔서 감사합니다.

참고 자료

• MGN 소개: 서비스 개요 · 일반 FAQ · 명칭 변경 안내
• 지원 범위: 운영체제 · 에이전트리스 복제
• 에이전트 설치: 설치 요구 사항 · Linux 설치 절차
• 복제 환경: 초기 설정 · Replication template · 보안 그룹과 데이터 라우팅 · 네트워크 요구 사항 · 퍼블릭 서브넷과 인터넷 게이트웨이
• 설치용 인증: MGN 자격 증명 준비 · IAM 역할 생성 · STS AssumeRole · CloudShell에서 AWS CLI 사용
• 로컬 VM 접속: VirtualBox NAT와 포트 포워딩 · Ubuntu OpenSSH와 공개 키 인증
• EC2 실행 설정: Launch Template 세부 설정 · default 버전 적용
• 테스트와 컷오버: 테스트 인스턴스 실행 · Ready for cutover 전환 · 컷오버 인스턴스 실행 · 컷오버 완료 · Lag·Backlog 확인 · 대상 인스턴스 설정
• MGN 관리용 인스턴스: Replication Server와 Conversion Server
• 운영 전환: 컷오버 단계에서 고려할 사항
• MGN 요금 관련 FAQ
• 리소스 정리: 에이전트 제거 · DisconnectFromService