Category: AWS Database Migration Service

AWS Schema Conversion Tool(AWS SCT) 및 AWS Database Migration Service(AWS DMS) 를 사용하여 상용 데이터베이스를 Amazon Aurora로 마이그레이션하는 작업을 간소화하는 방법에 대한 개요를 제공합니다. 특히, Oracle 에서 MySQL과 호환되는 Amazon Aurora 로의 마이그레이션에 중점을 둡니다.

원문은 AWS Database Blog의 How to Migrate Your Oracle Database to Amazon Aurora 입니다.

데이터베이스 엔진 변경은 매우 어려울 수 있습니다. 그러나 Amazon Aurora와 같이 확장성이 뛰어나고 비용 효율적이며 완벽하게 관리되는 서비스의 많은 장점으로 인해 그 도전은 가치가 있습니다. 프로세스를 단순화 할 수 있는 도구가 있는 경우 특히 그렇습니다. 특정 엔진에서 다른 엔진으로 데이트베이스를 마이그레이션 할 때, 고려해야 할 사항이 두 가지 있습니다. 스키마와 코드 개체의 변환, 그리고 데이터 자체의 마이그레이션과 변환 등입니다. 다행히 AWS 는 데이터베이스의 변환 및 마이그레이션을 용이하게 하는 도구를 제공합니다.

AWS Schema Conversion Tool 은 원본 데이터베이스 스키마와 대다수의 사용자 정의 코드를 대상 데이터베이스와 호환되는 형식으로 자동 변환해 줌으로써 이기종 데이터베이스 마이그레이션을 단순화 합니다. 이 도구에서 변환하는 사용자 지정 코드에는 뷰(views), 저장 프로시저(stored procedures) 및 함수(functions)가 포함됩니다. 도구에서 자동으로 변환할 수 없는 코드는 사용자가 직접 변환할 수 있도록 명확하게 표시됩니다. AWS Database Migration Service는 다운타임을 최소화하면서 쉽고 안전하게 데이터를 마이그레이션 할 수 있도록 지원합니다.

좋습니다! 그럼 어디서 부터 시작해야 할까요?

AWS SCT로 작업하기
일반적으로, 모든 마이그레이션의 첫 번째 단계는 실행 가능성과 그에 따른 노력을 평가하는 것입니다. AWS SCT를 사용하여 오라클 데이터베이스를 Aurora로 변환하는데 필요한 개괄적인 노력을 평가해 볼 수 있습니다. AWS SCT는 여러 운영체제에서 실행할 수 있습니다. 이 글의 목적을 위해 Windows 에서 이 도구를 실행해 보도록 하겠습니다. AWS SCT를 다운로드 하려면 AWS Schema Conversion Tool 문서의 설치 및 업데이트를 참조하십시오. AWS SCT에 대한 전체 설명서를 보려면, AWS Schema Conversion Tool 이란 무엇인가? 를 확인하십시오.

이 글은 AWS SCT의 설치 및 구성을 다루지는 않지만, SCT를 원본 및 대상 데이터베이스에 연결하기 위해 Oracle 및 MySQL용 드라이버를 설치하는 것이 중요합니다. 원본 데이터베이스인 Oracle에 연결 한 후, 주어진 스키마를 마우스 오른쪽 단추로 클릭하고 평가 보고서를 생성할 수 있습니다. 이 평가 보고서는 Oracle 에서 Aurora로 변환할 수 있는 스키마의 양과 변환 후 남은 수동 작업을 매우 높은 수준에서 알려줍니다. 다음은 평가 보고서의 예제입니다.

평가 보고서 외에도, SCT는 각 객체가 정확히 어떻게 변환되는지 알려줍니다. 객체를 변환할 수 없는 경우, SCT는 그 이유를 알려주고 상황을 해결할 수 있는 방법에 대한 힌트를 제공합니다.

스키마의 100%가 Oracle 에서 Aurora로 변환되지 않는 경우에는 다음가 같이 몇가지 방법으로 문제를 해결할 수 있습니다.

• SCT가 Aurora로 변환할 수 있도록 원본 Oracle 데이터베이스의 개체를 수정합니다.
• 스키마를 그대로 변환하고 Aurora 데이터베이스에 적용하기 전에 SCT가 생성한 스크립트를 수정하십시오.
• 변환할 수 없는 객체를 무시하고 대상 데이터베이스에서 수정하십시오. 예를 들어, Oracle 에서dbms_random 패키지를 호출하는 함수가 있다고 가정하십시오. 이 패키지는 Aurora에는 존재하지 않습니다. 이 문제를 해결하려면 다음을 수행하십시오.
  • 랜덤 값 생성을 애플리케이션 코드로 푸시하고 매개변수로 함수에 전달하십시오. 변환 전에 원본 데이터베이스에서 또는 변환 후에 대상 데이터베이스에 이 수정작업을 하도록 선택할 수 있습니다.
  • SCT가 생성한 코드를 수정하여 MySQL 에서 사용할 수 있는RAND()함수를 사용하고 Aurora 데이터베이스에 새 코드를 적용합니다.

다른 예로, Oracle 에서 시퀀스를 사용하여 일부 고유 식별자를 채우는 경우를 가정해 보십시오. Aurora는 시퀀스를 지원하지 않으므로 이것을 해결하기 위해서 다음과 같이 할 수 있습니다.

• Aurora의 자동 증가(auto-increment) 기능을 사용하여 고유한 식별자를 자동으로 채웁니다. 이 방법을 사용하는 경우 Aurora 데이터베이스에서 스키마를 작성한 후 대상 테이블을 수정하는 스크립트를 작성해야 할 수 있습니다.
• 고유한 식별자(함수 또는 유사한 것을 사용)를 생성하는 대체 방법을 만들고 시퀀스에 대한 참조를 새 함수로 바꿉니다. 변환 전에 Oracle 소스에서 또는 변환 후에 Aurora 데이터베이스에서 이 작업을 수행할 수 있습니다.
• 두가지 방법을 모두 사용해야 할 수도 있습니다.

일반적으로 마이그레이션 작업의 일부로 SCT를 사용하는 경우 다음과 같은 작업을 함께 진행하는 것이 좋은 방법입니다.

• SCT 평가 보고서를 작성하고 그것을 사용하여 변환 작업의 부족한 부분을 채우기 위한 계획을 수립하십시오. 마이그레이션 후보 시스템이 여러 개인 경우 SCT 평가 보고서를 사용하여 먼저 진행해야 할 시스템을 결정하십시오.
• 작업 항목을 검토하고 변환에 실패한 각 항목에 대한 적절한 해결책을 결정하십시오.
• 이 프로세스를 반복하여 AWS Database Migration Service와 함께 사용하여 새로운 스키마에 데이터를 로드하고 새로운 Aurora 데이터베이스에 대해 애플리케이션을 테스트 할 수 있습니다.

AWS DMS로 넘어가 보겠습니다!

AWS DMS로 작업하기
AWS DMS를 사용하여 Oracle 원본 데이터베이스의 데이터를 새로운 대상인 Aurora 데이터베이스로 로드 할 수 있습니다. DMS의 가장 큰 장점은 대량 데이터를 로드 하는 것 외에도 진행중인 트랜잭션을 캡처하여 적용한다는 것입니다. Oracle 원본과 Aurora 대상 데이터베이스는 이전 할 때까지 동기화되어 유지됩니다. 이 방법을 사용하면 마이그레이션을 완료하는 데 필요한 중단 시간을 크게 줄일 수 있습니다. 모든 DMS 마이그레이션에는 다음 요소가 포함됩니다. 원본 엔드 포인트, Oracle; 대상 엔드 포인트, Aurora; 복제 서버; 및 작업.

Oracle 에서 Aurora로 마이그레이션 할 때 기존 데이터를 마이그레이션하고 진행중인 변경 사항을 복제하도록 작업 구성하기를 원할 겁니다. 이렇게 하면 대량 데이터를 마이그레이션하는 동안 DMS가 트랜잭션을 캡처하도록 합니다. 대량 데이터를 로드 한 후 DMS는 캡처 된 트랜잭션을 적용하기 시작하여 Oracle 및 Aurora 데이터베이스를 동기화 합니다. Aurora로 전환된 준비가 되면 애플리케이션을 중지하고, DMS가 마지막 트랜잭션을 적용하도록 하고, 새로운 Aurora 데이터베이스를 가리키는 애플리케이션을 시작합니다.

DMS를 사용하여 Oracle 에서 Aurora로 마이그레이션 할 때 고려해야 할 몇 가지 사항이 있습니다.

Supplemental logging. DMS가 원본 Oracle 에서 변경사항을 캡처하려면 보충 로깅(supplemental logging) 기능을 사용해야 합니다. 자세한 지침은 DMS 설명서 에서 찾을 수 있습니다.

DMS의 3단계. DMS는 데이터를 마이그레이션하고 진행중인 변경 사항을 복제할 때 세 단계를 거칩니다.

• Bulk load:마이그레이션의 대량 로드(Bulk load) 단계에서 DMS는 한 번에 n개의 테이블을 개별적으로 로드 합니다. 디폴트로는 n=8 입니다. 이 값은 DMS 관리 콘솔 또는 AWS CLI를 사용하여 설정할 수 있습니다.
• Application of cached transactions:대량 로드 단계에서 DMS는 원본 데이터베이스에 대한 변경 내용을 캡처합니다. 테이블에 대한 대량 로드가 완료되면 DMS는 대량 로드의 일부인 것처럼 최대한 빨리 캐시된 변경 내용을 해당 테이블에 적용합니다.
• Transactional apply:모든 테이블에 대해 대량 로드가 완료되면 DMS는 캡처 된 변경 사항을 단일 테이블 업데이트가 아닌 트랜잭션으로 적용하기 시작합니다.

보조 색인(Secondary indexes). 경우에 따라 성능상의 이유로 대량 로드 단계에서 보조 인덱스를 제거 할 수 있습니다. 대량 로드 단계에서 보조 색인 일부 또는 전체를 제거하도록 선택하면 트랜잭션 적용 단계에서 마이그레이션을 일시 중지하고 다시 추가해야 합니다. 모든 테이블에 대해 전체 로드가 완료된 후 마이그레이션을 안전하게 일시 중지할 수 있습니다.

외래 키(Foreign keys), 트리거(triggers), 등. 대량 로드는 테이블 단위로 수행되기 때문에 마이그레이션의 대량 로드 및 캐시 된 트랜잭션 단계에서 대상 Aurora 데이터베이스의 외래 키 조건이 위반될 수 있습니다. 대상 Aurora 엔드 포인트 정의의 추가 연결 속성으로 다음을 추가하여 외래 키 점검을 불가능 하게 할 수 있습니다. initstmt=SET FOREIGN_KEY_CHECKS=0. 일반적으로 데이터의 대량 로드로 인해 혼란을 겪거나 부정적인 영향을 받을 수 있는 사항을 처리하기 위한 전략을 수립해야 합니다. 예를 들어, 문제가 발생하지 않도록 하려면 트리거 설치를 마이그레이션의 컷 오버 단계까지 연기 할 수 있습니다.

데이터 유형. 새로운 데이터베이스 엔진으로 마이그레이션 할 때, 지원되는 데이터 유형과, 원본 데이터 유형이 어떻게 새로운 대상 데이터 유형으로 변환되는 지를 이해하는 것은 중요합니다. 이 경우에는, DMS 설명서에 있는 Oracle 원본 데이터 유형과 Aurora 대상 데이터 유형을 확인해야 합니다

성능: 마이그레이션의 전체 성능은 원본 Oracle 데이터베이스의 데이터 양, 유형 및 분산에 따라 달라질 수 있습니다. 데이터베이스 마이그레이션 서비스 모범 사례 백서에는 마이그레이션 성능을 최적화 할 수 있는 몇가지 권장 사항이 있습니다.

프로세스를 요약하면 다음과 같습니다.

1. SCT 평가 보고서를 사용하여 현재 진행중인 작업의 개요를 확인하십시오. Aurora 로의 마이그레이션 후보가 여러 개인 경우 이 보고서를 통해 어떤 것을 먼저 마이그레이션 할지 결정할 수 있습니다.
2. 처리 전후에 필요할 수 있는 마이그레이션 단계를 없애기 위해 대상 스키마를 생성하는 것을 연습하고 DMS를 사용하여 로드 하십시오.
3. 대상 시스템에서 애플리케이션을 테스트하여 새로운 환경에서 예상한대로 동작하는지 확인하십시오. 로드, 네트워크 구성 등 프로덕션 환경과 유사한 구성에서 애플리케이션을 테스트 해보십시오.
4. 스키마 생성, 데이터 로딩, 후 처리 단계 적용, 원본과 동기화 된 대상 시스템 가져 오기 및 필요한 모든 단계를 포함하여 실제 마이그레이션을 실습하십시오.
5. SCT나 DMS 는 전체 시스템을 한번에 마이그레이션 할 것을 요구하지 않습니다. 이러한 도구를 사용하여 원하는 경우 시스템을 효율적으로 마이그레이션하고 재구성(rearchitect) 할 수 있습니다.

실제 마이그레이션을 시작하기 전에, SCT와 DMS 에 대한 문서를 자세하게 읽는 것이 좋습니다. 또한 단계별 연습 및 데이터베이스 마이그레이션 서비스 모범 사례 백서를 읽는 것이 좋습니다.

도구 사용에 대한 테스트를 위한 샘플 데이터베이스는 AWS Github 저장소에서 찾을 수 있습니다.

이 글은 여러분의 특정 상황에 필요한 모든 가능한 단계 또는 고려 사항을 설명하기 위한 것은 아니지만, SCT 및 DMS를 사용하여 상용 Oracle 데이터베이스의 구속을 어떻게 줄일 수 있는지에 대한 좋은 아이디어를 제공하기 위해 작성되었습니다. 마이그레이션에 행운과 행복이 가득하길!

더 자세한 것은 AWS Summit 2017 기술 세션 중 AWS DMS를 통한 오라클 DB 마이그레이션 방법 (발표 자료) 및 동영상도 참고하시기 바랍니다.

본 글은 아마존웹서비스 코리아의 솔루션즈 아키텍트가 국내 고객을 위해 전해 드리는 AWS 활용 기술 팁을 보내드리는 코너로서, 이번 글은 양승도 솔루션즈 아키텍트께서 번역해주셨습니다.

1년 전 AWS Database Migration Service 출시를 했을 때, 이미 1,000여 고객이 데이터베이스 이전 도구로서 DMS 서비스를 활용하고 있었습니다.

즉, AWS Database Migration Service 및 Schema Conversion Tool (SCT)는 AWS 고객이 고가의 자체 데이터베이스와 데이터웨어 하우스에서 보다 비용 효율적인 Amazon Aurora, Amazon Redshift, MySQL, MariaDB PostgreSQL 같은 클라우드 기반 데이터베이스와 데이터웨어 하우스로 이동하고 있으며, 이를 통해 다운 타임을 최소화 한 상태에서 전환하게 되었습니다. 예를 들어 Amazon Aurora로 전환하면 상용 데이터베이스의 10 분의 1의 비용으로 MySQL과 PostgreSQL 호환 데이터베이스를 사용할 수 있습니다. Expedia, Thomas Publishing, Pega, Veoci 등 고객 사례는 AWS DMS 활용 사례에서 보실 수 있습니다.

20,000 데이터베이스 이전 달성
AWS 고객은 지금까지 AWS Database Migration Service 를 사용하여 20,000 건의  데이터베이스를 AWS로 이전하고 현재도 그 수는 늘어나고 있습니다. (2016 년 9 월에 10,000 건 기록).

지난해에도 DMS와 SCT 서비스에 몇 가지 새로운 기능을 추가했습니다.

• 2016년 3월 – 8개 리전 정식 출시
• 2016년 5월 – 전환 대상으로 Redshift 추가
• 2016년 7월 – 지속적인 복제를 위한 고가용서 아키텍처 제공
• 2016년 7월 – 전환 소스 및 타겟으로 SSL 엔드포인트 및 Sybase 엔진 지원
• 2016년 8월 – Asia Pacific (Mumbai) , Asia Pacific (Seoul) , South America (Brazil) 리전 확장
• 2016년 10월 – US East (Ohio) 리전 확장
• 2016년 12월 – Oracle SSL 연결 기능제
• 2016년 12월 – Canada (Central)와 Europe (London) 리전 확장
• 2017년 1월 – 이벤트와 이벤트 구독 기능 추가
• 2017년 2월 – Oracle and Teradata에서 Amazon Redshift 전환 지원

자세한 정보
데이터 베이스 마이그레이션을 위해서는  먼저 최근 온라인 세미나 및 상세한 기술 문서들을 참고하시기 바랍니다.

Migrating From Sharded to Scale-Up – 일부 고객은 스케일 아웃 전략을 통해 데이터베이스 샤딩으로 마이그레이션 효과를 극대화 하고 있습니다. 두 개 이상의 샤드를 하나의 Aurora 인스턴스에 정리 복잡성을 줄이고 신뢰성을 높이면서 비용 절감을 실현하는 방법에 대한 블로그 글, 세미나 동영상, 발표 자료를 참고 하시기 바랍니다.

Migrating From Oracle or SQL Server to Aurora – Oracle 또는 SQL Server와 같은 상용 데이터베이스에서 Aurora로 이전하고 있습니다. 관련 정보는 발표 자료나 동영상을 참고하시기 바랍니다.

그 밖에도 AWS Database Blog에 다양한 글이 있습니다.

• Reduce Resource Consumption by Consolidating Your Sharded System into Aurora
• How to Migrate Your Oracle Database to Amazon Aurora
• Cross-Engine Database Replication Using AWS Schema Conversion Tool and AWS Database Migration Service
• Database Migration—What Do You Need to Know Before You Start?
• How to Script a Database Migration –

기술 문서에도 다양한 정보를 제공하고 있습니다.

• Migrating Databases to Amazon Web Services.
• Migrating an On-Premises Oracle Database to Amazon Aurora Using AWS Database Migration Service.
• Migrating an Amazon RDS Oracle Database to Amazon Aurora Using AWS Database Migration Service.
• Migrating MySQL-Compatible Databases to AWS.
• Migrating MySQL-Compatible Databases to Amazon Aurora.

서울 Summit에서 만납시다!
오는 4월 19-20일 개최되는 AWS Summit 2017 서울 행사에서 다양한 데이터베이스 관련 세션을 마련하였습니다. 지금 등록하시고 많은 참여 바랍니다.

— Jeff;

이 글은 AWS Database Migration Service – 20,000 Migrations and Counting의 한국어 요약입니다.

AWS Database Migration Service는 기존 온-프레미스 데이터베이스를 AWS로 쉽고 안전하게 마이그레이션에 도움을 주는 클라우드 데이터 이전에 중요한 서비스입니다. 지난 3월 정식 서비스 개시 이후 오늘 부터 Asia Pacific (Seoul) 리전에서 사용가능합니다.

본 서비스는 Oracle에서 Oracle로의 동종 마이그레이션뿐 아니라 Oracle에서 Amazon Aurora 또는 Microsoft SQL Server에서 MySQL로의 마이그레이션과 같은 이기종 데이터베이스 플랫폼 간의 마이그레이션도 지원합니다. 또한 Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle, SAP ASE(이전 Sybase ASE) 및 SQL Server를 포함해 지원되는 소스에서 Amazon Redshift로 데이터를 스트리밍하여 페타바이트 규모의 데이터 웨어하우스에서도 데이터 통합 및 용이한 분석이 가능합니다.

지난 7월 13일에는 몇 가지 신규 기능을 추가하였습니다. 지속적인 데이터 리플리케이션 기능을 추가하여, Multi-AZ 기능을 통해 좀 더 안정적인 리플리케이션을 제공합니다. 또한, SSL 엔드 포인트를 제공하여 좀 더 안전하게 정보를 제공할 수 있습니다. 좀 더 자세한 사항은 DMS 홈페이지나 DMS 기술 문서를 참고하시기 바랍니다.

■ AWS DMS 서비스 따라해 보기…

– AWS 코리아 마케팅팀;

여러분이 기존 환경에서 오라클, SQL서버, MySQL, MariaDB 및  PostgreSQL 데이터베이스를 운영하고 계시다면, AWS 클라우드로 이전하셔서 확장성이 높은 운영 효율적인 다양한 대용량 데이터 스토리지 옵션의 혜택을 누리실 수 있습니다.

그러면 어떻게 다운타임 없이 이전을 할 수 있을까요? 오늘 출시된 AWS Database Migration Service (DMS) 서비스가 바로 그 해답입니다. 작년 가을 AWS re:Invent 행사에서 미리 보기로 발표된 이후로 이미 우리 고객들의 1,000여개가 넘는 데이터베이스가 AWS로 이전하였습니다. 여러분도 바로 테라 바이트급 데이터베이스를 운영하는 도중이나 (신규 요구사항에 맞춤) 새로운 버전으로 업그레이드 하면서 라이브로 옮겨 보실 수 있습니다. 만약 클라우드로 옮기려고 하는 데이터베이스가 완전히 다른 엔진이라면 AWS Schema Conversion Tool 을 통해 스키마와 저장 프로시저를 새로운 환경으로 옮길 수 있습니다

AWS Database Migration Service는 AWS 상의 리플리케이션 인스턴스를 설정하여 동작하게 됩니다. 이 인스턴스는 기존 소스 데이터베이스에서 데이터를 업로드하고, 이전 대상 데이터베이스에 전송을 합니다. 이를 통해 최소한의 다운타임을 지원하는 리플리케이션 방식을 따라서 한번에 이전이 가능하다는 장점이 있습니다. DMS는 마이그레이션에 관련된 복잡한 문제들, 예를 들어 데이터 타입 변환, 데이터 플랫폼의 이전(오라클, Aurora 등)이 가능합니다. 또한, 리플리케이션 인스턴스 현황 및 헬스 체크 모니터링을 제공하며, 문제가 있을 때 알림을 보내고 필요하다면 자동으로 인스턴스를 대체할 수 있습니다. 

DMS는 다양한 이전 시나리오 및 네트워크 옵션을 제공합니다. 엔드 포인트가 AWS일 수도 있고, 기존 온-프레미스 환경일 수도 있습니다. 또한 EC2  인스턴스에 설치된 DB 혹은 RDS 인스턴스가 될 수도 있습니다. 소스 및 최종 이전 대상은 같은  Virtual Private Cloud (VPC)에 있거나, 두 개의 나눠진  VPC에서도 가능합니다. 여러분이 온-프레미스 데이터베이스를 이전하시려면, AWS Direct Connect.를 사용하여 전용 회선으로 연결하여 VPC 설정 후 사용 가능합니다.

데이터베이스 마이그레이션 하기
관리 콘솔에서 몇 번 클릭을 하기만 하면, 이전 작업을 시작할 수 있습니다. 먼저 이전을 원하는 데이터베이스를 선택하고, 스키마 이전, 리플리케이션 설정, 마이그레이션 시작을 하면 됩니다. 소스에서 이전이 완전히 완료가 되면, 애플리케이션에서 DB의 설정만 바꾸어 주면 됩니다.

AWS Database Migration Service 콘솔에서 DMS 를 클릭한 후, Create migration을 선택합니다.

콘솔에서는 마이그레이션 절차에 대해 간단하게 소개해 드립니다.

리플리케이션 인스턴스를 만들 각종 파라미터 값을 입력합니다.

이 글에서는 기존 VPC를 선택하고, Publicly accessible를 선택하지 않았습니다. 이전 대상 데이터베이스는 EC2 인스턴스에 있기 때문입니다.

리플리케이션 인스턴스가 만들어지면, 소스 및 최종 이동 대상 데이터베이스를 선택한 후   Run test를 선택합니다. 접속이 잘되는지 네트워크 이슈가 없는 지를 테스트해 볼 수 있습니다.

이제 실제 마이그레이션 작업이 진행되기 위해, Migration type을 설정하면, 기존 데이터, 이전 후 리플리케이션, 리플리케이션 등을 선택할 수 있습니다.

이제 Task Settings를 선택합니다. (LOBs는 Large Objects를 의미합니다).

마이그레이션 작업을 위해, Start/Resume를 선택하면 됩니다.

진행 사항을 보실 수 있으며, Table statistics를 통해 이전 사항을 확인할 수 있습니다. (아래 그림은 테스트 테이블입니다.)

이전이 완료되면, 간단한 테스트를 거쳐 애플리케이션의 DB 엔드포인트를 변경 한 후 배포하시면 됩니다.

AWS Database Migration Service는 다양한 선택 사항을 제공합니다. 예를 들어, 특정 테이블만 옮긴다던지, 여러 개의 다른 리플리케이션 작업을 할 수도 있고, 시간에 따라 작업을 활성화 시킬 수도 있습니다. 좀 더 자세한 사항은 DMS 기술 문서 (영문)을 참고하시면 됩니다.

여러분이 다양한 데이터베이스 세트를 옮기신다면, AWS Command Line Interface (CLI)나 the Database Migration Service API를 활용하시길 권장합니다.

가격 및 출시 리전
AWS Database Migration Service는 현재 US East (Northern Virginia), US West (Oregon), US West (Northern California), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo), Asia Pacific (Singapore),  및 Asia Pacific (Sydney) 리전에 우선 출시되었으며, 향후 빠른 시일 내에 (서울 리전을) 비롯한 다른 리전에 출시될 예정입니다.

— Jeff;

이 글은 AWS Database Migration Service의 한국어 번역입니다.