オンプレミス更改やシステム刷新のタイミングでは、AWSへの移行が有力候補になります。一方で、データベース移行は停止時間や整合性の影響が大きく、「失敗しにくい進め方」を先に見極めることが重要です。

特に情シス担当者の方は、「AWS Database Migration Service（AWS DMS）は本当に安全か」「CDCで最小ダウンタイム移行は成立するのか」「何が移って何が残るのか」と疑問を持つのではないでしょうか。

本記事では、AWS DMSの基本、できること・できないこと、CDC成立条件、手戻りを防ぐ前提チェック、進め方、料金の見方までを整理し、社内説明や相談判断に使える実務的な観点を解説します。

AWS DMSとは 基本機能とできること

AWS DMSの概要と主なユースケース

AWS DMSは、オンプレミスや他クラウド上のデータベースをAWSへ移行したり、継続的に複製したりするためのマネージドサービスです。初回にまとめてデータを移す「フルロード」と、その後の更新差分を追随する「CDC（Change Data Capture）」を組み合わせることで、切替時の停止時間を抑えた移行を検討しやすくなります。対応先はRDSやAuroraだけでなく、S3、Redshift、DocumentDBなどにも広がっており、単純な移行だけでなく段階的なモダナイゼーションにも活用できます。

主なユースケースは次のとおりです。

• オンプレミスDBからAmazon RDSやAmazon Auroraへ移行したい
• 停止時間をできるだけ短くして本番切替したい
• 将来的にS3やRedshiftへ連携し、分析基盤も整えたい
• 同種移行だけでなく、異種移行も視野に入れている

AWS DMSが選ばれる理由

AWS DMSが選ばれる理由は、移行元システムを稼働させながら進めやすいこと、レプリケーション基盤を自前で構築・保守しなくてよいこと、対応ソースとターゲットが広いことにあります。加えて、AWS側でも事前評価やスキーマ変換、監視などを含めた関連機能が用意されているため、移行プロジェクト全体を整理しやすい点も利点です。 

一方で、AWS DMSは万能ではありません。あくまで「データ移送」と「差分同期」に強みがあるサービスであり、スキーマ差分の吸収、アプリケーション影響の洗い出し、切替判断そのものまで自動化してくれるわけではありません。そのため、導入判断では「設定できるか」ではなく、「自社条件で安全に成立するか」を見極める必要があります。

結論 AWS DMSで最小ダウンタイム移行は可能だが成立条件が重要

AWS DMSで実現できること

結論から言うと、AWS DMSを使った最小ダウンタイム移行は可能です。一般的には、まずフルロードで既存データを移し、その後にCDCで更新差分を追随させます。切替直前までターゲット側を追随状態に保てれば、アプリケーション停止時間を短くしたカットオーバーが現実的になります。AWS公式でも「Full load plus CDC」を、既存データの移送と継続反映を組み合わせる代表的な方式として案内しています。 

最初に理解すべき制約

ただし、この方式はすべての案件で自動的に成立するわけではありません。AWSは、AWS DMSのCDCについて「リアルタイム複製ではなく、CDC遅延にSLAはない」と明示しています。遅延は、ソース側負荷、ネットワーク状況、レプリケーションインスタンスの性能、ターゲットの取り込み性能、データ特性に左右され、数分以上に伸びる場合もあります。 

また、CDCを成立させるには、ソースDB側に前提設定が必要です。たとえばOracleでは補足ロギング、MySQLではrow-based binary logging、ほかのエンジンでもログ取得や権限設定が求められます。つまり、AWS DMSの安全性は「ツールの有無」だけではなく、「ソースDB・ネットワーク・ターゲット構成まで含めて成立条件を満たせるか」によって決まります。 

ここで先に押さえたい判断ポイントは次の3点です。

• 自社DBでCDCに必要なログ設定を有効化できるか
• 許容停止時間に収まるだけの遅延水準を実測で確認できるか
• 自動で移らない要素を別工程として管理できるか

AWS DMSでできることとできないこと

フルロードとCDCの違い

フルロードは、移行開始時点の既存データをまとめてコピーする工程です。一方、CDCはその後に発生した更新、追加、削除をログから読み取り、ターゲットへ反映します。実務ではこの2つを組み合わせ、「最初に全量、次に差分追随」という構成が基本になります。 

できないことと制約

注意したいのは、AWS DMSがデータベースの全要素を完全自動で複製するサービスではないことです。異種移行では、スキーマやコードオブジェクトの変換にDMS Schema ConversionやAWS Schema Conversion Tool（AWS SCT）の併用が必要になります。DMS Schema Conversionは、テーブル、ビュー、ストアドプロシージャ、関数、データ型などの変換を支援しますが、変換できないものは手動対応が必要です。

また、LOB（Large Object。大きな文字列やバイナリ列）を多く含むテーブルは、転送モードによって性能差が出やすく、処理時間の読み違いにつながります。さらに、制約、トリガー、インデックスの有効化タイミングを誤ると、性能低下やタスク失敗の原因になります。 

適用可否の判断ポイント

AWS DMSの適用可否を早めに見るには、次の4論点を整理すると判断しやすくなります。

論点	確認内容	見落とした場合のリスク
ログ設定	補足ロギング、binlog、論理レプリケーション設定	CDCが成立しない
非自動移行要素	外部キー、ビュー、ユーザー、SP、関数など	移行後にアプリが動かない
性能条件	更新量、LOB量、書き込み性能、ネットワーク	遅延が拡大し切替できない
切替設計	停止条件、戻し条件、判定基準	本番判断が曖昧になる

加えて、同種移行であれば、必ずしもAWS DMSが最適とは限りません。停止時間をある程度確保できる場合は、バックアップ／リストアやネイティブレプリケーションの方がシンプルで、説明責任を果たしやすいこともあります。つまり、AWS DMSを「使えるか」ではなく、「使うのが最善か」で見る視点が大切です。

この段階で整理しておきたいことは次のとおりです。

• 何が自動で移り、何が別作業になるか
• 異種移行ならスキーマ変換をどう進めるか
• 性能懸念のあるテーブルをどこで検証するか

AWS DMSの前提チェックで詰まりを防ぐ

接続とネットワーク要件

AWS DMSはソースとターゲットの間でデータを中継するため、ネットワークの前提整理が甘いと、以降の検証がすべて不安定になります。オンプレミスからAWSへ移行する場合は、VPNまたはDirect Connect、名前解決、セキュリティグループ、ポート疎通、ルーティングまで確認が必要です。AWSも、移行初期にネットワーク設計を整理することを推奨しています。 

ソースとターゲットの前提条件

ソース側では、CDCに必要なログ設定、ログ保持期間、権限、メンテナンス運用への影響を確認します。ターゲット側では、事前にテーブルを作るのか、インデックスや制約をどの時点で有効化するのか、文字コードやデータ型互換をどう担保するのかを決めておきます。対応データベースは多いものの、エンジンやバージョンによって条件が細かく異なるため、最終的には最新の対応表確認が必須です。 

ログ設定と監視の基本

移行では「タスクが動いている」ことより、「切替判断に使える監視ができている」ことが重要です。AWSは、ホストメトリクス、レプリケーションタスクメトリクス、テーブル統計、タスクログの監視を推奨しています。CPU、メモリ、ストレージだけでなく、レイテンシやエラー傾向を見て、いつ誰が続行・中断判断するかまで定義しておくべきです。 

前提チェックでは、少なくとも次を外さないことが重要です。

• ネットワーク疎通と名前解決
• ログ設定とログ保持期間
• ターゲット側の性能余力
• 監視項目と切替判定基準

以下のような整理表を、社内ヒアリング用に使うと便利です。

項目	確認ポイント	主な担当
ネットワーク	VPN/Direct Connect、ポート、DNS、FW	インフラ担当
ソースDB	ログ設定、権限、ログ保持、負荷影響	DB担当
ターゲットDB	性能、文字コード、制約、有効化順序	DB担当
DMS監視	CloudWatch、ログ、イベント通知	運用担当

AWS DMSのCDC成立性を見極める

CDCの仕組みと成立条件

CDCは、ソースデータベースのトランザクションログから変更情報を取得し、ターゲットへ順次反映する仕組みです。OracleではSCN、SQL ServerではLSN、MySQLではbinlogなど、エンジンごとに参照する変更情報が異なります。成立条件は大きく3つで、ログを継続取得できること、AWS DMS側で処理し切れること、ターゲット側で取り込みをさばけることです。 

遅延と負荷の考え方

ここで重要なのは、CDCを「リアルタイム同期」と誤解しないことです。AWSは、CDC遅延がワークロード、ネットワーク、レプリケーションインスタンスのリソース、ターゲットの処理能力、データ特性によって変動すると案内しています。したがって、現実的な判断軸は「遅延ゼロ」ではなく、「業務が許容できる遅延と停止時間に収まるか」です。

成立しないケースと代替手段

更新量が極端に多い、巨大なLOB列が多い、ログ保持が短い、ターゲット側の書き込み性能が弱い、といったケースではCDCが成立しにくくなります。この場合は、バッチ移行、テーブル分割移行、段階切替、短時間停止を伴う移行、同種移行ならネイティブツール優先など、早めに代替案へ切り替える方が安全です。 

CDC成立性の判断では、次の観点を事前に数値化しておくと実務で使いやすくなります。

• 最大更新量の時間帯
• 許容できる遅延時間
• 切替直前に許容できる未反映差分量
• 代替案へ切り替える判断条件

AWS DMS移行で手戻りを防ぐ考え方

よくある失敗とリスク

AWS DMS移行で起きやすい失敗は、ツールそのものよりも前提整理不足に起因します。代表例は、テーブル本体は移ったがインデックス不足で性能が落ちる、CDC遅延が想定より大きく切替時間に収まらない、LOB設定を誤って処理時間が膨らむ、といったケースです。AWSも、フルロードとCDCの間でインデックスや制約の扱いを適切に設計することを推奨しています。 

データ不整合を防ぐポイント

整合性確認は件数比較だけでは不十分です。重要テーブルのハッシュ比較、主キー範囲ごとのサンプリング比較、業務画面からの疎通確認までを組み合わせる必要があります。特に基幹系では、「移ったこと」より「業務影響なく使えること」が重要です。切替後に発覚する不整合は、技術的な修正以上に、社内説明と信頼回復の負担が大きくなります。

外部支援を検討すべきケース

外部支援を検討すべきなのは、24時間稼働系、基幹系、異種移行、大規模データ、監査や説明責任が重い案件です。公開事例でも、Samsung ElectronicsはAWS DMSを活用して、11億ユーザー規模のSamsung Account基盤をOracleからAuroraへ段階移行し、月次運用コスト44％削減、90％のレイテンシを60ms未満に改善しています。
※参照：AWS Database Migration Service |サムスンケーススタディ |AWS

また、S&P Dow Jones IndicesはAWS DMSとAWS SCTを活用し、移行時間を10時間まで短縮しています。RWE Supply & Tradingでは、AWS DMSとAWS SCTを使った支援で、社内チームの移行工数を50％削減し、複雑なデータベース移行の予定を6か月前倒ししました。ISETAN MITSUKOSHI SYSTEMSでも、計画どおりの移行完了とゼロの計画外ダウンタイムが示されています。規模が異なっても、共通する成功要因は「段階移行」「PoC」「事前設計」「役割分担」です。
※参照：供給・取引のスピード化データベースをAmazon Auroraへ6ヶ月移行(Amazon DMAを使用) |ケーススタディ |AWS

手戻り防止の観点では、少なくとも以下を押さえるべきです。

• 失敗例を先に洗い出す
• 性能と整合性を分けて検証する
• 切替判断の責任分界を決める
• 必要なら第三者レビューを入れる

AWS DMSと他の移行手法の違い

AWS SCTとの違い

AWS DMSは、主にデータ移行と継続レプリケーションを担います。一方、AWS SCTやDMS Schema Conversionは、スキーマやコードオブジェクトの評価・変換を支援する役割です。異種移行では、データだけを移してもアプリケーションが動かないため、スキーマ変換工程を分けて考える必要があります。

他方式との使い分け

停止時間をある程度取れるなら、バックアップ／リストアの方が単純で説明しやすい場合があります。逆に、停止時間を極小化したいならAWS DMS＋CDCが有力です。同種移行ではネイティブレプリケーションの方が向くケースもあり、異種移行ではAWS DMSと変換ツールの併用が前提になります。

最適な移行方法の選び方

最適な移行方法は、停止許容時間、データ量、更新頻度、スキーマ差分、社内説明のしやすさで決まります。「AWSだからDMS」と短絡的に決めるのではなく、「どの方法が最も失敗条件を減らせるか」で比較することが重要です。

手法	向いているケース	強み	注意点
AWS DMS フルロード＋CDC	停止時間を短くしたい移行	差分追随で切替時間を抑えやすい	CDC成立条件の確認が必須
バックアップ／リストア	停止時間を確保できる同種移行	シンプルで説明しやすい	停止が長くなりやすい
AWS DMS＋AWS SCT	異種移行	データ移行とスキーマ変換を分担できる	変換後レビューが必要
ネイティブツール	特定製品間の同種移行	製品特性に最適化されやすい	AWS全体最適は別途設計が必要

比較時の着眼点は次のとおりです。

• 停止時間を優先するか
• 変換難易度を優先するか
• 社内説明のしやすさを優先するか
• 運用の継続性を優先するか

AWS DMSの対応データベースと構成パターン

主要データベースの対応状況

AWS DMSは、Oracle、SQL Server、MySQL、MariaDB、PostgreSQL、MongoDB、Db2など、多数のソースに対応しています。

ターゲットもAmazon RDS、Amazon Aurora、Amazon S3、Amazon Redshift、Amazon DocumentDBなど幅広いのが特長です。ただし、エンジンごとのCDC可否や細かな制限は異なるため、必ず最新の対応情報を確認する必要があります。 

一般的な構成パターン

現場で多い構成は、オンプレミスDBからAmazon AuroraまたはAmazon RDSへ移行するパターンです。ほかにも、AWS内の旧DBから新DBへの段階移行、複数ソースからS3やRedshiftへ集約し、分析基盤へ接続するパターンがあります。将来のデータ活用まで見据えるなら、移行時点で「業務DB」と「分析用途」の切り分けも意識したいところです。

大規模移行の注意点

大規模移行では、単純にインスタンスを大きくするだけでは足りません。AWSは、複数タスク化、並列ロード、LOBモード選定、ターゲット取り込み最適化などを推奨しています。フルロードでの並列化と、CDCでの遅延安定性は別論点なので、両方を検証する必要があります。 

この章で押さえたい実務ポイントは次のとおりです。

• 対応有無だけでなくCDC可否を見る
• バージョン差異を必ず確認する
• 大規模案件は並列化前提で設計する

AWS DMS移行の進め方

移行プロジェクトの流れ

AWS DMS移行の現実的な進め方は、要件整理、前提チェック、PoC、性能試験、切替設計、本番移行の順です。PoCでは、設定確認だけで終わらせず、ピーク時更新量での遅延、LOBの挙動、大きなテーブルのロード時間、エラー時の回復、ロールバック可否まで確認することが重要です。 

検証と成功判定

成功判定は「タスクが完走した」だけでは不十分です。件数一致、重要テーブルの差分なし、許容レイテンシ内、切替手順の再現性、ロールバック手順確認までを成功条件に含めるべきです。IPAの「DX動向2025」でも、日本企業は成果指標の設定率が米国・ドイツより大きく低く、評価指標の設定方法が課題になっていると示されています。移行案件でも、成功基準が曖昧だと最後に判断が止まりやすくなります。
※参照：IPA「DX動向2025」本文

切替とロールバック設計

切替時は、何分遅延なら続行するのか、どのエラーで中断するのか、どこまで戻すのかを事前に明文化します。情シス担当者にとって大切なのは、技術的に「できる」ことだけでなく、社内説明に耐えられる判断基準を持つことです。切替は作業そのものより、判断条件を先に定義しておくことで事故を減らせます。

プロジェクト進行では、次を文書化しておくと有効です。

• 成功判定条件
• 続行条件と中断条件
• ロールバック条件
• 本番当日の役割分担

AWS DMSの料金と運用の考え方

料金の見方とコスト要因

AWS DMSの料金は、主にオンデマンドのレプリケーションインスタンス課金、追加ログストレージ、Serverless利用時のDCU課金で構成されます。AWS DMS Serverlessは、使用した容量に応じて時間単位で課金され、自動スケールのため、変動が大きい移行ではコスト効率が出やすい傾向があります。一方、オンデマンドではピーク性能を見越したサイジングが必要です。なお、AWS DMS SCとFleet Advisorは基本的に無料で、保存先のAmazon S3利用料のみがかかります。

運用と監視のポイント

費用だけでなく、運用中に何を監視するかも重要です。CloudWatch、イベント通知、タスクログ、ソース・ターゲット双方のメトリクスを組み合わせ、単に「動作中」ではなく「遅延が縮む方向か」「切替判断に使える状態か」を見る必要があります。Multi-AZを使うか、PoCを何回回すか、継続レプリケーションをどれだけ長く保持するかで、総額は変わります。 

料金と運用では、次の論点を先に押さえると見積もり精度が上がります。

• PoCの回数
• 継続レプリケーション期間
• 追加ストレージの必要量
• 監視範囲と運用体制
• Multi-AZの要否

参考として、見積もり論点を表にすると次のようになります。

項目	主な費用要因	見積もり時の注意点
オンデマンド	インスタンス時間、追加ストレージ	ピーク前提の過大見積もりに注意
Serverless	DCU使用量、稼働時間	変動負荷に向きやすい
PoC	回数、期間、対象テーブル数	本番前提に近い条件で実施する
運用	監視、通知、保守対応	夜間判定や障害対応も含める

AWS DMSの相談前に準備すべきこと

事前に整理すべき情報

ベンダーや支援会社へ相談する前に、最低限そろえておきたいのは、ソースDBの種類とバージョン、データ量、更新量、停止許容時間、LOB有無、移行対象オブジェクトの範囲、社内制約です。これが曖昧だと、提案内容が一般論にとどまり、意思決定に使える情報が得にくくなります。

ベンダーへの確認事項

相談時には、「CDCが成立しない条件は何か」「どこをPoCで確認すべきか」「自動で移らないものは何か」「切替・ロールバック条件をどう置くべきか」を確認すると、実務的な議論になります。単に「できますか」ではなく、「どの条件なら安全に成立しますか」と聞く方が、判断材料を得やすくなります。

相談で得られること

適切な相談先であれば、AWS DMSを使うべきかどうかの見極めだけでなく、代替案比較、PoC観点整理、切替計画、監視項目、見積もり論点まで整理できます。特に、情シス担当者が社内説明責任を負う立場なら、「移行の可否」より「失敗条件をどこまで減らせるか」を整理できることが価値になります。

相談前には、次の情報をまとめておくと効果的です。

• ソースDBの製品名、バージョン、配置場所
• 対象データ量とピーク更新量
• 停止許容時間と切替希望時期
• LOB、ストアド、ビューなどの有無
• 現状の運用上の制約
• 社内説明で重視される論点

まとめ

AWS Database Migration Service（AWS DMS）は、最小ダウンタイム移行を実現しやすい有力な選択肢ですが、安全性はツール名だけで決まるものではありません。重要なのは、CDCの成立条件、移らない要素、性能限界、切替判断基準を事前に整理し、PoCで実測して確認することです。

特に、オンプレミスからAmazon RDSやAmazon Auroraへの移行では、「AWS DMSが使えるか」ではなく、「自社条件で無理なく成立するか」を軸に判断することが、手戻り防止につながります。社内説明やベンダー比較を進める段階にある場合は、前提整理とPoC観点の洗い出しから始め、必要に応じてテクノプロへ相談することで、失敗しにくい移行計画を具体化しやすくなります。