AWS DMS（Database Migration Service）入門｜オンプレDBのクラウド移行を支えるレプリケーション設計・SCT活用・カットオーバー戦略の実践ガイド

オンプレのDBをAWSへ移行する作業は、サーバー移行の中でも特に慎重さが求められる。データの欠損・整合性の破綻は業務に直結するうえ、「失敗したらやり直す」では済まない規模のデータを扱うケースが多い。ダウンタイムを最小限に抑えながら、数百GBから数TB単位のデータをいかに安全にクラウドへ運ぶか——そこに実用的な答えを出してくれるのが AWS DMS（Database Migration Service）だ。

この記事では、AWS DMSの仕組みと主要3コンポーネント、移行タスクの種類（フルロード/CDC/混合パターン）、スキーマ変換ツール AWS SCTとの使い分け、そして本番カットオーバーの実務判断まで、DBマイグレーションの全体像を体系的に解説する。AWS移行の6Rでいう「Replatform」「Refactor」フェーズを担う重要サービスなので、クラウド移行プロジェクトを進めているエンジニアにはぜひ参考にしてほしい。

なぜDBマイグレーションはサーバー移行より難しいのか

サーバーのリフトアンドシフトは、バックアップしてリストアすれば基本的に動く。しかしDBには「常に読み書きが発生している」という本質的な難しさがある。業務が動いている間もトランザクションは積み上がり、移行作業中に発生した差分をどう吸収するかが設計の核心になる。

オンプレでの旧来のDB移行は、こんな手順が多かった。

・メンテナンスウィンドウで業務を停止
・エクスポート（mysqldump、expdp等）
・データをネットワーク転送
・インポート
・整合性確認後にアプリ接続先を切り替え

これで数GB程度なら数時間で収まるが、TB単位になると一晩どころか週末をまたぐ停止が必要になる。それがAWS DMSを使うことで、業務を止めずに移行を進め、カットオーバーのダウンタイムを数分に圧縮できる。

AWS DMSの全体構成と3つのコンポーネント

AWS DMSは、次の3要素で構成される。ここを正確に理解しておくと、トラブルが起きたときの原因切り分けが格段に早くなる。

1. レプリケーションインスタンス

データを実際に読み書きするEC2ベースの中継サーバーだ。ソースDBからデータを読み込んで、ターゲットDBへ書き込む処理を担う。インスタンスクラスによって処理能力と料金が決まり、移行するデータ量や変更頻度に応じてサイズを選ぶ。

・dms.t3.medium（2vCPU / 4GB）: 小規模・検証用途
・dms.c5.large ～ c5.4xlarge: 本番移行の主力クラス（CPU集約型ワークロード向け）
・dms.r5.large ～ r5.8xlarge: LOBデータが多いなど大容量メモリが必要な場合

レプリケーションインスタンスはVPC内に配置する。ソースDBとターゲットDBの両方に疎通できるサブネットに置くのが基本設計で、Direct ConnectやVPN経由でオンプレとの接続を確保したうえで配置することが多い。

2. エンドポイント（ソースとターゲット）

ソースとターゲットのDB接続情報を定義するオブジェクトだ。ホスト名・ポート・認証情報・DB種別を設定する。各エンドポイントには接続テスト機能があり、設定後にレプリケーションインスタンスから実際に疎通確認ができる。

主なソース対応DB（抜粋）:
・Oracle Database（11g以降）
・Microsoft SQL Server（2005以降）
・MySQL / MariaDB
・PostgreSQL（9.4以降）
・MongoDB
・IBM Db2 LUW
・SAP ASE（旧Sybase）

主なターゲット対応DB（抜粋）:
・Amazon RDS（MySQL, PostgreSQL, MariaDB, Oracle, SQL Server）
・Amazon Aurora（MySQL互換・PostgreSQL互換）
・Amazon Redshift
・Amazon S3（CSV / Parquetでデータレイク直送も可）
・Amazon DynamoDB
・Amazon OpenSearch Service

2026年時点で対応DBは20種類以上あり、ほぼすべての商用DBとOSSのRDBMSをカバーしている。

3. レプリケーションタスク

「どのエンドポイントからどのエンドポイントへ、どの方法で移行するか」を定義する単位だ。後述する3つのタスクタイプから選択し、移行対象テーブルのマッピングルールを設定する。1インスタンスに複数タスクを作成でき、LOBを含むテーブルだけ別タスクに分離するといった柔軟な構成が取れる。

移行タスクの3タイプと使い分け

タスクタイプの選択が、移行計画の根幹を決める。誤って選ぶとカットオーバー当日に取り返しのつかない事態になるため、しっかり理解しておきたい。

1. フルロード（Full Load only）

既存データを一括でターゲットにコピーする方法だ。シンプルで処理速度も出やすいが、タスク実行中もソースDBへの書き込みは続くため、コピー後のデータは最新状態ではない。テスト移行や、移行期間中に業務を完全停止できる場合に限定して使う。

2. CDCのみ（Change Data Capture）

ソースDBの変更ログ（MySQLのバイナリログ、OracleのREDO LOG等）を継続的にキャプチャして、ターゲットへ差分を反映する方法だ。事前にデータが同期されている前提で動作するため、通常は単独では使わない。フルロード完了後の差分補完、あるいは同種DB間の継続レプリケーション（ホットスタンバイ等）に使う。

3. フルロード + CDC（本番移行の定番パターン）

これが本番移行で最もよく使われるパターンだ。まずフルロードでデータを一括コピーし、その後自動的にCDCモードへ切り替えて差分の同期を継続する。フルロード完了後もソースへの書き込みは続くが、DMSがリアルタイムで差分を追いかけ続ける。カットオーバー当日は、差分（レプリケーションラグ）がゼロに近づいたタイミングでアプリの接続先を切り替えるだけでよく、実際のダウンタイムは切り替え作業の数分に圧縮できる。

タスクタイプ	用途	カットオーバー時のダウンタイム
フルロードのみ	テスト移行・業務停止可能な場合	データコピー全体（長い）
CDCのみ	既存レプリカからの引き継ぎ	ほぼゼロ
フルロード + CDC	本番移行の標準パターン	切り替え作業のみ（数分）

AWS SCT（Schema Conversion Tool）との使い分け

AWS DMSはデータを移行するツールだが、DBエンジンが異なる場合はスキーマの変換も必要になる。そこで登場するのが AWS SCT（Schema Conversion Tool）だ。SCTはPC上で動作する無料のGUIツールで、ソースDBのスキーマ（テーブル定義、ストアドプロシージャ、ビュー等）をターゲットDBの構文へ自動変換する。

1. 同種DB間の移行——SCTは不要

MySQL → Amazon Aurora MySQL、PostgreSQL → Amazon RDS PostgreSQLのように、エンジンが同種であればスキーマ変換は不要だ。DMSだけで移行できる。Amazon RDSのマルチAZ構成やリードレプリカを使い始めたいだけなら、SCTは登場しない。

2. 異種DB間の移行——SCTが必須

Oracle → Aurora PostgreSQL、SQL Server → Amazon Aurora MySQLのような異種DB間の移行ではSCTが必須になる。商用DB特有のデータ型・組み込み関数・ストアドプロシージャは、OSSのRDBMSとは構文が大きく異なるからだ。代表的な変換ケースを挙げると次のとおりだ。

・OracleのNUMBER型 → PostgreSQLのNUMERIC型: 自動変換可
・OracleのDATE型（時刻含む） → PostgreSQLのTIMESTAMP型: 自動変換可
・PL/SQL関数・ストアドプロシージャ: 複雑なものは手動修正が必要
・Oracle固有関数（NVL, DECODE等）: PL/pgSQLの等価関数に変換（精度はケースによる）

3. SCT変換精度の現実と手動対応の見積もり

SCTの変換精度は「移行先DB × ソースDBの書き方」によって大きく変わる。プロジェクト着手前にSCTでスキャンだけを実行し、「変換に何件の手動修正が必要か」を事前把握しておくことが重要だ。この事前調査を省くと、後工程でストアドプロシージャの書き直し作業がスケジュールに入り込み、計画を大幅に圧迫する。SCTのスキャンは本番DBのコピー環境に対して実施でき、本番への影響はない。

カットオーバー設計の実務判断

フルロード + CDCでデータの同期が安定したら、いよいよカットオーバーの準備に入る。ここが移行プロジェクトの本番だ。段取り不足が直接的な事故につながるため、リハーサルを欠かせない工程として計画に組み込んでほしい。

1. レプリケーションラグの監視

Amazon CloudWatchで CDCLatencySource（ソースから読み込む遅延）と CDCLatencyTarget（ターゲットへの反映遅延）を監視する。ラグが数秒以下に安定していることを確認してからカットオーバーに入るのが鉄則だ。業務のピーク時間帯はトランザクション量が増えてラグが拡大しやすい。カットオーバーはラグが安定している業務閑散時間（深夜・早朝）を選ぶのが基本だ。

2. 接続文字列の切り替え手順

アプリケーション側の接続文字列（エンドポイントURL）をオンプレDBからターゲットDBへ切り替えるタイミングが、実質的なダウンタイムの開始と終了を決める。典型的な切り替え手順はこうなる。

・ソースDBへの新規書き込みを停止（メンテナンス画面へ切り替え）
・残存トランザクションのフラッシュ待ち（数秒から数分）
・DMSのCDCラグがゼロになったことを確認
・アプリの接続先をターゲットDBのエンドポイントへ切り替え
・動作確認（主要機能の読み書きチェック）
・メンテナンス画面を解除

この手順をステージング環境での模擬切り替えで何度か繰り返し、所要時間と作業手順を確定しておくことがリスク低減の要だ。

3. 切り戻し計画（ロールバック設計）

カットオーバー後に問題が発覚した場合の切り戻し手順もあらかじめ決めておく。DMSの場合、カットオーバー後もソースDBはそのまま残っているため、接続先をオンプレDBに戻すだけで業務を再開できる（ターゲットDB側で発生した書き込みは失われるが、ロールバック優先の場合はこれを割り切る）。切り戻し判断の期限（「カットオーバー後2時間以内」等）をステークホルダー間であらかじめ合意しておくことも重要だ。

料金の仕組みとコスト試算

AWS DMSの費用は主に3要素で構成される（2026年3月時点、東京リージョン ap-northeast-1 の参考価格）。

1. レプリケーションインスタンス

EC2と同様の時間課金だ。インスタンスをプロビジョニングしている時間に対して料金が発生し、移行完了後にインスタンスを削除することでコストはゼロになる。

・dms.t3.medium（2vCPU / 4GB）: 約 $0.10 /時間
・dms.c5.large（2vCPU / 4GB）: 約 $0.17 /時間
・dms.r5.large（2vCPU / 16GB）: 約 $0.24 /時間

2. ストレージとデータ転送

レプリケーションインスタンスに付属するSSDストレージが月額約 $0.115/GB かかる（デフォルト50GBで約 $5.75/月）。データ転送は同一リージョン内であれば低コストだが、オンプレからVPN/Direct Connect経由の転送はデータ量に応じて別途費用が発生する。

3. 概算コスト例（中規模DB移行）

500GBのMySQLをオンプレから Amazon Aurora MySQLへ移行するケースで試算してみよう。

項目	想定	概算費用
dms.c5.large × 2週間	フルロード1週間 + CDC安定稼働1週間	約 $28
ストレージ 100GB × 1ヶ月	変更ログのバッファ込み	約 $11.5
データ転送（同一リージョン内AZ間）	ターゲットAZ間レプリケーション分	約 $5
合計		約 $45（約6,500円）

移行作業そのもののコストは非常に安価だ。本番稼働後のAurora料金（インスタンス + ストレージ + I/O）は別途かかるが、DMSの移行作業コストはその試算に加える必要がほとんどない。AWS Pricing Calculator を使って、移行先のAurora/RDS本番コストをあわせて見積もっておこう。なお、Amazon RDS vs Auroraの料金・性能比較も参考に、移行先DBの選定を進めてほしい。

よくあるトラブルと対処法

【LOBカラムの移行でデータが切れる】

BLOB・CLOB・TEXT型など大容量のLOBデータは、デフォルトの「Limited LOBモード」では最大LOBサイズで切り捨てられることがある。タスク設定で「Full LOBモード」に変更するか、最大LOBサイズを実際のデータに合わせて拡張する。Full LOBモードは処理速度が落ちるため、LOBカラムを含むテーブルだけ別タスクに分離するのが現場での定石だ。

【ソースMySQLのバイナリログが無効になっている】

CDCはMySQLならバイナリログ（binlog）、PostgreSQLならlogical replicationを利用する。オンプレのMySQL環境ではデフォルトでbinlogが無効なケースがある。移行前に log_bin=ON と binlog_format=ROW を設定する必要があり、この変更にはMySQLの再起動が伴う。本番DB再起動のタイミングをプロジェクト早期に計画に組み込んでおくこと。

【文字コードの不一致でデータ化けが起きる】

ソースがShift_JIS・CP932などで、ターゲットがUTF-8の場合、エンドポイント設定でcharset mappingを明示しないと文字化けが発生する。ソースエンドポイントの追加接続属性に characterSetName=utf8mb4 等を指定してから移行を開始すること。

【CDCラグが増加し続ける】

ソースDBの書き込みトランザクション量がレプリケーションインスタンスの処理能力を超えると、ラグが増加し続ける。dms.c5.largeで追いつかない場合はdms.c5.xlargeまたはdms.r5.largeにサイズアップする。また、タスクのパラレルロード設定（ParallelLoad）を有効にすることで処理速度を改善できるケースもある。

本記事のまとめ

AWS DMSは、オンプレDBをダウンタイムを最小化しながらAWSへ移行するための専用サービスだ。「フルロード + CDC」パターンを使えば、業務が稼働したままデータ同期を維持し、カットオーバーのダウンタイムを数分に圧縮できる。

項目	ポイント
タスクタイプ	本番移行は「フルロード + CDC」が定番
SCTの要否	同種DB間は不要・異種DB間は必須
カットオーバー	CDCラグがゼロに近づいてから接続切り替え
切り戻し	ソースDBを残しておけば即座に戻せる
移行コスト	2週間の作業で数千円程度と安価

DBエンジンを変える異種移行（Oracle→Aurora、SQL Server→Aurora MySQL等）は難易度が上がるが、SCTによる事前スキャンで工数を把握してから着手すれば計画が立てやすくなる。ファイル移行が主体の場合は AWS DataSync（NFS/SMB/S3の大容量データ転送）と組み合わせると、DBはDMS・ファイルはDataSyncと役割分担してオンプレ全体の移行を効率的に進められる。