AWS DMS で Amazon RDS for SQL Server のデータ移行を行う～ Serverless 編～
コーヒーが好きな emi です。最近はカフェインを控えています。
以下のブログで、DMS のレプリケーションインスタンス（プロビジョンドインスタンス）を作成し、プロビジョンドモードで RDS for SQL Server のデータ移行検証を行いました。
今回は上記ブログの環境でレプリケーションインスタンス（プロビジョンドインスタンス）を削除し、DMS のタスクモードをサーバーレスにして RDS for SQL Server のデータ移行を試してみます。
構成イメージ
以下の構成で検証します。Windows Server 2022 には SQL Server Management Studio（SSMS）をインストールしておき、ソースとなる DB とターゲットとなる DB に接続して中身のデータを確認するために使います。
0. 準備
レプリケーションインスタンスとプロビジョンドタスクの削除
AWS DMS で Amazon RDS for SQL Server のデータ移行を行う | DevelopersIO で作成した構成から、レプリケーションインスタンス（プロビジョンドインスタンス）を削除しておきます。
普通に削除しようとすると、削除できませんでした。
詳細を表示すると、
Replication Instance 'dms-replication-instance' has one or more replication tasks.
（機械翻訳）レプリケーションインスタンス 『dms-replication-instance』 には、1つ以上のレプリケーションタスクが存在します。
つまり、レプリケーションインスタンスが紐づいているレプリケーションタスクを先に削除しておかないといけないそうです。
タスクを削除しましょう。
すぐに削除できました。
再度レプリケーションインスタンスを削除します。
10 分程度待ち、今度は削除できました。
ターゲット DB の掃除
AWS DMS で Amazon RDS for SQL Server のデータ移行を行う | DevelopersIO でデータが移行された状態になっているので、user テーブルを丸ごと削除しておきます。
user テーブルの削除
DROP TABLE dbo.[user];
データベース内のテーブル一覧の表示
SELECT name FROM sys.tables;
これは「sys.tables という表から、name 列の値を取り出して見る」というコマンドです。SQL Server には MySQL のように show tables; のようなテーブル一覧を表示するコマンドがありませんので、select でテーブル一覧を表示します。
sys.tables は SQL Server が内部で持っているシステムビュー（メタ情報の表）で、「このデータベースにどんなテーブルがあるか」という情報が格納されています。普通のユーザーが作るテーブルではなく、データベースの管理用テーブルです。
sys.tables には「テーブルID」「作成日時」「スキーマID」など様々な列があり、その中の一つが name 列で、テーブルの名前が入っています。
SELECT name FROM sys.tables; と書くと、テーブル名だけ一覧で表示されるわけです。
name に何もない、つまり、テーブルは無い状態であることが確認できました。
エンドポイント接続の確認（できない）
レプリケーションインスタンスがあった時は、レプリケーションエンドポイントとの接続確認を行うことができ、接続がうまくいっていないとタスクが作成できませんでした。
サーバーレスの場合はどうなるのか確認してみます。
「接続のテスト」をクリックすると、
Important: Connection testing for AWS DMS Serverless endpoints
When using endpoints with DMS Serverless replications, you cannot perform connection testing through this interface. DMS Serverless automatically validates your endpoint connection as part of the startup sequence when you start replication.
（機械翻訳）重要: AWS DMS サーバーレス エンドポイントの接続テストについてDMS サーバーレス レプリケーションでエンドポイントを使用する場合、このインターフェースを通じて接続テストを実行することはできません。DMS サーバーレスは、レプリケーションを開始する際の起動シーケンスの一環として、エンドポイント接続を自動的に検証します。
タスクモードがサーバーレスの場合、エンドポイント接続の確認はこの画面からはできないそうです。AWS 側で接続の確認を行ってくれるようです。
1. レプリケーションタスク（サーバーレス）の作成
レプリケーションタスクのタスクモードをサーバーレスで作成します。サーバーレス方式の場合はレプリケーションインスタンスを作成する必要がないので、もうタスクの作成に進みます。
タスク名、ソース DB、ターゲット DB を指定し、タスクモードはサーバーレスを選択します。タスクタイプは移行のみとします。
ターゲットテーブル準備モードは「ターゲットのテーブルをドロップ（削除）」、「レプリケーションに LOB 列を含める」では、デフォルトの「制限付き LOB モード」のままにします。
設定値の説明は AWS DMS で Amazon RDS for SQL Server のデータ移行を行う | DevelopersIO - 5. 移行タスクの作成 を参照してください。
高度な設定はデフォルトのまま進めます。
テーブルマッピングではウィザードを選択して「新しい選択ルールを追加」をクリックします。
今回は以下のように設定します。
- スキーマ名：
dbo - スキーマテーブル名：
user - アクション：含む
RDS for SQL Server に SQL Server Management Studio（SSMS）でデータを挿入する | DevelopersIO でデータを挿入したテーブルの情報を入れています。
作成済みの VPC、サブネットグループ、セキュリティグループを設定します。セキュリティグループは、レプリケーションインスタンスに設定したのと同じものを設定しています。
検証のため、可用性ではシングル AZ を選択しコストを抑えます。
アベイラビリティゾーンは指定なしで進めます。
「キャパシティ」では、レプリケーションに使用するコンピューティングリソースのキャパシティの最小値と最大値を設定します。このキャパシティは、DMS キャパシティユニット（DCU）と言います。
最小値は任意で、何も設定しないと 1 DCU（1 vCPU、2 GiB）になります。
最大値は必須項目です。
（参照）キャパシティ情報タブ転記
AWS DMS computes the minimum capacity required to successfully complete each replication. AWS DMS bases this assessment on the replication's workload. You set the maximum capacity for the replication. AWS DMS uses this range to create scaling rules for the following thresholds:
CPU utilization
Connections
Available memory
AWS DMS can increase capacity to the value of Maximum.
前回レプリケーションインスタンスを作成したとき t3.medium（2 vCPU、CPU バーストクレジットあり、 4 GiB メモリ）を指定したので、似たようなキャパシティとして、最大 DCU は 2 DCU（2 vCPU、4 GiB メモリ）にしてみました。
メンテナンスウィンドウを設定し、タスクを作成します。
サーバーレスタスクが作成されました。
2. レプリケーションタスク（サーバーレス）の開始
アクションからタスクを開始します。
移行前評価はオフにしてタスクを開始します。移行前評価はあとで検証しましょう。
タスクのステータスが初期化中となり、
メタデータの準備中となり、
キャパシティのプロビジョニング中となります。
キャパシティのプロビジョニングが終わり、タスクが開始されます。
サーバーレスのタスクのステータスは以下ドキュメントに遷移図があります。
タスクの作成からトータルで 20 分程待ち、ロードが完了しました。開始・停止時間と、プロビジョンド DMS キャパシティユニットのところに DCU が表記されました。
ターゲット DB に接続してデータが移行されているか確認します。
SELECT * FROM [user];
▼実行結果
id name address
----------- ---------- ----------
1 Yamada Tokyo
2 Satou Chiba
3 Kinjo Okinawa
(3 行に影響しました)
完了時刻: 2025-09-30T21:14:08.7899582+09:00
無事 user テーブルが作成され、データが移行されていることが確認できました。
また、少したってタスクのステータスを見ると、「停止およびプロビジョニング解除済み」となっていました。
プロビジョンドモードと違ってタスクが動いていない時間はコンピューティングリソースが解放されるので、コストがかかりっぱなしにならないというわけです。
ちなみに、時間当たりの料金だとサーバーレスの方が少し高いです。
オンデマンドインスタンス（プロビジョンドインスタンス）の料金（東京リージョン）
| インスタンスタイプ | 時間あたりの料金 (シングル AZ) | 時間あたりの料金 (マルチ AZ) |
|---|---|---|
| t3.medium（2 vCPU、CPU バーストクレジットあり、 4 GiB メモリ） | USD 0.112 | USD 0.224 |
サーバーレスの料金（東京リージョン）
| AWS DMS キャパシティユニット (DCU) | 時間あたりの料金 (シングル AZ) | 時間あたりの料金 (マルチ AZ) |
|---|---|---|
| 2（2 vCPU、4 GiB メモリ） | USD 0.229 USD | 0.458 |
おわりに
DMS のタスクモードをサーバーレスにして RDS for SQL Server のデータ移行を試してみました。
プロビジョンドモードと比べるとレプリケーションインスタンスを作成する手間が省けるので設定は簡単になりつつ、コンピューティングリソースを作成する兼ね合いでタスク作成から完了まで若干待ち時間が長いという特徴もありました。
実は一部エラーでうまく進まないタイミングがあったりもしたので、CloudWatch Logs も確認して後で詳細を確認しようと思います。
本記事への質問やご要望については画面下部のお問い合わせ 「DevelopersIO について」 からご連絡ください。記事に関してお問い合わせいただけます。
参考
