Amazon DynamoDB テーブルをある AWS アカウントから別の AWS アカウントに移行する方法を教えてください。

所要時間3分

クロスアカウントの Amazon DynamoDB テーブル移行を実行したいと考えています。

簡単な説明

ユースケースに合った以下の方法のいずれかを使用して、DynamoDB テーブルを別の AWS アカウントに移行します：

AWS Backup
DynamoDB のインポートと Amazon Simple Storage Service (Amazon S3) へのエクスポート
Amazon S3 と AWS Glue
Amazon EMR

解決策

AWS Backup

AWS Backup を使用して、クロスアカウントの DynamoDB バックアップを作成できます。詳細については、「AWS アカウント間でのバックアップコピーの作成」と「AWS Backup デモ: クロスアカウントおよびクロスリージョンのバックアップ」を参照してください。

ターゲットアカウントで、次の操作を行います：

DynamoDB が存在するリージョンのターゲットアカウントに AWS Backup ボールトを作成します。
ボールトを作成するときは、設定済みの AWS Key Management Service (AWS KMS) キーを使用します。これは、同じ組織のソースアカウントですでに共有されているキーです。
ボールトを作成したら、AWS Identity and Access Management (IAM) ポリシーをボールトに追加します。そのためには、[組織からのバックアップボールトへのアクセスを許可する] オプションを選択します。これにより、同じ組織内の他のアカウントをボールトにコピーできます。

ソースアカウントで、次の操作を行います:

DynamoDB が存在するソースアカウントで、テーブルデータを移行する必要があるリージョンに AWS Backup ボールトを作成します。
ボールトを作成するときは、設定済みの AWS KMS キーを使用してください。これは、組織内の他のアカウントと共有したキーです。
組織内の他のアカウントがボールトにコピーできるようにする IAM ポリシーをボールトに追加します。そのためには、[組織からのバックアップボールトへのアクセスを許可] オプションを選択します。
バックアッププランを作成して、ソースアカウントの DynamoDB テーブルのバックアップをターゲットアカウントに生成します。
バックアップボールトの場合は、ソースアカウントで作成した保管庫を必ず選択してください。
[別のアカウントのボールトにコピー] オプションを有効にします。
[リソースの割り当て] には、バックアップする必要のあるリソースを必ず含めてください。[特定のリソースタイプを含める] を選択できます。
[特定のリソースタイプを選択] で [DynamoDB] を選択します。すべてのテーブルを選択することも、バックアップする必要のあるテーブルのみを選択することもできます。

ターゲットアカウントで、次の操作を行います：

ターゲットアカウントで、作成したボールトに移動します。
リカバリポイントがソースアカウントと同じであることがわかります。
ターゲットアカウントの DynamoDB テーブルを復元できます。

注: この方法では、ソースアカウントとターゲットアカウントが同じ組織内にある必要があります。

DynamoDB のインポートと Amazon S3 へのエクスポート

DynamoDB テーブルデータを移行するには、ターゲットアカウントの Amazon S3 バケットにテーブルをエクスポートします。DynamoDB にこの S3 バケットに対する s3:ListBucket 権限があることを確認してください。S3 バケットには、エクスポートされたデータへのアクセスを拒否するアクセス制御リストがないことを確認してください。
エクスポートが完了したら、S3 バケットからターゲットアカウントの新しいテーブルにデータをインポートします。詳細については、「Amazon S3 への DynamoDB データエクスポート: 仕組み」を参照してください。

注: テーブルをエクスポートしてもテーブルの読み込み容量は消費されず、テーブルのパフォーマンスや可用性にも影響しません。また、テーブルをインポートしてもライター容量は消費されません。したがって、インポートプロセス中に追加の容量は必要ありません。

Amazon S3 と AWS Glue

S3 バケットと AWS Glue ジョブを使用して、DynamoDB テーブルを別の AWS アカウントに移行できます。

1. DynamoDB テーブルの初期移行は、別のアカウントの Amazon S3 バケットにテーブルをエクスポートすることで実行できます。

アカウント A からアカウント B の S3 バケットにテーブルをエクスポートしても、オブジェクトは引き続きアカウント A によって所有されます。アカウント B の AWS Identify Access Management (IAM) ユーザーは、デフォルトではオブジェクトにアクセスできません。エクスポート関数は、アクセスコントロールリスト (ACL) バケット所有者フルコントロールを使用してデータを書き込むことはありません。このオブジェクト所有権の問題の回避策として、エクスポートの完了後に、エクスポートされたすべてのオブジェクトに PutObjectACL 権限を含めてください。この回避策は、アカウント B のバケット所有者に、エクスポートされたすべてのオブジェクトへのアクセスを許可します。詳細については、「別の AWS アカウントによって Amazon S3 バケットにアップロードされたオブジェクトにアクセスできないのはなぜですか?」を参照してください。

2. Glue ジョブを使用して S3 バケットからファイルを読み取り、ターゲット DynamoDB テーブルに書き込みます。

ステップ 1 で説明したように、ターゲットアカウントの S3 バケットにデータをエクスポートした後、ターゲットアカウントで以下を実行します：

Amazon S3 内のデータに対して AWS Glue クローラーを実行します。クローラーはスキーマを推測し、そのスキーマ定義を使用して AWS Glue データカタログテーブルを作成します。

AWS Glue スタジオを使用して ETL ジョブを作成します。ソース、変換、およびターゲットを指定すると、AWS Glue Studio はこれらの入力に基づいて PySpark コードを自動的に生成します。このジョブでは、ソースとして AWS Glue データカタログテーブルを指定し、変換として ApplyMApplyMapping を指定します。ターゲットは指定しないでください。AWS Glue Studio は S3 からダイナミックフレームを作成するための PySpark コードを生成します。

AWS Glue Studio によって生成されたコードのキー名とデータ型マッピングが正しいことを確認してください。マッピングが正しくない場合は、コードを変更し、マッピングを修正してください。AWS Glue ジョブの作成時にターゲットを指定しなかったため、この例では次のようなシンクオペレーションを追加します。このオペレーションを追加すると、ジョブはターゲットの DynamoDB テーブルに直接書き込むことができます。

glueContext.write_dynamic_frame_from_options ( frame = Mapped, connection_type = "dynamodb", connection_options = { "dynamodb.region": "", "dynamodb.output.tableName": "", "dynamodb.throughput.write.percent": "1.0" } )

データをターゲットテーブルにロードするには、AWS Glue Studio または AWS Glue コンソールのジョブページからジョブを実行します。

3. S3 バケットにテーブルをエクスポートしたら、DynamoDB Streams と AWS Lambda を使用して、ソーステーブルからのデータ挿入と更新を別のアカウントのターゲットテーブルに移行します。詳細については、「Amazon DynamoDB によるクロスアカウントレプリケーション」を参照してください。

AWS Glue

AWS Glue ETL ジョブは、別のアカウントの DynamoDB テーブルからのデータの読み取りと書き込みの両方をサポートしています。DynamoDB.STS.Rolearn パラメーターを使用して、ジョブスクリプトでクロスアカウントロールを引き受けます。このロールを想定すると、DynamoDB へのクロスアカウントアクセスに使用する必要がある一時的な認証情報を取得できます。詳細については、「DynamoDB テーブルへのクロスアカウントクロスリージョンアクセス」および「AWS Step Functions と AWS Glue を使用して Amazon DynamoDB テーブルを Amazon S3 にエクスポートする方法」を参照してください。

Amazon EMR

Amazon EMR を使用して DynamoDB テーブルを移行する場合、ユースケースに応じて以下のいずれかのオプションを使用してください：

移行中にダウンタイムが発生しても余裕がある場合は、ソーステーブルへの書き込み操作を停止してください。これは、ターゲットテーブルがソーステーブルと同期していることを確認するためです。
ダウンタイムを許容できない場合は、移行中に発生するすべてのトランザクションをステージングテーブルに保存する必要があります。元のテーブルが他の AWS アカウントに移行されたら、新しいトランザクションをステージングテーブルからターゲットテーブルにプッシュします。

注: Amazon EMR でテーブルを移行するのに必要な時間は大きく異なる場合があります。この差異は、DynamoDB テーブルのプロビジョニングされたスループット、ネットワークパフォーマンス、およびテーブルに格納されているデータ量によって異なります。

Amazon EMR を使用して DynamoDB テーブルを移行するには、以下を実行してください：

ソースアカウントとターゲットアカウントの両方で EMR クラスターを起動します。[ソフトウェア設定] セクションで、必ず Apache Hive を含むオプションを選択してください。注: Amazon EMR クラスターをプライベートサブネットに起動するのがセキュリティのベストプラクティスです。プライベートサブネットには Amazon S3 VPC エンドポイントと DynamoDB へのルートが必要です。詳細については、「プライベートサブネット」を参照してください。クラスターがインターネットにアクセスする必要がある場合は、パブリックサブネットにある NAT ゲートウェイを使用してください。詳細については、「パブリックサブネットとプライベートサブネットを持つ VPC (NAT)」を参照してください。
両方のアカウントの EMR_EC2 _DefaultRole IAM ロールに、宛先アカウントの S3 バケットに書き込む権限があることを確認してください。詳細については、「AWS のサービスとリソースへの Amazon EMR アクセス権限の IAM サービスロールの設定」を参照してください。
ソースアカウントで、SSH を使用してマスターノードに接続します。
ソースアカウントで、Hive コマンドを使用して DynamoDB テーブルデータをターゲットアカウントの S3 バケットにエクスポートします。
移行先アカウントで、Amazon S3 データを新しい DynamoDB テーブルにインポートします。
ステージングテーブルを使用して移行中に発生した書き込みをキャプチャする場合は、ステージングテーブルでステップ 4 と 5 を繰り返します。