AWS Database Migration Service（DMS）とは？サーバーレスと同種・異種移行の使い分け・料金を実装者目線で解説

オンプレミスのOracleをAurora PostgreSQLへ、自前で運用しているMySQLをAmazon RDSへ。この移行を業務停止を抑えて通したいときに使うのが、AWS Database Migration Service（AWS DMS）です。ただしDMSは単一の機能ではなく、レプリケーション本体・スキーマ変換・同種データ移行という別系統の集まりで、どれを選ぶかで作り方も料金も変わります。構成要素と3つの移行モード、サーバーレスの容量設計、DMSを外すべき場面までを整理します。

まとめ：DMSの守備範囲とサーバーレス選択・料金の結論

AWS DMSは、リレーショナルデータベースやデータウェアハウス、NoSQLデータストアをAWSへ移行するマネージドサービスです。実体はAWS上でレプリケーションソフトウェアを動かすサーバーで、ソースとターゲットのエンドポイントを定義し、タスクを走らせてデータを移します。異なるエンジン間の移行にも対応し、移行中の変更を取り込む変更データキャプチャ（CDC）まで引き受けます。

入り口は3つに分かれます。エンジンをまたがない移行なら、ネイティブのデータベースツールで動く「同種データ移行」。またぐ移行なら、DMS Schema Conversionでスキーマを先に変換してからデータを流す2段構え。棚卸しを担っていたDMS Fleet Advisorは2026年5月20日にサポートが終了しています。

DMS本体には、レプリケーションインスタンスを自分で選ぶ標準構成と、容量をAWSが決めるサーバーレス構成があります。サーバーレスは2GBのメモリを1単位とするDCUで課金され、最小値と最大値の範囲で自動的に伸縮する仕組み。ただしフルロード中はスケールダウンしません。

採用判断の起点は機能表ではありません。ダンプとリストアが停止許容時間に収まるならネイティブツールで足ります。DMSに費用と設計工数を払う価値が出るのは、切替のダウンタイムを分単位へ縮めたいか、エンジンをまたぐかに当てはまるときです。

AWS DMSが引き受けるデータ移行処理と3つの機能グループの構成

最初に、このサービスが引き受ける範囲と引き受けない範囲を確定させます。

レプリケーションインスタンス・エンドポイント・タスクの3層構造

DMSの登場人物は3つです。レプリケーションインスタンスは、AWSクラウド上でレプリケーションソフトウェアを動かすサーバー。エンドポイントは、どこから抜き出してどこへ流し込むかを指す接続定義で、ソース側とターゲット側の2つを作ります。タスクは、そのインスタンス上で走る実際の移行処理です。

境界を誤解しやすいのは、ターゲット側にDMSが作るオブジェクトの範囲でしょう。ターゲットに存在しなければDMSは表と主キーを作ります。裏を返せば、セカンダリインデックス・外部キー制約・ビュー・トリガー・ストアドプロシージャは対象外。自分で用意するか、DMS Schema Conversionに作らせるかの二択になります。

可用性と暗号化はサービス側の担当です。一次のレプリケーションサーバーが落ちればバックアップ側が引き継ぎ、保存時のデータはAWS Key Management Service（AWS KMS）で暗号化、転送中のデータにはSSLを掛けられます。

フルロード・CDC・フルロード＋CDCという3つの移行モードの違い

タスクのモードは3種類です。フルロードは、開始時点のデータを一度だけ丸ごと移すモード。CDCのみは、ソース側のトランザクションログから変更を拾い続けて流し込むモード。そして両者を組み合わせたフルロード＋CDCが、業務停止を短くしたい移行で使う構成になります。

フルロード＋CDCの流れは、全件コピーの最中に発生した更新を裏で溜め、コピー完了後に適用してソースへ追いつく形です。追いついた状態のまま業務時間外に接続先を切り替えれば、停止は切替作業の時間だけで済みます。移行計画全体の組み立て方はクラウドデータ移行の手順と整合性検証の実務の側で設計してください。

2026年5月20日に終了したFleet Advisorと代替になる棚卸し手段

移行前の棚卸しを担っていたDMS Fleet Advisorは、2026年5月20日にサポートが終了しました。以降はコンソールにもリソースにもアクセスできません。SQL Server・MySQL・Oracle・PostgreSQLのサーバーを自動発見してインベントリを作り、右サイズのターゲットを推奨する機能でしたが、いまは前提から外して計画を立てます。

日本語の解説記事にはFleet Advisorを前提に手順を組んだものが残っているため、2025年以前の資料を参照するときは注意してください。棚卸しはAWS Application Discovery Serviceや、各データベースの管理ビューからの自前集計へ置き換えます。

同種移行と異種移行で変わるDMSの作り方とスキーマ変換の担当範囲

ここを取り違えると、使う必要のない機能に工数を払うことになります。

同種データ移行はネイティブツールで動く別系統のサーバーレス機能

ソースとターゲットのエンジンが同じなら、DMSの「同種データ移行」が使えます。自己管理のオンプレミス、Amazon EC2上、Amazon RDS上のデータベースをソースに取り、Amazon RDSまたはAmazon Auroraの同一エンジンへ移す機能です。内部ではネイティブツールでダンプを取り、ターゲット側でリストアします。

この系統はサーバーレスで動くため、レプリケーションインスタンスのサイズ決めが要りません。インスタンスプロファイル、データプロバイダー、移行プロジェクトの3資源を作ると、DMSがサーバーレス環境を用意して移行を走らせます。モードはフルロード、継続レプリケーション、その併用の3種類。ネイティブツール経由のため、パーティションや関数、ストアドプロシージャといった二次オブジェクトも移ります。

異種移行でDMS Schema Conversionが受け持つ変換と生成AI変換

エンジンをまたぐ場合は、データを流す前にスキーマを変換します。DMS Schema Conversionは、ソースのスキーマをAurora・Amazon RDS・Amazon Redshift向けへ変換するフルマネージド機能で、AWS Schema Conversion Tool（AWS SCT）の変換エンジンが土台。ルールベースで結果を再現可能にし、変換しきれないオブジェクトに生成AI変換を掛けて手作業を減らす構成です。

実務での使い方は、評価レポートを先に出すところから始めます。何が自動で変換され、何が手作業になるかが一覧になるため、工数見積もりを着手前に立てられます。変換したコードはターゲットへ直接適用するか、SQLスクリプトとしてAmazon S3へ書き出すかを選べる形です。

表のほかに、SQL ServerからMySQL系、OracleからAmazon Redshiftへの経路とIBM Db2の3経路があります。Db2 for LUWとDb2 for z/OSからPostgreSQL系への変換、Db2 for z/OSからAmazon RDS for Db2への変換はマネジメントコンソールに出てこないため、実行にはAWS CLIかDMSのAPIを使う形。生成AI変換は東京リージョン（ap-northeast-1）と大阪リージョンで使え、クロスリージョン推論を用いる点がドキュメントに明記されています。

同種データ移行に掛かる制限事項と、移行前に潰しておく前提条件の確認

同種データ移行は手軽な反面、設計前に押さえる制約が並びます。特に検証とスキーマ変更の扱いは移行計画を左右する箇所です。

• データ検証の組み込みツールが無く、突き合わせは自前で用意する
• PostgreSQLではビューがテーブルとしてターゲットへ移る
• 継続レプリケーション中にスキーマ変更を追えるのはMySQLのみ
• 上位バージョンから下位バージョンへの移行はできない
• 選択ルールはMySQLではフルロードのみ対応
• VPCのセカンダリCIDR範囲にあるDBインスタンスへは接続できない
• データプロバイダーで8081番ポートは使えない
• MySQLのKeyringプラグインで暗号化した表は非暗号化で着地する

1つ目の検証は移行の受け入れ条件に直結します。継続レプリケーション中にソース側で新しいテーブルを作ると、MySQL以外では追従できず移行をやり直す羽目になる点も、先に共有しておくべき制約です。

DMSサーバーレスとプロビジョンド構成の選び分けとDCUの決め方

DMS本体を使う場合、容量を自分で決めるかAWSに任せるかを最初に選びます。

DCUは2GBのメモリ単位・MinとMaxの決め方とスケールの挙動

サーバーレスでは、レプリケーションインスタンスとタスクの代わりに「レプリケーション設定」を作ります。エンドポイントの作り方は標準構成と同じで、違うのは容量の指定方法。1 DCU（DMS capacity unit）は2GBのメモリに相当し、課金は実際に使ったDCU分だけ発生します。

指定するのはMinCapacityUnitsとMaxCapacityUnitsの2つ。開始するとDMSはソースへ接続してメタデータを集め、必要な容量を計算してプロビジョニングし、フルロードとCDCを順に回します。公式ドキュメントの推奨は、最大値を大きく取ってスケールの余地を残し、最小値は急なスパイクに耐える値へ置くという組み方です。

最小値を絞りすぎると事故につながります。容量が足りないままだとCapacityUtilizationが上限に張り付き、レプリケーションログにメモリ不足のイベントが記録されて失敗する挙動。自動回復の仕組みは備わっているものの即座には効かないため、最小値を引き上げて再開するほうが復旧は早くなります。CDCを継続的に回す構成ではMultiAZの有効化が推奨されています。

フルロード中はスケールダウンしない・48時間で資源が解放される

自動スケールが効かない条件が2つあります。1つは、フルロードの実行中はスケールダウンしないこと。大きなテーブルを流している間、容量は下がりません。もう1つは、停止や失敗の状態から48時間以内に開始しなかったレプリケーションは、DMSがリソースを解放して再開できなくなることです。

再開の操作にも癖があります。いったん停止したレプリケーションは新規開始と同じやり方では動かず、開始種別にresume-processingを渡す形になり、最初から流し直す操作は用意されていません。ストレージ側は初期100GBが割り当てられ、15分ごとの監視で90%に達すると自動拡張されます。

サーバーレスが対応しないエンドポイントと標準構成を選ぶべき場面

サーバーレスの対応エンドポイントは標準構成より狭く、ここが選択の分岐点になります。ソースはMongoDB、DocumentDB、SQL Server、PostgreSQL互換、MySQL互換、MariaDB、Oracle、Amazon S3、IBM Db2。ターゲットはSQL Server、PostgreSQL、MySQL互換、Oracle、Amazon S3、Redshift、DynamoDB、Kinesis Data Streams、Amazon MSK、Neptuneなどです。

この一覧に自分の構成が乗らないなら標準構成を選びます。ほかに標準を選ぶ理由になるのは、エンジンのバージョンを固定して検証済みの挙動を保ちたい場合と、無料枠のdms.t3.microで小規模な移行を賄いたい場合。サーバーレスではバージョン選択がサービス側に寄るため、この2つは満たせません。なお利用にはサービスリンクロールが必要です。

レプリケーションエンジンの版とEOL日程・3.5.4と3.6.1の位置

標準構成を選ぶなら、エンジンバージョンの寿命を移行計画へ織り込みます。2026年7月時点の既定は3.5.4で、新規インスタンス作成の終了が2027年1月31日、EOLが2027年3月31日。3.6.1は2025年5月15日リリースで、次の既定バージョンになる予定として案内されています。

間の3.6.0には注意が要ります。2024年12月27日リリースで新規作成は2026年4月27日に終了、EOLは2026年7月27日。提供リージョンもアジアパシフィック（シドニー）に限られていました。3.5.3は2026年6月30日でEOL済み。数か月のCDCを回す移行では、走り切る前にEOLへ届かないかを確認してください。

AWS DMSの料金構造と、見積もりで抜けやすい費用項目の洗い出し

見積書で漏れるのは、DMS本体ではなく周辺で発生する費用のほうです。

課金はインスタンス時間かDCU時間・ストレージ・転送の3本立て

標準構成の課金対象は、レプリケーションインスタンスが起動している時間です。T2・T3・C4・C5・C6i・R4・R5・R6iの各クラスで単価が異なり、シングルAZとマルチAZでも別単価。サーバーレスでは、この時間課金が使用したDCU時間へ置き換わります。

ストレージは一定量が含まれます。C4・R4・R5では100GB、T2・T3では50GBの汎用SSD（GP2）が付き、超えた分が従量課金。データ転送はDMSへ入る方向が無料で、同一アベイラビリティーゾーンのRDSやEC2との転送も無料です。DMS Schema Conversionは機能そのものに料金が掛からず、保管ストレージ分だけが課金対象になります。

無料枠750時間とT3のCPUクレジット課金という2つの落とし穴

無料枠は、1年間にわたり月750時間のシングルAZ dms.t3.microと50GB分の汎用SSDが対象です。検証環境や小規模な単発移行なら、この枠内で通せる場面もあります。ただし2点の落とし穴があります。

1点目はバースト可能インスタンスのCPUクレジットで、T3クラスではクレジットを使い切ると1vCPU時間あたり0.075ドルが加算されます。フルロードはCPUを継続的に使うため、t3系で大きなテーブルを流すと想定外の額が乗る構造。2点目はマルチAZで、CDCでは推奨されるものの単価はシングルAZと別建てです。東京リージョンの時間単価は料金ページに例示がないため、AWS料金計算ツールで確認してください。

AWS DMS本体の料金以外に見積もりへ載せる周辺コストの項目

DMSの利用料は移行費用の一部にすぎません。並走して発生する費用を並べます。

• 移行先となるAmazon RDS・Auroraのインスタンス料金とストレージ料金
• 切替前の並走期間に生じるソース側とターゲット側の二重コスト
• Amazon CloudWatch Logsのログ保管とAWS Secrets Managerの標準料金
• AWS Direct ConnectやVPNなど、オンプレミスとの接続回線
• リージョンをまたぐ場合のデータ転送OUT

金額の主役になりやすいのは、ほぼ常に移行先データベース側です。DMSの単価を詰める前にAmazon RDSの対応エンジンと料金モデルで移行先の構成を固めるほうが、見積もりの精度は上がります。

AWS DMSを採用してよい条件と、別の手段へ寄せるべき3場面

ここからは判断です。DMSが向く条件と、外したほうがよい条件を切り分けます。

停止許容時間と差分量から引くDMS採用の下限条件を数値で決める

判断の起点は1つです。ダンプとリストアに掛かる時間が、業務を止められる時間に収まるか。収まるならmysqldumpやpg_dumpといったネイティブツール、あるいは同種データ移行をフルロードのみで回す構成で足ります。CDCの設計、ソース側のログ設定、追いつき確認を積む必要はありません。

収まらない場合に初めて、フルロード＋CDCの価値が出ます。停止許容時間が数時間以下でデータ量が数百GBを超える、あるいは24時間365日の稼働で止められる窓が無い構成が目安。もう1つの採用条件は異種移行で、こちらは停止時間に関係なくDMS Schema Conversionとの2段構えが要ります。発注側の判断材料としてまとめたマイグレーションとリプレイスの違いと発注判断も確認すると、移行方式の選定理由を社内で説明しやすくなります。

ネイティブツール・Auroraの移行機能・MGNへ寄せるべき場面

1つ目は、同一エンジン・同一バージョン間で停止窓に収まる規模の移行です。ネイティブツールのほうが手順が短く、エンドポイント定義やタスク設定を組む工数が丸ごと不要になります。同種データ移行を選ぶにしても、CDCまで有効にする理由があるかは切り分けてください。

2つ目は、データベースだけでなくサーバーそのものをAWSへ移す案件です。OSとアプリケーションを含めたブロックレベルの移行はDMSの守備範囲外で、AWS Transform MGNの対応OSと移行手順で扱うサーバー移行サービスへ寄せます。DBだけを切り出すか現行構成のまま持ち上げるかは、移行方式の選定そのものです。

3つ目は、ファイルやオブジェクトの転送です。DMSが扱うのはデータベースの行とドキュメントで、ファイルサーバーの中身を運ぶ用途はAWS DataSyncの担当になります。

データベース移行を外部へ委託するとき見積書で確認する5つの項目

移行を外部へ任せる場合、見積書の粒度で後の追加費用が決まります。確認したいのは次の5点です。

• ソースとターゲットのエンジンとバージョン（上位から下位へは不可）
• 同種か異種か。異種なら評価レポートが成果物に入るか
• CDCの要否と、切替時に確保する停止窓の長さ
• 移行データの検証方法と、突き合わせを誰が実施するか
• 二次オブジェクトと権限・ユーザーの移行がどこまで含まれるか

特に4点目と5点目は曖昧にされやすい箇所です。同種データ移行には検証の組み込みツールが無く、DMS本体が作るのも表と主キーまで。これらを「移行に含まれる」と読み違えたまま契約すると、受け入れテストの段階で作業が積み上がります。設計から切替まで任せるなら、システムマイグレーション・リプレイスの支援のように移行方式の選定と停止窓の設計を含めて相談できる体制かを確認してください。

よくある質問

DMSの検討時に問い合わせが多い論点を5つ挙げます。

AWS DMSとAWS SCTはどう使い分けますか？

役割が違います。AWS DMSが運ぶのはデータで、AWS Schema Conversion Tool（AWS SCT）が変換するのはスキーマとコードです。異種移行では両方を使い、SCTでスキーマを変換して適用してからDMSでデータを流します。現在はSCTの変換エンジンを土台にしたDMS Schema Conversionがマネージド機能として提供されているため、対応する変換パスならそちらを先に検討してください。

サーバーレスと標準構成のどちらを選べばよいですか？

対応エンドポイントの一覧に構成が収まり、負荷の見積もりに自信が持てないならサーバーレスです。容量の計算とスケール、パッチ適用をサービス側が引き受けます。逆に、バージョンを固定したい、無料枠のdms.t3.microで賄いたい、対応一覧に無いエンドポイントを使うのいずれかに当てはまるなら標準構成を選んでください。

移行中にソース側のデータベースは止める必要がありますか？

フルロード＋CDCの構成なら、移行の大半をソース稼働中に進められます。全件コピーの最中に発生した変更はDMSが溜めて後から適用し、以降も追いかけるためです。停止が要るのは接続先を切り替える瞬間だけ。ただしCDCにはソース側でトランザクションログの保持や補足ログの設定が要り、怠ると変更を拾えません。

Fleet Advisorが終了した後、移行対象の棚卸しはどうしますか？

DMS Fleet Advisorは2026年5月20日にサポートが終了し、コンソールもリソースも参照できません。棚卸しはAWS Application Discovery Serviceに寄せるか、各データベースの管理ビューやシステムカタログから対象スキーマとサイズを自前で集計する形へ置き換えます。2025年以前の解説記事はFleet Advisor前提のものが多いため、参照時期を確認して読んでください。

ターゲット側にインデックスや外部キーは自動で作られますか？

作られません。DMSがターゲットに用意するのは、存在しない場合の表と主キーまでです。セカンダリインデックス、外部キー制約、ビュー、トリガー、ストアドプロシージャは対象外で、自分で事前に作成するかDMS Schema Conversionに変換させます。なおフルロードの性能を考えると、セカンダリインデックスはロード完了後に作るほうが所要時間は短くなります。

関連記事

• Amazon Auroraとは？仕組み・RDSとの違いと料金モデル・採用判断を実装者目線で解説：移行先Auroraの料金と採用判断
• Aurora MySQL 8.4の全体像と移行を検討する読者が押さえる前提：MySQL系をAuroraへ移す際のバージョン前提
• Amazon Redshiftとは？特徴・料金・使い方とアーキテクチャを実務目線で解説：分析基盤をターゲットに置く場合の構成と料金
• PostgreSQLとMySQLの違いを徹底比較｜性能・データ型・全文検索・移行と使い分け【2026年版】：異種移行の変換先を決めるエンジン比較
• システム移行とは？移行方式の種類と進め方・失敗を防ぐ判断基準を解説：移行方式の選定基準を発注視点で整理