DynamoDBのデータを別AWSアカウントへ移すときは、まず移行先に新しいテーブルを作れるか、既にあるテーブルへ書き込みたいかを決めます。この違いによって選べる方法が変わります。
新規テーブルならAWS BackupやS3経由のエクスポート・インポートを検討できます。既存テーブルに追加・統合したい場合は、GlueやSDKによる書き込み処理が候補です。さらに、移行中も元テーブルが更新されるなら、その差分をどう取り込むかまで設計します。
方法を選ぶための比較表
| 方法 | 適した場面 | 最初に確認する条件 |
|---|---|---|
| AWS Backup | バックアップを別アカウントへコピーし、新規テーブルとして復元したい | 同じAWS Organizations組織内か、クロスアカウントコピーの設定があるか |
| S3エクスポート・インポート | データをS3経由で新規テーブルへ移したい | PITR、S3・KMS権限、インデックスの要件 |
| Glue・SDKによる読み書き | 既存テーブルへ統合したい、変換処理を入れたい | キーの衝突、書き込み能力、再試行と差分処理 |
新規テーブルへの移行方法は、AWS公式のアカウント間移行ガイドでも整理されています。S3からのインポートはLSI（ローカルセカンダリインデックス）をサポートしないため、LSIが必要な構成では最初に方式を見直します。GSIはサポートされています。
AWS Backup：同じ組織内でバックアップから復元する
AWS Backupでは、移行元で取得したバックアップを移行先アカウントへコピーし、そこで復元します。既存テーブルへのデータ追記ではなく、新しいテーブルを用意する方式です。
送信元と送信先が同じOrganizations組織に属していることに加え、DynamoDBの高度なバックアップ機能、クロスアカウントコピー、バックアップボールトの権限などを確認します。暗号化キーの利用条件も含め、単にバックアップがあるだけでコピーできるとは判断しないようにします。
既存のバックアップ運用に合わせやすい点が利点です。一方、別組織のアカウントへの移行では他の方法を検討します。手順の概要はAWS Backupによるコピー、機能の前提はDynamoDBの高度なバックアップを参照してください。
S3経由：ある時点のデータから新しいテーブルを作る
エクスポートには、移行元テーブルのPITR（ポイントインタイムリカバリ）が必要です。対象時点のデータをS3へ出力し、移行先でS3からインポートします。別Organizations組織への移行にも検討できる方法です。
- 移行元のPITRとエクスポート権限を確認する。
- 基準とする時点を決め、S3へフルエクスポートする。
- 移行先から対象のS3データと暗号化キーを利用できるようにする。
- キーやGSIなど、移行先テーブルの要件を指定してインポートする。
- 処理結果とデータを確認し、アプリケーションの切替へ進む。
S3からのインポートは既存テーブルへ追記する機能ではありません。また、データを取り込めたことと、TTL、Streams、バックアップ、アラーム、アプリケーション権限などの運用設定が揃ったことは別です。移行先で必要な設定を一覧にして確認します。具体的な流れはS3エクスポート・インポートによる移行を参照してください。
既存テーブルへ入れるなら、キーが重なる場合の動作を決める
既存テーブルへの統合では、Glueの処理やSDKを使って読み出し・書き込みを実装する方法があります。これはバックアップの復元とは異なり、移行処理そのものを管理する方式です。SDKによるアカウント間コピーの公式パターンも参考になります。
特に、移行元と移行先に同じ主キーがある場合、「上書き」「保持」「項目を比較して更新」のどれを求めるかを先に決めます。処理が途中で止まった際の再開方法や、同じデータを再処理した場合の結果も設計対象です。
データ量だけで簡単さを判断せず、処理時間、読み書き負荷、失敗時の再試行、実行ログまで含めて比較します。小規模でも既存データと統合する要件が複雑なら、十分な確認が必要です。
移行中に増えたデータは、自動で追従するとは限らない
例えば12時時点をエクスポートし、14時に移行先を使い始める場合、12時以降の更新をどう扱うかが残ります。フルコピーの成功だけでは、この2時間分の変更が移行先へ反映されたとはいえません。
更新を停止できるなら、停止・最終コピー・検証・切替の順序を検討します。停止できない場合は、変更を取り込む仕組みと、コピー済みデータとの整合性、更新・削除の順序を別途設計します。単発コピーをそのまま無停止移行と扱わないことが重要です。
切替前に確認すること
- 同じ基準時点で件数や代表キーの内容が合っているか。
- 必要なインデックスを使ったクエリが動くか。
- アプリケーションが移行先のアカウント・リージョン・テーブルを参照しているか。
- 移行中の更新と削除を、決めた方針どおりに反映したか。
- 切り戻す場合、移行先で発生した更新をどう扱うか。
最初に新規・既存テーブルの条件を決め、次に組織やインデックスの制約を確認し、最後に更新差分と切替を設計すると、方式を選びやすくなります。
関連する記事
- Glueテーブルの別アカウント移行：Glue Data Catalogの定義コピーと、ETLによる実データ転送は異なる作業です。
- CloudWatchダッシュボードの別アカウントへのコピー：移行後の監視環境を整える際に確認できます。
