AWS Database Migration Service (DMS) 完全ガイド 2026

初心者から実務者向けの包括的解説

AWS Database Migration Service（DMS） は、異種データベース間のマイグレーション・継続的レプリケーション・データ変換を提供する完全マネージドサービスです。Oracle・SQL Server・MySQL・PostgreSQL などのオンプレミス / 自社ホスト DB を AWS RDS / Aurora / Redshift / DynamoDB へ、最小限のダウンタイム で移行でき、Change Data Capture（CDC）により移行中の差分変更をリアルタイム同期します。2026 年現在、DMS Serverless・Fleet Advisor・DMS v3.5 による Schema Conversion Tool 統合、プレマイグレーション評価機能の強化により、複雑なクラウド移行を自動化できます。

ドキュメントの目的

本ガイドは以下を対象としています。

• 初心者向け： AWS DMS とは何か、なぜ必要かを学びたい方
• 開発者向け： DB マイグレーションを実行・管理したい方
• DBA 向け： スキーマ変換・パフォーマンスチューニング・監視を担当する方
• SRE / インフラ向け： マイグレーションタスク設計・自動化・CI/CD 統合
• アーキテクト向け： オンプレ DB のクラウド移行戦略・ハイブリッド構成検討者

2025-2026 年の DMS エコシステム

• DMS Serverless プレマイグレーション評価（2025年2月）：ソース・ターゲット DB を事前スキャン、互換性問題を検出
• DMS Serverless 拡張（2025年）：自動キャパシティプロビジョニング、スケーリング改善
• Schema Conversion Tool 統合（v3.5）：DDL 変換の精度向上、PL/SQL → PostgreSQL 互換 SQL 自動変換
• Fleet Advisor サポート終了（2026年5月20日）：Discovery 機能は DMS Serverless に集約
• Data Provider・Migration Project（DMS v3.5+）：ノーコード・スキーマレス移行オプション
• リアルタイムレプリケーション拡張：EventBridge・Kinesis との統合、ストリーミング CDC

目次

1. 概要
2. AWS DMS が解決する課題
3. 主な特徴
4. アーキテクチャと基本概念
5. コアコンポーネント
6. レプリケーションインスタンス
7. エンドポイント・接続
8. 移行タスク・設定
9. DMS Serverless
10. Schema Conversion Tool（SCT）統合
11. CDC（Change Data Capture）
12. テーブルマッピング・変換ルール
13. CLI・SDK・IaC 実装例
14. セキュリティ・暗号化
15. 監視・パフォーマンスチューニング
16. 類似ツール比較表
17. ベストプラクティス
18. トラブルシューティング
19. 2025-2026 最新動向
20. 学習リソース
21. 実装例・チェックリスト
22. まとめ
23. 参考文献

概要

初心者向けメモ： AWS DMS は「複雑なデータベース移行を自動化するツール」です。例えば、オンプレミスの Oracle 10GB のデータを AWS Aurora PostgreSQL に移行する際、通常は full dump/restore で数時間のダウンタイムが発生しますが、DMS は Full Load + CDC 方式で、移行中の変更を継続的に同期し、ダウンタイムを分単位に短縮できます。さらに Schema Conversion Tool と組み合わせれば、PL/SQL の自動変換など手動作業も大幅削減できます。

AWS DMS は、ゼロダウンタイム・異種 DB 移行のプラットフォーム として以下を実現します：

• 異種 DB マイグレーション：Oracle → Aurora PostgreSQL など、エンジン間の変換を自動化
• 最小ダウンタイム：Full Load + CDC で カットオーバー時間を秒～分に短縮
• スキーマ自動変換：Schema Conversion Tool（AWS SCT）で DDL・ストアドプロシージャを自動変換
• 継続的レプリケーション：CDC により移行後も本番 DB の変更を AWS にリアルタイム同期
• 複数ターゲット対応：RDS・Aurora・Redshift・DynamoDB・S3・OpenSearch・Kafka への同時転送
• フルマネージド：インスタンス管理・パッチ・バックアップは AWS が実施
• スケーラビリティ：DMS Serverless で自動スケーリング、大規模移行対応

参照：AWS Database Migration Service User Guide

AWS DMS が解決する課題

従来の課題

AWS DMS が提供する解決策

✅ 最小ダウンタイム移行：Full Load + CDC で移行中の変更を継続同期、ダウンタイム分単位
✅ 自動スキーマ変換：SCT で PL/SQL・T-SQL を自動変換、手作業削減
✅ データ整合性保証：CDC により本番 DB の変更をリアルタイムレプリケート、ロスゼロ
✅ 複数エンジンサポート：Oracle / SQL Server / MySQL / PostgreSQL / MariaDB 等から、RDS / Aurora / Redshift / DynamoDB へ
✅ 複数ターゲット同時転送：1 つのタスクで 複数の AWS サービス（RDS + Redshift など）へデータ流出
✅ フルマネージド：インスタンス・ネットワーク・バックアップを AWS が管理
✅ プレマイグレーション評価：DMS Serverless で事前スキャン、互換性問題・パフォーマンスリスク検出

主な特徴

1. 移行タイプ

Full Load（全ロード）:
  ├── ソース DB 全体をターゲットにコピー
  └── 開始時点の静止状態データを転送

Full Load + CDC（フルロード + 継続同期）:
  ├── Phase 1: Full Load で全データ転送
  ├── Phase 2: CDC で Full Load 中・後の変更を同期
  └── 本番カットオーバー直前まで差分を継続同期

CDC のみ（変更のみ同期）:
  ├── ソース DB の変更のみ キャプチャ・転送
  └── ターゲット DB の既存データはそのまま（手動で事前コピー）

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

コンピューティングリソース（EC2 ベース）:
├── dms.t2.small ~ dms.r5.4xlarge（データ量・スループットに応じて選択）
├── Multi-AZ（本番推奨）による HA
├── エラスティック容量（ストレージ）
└── ネットワーク帯域（最大 10 Gbps）

3. エンドポイント（Endpoint）

ソース（移行元）:
├── Oracle・SQL Server・MySQL・PostgreSQL・MariaDB
├── MongoDB・SAP・DB2・Sybase・IBM Informix
└── オンプレ / EC2 / RDS / Aurora

ターゲット（移行先）:
├── RDS（MySQL・PostgreSQL・MariaDB）
├── Aurora（MySQL / PostgreSQL compatible）
├── Redshift（データウェアハウス）
├── DynamoDB（NoSQL）
├── S3（データレイク）
├── OpenSearch（検索・分析）
└── Kafka（ストリーミング）

4. スキーマ変換

Schema Conversion Tool（SCT）:
├── DDL 自動変換（テーブル・インデックス・キー）
├── ストアドプロシージャ / 関数の自動変換
├── トリガー・ビューの変換
├── 互換性レポート生成（変換不可部分を列挙）
└── 手動修正箇所の提示

5. DMS Serverless

自動プロビジョニング・スケーリング:
├── レプリケーションインスタンスサイズを自動決定
├── データ量・スループットに応じて自動調整
├── キャパシティ計画不要
└── 按量課金（使用分のみ）

アーキテクチャと基本概念

DMS 移行アーキテクチャ

┌─────────────────────────────────────────────────┐
│ Source Database                                 │
├─────────────────────────────────────────────────┤
│ - Oracle 10g+                                   │
│ - SQL Server 2008 R2+                           │
│ - MySQL 5.6 / 5.7 / 8.0                         │
│ - PostgreSQL 9.5+                               │
│ - MariaDB, MongoDB, SAP, etc.                   │
│ - On-premises / EC2 / RDS / Aurora              │
└────────────────────┬────────────────────────────┘
                     │ (Network: Direct / VPN)
                     ↓
┌─────────────────────────────────────────────────┐
│ AWS DMS                                         │
├──────────────────────────────────────────────────┤
│ Replication Instance                            │
│ ├── Full Load（全データ転送）                     │
│ ├── CDC（変更データキャプチャ）                    │
│ └── Data Validation（検証）                      │
│                                                  │
│ Table Mapping & Rules                           │
│ ├── スキーマ・テーブル選択                        │
│ ├── フィルタリング                               │
│ └── 変換ルール（大文字・列削除等）                │
└──────────────┬────────────────────────────────┘
               │
      ┌────────┴────────┬──────────┬──────────┐
      ↓                 ↓          ↓          ↓
┌────────────┐   ┌──────────┐  ┌────────┐  ┌────────┐
│  RDS       │   │ Aurora   │  │Redshift│  │S3/DDB  │
│(OLTP)      │   │(OLTP)    │  │(OLAP)  │  │(Lake)  │
└────────────┘   └──────────┘  └────────┘  └────────┘

移行フェーズ

Phase 1: スキーマ変換（Schema Conversion Tool）
  Source DB DDL → AWS SCT → Target DB DDL（互換性チェック）

Phase 2: 事前検証（Premigration Assessment）
  ├── ソース DB テーブル・インデックス スキャン
  ├── ターゲット DB キャパシティ チェック
  ├── ネットワーク接続性・スループット測定
  └── 互換性問題・パフォーマンスリスク検出

Phase 3: Full Load（全データ転送）
  ├── 並列スレッドで テーブル単位にデータ転送
  ├── 進捗トラッキング、エラーリトライ
  └── 検証: ソース行数 ≒ ターゲット行数

Phase 4: CDC（継続同期）
  ├── ソース DB ログ（Binary Log / WAL / Archive Log）をキャプチャ
  ├── 差分変更を ターゲットに リアルタイム適用
  ├── レプリケーションラグ監視
  └── カットオーバー時は ラグ = 0 を確認

Phase 5: カットオーバー（本番切り替え）
  ├── ソース DB 書き込み停止（メンテナンスモード）
  ├── CDC ラグ = 0 を確認
  ├── アプリケーション接続先を ターゲット DB に切り替え
  ├── ユーザー検証（本番トラフィック）
  └── DMS タスク停止、ソース DB 廃止

コアコンポーネント

1. Replication Instance（レプリケーションインスタンス）

実際のデータ転送を実行するコンピューティングリソース:

クラス選択（マイグレーション規模に応じて）:
├── dms.t3.small（小規模、テスト）
├── dms.t3.medium / dms.m5.large（中規模）
├── dms.r5.large / dms.r5.xlarge（大規模）
└── dms.r5.2xlarge / 4xlarge（超大規模エンタープライズ）

ストレージ（メッセージキュー用）:
├── 初期: 100 GB
├── 自動拡張（ディスク満杯時）
└── 最大: 6 TiB

高可用性:
├── Multi-AZ デプロイ（HA）
├── 自動フェイルオーバー（異なる AZ）
└── 99.95% SLA

2. Source Endpoint（ソースエンドポイント）

移行元 DB の接続情報:
├── Engine: Oracle / SQL Server / MySQL / PostgreSQL / MariaDB / MongoDB / etc.
├── Server: IPアドレス or DNS（オンプレ / EC2 / RDS）
├── Port: DB ネイティブポート
├── Username / Password（Secrets Manager で管理推奨）
├── Database / Schema
└── SSL/TLS 設定

事前検証:
├── DMS から ソース DB への接続テスト（Run > Test Connection）
├── 権限確認（SELECT / ログアクセス等）
└── ネットワーク遅延・スループット測定

3. Target Endpoint（ターゲットエンドポイント）

移行先 AWS DB の接続情報:
├── Engine: RDS / Aurora / Redshift / DynamoDB / S3 / OpenSearch / Kafka
├── DB Instance: ARN or DNS
├── IAM ロール（Redshift・S3 アクセス用）
├── Username / Password or Credentials
└── SSL/TLS 設定

事前検証:
├── ターゲット DB のキャパシティ確認
├── DMS からの接続テスト
└── 書き込みパフォーマンス測定

4. Replication Task（レプリケーションタスク）

実行単位（Source + Target + Mapping + Settings の組み合わせ）:
├── Task Identifier: 一意の名前
├── Source Endpoint: 移行元
├── Target Endpoint: 移行先
├── Replication Instance: 実行する インスタンス
├── Migration Type: Full Load / Full Load + CDC / CDC only
├── Table Mappings: スキーマ・テーブル選択・変換ルール
├── Task Settings: 並列度・ログレベル・検証設定
└── Task Status: Creating → Running → Stopped / Failed / Success

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

インスタンス作成（CLI）

# 中規模マイグレーション向け Multi-AZ インスタンス
aws dms create-replication-instance \
  --replication-instance-identifier my-rep-instance \
  --replication-instance-class dms.r5.large \
  --allocated-storage 200 \
  --vpc-security-group-ids sg-xxxxxxxx \
  --replication-subnet-group-identifier my-subnet-group \
  --multi-az \
  --publicly-accessible false \
  --auto-minor-version-upgrade true \
  --tags Key=Environment,Value=production

# インスタンスステータス確認
aws dms describe-replication-instances \
  --query 'ReplicationInstances[*].[ReplicationInstanceIdentifier,ReplicationInstanceStatus,ReplicationInstanceClass]'

自動スケーリング（DMS Serverless）

# DMS Serverless で自動キャパシティプロビジョニング
aws dms create-replication-config \
  --replication-config-identifier my-serverless-config \
  --source-endpoint-arn arn:aws:dms:...:endpoint/source-oracle \
  --target-endpoint-arn arn:aws:dms:...:endpoint/target-aurora \
  --compute-config '{
    "EngineVersion": "3.5.0",
    "KmsKeyId": "arn:aws:kms:...",
    "PreferredMaintenanceWindow": "sun:03:00-sun:04:00",
    "MaximumCapacity": 32,  # DPU（Data Processing Unit）
    "MinimumCapacity": 2
  }' \
  --table-mappings file://table-mappings.json \
  --replication-settings file://task-settings.json

エンドポイント・接続

ソースエンドポイント作成（Oracle オンプレ）

aws dms create-endpoint \
  --endpoint-identifier source-oracle-prod \
  --endpoint-type source \
  --engine-name oracle \
  --server-name oracle-db.onpremise.company.com \
  --port 1521 \
  --database-name PROD \
  --username dms_user \
  --password '${ORACLE_PASSWORD}' \
  --extra-connection-attributes 'logicalLogSourceTableClasses=Redo' \
  --ssl-mode require \
  --tags Key=Source,Value=Oracle

# 接続テスト
aws dms test-connection \
  --replication-instance-arn arn:aws:dms:...:rep:... \
  --endpoint-arn arn:aws:dms:...:endpoint/source-oracle-prod

ターゲットエンドポイント作成（Aurora PostgreSQL）

aws dms create-endpoint \
  --endpoint-identifier target-aurora-postgres \
  --endpoint-type target \
  --engine-name aurora-postgresql \
  --server-name my-aurora-cluster.cluster-xxx.ap-northeast-1.rds.amazonaws.com \
  --port 5432 \
  --database-name proddb \
  --username postgres \
  --password '${AURORA_PASSWORD}' \
  --ssl-mode require \
  --tags Key=Target,Value=Aurora

移行タスク・設定

タスク作成（Full Load + CDC）

aws dms create-replication-task \
  --replication-task-identifier oracle-to-aurora-full \
  --source-endpoint-arn arn:aws:dms:...:endpoint/source-oracle \
  --target-endpoint-arn arn:aws:dms:...:endpoint/target-aurora \
  --replication-instance-arn arn:aws:dms:...:rep/my-rep-instance \
  --migration-type full-load-and-cdc \
  --table-mappings file://table-mappings.json \
  --replication-task-settings file://task-settings.json \
  --cdc-start-position '{"ServerName": "source", "BinLogFilename": "mysql-bin.000123", "BinLogPosition": 12345}' \
  --tags Key=Migration,Value=Oracle2Aurora

# タスク開始
aws dms start-replication-task \
  --replication-task-arn arn:aws:dms:...:task/oracle-to-aurora-full \
  --start-replication-task-type start-replication

Task Settings（タスク設定）

{
  "TargetMetadata": {
    "TargetSchema": "public",
    "SupportCascadingDDL": false,
    "FullLobMode": false
  },
  "FullLoadSettings": {
    "MaxFullLoadSubTasks": 8,
    "BatchApplyEnabled": true,
    "ParallelLoadThreads": 4,
    "TransactionConsistencyTimeout": 600000
  },
  "ChangeProcessingDdlHandlingPolicy": {
    "HandleSourceTableDropped": true,
    "HandleSourceTableAltered": true,
    "HandleSourceTableAlterOrDrop": true
  },
  "ValidationSettings": {
    "EnableValidation": true,
    "ValidationMode": "ROW_LEVEL",
    "ThreadCount": 5,
    "FailureMaxCount": 10000
  },
  "Logging": {
    "EnableLogging": true,
    "LogComponents": [
      {
        "Id": "SOURCE_UNLOAD",
        "Severity": "LOGGER_SEVERITY_DEFAULT"
      },
      {
        "Id": "SOURCE_CAPTURE",
        "Severity": "LOGGER_SEVERITY_INFO"
      },
      {
        "Id": "TARGET_LOAD",
        "Severity": "LOGGER_SEVERITY_INFO"
      }
    ]
  }
}

DMS Serverless

DMS Serverless の利点

1. 自動キャパシティプロビジョニング:
   └── インスタンスサイズを自動決定、キャパシティ計画不要

2. 按量課金:
   └── 使用量（DPU・時間）に応じた課金

3. スケーリング容易:
   └── 並列度・メモリを動的調整、大規模移行対応

4. インスタンス管理不要:
   └── AWS がメンテナンス・バージョン管理

Serverless Migration Config 作成

aws dms create-replication-config \
  --replication-config-identifier my-serverless-dms \
  --source-endpoint-arn arn:aws:dms:...:endpoint/source \
  --target-endpoint-arn arn:aws:dms:...:endpoint/target \
  --compute-config '{
    "KmsKeyId": "arn:aws:kms:region:account:key/key-id",
    "MaximumCapacity": 32,
    "MinimumCapacity": 2,
    "MultiAZ": true,
    "PreferredMaintenanceWindow": "sun:03:00-sun:04:00",
    "EngineVersion": "3.5.0"
  }' \
  --table-mappings file://table-mappings.json \
  --migration-type full-load-and-cdc \
  --tags Key=Name,Value=Serverless-Migration

Schema Conversion Tool（SCT）統合

SCT でのスキーマ変換フロー

Step 1: SCT プロジェクト作成
  ├── Source Engine: Oracle
  ├── Target Engine: PostgreSQL
  └── Connection: Oracle DB 接続（オンプレ / RDS）

Step 2: ソース DB スキャン
  ├── テーブル・インデックス・キー 検出
  ├── ストアドプロシージャ・関数 抽出
  ├── トリガー・ビュー スキャン
  └── 互換性評価: 変換可能 / 要修正 / 変換不可 を分類

Step 3: 自動変換
  ├── DDL 変換（CREATE TABLE / INDEX）
  ├── PL/SQL → PostgreSQL PL/pgSQL 変換
  ├── データ型マッピング（NUMBER → NUMERIC）
  └── トリガー・ビュー 変換

Step 4: 互換性レポート生成
  ├── 変換できた要素 列挙
  ├── 変換に要修正の要素 提示
  └── 完全変換不可な要素 説明

Step 5: 手動修正
  ├── SCT エディタで修正
  ├── 複雑なビジネスロジック（DBMS_JOB等）を手動コード化
  └── テスト

Step 6: ターゲット DB にスキーマを作成
  ├── SCT から CREATE TABLE スクリプト出力
  ├── AWS DMS + SCT で自動 DDL 実行
  └── インデックス・約束制約も同時作成

SCT コマンド例（CLI）

# SCT プロジェクト作成
aws-schema-conversion-tool create-project \
  --project-id my-oracle-to-postgres \
  --source-engine-name Oracle \
  --target-engine-name PostgreSQL \
  --source-connection-string 'Server=oracle-db.onpremise.com;Database=PROD;User=dms_user;Password=xxxxx' \
  --target-connection-string 'Server=my-aurora.ap-northeast-1.rds.amazonaws.com;Database=proddb;User=postgres;Password=xxxxx'

# ソース DB スキャン・変換
aws-schema-conversion-tool analyze \
  --project-id my-oracle-to-postgres \
  --schema-source 'PROD.%' \
  --output-dir ./conversion-report

CDC（Change Data Capture）

CDC の仕組み

ソース DB のログをキャプチャ：

1. Binary Log（MySQL / MariaDB）:
   ├── row-based logging 有効化
   ├── DMS が binlog をリアルタイム読み込み
   └── INSERT/UPDATE/DELETE を ターゲットに適用

2. WAL（PostgreSQL）:
   ├── logical replication slot 作成
   ├── DMS が WAL ストリーム購読
   └── 差分変更を ターゲットに送信

3. Archive Log / Redo Log（Oracle）:
   ├── Oracle LogMiner（Oracle 自体のツール）で ログ解析
   ├── DMS が Oracle LogMiner から変更キャプチャ
   └── ターゲット Oracle / Aurora にリプリケート

4. Transaction Log（SQL Server）:
   ├── SQL Server Change Tracking 有効化
   ├── DMS が Tlog から変更読み込み
   └── ターゲット SQL Server / RDS に同期

CDC タスク開始

# Full Load + CDC 合わせて開始（推奨）
aws dms start-replication-task \
  --replication-task-arn arn:aws:dms:...:task/oracle-to-aurora \
  --start-replication-task-type start-replication \
  # 自動的に Full Load 後、CDC に遷移

# CDC のみ開始（ソースに既存データ、ターゲットに事前コピー済み）
aws dms start-replication-task \
  --replication-task-arn arn:aws:dms:...:task/cdc-only \
  --start-replication-task-type cdc \
  --cdc-start-position '{
    "ServerName": "source",
    "BinLogFilename": "mysql-bin.000456",
    "BinLogPosition": 98765
  }'

CDC ラグ監視

# CDC レプリケーションラグを監視
aws dms describe-table-statistics \
  --replication-task-arn arn:aws:dms:...:task/oracle-to-aurora \
  --query 'TableStatistics[*].[SchemaName,TableName,CDCLatencyTarget,CDCLatencySource]'

# CloudWatch メトリクス確認
aws cloudwatch get-metric-statistics \
  --namespace AWS/DMS \
  --metric-name CDCLatencyTarget \
  --dimensions Name=ReplicationInstanceIdentifier,Value=my-rep-instance \
  --start-time 2026-04-26T00:00:00Z \
  --end-time 2026-04-26T12:00:00Z \
  --period 300 \
  --statistics Average,Maximum

テーブルマッピング・変換ルール

Table Mappings JSON

{
  "rules": [
    {
      "rule-type": "selection",
      "rule-id": "1",
      "rule-name": "include-all-tables",
      "object-locator": {
        "schema-name": "SALES",
        "table-name": "%"
      },
      "rule-action": "include",
      "comments": "Replicate all tables from SALES schema"
    },
    {
      "rule-type": "selection",
      "rule-id": "2",
      "rule-name": "exclude-large-logs",
      "object-locator": {
        "schema-name": "LOGS",
        "table-name": "%"
      },
      "rule-action": "exclude",
      "comments": "Skip LOGS schema (too large)"
    },
    {
      "rule-type": "transformation",
      "rule-id": "3",
      "rule-name": "convert-schema-to-lowercase",
      "rule-action": "convert-lowercase",
      "rule-target": "schema",
      "object-locator": {
        "schema-name": "%"
      }
    },
    {
      "rule-type": "transformation",
      "rule-id": "4",
      "rule-name": "convert-table-to-snake_case",
      "rule-action": "add-prefix",
      "rule-target": "table",
      "value": "tbl_",
      "object-locator": {
        "schema-name": "SALES",
        "table-name": "%"
      }
    },
    {
      "rule-type": "transformation",
      "rule-id": "5",
      "rule-name": "exclude-sensitive-column",
      "rule-action": "remove-column",
      "rule-target": "column",
      "object-locator": {
        "schema-name": "CUSTOMERS",
        "table-name": "USERS",
        "column-name": "SSN"
      },
      "comments": "Remove PII - Social Security Number"
    },
    {
      "rule-type": "transformation",
      "rule-id": "6",
      "rule-name": "mask-credit-card",
      "rule-action": "data-obfuscation",
      "rule-target": "column",
      "object-locator": {
        "schema-name": "PAYMENTS",
        "table-name": "%",
        "column-name": "CARD_NUMBER"
      },
      "obfuscation-info": {
        "obfuscation-type": "mask-last-four",
        "replace-with-dummy-value": "1111222233334444"
      }
    }
  ]
}

CLI・SDK・IaC 実装例

Terraform で DMS タスク自動化

resource "aws_dms_replication_instance" "main" {
  replication_instance_class   = "dms.r5.large"
  replication_instance_identifier = "oracle-to-aurora"
  allocated_storage            = 200
  publicly_accessible          = false
  multi_az                      = true
  vpc_security_group_ids        = [aws_security_group.dms.id]
  replication_subnet_group_id   = aws_dms_replication_subnet_group.main.id

  tags = {
    Name = "Migration-Replication"
  }
}

resource "aws_dms_endpoint" "source_oracle" {
  endpoint_type = "source"
  engine_name   = "oracle"
  server_name   = "oracle-prod.onpremise.com"
  port          = 1521
  database_name = "PROD"
  username      = "dms_user"
  password      = var.oracle_password

  tags = {
    Name = "Source-Oracle"
  }
}

resource "aws_dms_endpoint" "target_aurora" {
  endpoint_type = "target"
  engine_name   = "aurora-postgresql"
  server_name   = aws_rds_cluster.aurora.cluster_resource_id
  port          = 5432
  database_name = "proddb"
  username      = "postgres"
  password      = var.aurora_password
  ssl_mode      = "require"

  tags = {
    Name = "Target-Aurora"
  }
}

resource "aws_dms_replication_task" "oracle_to_aurora" {
  replication_instance_arn      = aws_dms_replication_instance.main.arn
  replication_task_identifier   = "oracle-to-aurora-full-cdc"
  migration_type                = "full-load-and-cdc"
  source_endpoint_arn           = aws_dms_endpoint.source_oracle.arn
  target_endpoint_arn           = aws_dms_endpoint.target_aurora.arn
  table_mappings                = jsonencode(local.table_mappings)
  replication_task_settings     = jsonencode(local.task_settings)
  start_replication_task        = true

  depends_on = [
    aws_dms_replication_instance.main
  ]

  tags = {
    Name = "Migration"
  }
}

Python SDK 例

import boto3
import json
from datetime import datetime

dms = boto3.client('dms', region_name='ap-northeast-1')

# タスク進捗監視
def monitor_migration_task(task_arn):
    while True:
        response = dms.describe_replication_tasks(
            Filters=[
                {'Name': 'replication-task-arn', 'Values': [task_arn]}
            ]
        )
        task = response['ReplicationTasks'][0]
        
        print(f"Status: {task['Status']}")
        print(f"PercentComplete: {task.get('ReplicationTaskStats', {}).get('PercentComplete')}%")
        print(f"TablesLoaded: {task.get('ReplicationTaskStats', {}).get('TablesLoaded')}")
        print(f"TablesLoading: {task.get('ReplicationTaskStats', {}).get('TablesLoading')}")
        print(f"CDCLatencyTarget: {task.get('ReplicationTaskStats', {}).get('CDCLatencyTarget')} ms")
        
        if task['Status'] in ['stopped', 'failed']:
            break
        
        time.sleep(30)

# テーブル統計確認
def get_table_stats(task_arn):
    response = dms.describe_table_statistics(
        ReplicationTaskArn=task_arn
    )
    
    for table in response['TableStatistics']:
        print(f"{table['SchemaName']}.{table['TableName']}")
        print(f"  FullLoadRows: {table['FullLoadRows']}")
        print(f"  InsertCount: {table['Inserts']}")
        print(f"  UpdateCount: {table['Updates']}")
        print(f"  DeleteCount: {table['Deletes']}")
        print(f"  ValidationState: {table.get('ValidationState', 'N/A')}")

セキュリティ・暗号化

転送中の暗号化

# SSL/TLS を強制（MySQL）
aws dms create-endpoint \
  --endpoint-identifier mysql-endpoint \
  --engine-name mysql \
  --server-name mysql.example.com \
  --ssl-mode require \
  --certificate-arn arn:aws:acm:...:certificate/... \
  # DMS → MySQL 間の通信を TLS で暗号化

保存時の暗号化（KMS）

# DMS レプリケーションインスタンスの KMS 暗号化
aws dms create-replication-instance \
  --replication-instance-identifier encrypted-rep \
  --kms-key-id arn:aws:kms:region:account:key/key-id \
  # EBS ストレージ・メッセージキューを KMS で暗号化

IAM ポリシー（最小権限）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DMSTaskManagement",
      "Effect": "Allow",
      "Action": [
        "dms:DescribeReplicationTasks",
        "dms:StartReplicationTask",
        "dms:StopReplicationTask",
        "dms:DescribeTableStatistics"
      ],
      "Resource": "arn:aws:dms:region:account:task:migration-*"
    },
    {
      "Sid": "SecretsManagerAccess",
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue"
      ],
      "Resource": "arn:aws:secretsmanager:region:account:secret:dms-*"
    }
  ]
}

監視・パフォーマンスチューニング

CloudWatch メトリクス

主要メトリクス:

FullLoadThroughput（全ロード時スループット）:
  └── MB/sec で送信率を監視

CDCLatencySource（ソース側 CDC ラグ）:
  └── ソース DB のログキャプチャ遅延

CDCLatencyTarget（ターゲット側 CDC ラグ）:
  └── ターゲットへのデータ適用遅延（カットオーバー判断に重要）

CPUUtilization / FreeMemory:
  └── レプリケーションインスタンスのリソース使用率

TableLoadProgressPercentage:
  └── Full Load の進捗度（0～100%）

パフォーマンスチューニング

# タスク設定で並列度を調整
{
  "FullLoadSettings": {
    "MaxFullLoadSubTasks": 12,        # デフォルト 8、並列テーブル数を増加
    "ParallelLoadThreads": 8,         # テーブル内並列スレッド
    "BatchApplyEnabled": true,        # バッチ適用で I/O 最適化
    "BatchApplyTimeoutMin": 1,
    "BatchApplyMemoryLimit": 1000,
    "CommitTimeout": 5000,
    "TransactionConsistencyTimeout": 600000
  }
}

# リソース増強
# → インスタンスクラス dms.m5.large → dms.r5.xlarge にスケールアップ
# → Multi-AZ を有効化（本番推奨）

類似ツール比較表

ベストプラクティス

計画・設計段階

✅ 事前スキャン・互換性評価

• DMS Serverless の Premigration Assessment で ソース・ターゲットを検査
• 互換性問題・パフォーマンスリスクを早期検出

✅ Schema Conversion Tool で DDL 変換テスト

• Oracle PL/SQL → PostgreSQL への自動変換を事前検証
• 変換不可部分を特定し、手動対応計画立案

✅ ネットワーク・スループット確認

• DMS レプリケーションインスタンス ↔ ソース DB 間の接続性テスト
• 推定マイグレーション時間を計算（データサイズ÷スループット）

✅ ターゲット DB キャパシティ計画

• RDS / Aurora インスタンスサイズをソース DB 負荷の 1.5～2 倍に設定
• インデックス・統計情報 作成の時間を余裕を持たせる

実装段階

✅ Multi-AZ レプリケーションインスタンス

• 本番マイグレーションは高可用性を確保
• 自動フェイルオーバーで障害時も継続

✅ Full Load + CDC の段階的実行

• Phase 1: テスト環境で Full Load テスト（ダウンタイムなし）
• Phase 2: 本番環境で Full Load 実行
• Phase 3: CDC で差分同期、カットオーバー前にラグ = 0 確認

✅ テーブルマッピングルールで柔軟性確保

• 大規模テーブルは除外・分割して並列マイグレーション
• PII（SSN・クレジットカード）はマスキング・削除ルール設定

✅ バリデーション有効化

• Task Settings で EnableValidation: true 設定
• Full Load 完了後、ソース・ターゲットの行数・チェックサム比較

運用・監視

✅ CloudWatch アラーム設定

• CDCLatencyTarget > 300 秒でアラート（カットオーバー判断基準）
• CPU / メモリ 80% 超過で通知

✅ 定期的なレプリケーションラグ監視

watch -n 10 'aws dms describe-table-statistics \
  --replication-task-arn ... \
  --query "TableStatistics[*].[TableName,CDCLatencyTarget]"'

✅ エラーハンドリング

• DDL エラー（不正な型変換）は Task で自動スキップ可能
• ただし重大エラーは手動対応が必要

トラブルシューティング

2025-2026 最新動向

1. DMS Serverless プレマイグレーション評価（2025年2月）

• 自動互換性検査：ソース・ターゲット DB をスキャン、移行前の問題を検出
• パフォーマンス分析：テーブルサイズ・複雑性から最適インスタンス推奨
• 参照: Announcing AWS DMS Serverless comprehensive premigration assessments

2. Fleet Advisor サポート終了（2026年5月20日予定）

• 移行理由：Discovery 機能が DMS Serverless に統合
• 対策：既存 Fleet Advisor ユーザーは DMS Serverless への移行を検討

3. DMS v3.5 / Data Provider・Migration Project

• ノーコード・スキーマレス移行：AWS Management Console から直感的に操作
• Data Provider：カスタムデータソース定義
• Migration Project：複数タスク・マイグレーション計画の一元管理

4. リアルタイムレプリケーション拡張

• EventBridge 統合：CDC イベントを EventBridge に送信、Lambda トリガー
• Kinesis ストリーミング：CDC ログを Kinesis Data Streams に連携

学習リソース

公式ドキュメント

1. AWS DMS User Guide
2. AWS DMS API Reference
3. AWS Schema Conversion Tool User Guide
4. DMS Serverless Documentation
5. Working with Table Mappings
6. Change Data Capture (CDC)

AWS ブログ・チュートリアル

1. AWS DMS Latest Updates
2. DMS Serverless Getting Started
3. Zero-Downtime Migration Patterns

コミュニティ・参考

1. GoldenGate - Oracle Official
2. Striim Platform
3. Debezium - Open Source CDC
4. Confluent Replicator

実装例・チェックリスト

実装例：Oracle → Aurora PostgreSQL フルマイグレーション

# Step 1: SCT で DDL 変換
aws-schema-conversion-tool create-project \
  --project-id oracle-to-aurora \
  --source-engine-name Oracle \
  --target-engine-name PostgreSQL \
  # PL/SQL を自動変換

# Step 2: DMS レプリケーションインスタンス作成
aws dms create-replication-instance \
  --replication-instance-identifier migration-rep \
  --replication-instance-class dms.r5.large \
  --multi-az

# Step 3: エンドポイント作成・テスト
aws dms create-endpoint \
  --endpoint-identifier source-oracle \
  --engine-name oracle \
  --server-name oracle-prod.company.com

aws dms test-connection \
  --replication-instance-arn ... \
  --endpoint-arn ...

# Step 4: マイグレーションタスク実行
aws dms create-replication-task \
  --replication-task-identifier oracle-aurora-full-cdc \
  --migration-type full-load-and-cdc \
  ...

# Step 5: 進捗監視
aws dms describe-replication-tasks \
  --filters Name=replication-task-arn,Values=...

# Step 6: バリデーション
aws dms describe-table-statistics \
  --replication-task-arn ... \
  --query 'TableStatistics[*].[TableName,ValidationState]'

# Step 7: カットオーバー
# CDC ラグ = 0 を確認後、アプリケーション接続先を Aurora に切り替え

導入チェックリスト

• [ ] 計画段階

  • [ ] ソース DB の構成・サイズ・複雑性をドキュメント化
  • [ ] ターゲット AWS DB（RDS / Aurora / Redshift）を決定
  • [ ] 必要なダウンタイム（許容値）定義
  • [ ] マイグレーション スケジュール・ウィンドウ決定

• [ ] 設計段階

  • [ ] Schema Conversion Tool で DDL 互換性評価
  • [ ] Table Mappings / 変換ルール設計
  • [ ] DMS Serverless vs Traditional Instance 検討
  • [ ] セキュリティ設計（KMS・IAM・ネットワーク）

• [ ] テスト段階

  • [ ] 開発環境で Full Load テスト実行
  • [ ] CDC ラグ・パフォーマンス測定
  • [ ] バリデーション結果確認（行数・チェックサム）
  • [ ] フェイルオーバー・リトライ動作確認

• [ ] 本番段階

  • [ ] ソース DB バックアップ実施
  • [ ] CloudWatch アラーム設定
  • [ ] Full Load 開始
  • [ ] CDC で差分同期、ラグ監視
  • [ ] カットオーバー計画・リハーサル
  • [ ] 本番切り替え・ロールバック手順用意

• [ ] 運用段階

  • [ ] マイグレーション後の検証・監視（1～2週間）
  • [ ] ターゲット DB パフォーマンスチューニング
  • [ ] インデックス再作成・統計更新
  • [ ] ソース DB 廃止タイミング決定

まとめ

AWS DMS は「複雑なオンプレ DB を AWS へ最小ダウンタイムで移行する標準プラットフォーム」 です。

主要なポイント：

1. ゼロダウンタイム移行：Full Load + CDC で移行中も本番サービス継続
2. スキーマ自動変換：Oracle → PostgreSQL などの複雑な変換を自動化
3. 複数ターゲット対応：RDS・Aurora・Redshift・DynamoDB・S3 に同時配信
4. DMS Serverless：インスタンス管理不要、自動スケーリング
5. プレマイグレーション評価：事前スキャンで互換性問題を検出

採用判断：

✅ AWS DMS を選ぶべき：

• オンプレ / 自社ホスト DB を AWS に移行したい
• ダウンタイム最小化が重要
• 複雑なスキーマ（ストアドプロシージャ・トリガー）がある
• 移行後も本番 DB との継続レプリケーション必要

❌ AWS DMS ではなく AWS Glue・Lambda を選ぶべき：

• バッチベースの定期 ETL（日次・週次）
• 複雑なデータ変換・クレンジングが必須
• Spark・Python での カスタムロジック重視

AWS DMS は、エンタープライズ DB 移行・最小ダウンタイム・自動化 の 3 つを求める大規模組織に最適です。

参考文献

公式ドキュメント

• AWS DMS User Guide
• AWS DMS API Reference
• AWS Schema Conversion Tool
• DMS Best Practices

AWS ブログ・リリースノート

• AWS Database Blog
• Announcing AWS DMS Serverless comprehensive premigration assessments
• DMS Release Notes

代替ツール

• GoldenGate - Oracle
• Striim - Real-time Streaming
• Fivetran - SaaS Data Integration
• HVR - Heterogeneous Replication
• Debezium - Open Source CDC
• Confluent Replicator

最終更新：2026-04-26
バージョン：v2.0