온프레미스 VM을 AWS로 옮길 때 확인해야 할 것들

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

온프레미스 환경을 AWS로 옮기려고 하면 어떤 마이그레이션 서비스를 써야 할지부터 고민하게 됩니다. 하지만 같은 마이그레이션이라도 서버의 OS와 애플리케이션을 통째로 옮기는 것과, 파일이나 데이터베이스만 옮기는 것은 다른 작업입니다.

온프레미스 환경은 계속 운영하면서 백업만 AWS에 보관하려는 경우도 있습니다. 그래서 서비스를 고르기 전에 무엇을 옮기고, 무엇을 남겨둘지부터 생각해보는 게 좋습니다.

이 글에서는 서버를 그대로 옮기는 경우부터 시작해, 데이터를 따로 옮기거나 온프레미스와 AWS를 함께 사용하는 경우까지 살펴보겠습니다. 각 상황에서 가능한 이전 방식과 별도의 마이그레이션 서비스가 도움이 되는 경우를 설명하고, 다운타임과 라이선스 이야기도 함께 짚어보겠습니다.

서버를 그대로 옮기고 싶다면

기존 OS와 애플리케이션 설정을 유지하고 싶다면 VM 이미지를 가져오는 방식을 생각해볼 수 있습니다. VM Import/Export에서는 가상화 환경에서 VM 이미지를 내보내 S3에 업로드하고, AMI로 변환한 뒤 EC2를 기동합니다.

전용 테스트·컷오버 기능은 없지만, 변환한 AMI에서 EC2를 미리 기동해 사전 검증할 수 있습니다. AWS Backup에 저장된 VM 백업이 있다면, 이미지 파일을 직접 내보내 가져오는 대신 그 백업을 EC2/EBS로 복원하는 경로도 있습니다.

이때 복원할 대상이 VM 전체인지 데이터 디스크만인지도 구분해야 합니다. AWS Backup에서 인스턴스로 복원하면 OS를 포함한 VM 전체를 EC2로 옮기므로 부팅 가능 여부를 확인해야 합니다. VMware Tools는 복원 과정에서 관련 폴더가 자동으로 제외되므로 필요하면 복원 후 다시 설치해야 합니다.

반면 데이터 디스크(비부팅 디스크)만 EBS로 복원해 별도 인스턴스에 연결하는 볼륨 복원에서는 원본 OS의 부팅 가능 여부를 신경 쓰지 않아도 됩니다. 대신 연결할 인스턴스가 해당 파일시스템과 파티션 형식을 지원하는지는 확인해야 합니다.

옮기는 동안 바뀐 데이터는 어떻게 할까?

이미지나 백업을 바탕으로 복원하는 방식은 특정 시점의 서버 상태를 옮긴다는 공통점이 있습니다. 원본 서버를 계속 운영한다면, 이미지를 만든 뒤에 바뀐 데이터를 어떻게 반영할지도 함께 생각해야 합니다.

복원에 필요한 시간은 데이터 규모와 복원 방식에 따라 달라지므로, 사전 테스트로 확인하는 게 좋습니다. 정확한 수치는 확인하지 못했지만, 이런 구조에서는 백업 빈도를 높여도 복원 시간 자체가 크게 줄어들지는 않을 것으로 보입니다.

이전 중에 발생하는 변경분까지 계속 반영하려면, 이미지를 한 번 가져오는 것에서 더 나아가 지속적으로 복제하는 방식이 필요합니다. 이때 AWS Transform MGN(구 AWS Application Migration Service)을 사용할 수 있습니다. 에이전트 기반 방식에서는 원본 서버에 AWS Replication Agent를 설치하고 초기 동기화를 마친 뒤, 블록 레벨 변경분을 스테이징 영역으로 지속 복제하면서 테스트와 컷오버를 준비합니다.

초기 동기화가 끝나면 원본 서버를 중단하지 않고 테스트 인스턴스를 띄워 반복 검증할 수 있습니다. 테스트 중에도 스테이징 영역으로의 변경분 복제는 계속됩니다. 다만 원본 서버당 동시 작업은 1개로 제한됩니다.

테스트와 컷오버에 사용할 EC2의 서브넷과 인스턴스 유형 등은 Launch settings에서 별도로 설정해야 합니다. 서버 데이터를 복제하는 것과 AWS에서 어떤 환경으로 기동할지 정하는 것은 별개인 셈입니다.

그렇다고 지속 복제가 곧 무중단 전환을 뜻하는 것은 아닙니다. 컷오버 전에는 원본 서버의 운영 서비스를 중지해 새로운 데이터 변경을 막고, 복제 지연이 0인지 확인해야 합니다.

마지막 변경분을 반영하는 데 걸리는 시간은 미반영 데이터 양과 네트워크·스토리지 성능에 따라 달라집니다. 컷오버 시점에는 최신 복제 데이터를 기반으로 새 인스턴스를 기동하므로, 실제 전환에는 인스턴스 기동·접속 확인·애플리케이션 검증 시간도 별도로 필요합니다.

참고로 지원되는 VMware vCenter 환경에서는 개별 VM에 에이전트를 설치하지 않는 에이전트리스 방식도 제공됩니다. 이 경우에도 별도의 MGN vCenter Client가 필요하며, 스냅샷 전송 방식이므로 최신 스냅샷을 기다리는 과정에서 컷오버 시간이 더 길어질 수 있습니다.

물론 기존 OS를 반드시 그대로 옮겨야 하는 것은 아닙니다. AWS에 새 서버를 구축하고 애플리케이션을 설치한 뒤, 필요한 데이터만 옮기는 방법도 있습니다. 기존 설정을 다시 구성하고 검증해야 하지만, 더 이상 필요하지 않은 구성까지 함께 가져오지 않고 새 환경을 정리할 기회가 됩니다.

지원되는 마이그레이션 경로 자체가 없는 EOL OS라면 이런 신규 구축 방식이 사실상 필요합니다. 다만 MGN에는 지원되는 Windows Server 버전을 업그레이드하는 사전 정의 작업도 있으므로, 버전업이 있다고 무조건 신규 구축이 필요한 것은 아닙니다.

이미지를 옮기면 라이선스도 그대로 따라올까?

이미지를 정상적으로 기동했다고 해서 확인이 끝난 것은 아닙니다. VM 이미지를 그대로 옮긴다고 해서 기존 라이선스까지 같은 조건으로 사용할 수 있는 것은 아닙니다.

기존에 보유한 라이선스를 가져와 사용하는 방식을 BYOL(Bring Your Own License)이라고 합니다. 이미지 이전만으로 BYOL이 보장되는 것은 아니므로, 제품별 계약 조건과 마이그레이션 경로의 라이선스 처리 방식을 함께 확인해야 합니다.

예를 들어 Windows Server 이미지를 VM Import/Export로 가져올 때 라이선스 옵션을 별도로 지정하지 않으면 AWS 라이선스(License Included)가 기본값입니다. 기존 이미지를 사용하더라도, 라이선스는 원본과 다른 방식으로 적용될 수 있는 것입니다.

기존 Windows Server 라이선스를 사용하려면 BYOL 자격 조건과 배포 환경에 대한 제약을 따로 확인해야 합니다. Windows만의 이야기도 아니어서, VM Import/Export로 RHEL·SUSE 이미지를 가져올 때는 각 배포판의 BYOS(Bring Your Own Subscription) 조건을 확인해야 합니다.

파일만 옮긴다면

서버를 새로 구축하기로 했거나 기존 OS까지 옮길 필요가 없다면, 데이터만 따로 이전하는 방법으로 범위를 좁힐 수 있습니다. 일반 파일이라면 먼저 원본과 대상 사이에서 직접 복사할 수 있는지 생각해볼 수 있습니다. 예를 들어 대상 EC2에 SSH로 접속할 수 있는 환경에서는 SCP 같은 도구로 파일을 전송할 수 있습니다.

두 서버를 직접 연결하기 어렵다면 S3를 중간 저장소로 사용하는 방법도 있습니다. 원본에서 S3에 업로드한 뒤 대상 EC2에서 다운로드하는 방식입니다. 양쪽 서버가 각각 S3에 접근할 수 있다면 서로 직접 접속하지 않아도 되고, 업로드와 다운로드 시점을 나누어 진행할 수도 있습니다. 최종 보관 위치가 S3라면 다시 다운로드할 필요 없이 업로드에서 끝납니다.

AWS CLI 같은 도구로 이 작업을 수행할 수 있지만, S3가 중간에 있다고 해서 이전 과정 전체가 자동화되는 것은 아닙니다. EC2까지 옮기는 경우에는 업로드와 다운로드 두 단계를 관리해야 하고, 중간에 보관한 파일의 접근 권한과 보관 기간도 정해야 합니다. 직접 복사하는 경우와 마찬가지로 누락된 파일이 없는지, 대상에서도 필요한 소유권과 권한이 적용되는지는 확인해야 합니다.

이런 전송을 반복하거나 일정·대역폭·검증을 함께 관리해야 한다면 AWS DataSync를 검토할 수 있습니다. 온프레미스 스토리지와 Amazon S3, EFS, FSx 사이에서 데이터를 온라인으로 전송하며, 체크섬으로 전송 데이터의 무결성을 검증합니다. 온프레미스에 에이전트를 배포하는 준비는 필요하지만, 전송 일정과 대역폭 제한 등을 설정해 작업을 관리할 수 있습니다.

DataSync가 위치 간 데이터를 전송하는 구간은 TLS로 암호화됩니다. 다만 원본 스토리지에서 데이터를 읽거나 대상 스토리지에 쓰는 구간의 보호 방식은 각 스토리지의 프로토콜과 설정에 따라 달라집니다.

어느 방식을 선택하든 원본 파일이 계속 바뀐다면 마지막 변경분을 어떻게 반영할지 정해야 합니다. 대부분의 파일을 먼저 옮겨두고 전환 시점에 애플리케이션의 쓰기를 잠시 멈춘 뒤 마지막으로 동기화하는 식입니다. 한 번 복사하면 끝나는지, 반복 전송과 검증까지 필요한지를 먼저 판단하면 직접 복사나 S3 경유로 충분한지, DataSync가 도움이 될지 결정하기가 쉬워집니다.

데이터베이스를 옮긴다면

데이터베이스도 처음부터 전용 마이그레이션 서비스를 선택해야 하는 것은 아닙니다. 같은 DB 엔진으로 옮긴다면 엔진이 제공하는 덤프나 백업을 만들고, 대상에 전송해 복원하는 방법부터 검토할 수 있습니다. 예를 들어 PostgreSQL은 pg_dump로 논리 백업을 만든 뒤 대상에 복원할 수 있습니다. 백업 파일은 앞서 설명한 것처럼 직접 전송하거나 S3를 거쳐 옮길 수 있으며, 대상 엔진과 버전에서 복원 가능한 형식인지는 확인해야 합니다.

다만 백업을 만드는 동안 DB를 계속 운영할 수 있다는 것과, 데이터 누락 없이 새 DB로 전환할 수 있다는 것은 다른 이야기입니다. pg_dump는 실행 시작 시점의 일관된 데이터를 담지만, 그 이후 변경분까지 자동으로 따라오지는 않습니다. 백업 시점 이후의 쓰기를 제한하거나 변경분을 별도로 반영해야 하므로, 전송·복원·검증에 필요한 시간과 허용 가능한 중단 시간을 함께 봐야 합니다.

이 시간을 그대로 감당하기 어렵다면 먼저 전체 데이터를 옮겨두고 변경분을 계속 반영하는 방식으로 접근할 수 있습니다. SQL Server를 유지하는 경우에는 라이선스 조건을 확인해 새 OS에 SQL Server를 설치하고, 전체 백업을 복원한 뒤 트랜잭션 로그 백업을 지속적으로 전송·복원하는 로그 시핑을 검토할 수 있습니다. 컷오버 시점에 적용할 변경분을 줄여 다운타임을 줄이는 방식입니다.

AWS Database Migration Service(DMS)도 초기 데이터와 이후 변경분을 옮기는 선택지입니다. 지원되는 소스와 대상 조합에서 전체 로드와 CDC(변경 데이터 캡처)를 이용할 수 있어, 운영 DB를 RDS/Aurora 같은 매니지드 DB로 옮길 때도 활용할 수 있습니다. 로그 백업을 전송·복원하는 로그 시핑과 달리, DMS CDC는 원본의 변경 내용을 읽어 대상에 반영합니다.

데이터를 계속 반영할 수 있더라도 마지막 전환 시점에는 쓰기를 정리하고 반영 상태를 확인해야 합니다. 기존 백업·복원 절차로 허용된 시간 안에 이전할 수 있다면 그 방식을 활용하고, 중단 시간을 줄여야 한다면 엔진의 복제 기능이나 로그 시핑, DMS 같은 방식을 비교해보는 게 좋습니다.

여기까지가 데이터를 옮기는 문제라면, Oracle에서 PostgreSQL로 옮기는 것 같은 이기종 마이그레이션에서는 구조와 동작을 바꾸는 문제도 추가됩니다. 스키마 변환이 필요하고, 규칙 기반 변환에 생성형 AI를 보조로 붙이더라도 100% 자동 변환을 기대하기는 아직 어렵습니다. 데이터가 모두 도착했는지뿐 아니라 애플리케이션 쿼리가 같은 결과를 내는지까지 함께 검증해야 합니다.

온프레미스 환경을 계속 운영한다면

지금까지는 서버나 데이터를 AWS로 옮기는 경우를 살펴봤습니다. 하지만 온프레미스 환경을 그대로 운영하면서 백업만 클라우드에 보관하거나, 필요한 스토리지만 AWS와 연결하려는 경우도 있습니다.

백업 파일을 다른 장소에 보관하는 것이 목적이라면, 기존 백업 도구로 만든 파일을 S3에 업로드하는 방법부터 생각해볼 수 있습니다. 복구할 때는 해당 파일을 가져와 기존 도구와 호환되는 환경에서 복원합니다. 백업 일정과 보관 기간, 복구 검증은 기존 도구나 운영 절차로 관리해야 하며, VM 백업 파일을 S3에 보관했다고 해서 곧바로 EC2로 복원할 수 있는 것은 아닙니다. 파일의 보관 위치와 복원 방법은 별개입니다.

VMware 환경의 백업 작업과 정책을 AWS Backup에서 관리하고 싶다면 Backup Gateway를 사용할 수 있습니다. vCenter에 가상 어플라이언스를 배포하면 VM을 검색하고 데이터를 암호화해 AWS Backup으로 보냅니다. vSphere 6.7/7.0/8을 지원하며, 앞서 설명한 것처럼 이 백업을 EC2로 복원해 이전에 활용할 수도 있습니다. 기존 백업 파일을 보관하는 것과, AWS Backup으로 백업 작업을 관리하는 것의 차이라고 보면 됩니다.

반면 백업 보관이 아니라 온프레미스 애플리케이션이 AWS의 파일 스토리지를 계속 사용해야 한다면 연결 방식부터 달라집니다. 예를 들어 온프레미스 Linux 서버에서 Site-to-Site VPN이나 Direct Connect를 통해 VPC에 연결하고 EFS를 NFS로 마운트하는 방법이 있습니다. 별도의 스토리지 게이트웨이 없이 파일시스템에 접근하는 구성이지만, 애플리케이션이 원격 스토리지의 지연과 네트워크 연결에 영향을 받는다는 점을 고려해야 합니다.

기존 파일 공유나 테이프·블록 스토리지 인터페이스를 활용하면서 로컬 캐시도 두고 싶다면 AWS Storage Gateway를 검토할 수 있습니다. 파일을 위한 S3 File Gateway, 테이프를 위한 Tape Gateway, 블록 스토리지를 위한 Volume Gateway가 있으며, VMware, Hyper-V, KVM 또는 EC2에 가상 게이트웨이를 배포할 수 있습니다. AWS 스토리지에 직접 연결할지, 게이트웨이를 사이에 둘지는 애플리케이션이 사용하는 인터페이스와 로컬 캐시의 필요성에 따라 달라집니다.

네트워크로 옮기기 어렵다면

데이터가 많다고 해서 바로 물리 운반이 필요한 것은 아닙니다. 초기 데이터를 미리 나누어 전송하고 마지막에 변경분만 반영할 수 있는지, 업무 외 시간에 전송량을 늘릴 여지가 있는지부터 살펴볼 수 있습니다. 일회성 이전이 아니라 이후에도 온프레미스와 AWS 사이에 많은 데이터를 주고받아야 한다면 Direct Connect 같은 네트워크 연결도 검토할 수 있습니다. 다만 회선을 준비하는 시간과 대역폭, 비용을 함께 고려해야 합니다.

이렇게 조정해도 온라인 전송이 일정 안에 끝나기 어렵다면, 물리적으로 데이터를 운반하는 방법을 생각해볼 수 있습니다. 다만 과거에 사용하던 서비스를 지금도 그대로 선택할 수 있는 것은 아닙니다.

AWS Snowball은 2025년 11월 7일부터 신규 고객 이용이 중단되었고, 2026년 12월 31일에는 전체 커머셜 리전에서 서비스가 종료될 예정입니다. 신규로 물리 전송이 필요하다면 다른 대안을 검토해야 합니다.

이 경우 AWS Data Transfer Terminal이 대안 중 하나입니다. 다만 디바이스를 배송받는 방식이 아니라, 데이터를 담은 장치를 LA·뉴욕·뮌헨 같은 지정된 장소로 직접 가져가 100Gbps급 회선으로 전송하는 방식입니다.

현재는 AWS Enterprise Support 고객만 이용할 수 있으며, 국내에서 자주 활용하기에는 물리적 접근성에도 제약이 있습니다. 페타바이트급 데이터나 네트워크 대역폭이 근본적으로 부족한 환경에서는 검토할 수 있지만, 제공 위치와 이용 자격이 맞는지 먼저 확인해야 합니다.

여기서 물리 전송 수단은 어디까지나 데이터를 옮기는 방법이라는 점도 구분해야 합니다. 앞서 다룬 MGN의 에이전트 기반 방식은 네트워크를 통해 블록 레벨 복제를 지속하므로, Snowball처럼 오프라인으로 데이터를 운반하는 수단으로 이 복제 경로를 대체할 수는 없습니다.

마무리하며

같은 대상을 옮기더라도 방법은 하나가 아닙니다. 파일을 직접 복사하거나 S3를 거쳐 옮길 수도 있고, DB의 기존 백업·복원 기능만으로 이전할 수도 있습니다. 중요한 것은 특정 서비스를 사용하는지보다, 옮기는 동안 바뀐 데이터와 실제 전환에 필요한 시간을 어떻게 다루는지라고 생각합니다.

먼저 단순 복사나 복원으로 충분한지 판단하고, 지속적인 변경분 반영이나 반복 작업의 관리가 필요할 때 그에 맞는 서비스를 선택하면 됩니다. 하나의 환경 안에서도 서버와 파일, DB가 각각 다른 방식으로 옮겨질 수 있고, 옮긴 뒤의 검증은 어느 방식에서든 필요합니다.

특히 이미지를 그대로 옮겼다고 해서 기존 라이선스까지 같은 조건으로 사용할 수 있는 것은 아닙니다. 마이그레이션 방식을 고를 때는 기술적인 이전 가능 여부와 라이선스 조건을 따로 확인해두는 게 좋다고 생각합니다.

이번 글이 마이그레이션 방식을 검토할 때 참고가 되었으면 합니다. 각 서비스의 세부 설정이나 실제 마이그레이션 절차는 다음 글에서 다뤄보겠습니다.

참고 자료

• VM Import/Export: 이미지 가져오기 · 라이선스 고려사항 · 라이선스 옵션 지정
• MGN 이전 절차: 이전 흐름 · 컷오버 전 조치 · 컷오버 가이드 · 복제 지연과 오류
• MGN 설정과 지원 방식: 대상 인스턴스 설정 · 에이전트리스 복제 · 일반 FAQ와 명칭 변경 · 사전 정의 작업과 Windows 업그레이드
• AWS Microsoft 라이선스 FAQ
• AWS Backup: 서비스 개요와 백업 정책 · VM 복원 · 게이트웨이 인프라 구성
• 파일 전송: SCP · AWS CLI의 S3 업로드·다운로드 · AWS DataSync
• DataSync의 전송 보호: 전송 중 암호화 · 데이터 무결성 검증
• PostgreSQL 덤프와 복원
• AWS DMS: 서비스 소개 · CDC · 전환 절차 예시
• SQL Server 로그 시핑을 이용한 마이그레이션
• 하이브리드 스토리지: EFS 연결 구조 · AWS Storage Gateway
• AWS Direct Connect 개요
• AWS Snowball
• AWS Data Transfer Terminal이란?