마이그레이션 & 전송 서비스

마이그레이션 계획은 애플리케이션을 얼마나 바꿀 수 있는지와 이전 가능한 시간·대역폭에서 출발한다. 서버를 거의 그대로 옮기는 경우와 데이터베이스 엔진을 바꾸는 경우는 도구와 검증 방법이 다르다. 먼저 7R로 애플리케이션별 방향을 정하고, 그 다음 데이터·서버·파일 전송 경로를 고른다.

1. 7R 마이그레이션 전략

클라우드로 이전할 때 애플리케이션마다 전략이 다르다. AWS 마이그레이션 가이드는 워크로드 이전 방향을 일곱 가지 전략(7R)으로 분류한다.

전략 선택 기준

비용·속도 우선          → Rehost (가장 빠름, 최소 변경)
DB 운영 부담 줄이기     → Replatform (RDS, Aurora로 전환)
레거시 라이선스 문제    → Repurchase (SaaS 전환)
장기적 클라우드 최적화  → Refactor (가장 많은 노력, 최대 효과)
사용하지 않는 시스템    → Retire
규제·의존성 문제        → Retain

선택 기준: 빠른 이전이면 Rehost, VMware 인프라를 함께 옮기는 조건이면 Relocate, SaaS 전환이면 Repurchase를 검토한다. Refactor는 애플리케이션을 고쳐 쓰는 작업이 포함되어 이전 범위와 일정을 더 신중히 잡아야 한다.

2. 마이그레이션 탐색과 진행 관리

핵심 개념

AWS Migration Hub는 기존 고객의 진행 중인 프로젝트를 추적하는 서비스로, 2025년 11월부터 신규 고객 등록을 받지 않는다. 신규 마이그레이션 프로젝트의 검색·계획은 AWS Transform을 우선 검토하고, 기존 Migration Hub 사용자는 진행 중인 프로젝트를 계속 관리할 수 있다.

온프레미스 서버와 애플리케이션 정보 수집
  → AWS Transform의 검색·평가 기능 또는 지원되는 discovery 도구
    ├── 에이전트리스 탐색: 지원되는 가상화 환경의 인벤토리 수집
    └── 에이전트 기반 탐색: 서버별 상세 구성과 사용량 수집

수집된 데이터 → Migration Hub에서 시각화
  → 어떤 서버가 어떤 앱과 연결되어 있는지 의존성 맵
  → 기존 프로젝트는 Migration Hub에서 진행 추적

3. DMS (Database Migration Service)

핵심 개념

DMS는 데이터베이스를 AWS로 마이그레이션하는 서비스다. 원본 DB를 유지하면서 실시간으로 데이터를 복제할 수 있어 다운타임 최소화가 핵심이다.

소스 DB (온프레미스 / RDS / EC2)
  → DMS 복제 인스턴스 (Replication Instance)
    → 타겟 DB (RDS, Aurora, Redshift, DynamoDB 등)

마이그레이션 유형

[Full Load + CDC 흐름]
1. 초기 전체 데이터 복사 (몇 시간 ~ 며칠)
2. 복사 완료 후 CDC로 실시간 동기화
3. 원본·타겟 데이터 일치 확인
4. 애플리케이션 연결 전환 (짧은 다운타임)
5. 원본 DB 폐기

동종 vs 이기종 마이그레이션

동종 (Homogeneous): MySQL → MySQL, Oracle → Oracle

• DMS로 직접 마이그레이션

이기종 (Heterogeneous): Oracle → Aurora, SQL Server → MySQL

1단계: AWS SCT (Schema Conversion Tool)
        → 스키마·저장 프로시저·함수 자동 변환
2단계: DMS
        → 데이터 복제

SAP 핵심: 이기종 DB 마이그레이션 = SCT(스키마 변환) + DMS(데이터 이전)

소스 & 타겟 지원

소스: Oracle, SQL Server, MySQL, PostgreSQL, MongoDB, SAP, IBM DB2, Azure SQL 등

타겟: RDS, Aurora, Redshift, DynamoDB, S3, OpenSearch, Kafka, DocumentDB 등

DMS 고가용성

단일 AZ 복제 인스턴스: 테스트·개발용
Multi-AZ 복제 인스턴스: 프로덕션 (자동 장애 조치)

4. 서버 이전: AWS Transform MGN

핵심 개념

AWS Server Migration Service(SMS)는 2023년에 지원이 종료된 레거시 서비스다. 신규 서버 리호스팅에서는 2026년 6월 AWS Application Migration Service에서 이름이 바뀐 AWS Transform MGN을 우선 검토한다.

소스 서버에 AWS Replication Agent 설치
  → 블록 레벨 지속 복제 (네트워크로 실시간 동기화)
    → 스테이징 영역 (저비용 EC2)에서 지속 업데이트
      → 컷오버 시점에 프로덕션 EC2로 전환
        → 다운타임: 분 단위

AWS Transform MGN은 원본 서버에 복제 에이전트를 설치해 블록 변경분을 지속적으로 복제한다. 컷오버 전에 테스트 인스턴스를 실행해 애플리케이션을 검증하고, 최종 전환 절차와 허용 중단 시간을 계획한다. 실제 RTO는 환경과 테스트 결과에 따라 달라진다.

5. 데이터 전송 서비스

대용량 데이터를 AWS로 이전할 때 네트워크 한계를 극복하는 방법이 중요하다.

전송 방법 선택 기준

전송 데이터량 / 가용 네트워크 대역폭 = 전송 소요 일수

예: 100TB / 100Mbps = 약 90일 소요
→ 네트워크 전송 비현실적 → 실제 데이터 반입 경로와 AWS Data Transfer Terminal 이용 가능 여부 확인

이 계산은 이상적인 전송률 기준이다. 프로토콜 오버헤드와 회선 사용률, 재시도 시간을 고려해 실제 측정값으로 일정을 잡는다. Snow Family 장비는 신규 고객에게 제공되지 않으므로 예전 시험 자료의 장비 추천을 그대로 현재 배포 계획에 적용하지 않는다.

6. 대용량 데이터 이전과 Snow 장비의 제공 상태

2026년 9월 기준, AWS Snowball Edge는 신규 고객이 주문할 수 없고 기존 고객만 계속 이용할 수 있다. Snowcone 주문도 종료됐으며, Snowmobile은 2024년에 서비스 목록에서 내려갔다. 기존 상용 리전 Snowball Edge 지원은 2026년 12월 31일 종료 예정이므로 실제 계획에서는 AWS 공지의 최신 상태를 확인한다.

신규 데이터 이전은 네트워크가 허용되면 DataSync나 Direct Connect를 검토한다. 물리적 반입이 필요한 경우 AWS Data Transfer Terminal은 저장 장치를 직접 가져와 AWS 네트워크에 연결하는 방식이다. 현재 Enterprise Support 고객만 사용할 수 있고, 시설 위치와 예약 가능 여부도 먼저 확인해야 한다. 단절된 현장의 엣지 컴퓨팅은 Outposts나 AWS 파트너 대안을 비교한다.

Snowball Edge를 이미 사용할 수 있는 고객은 서비스 종료 일정과 대체 계획을 함께 검토한다. 예전의 Snowcone·Snowmobile 용량 숫자는 현재 신규 고객의 선택 기준으로 사용하지 않는다.

7. DataSync

핵심 개념

DataSync는 온프레미스 ↔ AWS 간 파일 데이터 자동 동기화 서비스다. NFS, SMB 파일 서버의 데이터를 S3, EFS, FSx로 전송한다.

온프레미스 NFS/SMB 서버
  → DataSync Agent (온프레미스 VM 설치)
    → AWS DataSync (관리형)
      → S3 / EFS / FSx for Windows / FSx for Lustre

주요 특징

• 자동 암호화·검증 (전송 중 무결성 확인)
• 대역폭 제한 설정 (업무 시간 중 제한)
• 일정 기반 또는 온디맨드 동기화
• 권한·타임스탬프·메타데이터 보존

DataSync와 물리적 반입 경로 비교

Storage Gateway와의 차이

• DataSync: 대량 일괄 마이그레이션 및 주기적 동기화
• Storage Gateway: 온프레미스 앱이 AWS 스토리지를 로컬처럼 사용 (지속 연결)

8. Transfer Family

핵심 개념

Transfer Family는 기존 파일 전송 프로토콜(SFTP, FTPS, FTP, AS2)을 그대로 사용하면서 S3 또는 EFS에 파일을 저장하는 서비스다.

파트너 / 외부 시스템
  → SFTP / FTPS / FTP / AS2 프로토콜
    → AWS Transfer Family (관리형 엔드포인트)
      → S3 or EFS

사용 시나리오

• 레거시 EDI 시스템이 AS2로 파일 교환
• 파트너사가 SFTP로 파일 업로드 (코드 변경 없이)
• FTP 서버를 AWS로 마이그레이션 (클라이언트 설정 변경 불필요)

인증 방식

• 서비스 관리형: Transfer Family 내부 사용자 관리
• 디렉터리 서비스: Active Directory 연동
• 커스텀 ID 공급자: Lambda + API Gateway로 인증 로직 구현

9. 마이그레이션 시나리오별 선택

시나리오 1: 대규모 온프레미스 서버 → EC2

현황: VMware 기반 500대 서버
전략: Rehost (Lift & Shift)
도구: Application Discovery Service → Migration Hub 추적
      AWS Transform MGN (서버별 복제 + 컷오버)

시나리오 2: Oracle DB → Aurora PostgreSQL

현황: 온프레미스 Oracle, 5TB
전략: Replatform
도구: SCT (스키마·프로시저 변환)
      DMS Full Load + CDC (다운타임 최소화)

시나리오 3: 데이터센터 80TB 파일 → S3

현황: NFS 파일 서버 80TB, 1Gbps 전용선
계산: 80TB / 1Gbps ≈ 약 7일 (실제 효율 50% 가정 시 14일)
전략: DataSync (네트워크 전송, 메타데이터 보존)
      물리 반입이 필요하면 AWS Data Transfer Terminal 위치·지원 요건 확인

시나리오 4: 네트워크가 없는 원격 시설에서 대용량 데이터 반출

현황: 인터넷 연결이 없는 원격 시설
판단: 신규 Snow 장비 주문이 불가하므로 현장 네트워크 구축, 승인된 AWS 파트너,
      또는 데이터 보관·운송·반입 절차를 별도로 비교

시나리오 5: 파트너사 파일 수신 (SFTP 유지)

현황: 파트너사들이 SFTP로 파일 전송 중
목표: 파트너 코드 변경 없이 파일을 S3로 수집
도구: AWS Transfer Family (SFTP 엔드포인트 + S3 백엔드)

시나리오 6: 레거시 앱 + 신규 클라우드 혼재 (하이브리드)

현황: 일부 앱은 온프레미스 유지 필요, 일부는 AWS 이전
도구: Storage Gateway (온프레미스 앱 → AWS 스토리지 연동)
      Direct Connect (안정적 전용선)
      AWS Transform (신규 이전 계획) 또는 기존 Migration Hub 프로젝트

10. 핵심 암기 포인트

핵심 내용을 다시 정리하면

• 7R: Rehost → Relocate → Replatform → Repurchase → Refactor → Retire → Retain
• DMS: Full Load + CDC로 다운타임 최소화, 이기종 DB는 SCT 먼저
• AWS Transform MGN: 블록 레벨 복제로 서버를 이전하며, 컷오버 시간은 사전 테스트로 확인
• Snow 장비: 신규 고객 주문이 종료된 서비스. 기존 사용자는 지역별 종료 일정을 확인하고 대체 이전 경로를 계획
• DataSync: 온라인 파일 동기화, 메타데이터 보존, 스케줄 지원
• Transfer Family: 레거시 프로토콜(SFTP 등) 유지하며 S3/EFS 연동

공식 문서

• AWS migration strategies (7 Rs)
• AWS Transform MGN release notes
• AWS Migration Hub availability change
• AWS Snowball Edge availability change
• AWS Snow device availability update
• AWS services in full shutdown
• AWS Data Transfer Terminal

이어 읽기: 14. 온프레미스와 AWS를 잇는 하이브리드 아키텍처