【AWS】DMS について詳細調査（SQL Server → Redshift）

2026年7月8日

DMS とは何か

AWS DMS（AWS Database Migration Service）は、DB 間でデータを移行・継続同期するためのマネージドサービスです。

AWS DMS とはDMS は AWS Database Migration Service の略で、簡単に言うと、あるデータベースのデータを、別のデータベースや S3 などの保存先へ移行・同期するための AWS サービスです。リレーショナルDB、データウェアハウス、NoSQL DB、その他データストアの移行に使えるサービスと説明されています。DMS は、元DBを読み取り、DMSが中継し、先DBへデータを流す仕組みです。以下のイメージです。SQL Server / MySQL / PostgreSQL / Oracle など ↓ AWS DMS ↓Redshift / RDS / Aurora / S3 などこのように、DBのデ...

SQL Server → Redshift の場合は、以下のような役割です。

SQL Server
  ↓
AWS DMS レプリケーションインスタンス
  ↓
一時的な CSV / 変更データ
  ↓
S3
  ↓
Redshift COPY
  ↓
Redshift テーブル

DMS のタスクでは、主に次の3つの移行方式があります。

方式	内容	用途
フルロード、再ロード、Full Load	既存データを一括コピー	初回移行
CDC only	変更分だけ連携	既にターゲットに初期データがある場合
フルロード + CDC	初期データをコピーし、その後の変更も継続反映	本番系の継続レプリケーションでよく使う

DMS タスクは Full load、Full load + CDC、CDC only を選択でき、Full load + CDC では既存データをロードしながらソース側の変更を捕捉し、フルロード後に変更分をターゲットへ適用すると説明されています。

DMS の主要コンポーネント

DMS は、主に以下で構成されます。

コンポーネント	役割
レプリケーションインスタンス	DMS タスクを実行する実体。ソースから読み、ターゲットへ書く処理を行う
ソースエンドポイント	SQL Server への接続情報
ターゲットエンドポイント	Redshift への接続情報
レプリケーションタスク	どのテーブルを、どの方式で、どの設定で連携するか
テーブルマッピング	対象スキーマ・テーブル・除外条件・変換ルール
タスク設定 JSON	タスク設定 JSON

DMS タスクには、レプリケーションインスタンス、ソースエンドポイント、ターゲットエンドポイント、移行方式、テーブルマッピング、CloudWatch ログなどを指定します。

SQL Server → Redshift の全体像

SQL Server → Redshift の DMS は、SQL Server のトランザクションログ / CDC 情報を読み取り、Redshift に反映する仕組みです。

ただし Redshift は OLTP DB ではなく、分析向けの DWH です。そのため、DMS は Redshift に対して1行ずつ直接 JDBC で INSERT / UPDATE / DELETE するというより、S3 を中間置き場として使い、Redshift の COPY でまとめて取り込む動きになります。

Redshift がターゲットの場合、DMS はまずデータを CSV ファイルにエクスポートし、S3 バケットへアップロードし、その後 Redshift の COPY コマンドで対象テーブルにロードすると説明されています。

Amazon Redshiftへのデータベース移行中、AWS DMSはまずデータをAmazon S3バケットに移動します。ファイルがAmazon S3バケットに格納されると、AWS DMSはそれらをAmazon Redshiftデータウェアハウス内の適切なテーブルに転送します。AWS DMSは、Amazon Redshiftデータベースと同じAWSリージョンにS3バケットを作成します。AWS DMSレプリケーションインスタンスも、同じAWSリージョンに配置する必要があります。

AWS DMS は、Amazon S3 バケットを使用してデータを Amazon Redshift データベースに転送します。AWS DMS がバケットを作成するには、コンソールで IAM ロールを使用します
dms-access-for-endpoint。AWS CLI または DMS API を使用して、ターゲットデータベースとして Amazon Redshift を指定してデータベース移行を作成する場合は、この IAM ロールを作成する必要があります。

Amazon Redshift ターゲットの中間ストレージとして使用する S3 バケットでは、バージョン管理を有効にしないでください。S3 バージョン管理が必要な場合は、ライフサイクルポリシーを使用して古いバージョンを積極的に削除してください。そうしないと、S3
list-object 呼び出しのタイムアウトによりエンドポイントテストの接続が失敗する可能性があります。

DMS ログを調査すると S3 バケットへのアップロードなどが出てきます。SQL Server → Redshift のレプリケーションで S3 は中間領域として使われます。

初回ロードと CDC の流れ

たとえば SQL Server に以下のテーブルがあるとします。

CREATE TABLE dbo.user (
    id INT NOT NULL PRIMARY KEY,
    name NVARCHAR(100) NOT NULL,
    status NVARCHAR(20) NULL,
    updated_at DATETIME2 NOT NULL
);

DMS タスクを Full load + CDC で開始すると、流れは以下になります。

フェーズ1：Full Load

最初に、SQL Server の既存データを読みます。

SELECT * FROM dbo.user;

DMS は取得したデータを内部的に CSV 化し、S3 に置き、Redshift の COPY で取り込みます。

SQL Server dbo.user
  ↓
DMS
  ↓
S3: 一時CSV
  ↓
Redshift COPY
  ↓
Redshift public.user

Redshift ターゲットでは、フルロード（Full Load）時に DMS がソースレコードを CSV ファイルへ変換し、S3 の BucketFolder/TableID 配下へロードし、COPY 完了後にファイルを削除する仕様です。CDC 時は NetChanges テーブル用のパスへ変更データをロードします。

フェーズ2：Full Load 中の変更をキャッシュ

Full Load 中にもアプリケーションは SQL Server を更新し続ける可能性があります。

INSERT INTO dbo.user (id, name, status, updated_at)
VALUES (101, N'山田', N'active', SYSDATETIME());

UPDATE dbo.user
SET status = N'inactive', updated_at = SYSDATETIME()
WHERE id = 10;

DELETE FROM dbo.user
WHERE id = 20;

DMS はフルロード（Full Load）中に発生した変更を CDC として捕捉し、あとで Redshift に反映します。

フェーズ3：CDC 継続同期

Full Load が終わった後、DMS は SQL Server の変更ログを読み続けます。

SQL Server の INSERT / UPDATE / DELETE
  ↓
DMS が変更を捕捉
  ↓
S3 に変更データを一時出力
  ↓
Redshift に反映

DMS は CDC では DB エンジンのログを使って変更を収集します。変更適用が追いつかない場合、DMS はレプリケーションインスタンス上に変更をバッファし、メモリが足りなくなるとディスク上の Change Cache に、一時的にスピルする（メモリからディスク溢れだす）ことがあります。

SQL Server 側の CDC の考え方

SQL Server を DMS のソースにして継続レプリケーションする場合、DMS は SQL Server 側で変更を追跡できる状態を必要とします。

公式ドキュメントでは、SQL Server ソースで CDC を使うには、SQL Server が Full Backup 構成であること、リカバリモデルが FULL または BULK_LOGGED であること、DMS の CDC には SQL Server 側でフルトランザクションログが必要であり、MS-Replication または SQL Server CDC を有効にする必要があると説明されています。

BULK_LOGGED

BULK_LOGGED とは、SQL Server の 復旧モデル（Recovery Model） の1つです。

大量データ投入やインデックス作成などの一部のバルク処理で、トランザクションログの出力量を減らすためのモードです。

SQL Server の復旧モデルには主に以下があります。

復旧モデル（リカバリモデル）	概要	CDC 利用
SIMPLE	ログバックアップなし。復旧できるのは基本的にバックアップ時点まで	✖
FULL	すべての変更をログに記録。任意時点復旧が可能	〇
BULK_LOGGED	FULL に近いが、一部の大量処理を最小ログ記録にする	〇

オンプレミスや EC2 上の SQL Server の場合

オンプレミスや EC2 上の SQL Server では、DMS は基本的に以下の使い分けをします。

テーブル状態	DMS の変更取得方式
主キーあり	SQL Server Replication
主キーなし	SQL Server CDC

self-managed SQL Server では、主キーありテーブルの変更捕捉に MS-Replication、主キーなしテーブルの変更捕捉に MS-CDC を使うと説明されています。

RDS for SQL Server の場合

Amazon RDS for SQL Server は MS-Replication をサポートしないため、DMS は主キーあり・なしに関係なく MS-CDC を使う必要があると説明されています。

そのため、RDS SQL Server → Redshift の構成では、データベースレベル CDC とテーブルレベル CDC が非常に重要です。

MS-Replication

MS-Replication は、正式には Microsoft SQL Server Replication のことです。

SQL Server にあるデータやDBオブジェクトを、別のDBへコピー・配布し、その後も同期するための SQL Server 標準機能です。Replication は「あるDBから別のDBへデータやDBオブジェクトをコピー・配布し、整合性を保つために同期する技術群」と説明されています。

AWS Summit Japan 2026 に参加してのセッションメモ