DynamoDBテーブルを別のアカウントやリージョンにコピーする方法

DynamoDBにはワンクリックの「テーブルをコピー」コマンドがありません — AWS CLIにも、コンソールにもです。すべてのコピーは実際には2つの半分から成ります:ソースからデータを取り出すことと、宛先のテーブルにロードすることです。前半はGUIが真価を発揮する場所です — ロスレスで、フィルタ可能で、検証済みのエクスポート — 一方、後半は常にAWSのツーリングで実行されます。このガイドは両方と、本番で噛みつく運用上の落とし穴を扱います。

DynamoDBテーブルを別のアカウントやリージョンにコピーするには？

ネイティブのcopy-tableコマンドはありません。取り出す半分については、テーブルのロスレスなDynamoDB-JSONエクスポートを取得するか(DynoTableならワンクリック、スクリプト不要)、マネージドのS3エクスポートでスナップショットを取ります。入れる半分については、状況に合うAWS側のアプローチを選びます:小さな単発コピーにはScan + BatchWriteItemのスクリプト、大きなテーブルにはS3へのエクスポートからのインポート、完全な忠実度でのクロスアカウント移動にはAWS Backupのコピー+リストア、継続的なライブレプリケーションにはグローバルテーブルです。リストアやインポートはいずれも新しいテーブルを作成します。

普遍的に「正しい」アプローチはありません — テーブルのサイズ、必要なのがポイントインタイムのスナップショットかライブデータか、宛先が新規テーブルか既存テーブルかによって決まります。

エクスポートの半分:DynoTableでデータを取り出す

リストアが始まる前に、データはソースを離れなければなりません — そして手書きのスキャンループは、小さな移行の中で最もエラーを起こしやすい部分です(ページの取りこぼし、数値精度の破損、型タグの早すぎる除去)。DynoTableはその半分をワンクリックでこなします:

• 設計からしてロスレス: フィルタの全一致をマーシャリングされたDynamoDB-JSON — プレーンJSONが壊してしまう大きな数値(> 2⁵³)を保持する、型で包まれたワイヤ形式 — でエクスポートするか、宛先がDynamoDBでないならNDJSON/CSVでエクスポートします。フォーマットの詳細はCSVへのエクスポートを参照してください。
• 全か無かではなく、スコープ指定: マネージドのS3エクスポートは_テーブル全体_のスナップショットですが、DynoTableはクエリに一致するすべてのアイテムをDynamoDBから直接ストリームしてエクスポートします — つまり「TENANT#42のアイテムだけをステージングにコピー」はスクリプトではなくフィルタです。
• 大きなテーブルも歓迎: エクスポートはデタッチしてバックグラウンドで実行され、1行ずつディスクにストリームされます — 数ギガバイトの取り出しも、タブの切り替えやアプリのリロードを生き延びます。
• ロード後の検証: 宛先のテーブルが立ち上がったら、ソースとターゲットを並べて閲覧し、アイテム数を比較し(テーブルのサイズとアイテム数)、サンプルレコードを抜き取り確認できます — 検証スクリプトを書かずにです。

正直な境界線:DynoTableはデータを取り出し、結果を検証します — 宛先テーブルへのロードは、次に扱うAWSツーリング(書き込みスクリプト、S3インポート、Backupリストア)で実行されます。

アプローチ1:Scan + BatchWriteItem(スクリプト)

最もローテクな選択肢:ソースからScanですべてのアイテムを読み、BatchWriteItemで宛先に書き込みます。スクリプトが両側の認証情報を持っている(またはターゲットアカウントのロールを引き受ける)限り、クロスアカウントでもクロスリージョンでも機能します。

# Sketch — read source, write target (pseudo; use the SDK in real life)
aws dynamodb scan --table-name SourceTable --region us-east-1 \
  > items.json
# transform Items[] into BatchWriteItem RequestItems, then:
aws dynamodb batch-write-item --request-items file://batch.json \
  --region eu-west-1

落とし穴は実在し、見落としやすいものです:

• BatchWriteItemは1回の呼び出しにつき25アイテムまたは16MBが上限です — 分割が必須で、1回の呼び出しが_未処理のアイテム_を返すことがあり、指数バックオフでリトライしなければなりません (APIリファレンス)。
• 書き込みは書き込みキャパシティを消費します。 プロビジョンドのターゲットではすぐにProvisionedThroughputExceededExceptionにぶつかります。オンデマンドはより多くを吸収しますが、それでも各パーティションには1,000 WCU / 3,000 RCUのハードリミットがあります。始める前に、書き込み負荷を宛先のキャパシティに対して見積もってください。
• Scanはテーブル全体を読み取り、すべてのアイテムを計測します — 古典的なQuery-vs-Scanのコストです。大きなテーブルはLastEvaluatedKeyによるページネーションも意味します。ページネーションを参照してください。
• アトミックではありません。 スキャンの実行中に書き込まれたアイテムは取りこぼされる可能性があります — 一貫したスナップショットが得られるのは、ソースが静止している場合だけです。

小さなテーブルや、コピー中に変換/フィルタが必要な場合に最適です — そして読み取りの半分がDynoTableのマーシャリングされたエクスポートとしてすでに存在するなら、スクリプトは分割して書き込むループだけに縮みます。

アプローチ2:S3にエクスポートし、新しいテーブルにインポートする

大きなテーブルには、DynamoDBのマネージドなS3へのエクスポートとS3からのインポートの組み合わせが、キャパシティをまったく叩かずに済みます。

エクスポートはテーブルをS3バケットにスナップショットします (仕組み):

• ソーステーブルでポイントインタイムリカバリ(PITR)の有効化が必要です。
• 読み取りキャパシティを消費せず、テーブルのパフォーマンスに影響しません — ライブテーブルではなく継続的なバックアップから読み取ります。
• 出力はDynamoDB JSONまたはAmazon Ion形式です。(S3に着地するのは、型タグごとすべて含んだDynamoDB-JSONワイヤフォーマットです。)
• 別のアカウントが所有する、別のリージョンにあるS3バケットにも書き込めます。
• フルと増分のエクスポートをサポートします(増分エクスポートGA、2023年9月)。

インポートはそのS3データから新しいテーブルを構築します (仕組み):

• まっさらな新規テーブルにのみインポートします — 既存のテーブルにはインポートできません。
• 新しいテーブルの書き込みキャパシティを消費しません。
• CSV、DynamoDB JSON、Amazon Ionを受け付けます(オプションでGZIP/ZSTD圧縮)。
• ソースのS3バケットは別のアカウントや別のリージョンにあっても構いません。
• インポート時にセカンダリインデックスを定義でき、インポート完了と同時にクエリ可能になります。

ポイントインタイムのスナップショット(ライブデータではなく)が許容できる、大規模なクロスアカウント/クロスリージョン移行には、これが最もクリーンな経路です。

アプローチ3:AWS Backupのコピー+リストア

すでにAWS Backupを使っているなら、リカバリポイントをアカウントとリージョンをまたいでコピーできます (クロスアカウント移行ガイド):

1. ソーステーブルをバックアップボールトにバックアップします。
2. バックアップをターゲットのアカウント/リージョンのボールトにコピーします。
3. ターゲットで新しいテーブルにリストアします。

主な制約:

• クロスアカウントコピーには、両方のアカウントが同じAWS Organizationに属している必要があります。
• リストアは常に新しいテーブルを作成します — 既存のテーブルの上にリストアすることはできません。
• グローバルセカンダリインデックスはデフォルトで保持されます(リストアの時間/コストを節約するために一部または全部を除外できます)。リストア時に新しいインデックスを_追加_することはできません。
• 暗号化の落とし穴: クロスリージョンのリストアで同じKMSキーを保持するにはマルチリージョンキーが必要です。クロスアカウントではキーをターゲットアカウントと共有しなければなりません。AWS所有キーとAWSマネージドキーは共有もマルチリージョン化もできません (リストア時の暗号化に関する注記)。

アプローチ4:グローバルテーブル(単発コピーではなくライブレプリケーション)

グローバルテーブルはテーブルをリージョン間で — そして今ではオプションでアカウント間でも (マルチアカウントGA、2026年2月) — 継続的にレプリケートします。どのレプリカも読み取りと書き込みを提供し(マルチアクティブ)、非同期のラストライターウィンズのレプリケーションで動きます (グローバルテーブルのドキュメント)。

これは「コピーして立ち去る」ツールではありません — 継続的なレプリケーションです。宛先リージョンを無期限に同期させておきたいとき(DR、低レイテンシのローカル読み取り)に使い、クリーンな単発移行には使いません。既存のテーブルにリージョンを追加すると、DynamoDBが既存データを新しいレプリカにバックフィルします。

運用上の落とし穴(すべてのアプローチ共通)

• GSIの再作成はタダではありません。 scan+writeのコピーはインデックスを運びません — ターゲットで定義し、それらは個別にバックフィルされます(そして課金されます)。宛先のGSI vs LSIレイアウトは前もって計画してください。LSIはテーブル作成時にしか作成できません (LSIのドキュメント)。
• キャパシティモードは引き継がれません。 新しいテーブルは、ソースのモードではなく、あなたが設定したモードで始まります。scan+writeのコピーの前に書き込み負荷を見積もってください — 代表的なアイテムをアイテムサイズ計算ツールで測り、アイテム数を掛けてWCUの概算を出します。
• TTL、ストリーム、オートスケーリング、タグはテーブル設定であってデータではありません — どのコピー方法もそれらすべてを運びはしません。ターゲットで再適用してください。
• DynamoDB JSON ≠ プレーンJSON。 エクスポートとスキャンは型タグ付きのDynamoDB-JSONを出力します。途中で変換するなら、DynamoDB JSONコンバータがマーシャリングを引き受けます。
• カットオーバー前に検証を。 両側でアイテム数を比較し、レコードを抜き取り確認してください — DescribeTableのカウントは最大6時間古いことを忘れずに。作りたてのターゲットが正当にゼロを報告することもあります。

よくある質問

DynamoDBテーブルをコピーするAWS CLIコマンドはありますか？ いいえ。ネイティブのcopy-tableコマンドはありません。scan + batch-write-itemを組み合わせるか、マネージドのエクスポート/インポートかAWS Backupの機能を使います。

DynamoDBテーブルを別のアカウントにコピーするには？ 3つの選択肢があります:両アカウントの認証情報を持つscan+writeスクリプト、S3エクスポート/インポート(バケットはクロスアカウント可)、またはAWS Backupのコピー+リストア(両アカウントが同じAWS Organizationに属している必要があります)。

DynamoDBテーブルを別のリージョンにコピーするには？ S3エクスポート/インポートとAWS Backupはどちらもクロスリージョンをサポートします。単発のコピーではなく_継続的な_クロスリージョン同期には、ターゲットリージョンにグローバルテーブルのレプリカを追加します。

テーブルをコピーするとインデックスもコピーされますか？ S3インポートとAWS Backupのリストアではセカンダリインデックスを保持/定義できます。scan+writeスクリプトではできません — ターゲットで自分でインデックスを作成し、それらは個別にバックフィルされます。

既存のDynamoDBテーブルにインポートできますか？ いいえ。DynamoDBのS3インポートもAWS Backupのリストアも、新しいテーブルを作成します。既存のテーブルにマージするには、scan+writeスクリプトを使ってください。

テーブルの一部だけをコピーできますか？ マネージドのエクスポート/インポートとBackupの経路はテーブル全体のみです。サブセットには、DynoTableからフィルタの一致分を(ロスレスなマーシャリングされたDynamoDB-JSONで)エクスポートするか、フィルタ付きスキャンをスクリプトにして、そのサブセットをターゲットに書き込みます。

GUIはカットオーバーを正気に保ちます:移動するアイテムをちょうどそのままロスレスにエクスポートし、ソースとターゲットを並べて閲覧し、コピー後にアイテム数といくつかのサンプルレコードを検証し、スキャンスクリプトを書かずにアドホックなチェックを実行できます。DynoTableをダウンロードして、アカウントとリージョンをまたぐ移行のエクスポートと検証の半分を実行してください。