Aurora クローン作成の概要 Aurora クローン作成の制限 Aurora クローン作成の仕組み Aurora クローンの作成クロス VPC クローニングクロスアカウントのクローン作成

Amazon Aurora DB クラスターのボリュームのクローン作成

Aurora クローン作成を使用すると、元のクラスターと同じデータページを共有するものの、個別の独立したボリュームを持つ新しいクラスターを作成できます。このプロセスは、高速で、費用効果が高いように設計されています。関連付けられたデータボリュームを持つ新しいクラスターは、クローンと呼ばれます。クローンの作成は、スナップショットの復元など、他の手法を使用してデータを物理的にコピーするよりも、高速かつスペース効率に優れています。

トピック

Aurora クローン作成の概要
Aurora クローン作成の制限
Aurora クローン作成の仕組み
Amazon Aurora クローンの作成
Amazon Aurora を使用したクロス VPC クローニング
AWS RAM および Amazon Aurora を使用したクロスアカウントのクローン作成

Aurora クローン作成の概要

Aurora では、クローン作成に、コピーオンライトプロトコルが使用されます。このメカニズムでは、初期クローンを作成するために使用する追加領域は最小限です。クローンが初期に作成されると、Aurora は、ソース Aurora DB クラスターと新しい (クローンの) Aurora DB クラスターで使用されるデータのコピーを 1 つだけ保持します。追加のストレージは、ソース Aurora DB クラスターまたは Aurora DB クラスターのクローンが (Aurora ストレージボリューム上の) データに変更を加えた場合にのみ割り当てられます。コピーオンライトプロトコルの詳細については、「Aurora クローン作成の仕組み」を参照してください。

Aurora のクローン作成は、データを破損の危険にさらすことなく、本番データを使用してテスト環境を迅速にセットアップする場合に特に役立ちます。クローンは、次のようなさまざまなタイプのアプリケーションに使用できます。

潜在的な変更 (スキーマの変更やパラメータグループの変更など) を試して、すべての影響を評価する。
データのエクスポートや分析クエリの実行など、大量のワークロードを扱うオペレーションをクローン上で実行する。
開発、テスト、またはその他の目的のために、本番 DB クラスターのコピーを作成する。

同じ Aurora DB クラスターから複数のクローンを作成できます。また、別のクローンから複数のクローンを作成することもできます。

Aurora クローンを作成したら、その Aurora DB インスタンスを、ソース Aurora DB クラスターとは異なる設定にできます。例えば、開発用途のクローンは、ソース本番 Aurora DB クラスターと同じ高可用性要件を満たす必要がない場合があります。この場合、Aurora DB クラスターで使用される複数の DB インスタンスではなく、単一の Aurora DB インスタンスを使用するようにクローンを設定できます。

作成元とは異なるデプロイ設定を使用してクローンを作成すると、作成元の Aurora DB エンジンの最新のマイナーバージョンを使用してクローンが作成されます。

Aurora DB クラスターからクローンを作成すると、クローンは作成者の AWS アカウント (ソース Aurora DB クラスターを所有しているアカウントと同じアカウント) に作成されます。ただし、Aurora Serverless v2 とプロビジョニングされた Aurora DB クラスターおよびクローンを他の AWS アカウントと共有することもできます。詳細については、「AWS RAM および Amazon Aurora を使用したクロスアカウントのクローン作成」を参照してください。

テスト、開発などの用途へのクローンの使用が終了したら、クローンを削除できます。

Aurora クローン作成の制限

Aurora のクローン作成には、現在、次の制約事項があります。

AWS リージョンで許可される DB クラスターの最大数まで、必要な数のクローンを作成できます。

コピーオンライトプロトコルまたはフルコピープロトコルを使用してクローンを作成できます。フルコピープロトコルは、ポイントインタイムリカバリのように機能します。
ソース Aurora DB クラスターとは異なる AWS リージョンにはクローンを作成できません。
パラレルクエリ機能なしの Aurora DB クラスターから、パラレルクエリを使用するクラスターにクローンを作成することはできません。並行クエリを使用するクラスターにデータを格納するには、元のクラスターのスナップショットを作成して、並行クエリ機能を使用するクラスターにそれを復元します。
DB インスタンスを持たない Aurora DB クラスターからクローンを作成することはできません。少なくとも 1 つの DB インスタンスを持つ Aurora DB クラスターのクローン作成のみが可能です。
クローンは、Aurora DB クラスターとは異なる仮想プライベートクラウド (VPC) で作成できます。その場合、VPCのサブネットは同じアベイラビリティーゾーンにマッピングする必要があります。
プロビジョニングされた Aurora DB クラスターから、Aurora プロビジョニングされたクローンを作成できます。
Aurora Serverless v2 インスタンスを持つクラスターは、プロビジョンドクラスターと同じルールに従います。
Aurora Serverless v1 の場合:
- Aurora Serverless v1 DB クラスターからプロビジョニングされたクローンを作成できます。
- Aurora Serverless v1 またはプロビジョニングされた DB クラスターから Aurora Serverless v1 クローンを作成できます。
- 暗号化されていないプロビジョニングされた Aurora DB クラスターからは Aurora Serverless v1 クローンを作成できません。
- 現在、Aurora Serverless v1 DB クラスターのクローン作成では、他のアカウントへのクローン作成はサポートされていません。詳細については、「クロスアカウントのクローン作成の制約事項」を参照してください。
- クローンの Aurora Serverless v1 DB クラスターの動作と制限は、Aurora Serverless v1 DB クラスターと同じです。詳細については、「Amazon Aurora Serverless v1 の使用」を参照してください。
- Aurora Serverless v1 DB クラスターは常に暗号化されます。クローンを作成するとき Aurora Serverless v1 DB クラスターをプロビジョニングされた Aurora DB クラスターに変換すると、プロビジョニングされた Aurora DB クラスターは暗号化されます。暗号化キーは選択できますが、暗号化を無効にすることはできません。プロビジョニングされた Aurora DB クラスターから Aurora Serverless v1 にクローンを作成するには、まず暗号化プロビジョニングされた Aurora DB クラスターから開始する必要があります。

Aurora クローン作成の仕組み

Aurora クローン作成は Aurora DB クラスターのストレージレイヤーで動作します。コピーオンライトプロトコルが使用されます。これは、Aurora ストレージボリュームをサポートする基盤となる耐久性の高いメディアという点で、高速かつスペース効率に優れています。Aurora クラスターボリュームの詳細については、「Amazon Aurora ストレージの概要」を参照してください。

コピーオンライトプロトコルの理解

Aurora DB クラスターでは、基になる Aurora ストレージボリュームのページにデータが格納されます。

例えば、次の図には、4 つのデータページ 1、2、3、4 を持つ Aurora DB クラスター (A) があります。クローン B が Aurora DB クラスターから作成されたとします。クローンが作成されても、データはコピーされません。クローンは、ソース Aurora DB クラスターと同じページのセットを参照しています。

ソースクラスター A とクローン B 用の Amazon Aurora クラスターボリューム (4 ページ)

クローンが作成されたとき、通常は追加のストレージは必要ありません。コピーオンライトプロトコルでは、ソースセグメントと同じ物理ストレージメディア上のセグメントを使用します。追加のストレージが必要になるのは、ソースセグメントの容量がクローンセグメント全体に対して十分でない場合のみです。この場合、ソースセグメントは別の物理デバイスにコピーされます。

次の図に、前述と同様にクラスター A とそのクローン B を使用して動作中のコピーオンライトプロトコルの例を示します。Aurora DB クラスター (A) に変更を加えて、ページ 1 に保持されているデータが変更されたとします。元のページ 1 に書き込む代わりに、Aurora は新しいページ 1[A] を作成します。クラスター (A) の Aurora DB クラスターボリュームは、1[A]、2、3、4 ページを参照していますが、クローン (B) は引き続き元のページを参照しています。

Amazon Aurora のソース DB クラスターボリュームとそのクローンのどちらにも変更が加えられた場合。

クローンでは、ストレージボリュームのページ 4 に変更が加えられています。元のページ 4 に書き込む代わりに、Aurora は新しいページ 4[B] を作成します。クローンはページ 1、2、3、およびページ 4[B] を参照し、クラスター (A) は引き続き 1[A]、2、3、4 を参照しています。

時間が経過してソース Aurora DB クラスターボリュームとクローンの両方で追加の変更があると、その変更をキャプチャして保存するためにさらにストレージが必要になります。

ソースクラスターボリュームの削除

当初、クローンボリュームは、クローンの作成元のボリュームと同じデータページを共有します。元のボリュームが存在する限り、クローンボリュームはクローンが作成または変更したページの所有者と見なされるのみです。したがって、クローンボリュームの VolumeBytesUsed メトリクスは最初は小さく、元のクラスターとクローンの間でデータが分岐するに従って増えていきます。ソースボリュームとクローン間でページが同じである場合、ストレージ料金は元のクラスターにのみ適用されます。VolumeBytesUsed メトリクスの詳細については、「Amazon Aurora のクラスターレベルのメトリクス」を参照してください。

1 つ以上のクローンが関連付けられているソースクラスターボリュームを削除しても、クローンのクラスターボリューム内のデータは変更されません。Aurora は、ソースクラスターボリュームが以前に所有していたページを保持します。Aurora は、削除したクラスターが所有していたページのストレージ料金を再分配します。例えば、元のクラスターに 2 つのクローンがあり、後で元のクラスターを削除したとします。元のクラスターが所有していたデータページの半分は、1 つのクローンが所有することになります。残りの半分のページは、もう 1 つのクローンが所有します。

元のクラスターを削除してクローンを作成または削除すると、Aurora は同じページを共有するすべてのクローン間で、データページの所有権を引き続き再配分します。したがって、クローンのクラスターボリュームに応じてメトリクスの値が変わることがわかります。より多くのクローンを作成して、ページの所有権がより多くのクラスターに分散されると、メトリクスの値は減少する可能性があります。また、クローンを削除して、ページの所有権を割り当てるクラスターの数が少なくなると、メトリクスの値は増える可能性があります。書き込みオペレーションがクローンボリュームのデータページにどのように影響するかについては、「コピーオンライトプロトコルの理解」を参照してください。

元のクラスターとクローンを同じ AWS アカウントが所有している場合、これらのクラスターのすべてのストレージ料金は同じ AWS アカウントに適用されます。一部のクラスターがクロスアカウントクローンである場合、元のクラスターを削除すると、クロスアカウントクローンを所有する AWS アカウントに追加のストレージ料金がかかる可能性があります。

例えば、クローンを作成する前に、クラスターボリュームに 1,000 件の使用済みデータページがあるとします。このクラスターのクローンを作成すると、当初のクローンボリュームの使用済みページはゼロです。クローンが 100 件のデータページに変更を加えると、その 100 ページだけがクローンボリュームに保存され、使用済みとしてマークされます。親ボリュームから変更されていない残りの 900 ページは、両方のクラスターで共有されます。この例で、親クラスターの場合は 1,000 ページ、クローンボリュームの場合は 100 ページに対してストレージ料金が発生します。

ソースボリュームを削除した場合、クローンのストレージ料金は、変更した 100 ページと元のボリュームの 900 の共有ページを含めて、合計 1,000 ページ分となります。

Amazon Aurora クローンの作成

ソース Aurora DB クラスターと同じ AWS アカウントにクローンを作成できます。そうするには、AWS Management Console または AWS CLI を使用して、その後の手順を行ってください。

別の AWS アカウントにクローン作成を許可したり、別の AWS アカウントとクローンを共有したりするには、AWS RAM および Amazon Aurora を使用したクロスアカウントのクローン作成の手順を使用します。

AWS Management Console を使用して Aurora DB クラスターのクローンを作成する手順を以下に示します。

AWS Management Console を使用してクローンを作成すると、1 つの Aurora DB インスタンスを持つ Aurora DB クラスターができます。

これらの手順は、クローンを作成しているのと同じ AWS アカウントが所有する DB クラスターに適用されます。別の AWS アカウントが所有する DB クラスターの場合は、AWS RAM および Amazon Aurora を使用したクロスアカウントのクローン作成を参照してください。

AWS を使用して、お客様の AWS Management Console アカウントが所有している DB クラスターのクローンを作成するには

AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
ナビゲーションペインで、[データベース] を選択します。
リストから Aurora DB クラスターを選択し、[アクション] で、[クローンの作成] を選択します。

[クローンの作成] ページが開きます。そこで、[設定]、[接続] などの Aurora DB クラスタークローンのオプションが設定できます。
[DB インスタンス識別子] に、作成する Aurora DB クラスターのクローンに付ける名前を入力します。
Aurora Serverless v1 DB クラスターの場合は、[キャパシティータイプ] に[プロビジョニング済み] または [サーバーレス] を選択します。

ソース Aurora DB クラスターが Aurora Serverless v1 DB クラスターまたは暗号化されているプロビジョニングされた Aurora DB クラスターであるときのみ、[サーバーレス] を選択することができます。
Aurora Serverless v2 またはプロビジョニングされた DB クラスターの場合は、[クラスターストレージ設定] に Aurora Standard または Aurora I/O-Optimized を選択します。

詳細については、「Amazon Aurora DB クラスターのストレージ設定」を参照してください。
DB インスタンスのサイズまたは DB クラスターの容量を選択してください。
- プロビジョニングされたクローンの場合は、DB インスタンスクラスを選択します。
  
  用意されている設定のままにすることも、クローンに別の DB インスタンスクラスを使用することもできます。
- Aurora Serverless v1 または Aurora Serverless v2 クローンの場合は、[容量設定] を選択します。
  
  用意されている設定のままにすることも、クローンに合わせて変更することもできます。
クローンに必要な他の設定を選択します。Aurora DB クラスターとインスタンスの設定の詳細については、「Amazon Aurora DB クラスターの作成」を参照してください。
[クローンの作成] を選択します。

クローンが作成されると、コンソールの [データベース] セクションに他の Aurora DB クラスターとともに一覧表示され、現在の状態が表示されます。状態が [使用可能] の場合は、クローンはすぐに使用できます。

AWS CLI を使用して Aurora DB クラスターのクローンを作成するには、いくつかのステップが必要です。

restore-db-cluster-to-point-in-time AWS CLI コマンドを使用すると、Aurora DB インスタンスの個数が 0 の空の Aurora DB クラスターができます。つまり、このコマンドは Aurora DB クラスターのみを復元し、クラスターの DB インスタンスは復元しません。これは、クローンが使用可能になった後に別途行います。プロセスは 2 ステップで、次のとおりです。

restore-db-cluster-to-point-in-time CLI コマンドを使用して、クローンを作成します。このコマンドで使用するパラメータで、作成する空の Aurora DB クラスター (クローン) の容量タイプなどの詳細が制御されます。
create-db-instance CLI コマンドを使用して、クローン用の Aurora DB インスタンスを作成し、復元された Aurora DB クラスターに Aurora DB インスタンスを再作成します。

トピック

クローンの作成
ステータスの確認とクローンの詳細の取得
クローン用の Aurora DB インスタンスの作成
クローン作成に使用するパラメータ

クローンの作成

restore-db-cluster-to-point-in-time CLI コマンドに渡す特定のパラメータは、さまざまです。渡す内容は、ソース DB クラスターのエンジンモードのタイプ (Serverless またはプロビジョニング) および作成するクローンのタイプによって異なります。

ソース Aurora DB クラスターと同じエンジンモードのクローンを作成するには

restore-db-cluster-to-point-in-time CLI コマンドを使用して、次のパラメータに値を指定します。
- --db-cluster-identifier - クローン用の意味のある名前を選択します。restore-db-cluster-to-point-in-time CLI コマンド使用時に、クローンに名前を付けます。次に、create-db-instance CLI コマンドで、クローンの名前を渡します。
- --restore-type - ソース DB クラスターのクローンの作成に copy-on-write を使用します。このパラメータを指定しない場合、restore-db-cluster-to-point-in-time は、クローンを作成するのではなく、Aurora DB クラスターを復元します。
- --source-db-cluster-identifier - クローンを作成するソース Aurora DB クラスターの名前を使用します。
- --use-latest-restorable-time - この値は、ソース DB クラスターの最新の復元可能なボリュームデータを指します。これを使用してクローンを作成します。

次の例では、my-source-cluster という名前のクラスターから my-clone という名前のクローンを作成します。

Linux、macOS、Unix の場合:


aws rds restore-db-cluster-to-point-in-time \
    --source-db-cluster-identifier my-source-cluster \
    --db-cluster-identifier my-clone \
    --restore-type copy-on-write \
    --use-latest-restorable-time

Windows の場合:


aws rds restore-db-cluster-to-point-in-time ^
    --source-db-cluster-identifier my-source-cluster ^
    --db-cluster-identifier my-clone ^
    --restore-type copy-on-write ^
    --use-latest-restorable-time

このコマンドは、クローンの詳細を含む JSON オブジェクトを返します。クローンの DB インスタンスを作成する前に、作成した DB クラスターのクローンが使用可能であることを確認します。詳細については、「ステータスの確認とクローンの詳細の取得」を参照してください。

ソース Aurora DB クラスターとは異なるエンジンモードでクローンを作成するには

restore-db-cluster-to-point-in-time CLI コマンドを使用して、次のパラメータに値を指定します。
- --db-cluster-identifier - クローン用の意味のある名前を選択します。restore-db-cluster-to-point-in-time CLI コマンド使用時に、クローンに名前を付けます。次に、create-db-instance CLI コマンドで、クローンの名前を渡します。
- --source-db-cluster-identifier - クローンを作成するソース Aurora DB クラスターの名前を使用します。
- --restore-type - ソース DB クラスターのクローンの作成に copy-on-write を使用します。このパラメータを指定しない場合、restore-db-cluster-to-point-in-time は、クローンを作成するのではなく、Aurora DB クラスターを復元します。
- --use-latest-restorable-time - この値は、ソース DB クラスターの最新の復元可能なボリュームデータを指します。これを使用してクローンを作成します。
- --engine-mode - (オプション) このパラメータは、ソース Aurora DB クラスターとは異なるタイプのクローンを作成する場合にのみ使用します。次のように --engine-mode として渡す値を選択します。
  - Aurora Serverless DB クラスターからプロビジョニングされた Aurora DB クラスターのクローンを作成するには、provisioned を使用します。
  - プロビジョニングされた Aurora DB クラスターから Aurora Serverless v1 DB クラスターのクローンを作成するには、serverless を使用します。serverless エンジンモードを指定すると、--scaling-configuration を選択することもできます。
- --scaling-configuration - (オプション) --engine-mode serverless の場合に使用して、Aurora Serverless v1 クローンの最小と最大の容量を設定します。このパラメータを使用しない場合、Aurora は DB エンジンのデフォルトの容量値を使用してクローンを作成します。
- --serverless-v2-scaling-configuration - (オプション) このパラメータを使用して、Aurora Serverless v2 クローンの最小と最大の容量を設定します。このパラメータを使用しない場合、Aurora は DB エンジンのデフォルトの容量値を使用してクローンを作成します。

次の例では、my-source-cluster という名前のプロビジョニングされた Aurora DB クラスターから my-clone という名前の Aurora Serverless v1 クローンを作成します。プロビジョニングされた Aurora DB クラスターは暗号化されています。

Linux、macOS、Unix の場合:


aws rds restore-db-cluster-to-point-in-time \
    --source-db-cluster-identifier my-source-cluster \
    --db-cluster-identifier my-clone \
    --engine-mode serverless \
    --scaling-configuration MinCapacity=8,MaxCapacity=64 \
    --restore-type copy-on-write \
    --use-latest-restorable-time

Windows の場合:


aws rds restore-db-cluster-to-point-in-time ^
    --source-db-cluster-identifier my-source-cluster ^
    --db-cluster-identifier my-clone ^
    --engine-mode serverless ^
    --scaling-configuration MinCapacity=8,MaxCapacity=64 ^
    --restore-type copy-on-write ^
    --use-latest-restorable-time

これらのコマンドは、DB インスタンスの作成に必要なクローンの詳細を含む JSON オブジェクトを返します。クローン (空の Aurora DB クラスター) のステータスが [使用可能] になるまでこれを実行できません。

注記

restore-db-cluster-to-point-in-time AWS CLI コマンドは、その DB クラスターの DB インスタンスではなく、DB クラスターのみを復元します。復元された DB クラスターの DB インスタンスを作成するには、create-db-instance コマンドを呼び出すときに、復元する DB クラスターの識別子を --db-cluster-identifier に指定する必要があります。restore-db-cluster-to-point-in-time コマンドが完了し、DB クラスターが使用可能になった後でのみ、DB インスタンスを作成できます。

例えば、これからクローンを作成しようとしている tpch100g という名前のクラスターがあるとします。次の Linux の例では、tpch100g-clone という名前のクローンクラスターと、新しいクラスター用の tpch100g-clone-instance という名前のプライマリインスタンスを作成します。--master-username や --master-user-password など、いくつかのパラメータは指定する必要がありません。Aurora では、元のクラスターからそれらが自動的に決定されます。使用する DB エンジンについては、指定が必要です。この例では、新しいクラスターをテストして、--engine パラメータに使用する適切な値を判断します。


$ aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier tpch100g \
  --db-cluster-identifier tpch100g-clone \
  --restore-type copy-on-write \
  --use-latest-restorable-time

$ aws rds describe-db-clusters \
  --db-cluster-identifier tpch100g-clone \
    --query '*[].[Engine]' \
    --output text
aurora-mysql

$ aws rds create-db-instance \
  --db-instance-identifier tpch100g-clone-instance \
  --db-cluster-identifier tpch100g-clone \
  --db-instance-class db.r5.4xlarge \
  --engine aurora-mysql

ステータスの確認とクローンの詳細の取得

次のコマンドを使用して、新しく作成した空の DB クラスターのステータスが確認できます。


$ aws rds describe-db-clusters --db-cluster-identifier my-clone --query '*[].[Status]' --output text

または、次の AWS CLI クエリを使用して、ステータスなどの必要な値を取得して、クローン用の DB インスタンスを作成できます。

Linux、macOS、Unix の場合:


aws rds describe-db-clusters --db-cluster-identifier my-clone \
  --query '*[].{Status:Status,Engine:Engine,EngineVersion:EngineVersion,EngineMode:EngineMode}'

Windows の場合:


aws rds describe-db-clusters --db-cluster-identifier my-clone ^
  --query "*[].{Status:Status,Engine:Engine,EngineVersion:EngineVersion,EngineMode:EngineMode}"

このクエリにより、以下のような出力が返されます。


[
  {
        "Status": "available",
        "Engine": "aurora-mysql",
        "EngineVersion": "8.0.mysql_aurora.3.04.1",
        "EngineMode": "provisioned"
    }
]

クローン用の Aurora DB インスタンスの作成

Aurora Serverless v2 またはプロビジョニングされたクローン用の DB インスタンスを作成するには、create-db-instance CLI コマンドを使用します。Aurora Serverless v1 クローン用の DB インスタンスは作成しません。

DB インスタンスは、--master-username および --master-user-password プロパティを、ソース DB クラスターから引き継ぎます。

次の例では、プロビジョニングされたクローンの DB インスタンスを作成します。

Linux、macOS、Unix の場合:


aws rds create-db-instance \
    --db-instance-identifier my-new-db \
    --db-cluster-identifier my-clone \
    --db-instance-class db.r5.4xlarge \
    --engine aurora-mysql

Windows の場合:


aws rds create-db-instance ^
    --db-instance-identifier my-new-db ^
    --db-cluster-identifier my-clone ^
    --db-instance-class db.r5.4xlarge ^
    --engine aurora-mysql

クローン作成に使用するパラメータ

次の表は restore-db-cluster-to-point-in-time を使用して Aurora DB クラスターのクローンを作成する際に使用されるさまざまなパラメータをまとめたものです。

Parameter	説明
`--source-db-cluster-identifier`	クローンを作成するソース Aurora DB クラスターの名前を使用します。
`--db-cluster-identifier`	`restore-db-cluster-to-point-in-time` コマンドを使用してクローンを作成するときに、わかりやすい名前を選択します。次に、この名前を `create-db-instance` コマンドに渡します。
`--restore-type`	`--restore-type` として `copy-on-write` を指定すると、ソース Aurora DB クラスターを復元するのではなく、ソース DB クラスターのクローンを作成します。
`--use-latest-restorable-time`	この値は、ソース DB クラスターの最新の復元可能なボリュームデータを指します。これを使用してクローンを作成します。
`--engine-mode`	このパラメータを使用して、以下のいずれかの値でソース Aurora DB クラスターとは異なるタイプのクローンを作成します。 Aurora Serverless v1 DB クラスターからプロビジョニングされた、または Aurora Serverless v2 クローンを作成するには、`provisioned` を使用します。プロビジョニングされた、または Aurora Serverless v2 DB クラスターから Aurora Serverless v1 クローンを作成するには、`serverless` を使用します。 `serverless` エンジンモードを指定すると、`--scaling-configuration` を選択することもできます。
`--scaling-configuration`	このパラメータを使用して、Aurora Serverless v1 クローンの最小と最大の容量を設定します。このパラメータを指定しない場合、Aurora は DB エンジンのデフォルトの容量値を使用してクローンを作成します。
`--serverless-v2-scaling-configuration`	このパラメータを使用して、Aurora Serverless v2 クローンの最小と最大の容量を設定します。このパラメータを指定しない場合、Aurora は DB エンジンのデフォルトの容量値を使用してクローンを作成します。

Amazon Aurora を使用したクロス VPC クローニング

元のクラスターとクローンに異なるネットワークアクセスコントロールを課すとします。例えば、クローニングを使用して、開発用とテスト用に異なる VPC に本番稼働用 Aurora クラスターのコピーを作成できます。または、パブリックサブネットからプライベートサブネットへの移行の一環としてクローンを作成して、データベースのセキュリティを強化することもできます。

以下のセクションでは、元のクラスターとクローンの両方が、異なるサブネットまたは異なる VPC からでも同じ Aurora ストレージノードにアクセスできるように、クローンのネットワーク設定を設定する方法を示します。ネットワークリソースを事前に検証すると、診断が困難なクローニング時のエラーを回避できることがあります。

Aurora が VPC、サブネット、および DB サブネットグループと相互作用する方法に慣れていない場合は、まず、「Amazon VPC VPC とAmazon Aurora」を参照してください。そのセクションのチュートリアルでは、これらの種類のリソースを AWS コンソールで作成し、それらの組み合わせを理解できます。

ステップでは RDS サービスと EC2 サービスを切り替える必要があるため、例では AWS CLI コマンドを使用して、このような操作を自動化して出力を保存する方法を理解します。

開始する前に
ネットワーク環境に関する情報の収集
クローンのネットワークリソースの作成
新しいネットワーク設定で Aurora クローンを作成する

開始する前に

クロス VPC クローンの設定を開始する前に、次のリソースがあることを確認してください。

クローニングのソースとして使用する Aurora DB クラスター。Aurora DB クラスターを初めて作成する場合は、「Amazon Aurora の開始方法」のチュートリアルを参照して、MySQL または PostgreSQL データベースエンジンを使用してクラスターを設定します。
クロス VPC クローンを作成する場合は、2 番目の VPC。クローンに使用する VPC がない場合は、「チュートリアル: DB クラスターで使用する VPC を作成する (IPv4 専用)」または「チュートリアル: DB クラスター用の VPC を作成する (デュアルスタックモード)」を参照してください。

ネットワーク環境に関する情報の収集

クロス VPC クローニングでは、ネットワーク環境は元のクラスターとそのクローンの間で大きく異なる場合があります。クローンを作成する前に、元のクラスターで使用される VPC、サブネット、DB サブネットグループ、および AZ に関する情報を収集して記録します。これにより、問題発生の可能性を最小限に抑えることができます。ネットワーク問題が発生した場合は、診断情報を検索するためにトラブルシューティングアクティビティを中断する必要はありません。以下のセクションでは、これらのタイプの情報を収集するための CLI の例を示します。クローンの作成時やトラブルシューティング時に参照しやすい形式で詳細を保存できます。

ステップ 1: 元のクラスターのアベイラビリティーゾーンを確認する
ステップ 2: 元のクラスターの DB サブネットグループを確認する
ステップ 3: 元のクラスターのサブネットを確認する
ステップ 4: 元のクラスターの DB インスタンスのアベイラビリティーゾーンを確認する
ステップ 5: クローンに使用できる VPC を確認する

ステップ 1: 元のクラスターのアベイラビリティーゾーンを確認する

クローンを作成する前に、元のクラスターがストレージに使用する AZ を確認してください。「Amazon Aurora ストレージと信頼性」で説明されているように、各 Aurora クラスターのストレージは、厳密に 3 つの AZ に関連付けられます。Amazon Aurora DB クラスターはコンピューティングとストレージの分離を利用するため、このルールはクラスター内のインスタンス数に関係なく当てはまります。

例えば、次のような CLI コマンドを実行して、my_cluster を独自のクラスター名に置き換えます。次の例では、AZ 名のアルファベット順にソートされたリストを生成します。


aws rds describe-db-clusters \
  --db-cluster-identifier my_cluster \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' \
  --output text

次の例は、前の describe-db-clusters コマンドからの出力例を示しています。これは、Aurora クラスターのストレージが常に 3 つの AZ を使用することを示しています。


us-east-1c
us-east-1d
us-east-1e

これらの AZ に接続するためのリソースがすべて揃っていないネットワーク環境にクローンを作成するには、これらの AZ の少なくとも 2 つに関連付けられたサブネットを作成し、それらの 2 つまたは 3 つのサブネットを含む DB サブネットグループを作成する必要があります。次の例は、その方法を示しています。

ステップ 2: 元のクラスターの DB サブネットグループを確認する

クローンに元のクラスターと同じ数のサブネットを使用する場合は、元のクラスターの DB サブネットグループからサブネットの数を取得できます。Aurora DB サブネットグループには、それぞれが異なる AZ に関連付けられているサブネットが少なくとも 2 つ含まれています。サブネットが関連付けられている AZ を書き留めます。

次の例は、元のクラスターの DB サブネットグループを検索し、対応する AZ に逆算する方法を示しています。最初のコマンドで、my_cluster をクラスターの名前に置き換えます。2 番目のコマンドで、my_subnet を DB サブネットグループの名前に置き換えます。


aws rds describe-db-clusters --db-cluster-identifier my_cluster \
  --query '*[].DBSubnetGroup' --output text

aws rds describe-db-subnet-groups --db-subnet-group-name my_subnet_group \
  --query '*[].Subnets[].[SubnetAvailabilityZone.Name]' --output text

2 つのサブネットを含む DB サブネットグループを持つクラスターの場合、出力例は次のようになります。この場合、two-subnets は DB サブネットグループの作成時に指定された名前です。


two-subnets

us-east-1d
us-east-1c

3 つのサブネットを含む DB サブネットグループを持つクラスターの場合、出力例は次のようになります。


three-subnets

us-east-1f
us-east-1d
us-east-1c

ステップ 3: 元のクラスターのサブネットを確認する

元のクラスターのサブネットに関する詳細が必要な場合は、次のような AWS CLI コマンドを実行します。IP アドレス範囲、所有者などのサブネット属性を調べることができます。これにより、同じ VPC で異なるサブネットを使用するか、異なる VPC に同様の特性を持つサブネットを作成するかを決定できます。

VPC で使用可能なすべてのサブネットのサブネット ID を検索します。


aws ec2 describe-subnets --filters Name=vpc-id,Values=my_vpc \
  --query '*[].[SubnetId]' --output text

DB サブネットグループで使用される正確なサブネットを検索します。


aws rds describe-db-subnet-groups --db-subnet-group-name my_subnet_group \
  --query '*[].Subnets[].[SubnetIdentifier]' --output text

次に、次のコマンドのように、調査するサブネットをリストで指定します。my_subnet_1 などをサブネットの名前に置き換えます。


aws ec2 describe-subnets \
  --subnet-ids '["my_subnet_1","my_subnet2","my_subnet3"]'

次の例は、このような describe-subnets コマンドからの部分的な出力を示しています。この出力は、関連する AZ やそれが属する VPC など、サブネットごとに確認できる重要な属性の一部を示しています。


{
    'Subnets': [
        {
            'AvailabilityZone': 'us-east-1d',
            'AvailableIpAddressCount': 54,
            'CidrBlock': '10.0.0.64/26',
            'State': 'available',
            'SubnetId': 'subnet-000a0bca00e0b0000',
            'VpcId': 'vpc-3f3c3fc3333b3ffb3',
            ...
        },
        {
            'AvailabilityZone': 'us-east-1c',
            'AvailableIpAddressCount': 55,
            'CidrBlock': '10.0.0.0/26',
            'State': 'available',
            'SubnetId': 'subnet-4b4dbfe4d4a4fd4c4',
            'VpcId': 'vpc-3f3c3fc3333b3ffb3',
            ...

ステップ 4: 元のクラスターの DB インスタンスのアベイラビリティーゾーンを確認する

この手順を使用して、元のクラスターの DB インスタンスに使用される AZ を理解できます。これにより、クローン内の DB インスタンスにまったく同じ AZ を設定できます。また、クローンが本番環境、開発、テストなどに使用されているかどうかに応じて、クローン内で使用する DB インスタンスの数を増減することもできます。

元のクラスター内のインスタンスごとに、次のようなコマンドを実行します。インスタンスの作成が完了し、最初に Available 状態になっていることを確認します。my_instance をインスタンス識別子に置き換えます。


aws rds describe-db-instances --db-instance-identifier my_instance \
  --query '*[].AvailabilityZone' --output text

次の例は、前述の describe-db-instances コマンドを実行したときの出力を示しています。Aurora クラスターには 4 つのデータベースインスタンスがあります。したがって、コマンドを 4 回実行し、毎回異なる DB インスタンス識別子を置き換えます。出力は、これらの DB インスタンスが最大 3 つの AZ にどのように分散されるかを示しています。


us-east-1a
us-east-1c
us-east-1d
us-east-1a

クローンが作成され、そのクローンに DB インスタンスを追加すると、create-db-instance コマンドでこれらの同じ AZ 名を指定できます。これにより、元のクラスターとまったく同じ AZ 用に設定された新しいクラスターに DB インスタンスを設定できます。

ステップ 5: クローンに使用できる VPC を確認する

クローンを元の VPC とは異なる VPC に作成する場合は、アカウントで使用できる VPC ID のリストを取得できます。元のクラスターと同じ VPC 内に追加のサブネットを作成する必要がある場合も、このステップを実行できます。コマンドを実行してサブネットを作成するときは、VPC ID をパラメータとして指定します。

アカウントのすべての VPC を一覧表示するには、次の CLI コマンドを実行します。


aws ec2 describe-vpcs --query '*[].[VpcId]' --output text

次の例は、前の describe-vpcs コマンドからの出力例を示しています。出力は、現在の AWS アカウントにクロス VPC クローニングのソースまたはデスティネーションとして使用できる 4 つの VPC があることを示しています。


vpc-fd111111
vpc-2222e2cd2a222f22e
vpc-33333333a33333d33
vpc-4ae4d4de4a4444dad

クローンのデスティネーションと同じ VPC を使用することも、別の VPC を使用することもできます。元のクラスターとクローンが同じ VPC にある場合は、同じ DB サブネットグループをクローンに再利用できます。別の DB サブネットグループを作成することもできます。例えば、新しい DB サブネットグループではプライベートサブネットを使用し、元のクラスターの DB サブネットグループではパブリックサブネットを使用することができます。別の VPC にクローンを作成する場合は、新しい VPC に十分なサブネットがあり、サブネットが元のクラスターの適切な AZ に関連付けられていることを確認してください。

クローンのネットワークリソースの作成

ネットワーク情報の収集中に、クローンに追加のネットワークリソースが必要であることがわかった場合は、クローンをセットアップする前にそれらのリソースを作成できます。例えば、より多くのサブネット、特定の AZ に関連付けられたサブネット、または新しい DB サブネットグループを作成する必要がある場合があります。

ステップ 1: クローンのサブネットを作成する
ステップ 2: クローンの DB サブネットグループを作成する

ステップ 1: クローンのサブネットを作成する

クローンの新しいサブネットを作成する必要がある場合は、次のようなコマンドを実行します。これは、別の VPC でクローンを作成するとき、またはパブリックサブネットの代わりにプライベートサブネットを使用するなど、他のネットワーク変更を行うときに必要になる場合があります。

AWS はサブネットの ID を自動的に生成します。my_vpc をクローンの VPC の名前に置き換えます。範囲内に少なくとも 16 個の IP アドレスを許可する --cidr-block オプションのアドレス範囲を選択します。指定する他のプロパティを含めることができます。コマンド aws ec2 create-subnet help を実行して、すべての選択肢を表示します。


aws ec2 create-subnet --vpc-id my_vpc \
  --availability-zone AZ_name --cidr-block IP_range

次の例は、新しく作成されたサブネットの重要な属性を示しています。


{
    'Subnet': {
        'AvailabilityZone': 'us-east-1b',
        'AvailableIpAddressCount': 59,
        'CidrBlock': '10.0.0.64/26',
        'State': 'available',
        'SubnetId': 'subnet-44b4a44f4e44db444',
        'VpcId': 'vpc-555fc5df555e555dc',
        ...
        }
}

ステップ 2: クローンの DB サブネットグループを作成する

別の VPC または同じ VPC 内の別のサブネットセットにクローンを作成する場合は、新しい DB サブネットグループを作成し、クローンの作成時に指定します。

以下の詳細がすべてわかっていることを確認してください。これらはすべて、前の例の出力から確認できます。

元のクラスターの VPC。手順については、ステップ 3: 元のクラスターのサブネットを確認するを参照してください。
別の VPC で作成する場合は、クローンの VPC。手順については、ステップ 5: クローンに使用できる VPC を確認するを参照してください。
元のクラスターの Aurora ストレージに関連付けられている 3 つの AZ。手順については、ステップ 1: 元のクラスターのアベイラビリティーゾーンを確認するを参照してください。
元のクラスターの DB サブネットグループに関連付けられている 2 つまたは 3 つの AZ。手順については、ステップ 2: 元のクラスターの DB サブネットグループを確認するを参照してください。
クローンに使用する VPC 内のすべてのサブネットのサブネット ID および関連付られている AZ。ステップ 3: 元のクラスターのサブネットを確認すると同じ describe-subnets コマンドを使用して、デスティネーション VPC の VPC ID を置き換えます。

元のクラスターのストレージに関連付けられ、デスティネーション VPC のサブネットに関連付けられている AZ の数を確認します。クローンを正常に作成するには、2 つまたは 3 つの AZ が共通している必要があります。共通する AZ が 2 つ未満の場合は、ステップ 1: クローンのサブネットを作成するに戻ります。元のクラスターのストレージに関連付けられた AZ に関連付けられた新しいサブネットを 1 つ、2 つ、または 3 つ作成します。

元のクラスターの Aurora ストレージと同じ AZ に関連付けられているデスティネーション VPC 内のサブネットを選択します。理想的には、3 つの AZ を選択します。これにより、コンピューティングリソースの高可用性を実現するために、クローンの DB インスタンスを複数の AZ に分散するための最大の柔軟性が得られます。

次のようなコマンドを実行して、新しい DB サブネットグループを作成します。リスト内のサブネットの ID を置き換えます。環境変数を使用してサブネット ID を指定する場合は、ID の前後の二重引用符を保持するように、--subnet-ids パラメータリストを引用符で囲むように注意してください。


aws rds create-db-subnet-group --db-subnet-group-name my_subnet_group \
  --subnet-ids '["my_subnet_1","my_subnet_2","my_subnet3"]' \
  --db-subnet-group-description 'DB subnet group with 3 subnets for clone'

次の例は、create-db-subnet-group コマンドの部分的出力を示しています。


{
    'DBSubnetGroup': {
        'DBSubnetGroupName': 'my_subnet_group',
        'DBSubnetGroupDescription': 'DB subnet group with 3 subnets for clone',
        'VpcId': 'vpc-555fc5df555e555dc',
        'SubnetGroupStatus': 'Complete',
        'Subnets': [
            {
                'SubnetIdentifier': 'my_subnet_1',
                'SubnetAvailabilityZone': {
                    'Name': 'us-east-1c'
                },
                'SubnetStatus': 'Active'
            },
            {
                'SubnetIdentifier': 'my_subnet_2',
                'SubnetAvailabilityZone': {
                    'Name': 'us-east-1d'
                },
                'SubnetStatus': 'Active'
            }
            ...
        ],
        'SupportedNetworkTypes': [
            'IPV4'
        ]
    }
}

この時点では、実際にはクローンをまだ作成していません。クローンの作成時に restore-db-cluster-to-point-in-time および create-db-instance コマンドに適切なパラメータを指定できるように、関連するすべての VPC およびサブネットリソースを作成しました。

新しいネットワーク設定で Aurora クローンを作成する

新しいクラスターが使用する VPC、サブネット、AZ、およびサブネットグループの適切な設定が整っていることを確認したら、実際のクローニング操作を実行できます。次の CLI の例では、--db-subnet-group-name、--availability-zone、--vpc-security-group-ids など、クローンとその DB インスタンスをセットアップするためにコマンドで指定するオプションが強調表示されています。

ステップ 1: クローンの DB サブネットグループを指定する
ステップ 2: クローン内のインスタンスのネットワーク設定を指定する
ステップ 3: クライアントシステムからクローンへの接続を確立する

ステップ 1: クローンの DB サブネットグループを指定する

クローンを作成するときには、DB サブネットグループを指定することで、適切な VPC、サブネット、および AZ 設定をすべて設定できます。前述の例のコマンドを使用して、DB サブネットグループに入るすべての関係とマッピングを確認します。

例えば、次のコマンドは、元のクラスターをクローンにクローニングする方法を示しています。最初の例では、ソースクラスターは 2 つのサブネットに関連付けられ、クローンは 3 つのサブネットに関連付けられています。2 番目の例は、3 つのサブネットを持つクラスターから 2 つのサブネットを持つクラスターへのクローニングという逆の例を示しています。


aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier cluster-with-3-subnets \
  --db-cluster-identifier cluster-cloned-to-2-subnets \
  --restore-type copy-on-write --use-latest-restorable-time \
  --db-subnet-group-name two-subnets

クローンで Aurora Serverless v2 インスタンスを使用する場合は、次に示すように、クローンの作成時に --serverless-v2-scaling-configuration オプションを含めます。これにより、クローンに DB インスタンスを作成するときに db.serverless クラスを使用できます。後でクローンを変更して、このスケーリング設定属性を追加することもできます。この例のキャパシティー番号により、クラスター内の各 Serverless v2 インスタンスは 2～32 の Aurora キャパシティーユニット (ACU) の間でスケールできます。。Aurora Serverless v2 の機能と容量範囲の選択方法については、「Aurora Serverless v2 を使用する」を参照してください。


aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier cluster-with-2-subnets \
  --db-cluster-identifier cluster-cloned-to-3-subnets \
  --restore-type copy-on-write --use-latest-restorable-time \
  --db-subnet-group-name three-subnets \
  --serverless-v2-scaling-configuration 'MinCapacity=2,MaxCapacity=32'

DB インスタンスで使用されるサブネットの数に関係なく、ソースクラスターとクローンの Aurora ストレージは 3 つの AZ に関連付けられます。次の例では、前の例の restore-db-cluster-to-point-in-time コマンドの両方について、元のクラスターとクローンの両方に関連付けられている AZ を一覧表示します。


aws rds describe-db-clusters --db-cluster-identifier cluster-with-3-subnets \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1c
us-east-1d
us-east-1f

aws rds describe-db-clusters --db-cluster-identifier cluster-cloned-to-2-subnets \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1c
us-east-1d
us-east-1f

aws rds describe-db-clusters --db-cluster-identifier cluster-with-2-subnets \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1a
us-east-1c
us-east-1d

aws rds describe-db-clusters --db-cluster-identifier cluster-cloned-to-3-subnets \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1a
us-east-1c
us-east-1d

元のクラスターとクローンクラスターの各ペア間で少なくとも 2 つの AZ が重複するため、両方のクラスターが同じ基盤となる Aurora ストレージにアクセスできます。

ステップ 2: クローン内のインスタンスのネットワーク設定を指定する

クローンに DB インスタンスを作成するとき、デフォルトではクラスター自体から DB サブネットグループが継承されます。これにより、Aurora は各インスタンスを特定のサブネットに自動的に割り当て、サブネットに関連付けられた AZ に作成します。この選択は、クローンに新しいインスタンスを追加する際にサブネット ID や AZ を追跡する必要がないため、特に開発およびテストシステムにとって便利です。

別の方法として、クローンの Aurora DB インスタンスを作成するときに AZ を指定できます。指定する AZ は、クローンに関連付けられている一連の AZ のものである必要があります。クローンに使用する DB サブネットグループに 2 つのサブネットのみが含まれている場合は、これら 2 つのサブネットに関連付けられている AZ からのみ選択できます。この選択により、ライターインスタンスとスタンバイリーダーインスタンスが異なる AZ にあることが確認できるため、高可用性システムのための柔軟性と耐障害性が得られます。または、クラスターに追加のリーダーを追加すると、それらのリーダーが 3 つの AZ に分散していることを確認できます。そうすることで、1 つの AZ に障害が発生した場合でも、他の 2 つの AZ にライターインスタンスと別のリーダーインスタンスがあります。

次の例では、カスタム DB サブネットグループを使用するクローンされた Aurora PostgreSQL クラスターにプロビジョニングされた DB インスタンスを追加します。


aws rds create-db-instance --db-cluster-identifier my_aurora_postgresql_clone \
  --db-instance-identifier my_postgres_instance \
  --db-subnet-group-name my_new_subnet \
  --engine aurora-postgresql \
  --db-instance-class db.t4g.medium

次の例は、このようなコマンドからの部分的な出力を示しています。


{
  'DBInstanceIdentifier': 'my_postgres_instance',
  'DBClusterIdentifier': 'my_aurora_postgresql_clone',
  'DBInstanceClass': 'db.t4g.medium',
  'DBInstanceStatus': 'creating'
  ...
}

次の例では、カスタム DB サブネットグループを使用する Aurora MySQL クローンに Aurora Serverless v2 DB インスタンスを追加します。Serverless v2 インスタンスを使用するには、前の例に示すように、 restore-db-cluster-to-point-in-time コマンドの --serverless-v2-scaling-configuration オプションを必ず指定してください。


aws rds create-db-instance --db-cluster-identifier my_aurora_mysql_clone \
  --db-instance-identifier my_mysql_instance \
  --db-subnet-group-name my_other_new_subnet \
  --engine aurora-mysql \
  --db-instance-class db.serverless

次の例は、このようなコマンドからの部分的な出力を示しています。


{
  'DBInstanceIdentifier': 'my_mysql_instance',
  'DBClusterIdentifier': 'my_aurora_mysql_clone',
  'DBInstanceClass': 'db.serverless',
  'DBInstanceStatus': 'creating'
  ...
}

ステップ 3: クライアントシステムからクローンへの接続を確立する

クライアントシステムから Aurora クラスターにすでに接続している場合は、新しいクローンへの同じタイプの接続を許可する必要がある場合があります。例えば、Amazon Cloud9 インスタンスまたは EC2 インスタンスから元のクラスターに接続できます。同じクライアントシステム、またはデスティネーション VPC に作成した新しいクライアントシステムからの接続を許可するには、VPC 内のと同等の DB サブネットグループと VPC セキュリティグループを設定します。次に、クローンの作成時にサブネットグループとセキュリティグループを指定します。

次の例では、Aurora Serverless v2 クローンをセットアップします。この設定は、DB クラスターの作成時には --engine-mode provisioned と --serverless-v2-scaling-configuration の組み合わせに基づき、クラスターに各 DB インスタンスを作成するときには --db-instance-class db.serverless に基づいています。provisioned エンジンモードがデフォルトであるため、必要に応じてそのオプションを省略できます。


aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier serverless-sql-postgres\
  --db-cluster-identifier serverless-sql-postgres-clone \
  --db-subnet-group-name 'default-vpc-1234' \
  --vpc-security-group-ids 'sg-4567' \
  --serverless-v2-scaling-configuration 'MinCapacity=0.5,MaxCapacity=16' \
  --restore-type copy-on-write \
  --use-latest-restorable-time

次に、クローンに DB インスタンスを作成するときに、同じ --db-subnet-group-name オプションを指定します。オプションで、--availability-zone オプションを含めて、そのサブネットグループ内のサブネットに関連付けられた AZ のいずれかを指定できます。その AZ は、元のクラスターに関連付けられている AZ の 1 つでもある必要があります。


aws rds create-db-instance \
  --db-cluster-identifier serverless-sql-postgres-clone \
  --db-instance-identifier serverless-sql-postgres-clone-instance \
  --db-instance-class db.serverless \
  --db-subnet-group-name 'default-vpc-987zyx654' \
  --availability-zone 'us-east-1c' \
  --engine aurora-postgresql

クラスターをパブリックサブネットからプライベートサブネットに移動する

クローニングを使用して、パブリックサブネットとプライベートサブネット間でクラスターを移行できます。これは、アプリケーションを本番環境にデプロイする前に、アプリケーションにセキュリティレイヤーを追加するときに実行できます。この例では、Aurora でクローニングプロセスを開始する前に、プライベートサブネットと NAT ゲートウェイを既に設定しておく必要があります。

Aurora に関連するステップについては、前述の例と同じ一般的なステップをネットワーク環境に関する情報の収集および新しいネットワーク設定で Aurora クローンを作成するに実行できます。主な違いは、元のクラスターのすべての AZ にマッピングするパブリックサブネットがある場合でも、Aurora クラスターに十分なプライベートサブネットがあり、それらのサブネットが元のクラスターの Aurora ストレージに使用されるすべての同じ AZ に関連付けられていることを確認する必要があることです。他のクローニングのユースケースと同様に、必要な AZ に関連付けられている 3 つまたは 2 つのプライベートサブネットを使用して、クローンの DB サブネットグループを作成できます。ただし、DB サブネットグループで 2 つのプライベートサブネットを使用する場合は、元のクラスターで Aurora ストレージに使用される 3 番目の AZ に関連付けられた 3 番目のプライベートサブネットが必要です。

このチェックリストを参照して、このタイプのクローニング操作を実行するためのすべての要件が満たされていることを確認できます。

元のクラスターに関連付けられている 3 つの AZ を記録します。手順については、ステップ 1: 元のクラスターのアベイラビリティーゾーンを確認するを参照してください。
元のクラスターの DB サブネットグループ内のパブリックサブネットに関連付けられている 3 つまたは 2 つの AZ を記録します。手順については、ステップ 3: 元のクラスターのサブネットを確認するを参照してください。
元のクラスターに関連付けられている 3 つの AZ すべてにマッピングされるプライベートサブネットを作成します。また、NAT ゲートウェイの作成など、その他のネットワーク設定を行って、プライベートサブネットと通信できるようにします。詳細な手順については、「Amazon Virtual Private Cloud ユーザーガイド」の「サブネットの作成」を参照してください。
最初のポイントから AZ に関連付けられている 3 つまたは 2 つのプライベートサブネットを含む新しい DB サブネットグループを作成します。手順については、ステップ 2: クローンの DB サブネットグループを作成するを参照してください。

すべての前提条件が満たされたら、クローンを作成し、それを使用するようにアプリケーションを切り替える間、元のクラスターでのデータベースアクティビティを一時停止できます。クローンが作成され、クローンに接続してアプリケーションコードを実行できることを確認してから、元のクラスターの使用を中止できます。

クロス VPC クローンを作成するエンドツーエンドの例

元の VPC とは異なる VPC でクローンを作成する場合、前の例と同じ一般的な手順を使用します。VPC ID はサブネットのプロパティであるため、RDS CLI コマンドを実行するときに実際にはパラメータとして VPC ID を指定しません。主な違いは、新しいサブネット、特定の AZ にマッピングされた新しいサブネット、VPC セキュリティグループ、および新しい DB サブネットグループを作成する必要があることです。これは、この VPC で作成する最初の Aurora クラスターである場合に特に当てはまります。

このチェックリストを参照して、このタイプのクローニング操作を実行するためのすべての要件が満たされていることを確認できます。

元のクラスターに関連付けられている 3 つの AZ を記録します。手順については、ステップ 1: 元のクラスターのアベイラビリティーゾーンを確認するを参照してください。
元のクラスターの DB サブネットグループ内のサブネットに関連付けられている 3 つまたは 2 つの AZ を記録します。手順については、ステップ 2: 元のクラスターの DB サブネットグループを確認するを参照してください。
元のクラスターに関連付けられている 3 つの AZ すべてにマッピングされるサブネットを作成します。手順については、ステップ 1: クローンのサブネットを作成するを参照してください。
クローン内の DB インスタンスと通信できるようにするには、クライアントシステム、アプリケーションサーバーなどの VPC セキュリティグループの設定など、その他のネットワーク設定を行います。手順については、セキュリティグループによるアクセス制御を参照してください。
最初のポイントから AZ に関連付けられている 3 つまたは 2 つのサブネットを含む新しい DB サブネットグループを作成します。手順については、ステップ 2: クローンの DB サブネットグループを作成するを参照してください。

すべての前提条件が満たされたら、クローンを作成し、それを使用するようにアプリケーションを切り替える間、元のクラスターでのデータベースアクティビティを一時停止できます。クローンが作成され、クローンに接続してアプリケーションコードを実行できることを確認してから、元のクラスターとクローンの両方の実行を続けるか、元のクラスターの使用を中止するかを考慮できます。

次の Linux の例は、ある VPC から別の VPC に Aurora DB クラスターをクローンするための AWS CLI 操作のシーケンスを示しています。例に関連しない一部のフィールドは、コマンド出力に表示されていません。

まず、ソースおよびデスティネーション VPC の ID を確認します。 VPCs VPC の作成時に VPC に割り当てるわかりやすい名前は、VPC メタデータのタグとして表されます。


$ aws ec2 describe-vpcs --query '*[].[VpcId,Tags]'
[
    [
        'vpc-0f0c0fc0000b0ffb0',
        [
            {
                'Key': 'Name',
                'Value': 'clone-vpc-source'
            }
        ]
    ],
    [
        'vpc-9e99d9f99a999bd99',
        [
            {
                'Key': 'Name',
                'Value': 'clone-vpc-dest'
            }
        ]
    ]
]

元のクラスターはソース VPC に既に存在します。Aurora ストレージの同じ AZ セットを使用してクローンを設定するには、元のクラスターで使用されている AZ を確認します。


$ aws rds describe-db-clusters --db-cluster-identifier original-cluster \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1c
us-east-1d
us-east-1f

元のクラスターで使用される AZ に対応するサブネット us-east-1c、us-east-1d、および us-east-1f があることを確認します。


$ aws ec2 create-subnet --vpc-id vpc-9e99d9f99a999bd99 \
  --availability-zone us-east-1c --cidr-block 10.0.0.128/28
{
    'Subnet': {
        'AvailabilityZone': 'us-east-1c',
        'SubnetId': 'subnet-3333a33be3ef3e333',
        'VpcId': 'vpc-9e99d9f99a999bd99',
    }
}

$ aws ec2 create-subnet --vpc-id vpc-9e99d9f99a999bd99 \
--availability-zone us-east-1d --cidr-block 10.0.0.160/28
{
    'Subnet': {
        'AvailabilityZone': 'us-east-1d',
        'SubnetId': 'subnet-4eeb444cd44b4d444',
        'VpcId': 'vpc-9e99d9f99a999bd99',
    }
}

$ aws ec2 create-subnet --vpc-id vpc-9e99d9f99a999bd99 \
--availability-zone us-east-1f --cidr-block 10.0.0.224/28
{
    'Subnet': {
        'AvailabilityZone': 'us-east-1f',
        'SubnetId': 'subnet-66eea6666fb66d66c',
        'VpcId': 'vpc-9e99d9f99a999bd99',
    }
}

この例では、デスティネーション VPC に必要な AZ にマッピングされるサブネットがあることを確認します。


aws ec2 describe-subnets --query 'sort_by(*[] | [?VpcId == `vpc-9e99d9f99a999bd99`] |
[].{SubnetId:SubnetId,VpcId:VpcId,AvailabilityZone:AvailabilityZone}, &AvailabilityZone)' --output table

---------------------------------------------------------------------------
|                             DescribeSubnets                             |
+------------------+----------------------------+-------------------------+
| AvailabilityZone |         SubnetId           |          VpcId          |
+------------------+----------------------------+-------------------------+
|  us-east-1a      |  subnet-000ff0e00000c0aea  |  vpc-9e99d9f99a999bd99  |
|  us-east-1b      |  subnet-1111d111111ca11b1  |  vpc-9e99d9f99a999bd99  |
|  us-east-1c      | subnet-3333a33be3ef3e333   |  vpc-9e99d9f99a999bd99  |
|  us-east-1d      | subnet-4eeb444cd44b4d444   |  vpc-9e99d9f99a999bd99  |
|  us-east-1f      | subnet-66eea6666fb66d66c   |  vpc-9e99d9f99a999bd99  |
+------------------+----------------------------+-------------------------+

VPC に Aurora DB クラスターを作成する前に、Aurora ストレージに使用される AZ にマッピングされるサブネットを持つ DB サブネットグループが必要です。通常のクラスターを作成するときには、3 つの AZ の任意のセットを使用できます。既存のクラスターのクローンを作成する場合、サブネットグループは Aurora ストレージに使用する 3 つの AZ のうち少なくとも 2 つと一致する必要があります。


$ aws rds create-db-subnet-group \
  --db-subnet-group-name subnet-group-in-other-vpc \
  --subnet-ids '["subnet-3333a33be3ef3e333","subnet-4eeb444cd44b4d444","subnet-66eea6666fb66d66c"]' \
  --db-subnet-group-description 'DB subnet group with 3 subnets: subnet-3333a33be3ef3e333,subnet-4eeb444cd44b4d444,subnet-66eea6666fb66d66c'

{
    'DBSubnetGroup': {
        'DBSubnetGroupName': 'subnet-group-in-other-vpc',
        'DBSubnetGroupDescription': 'DB subnet group with 3 subnets: subnet-3333a33be3ef3e333,subnet-4eeb444cd44b4d444,subnet-66eea6666fb66d66c',
        'VpcId': 'vpc-9e99d9f99a999bd99',
        'SubnetGroupStatus': 'Complete',
        'Subnets': [
            {
                'SubnetIdentifier': 'subnet-4eeb444cd44b4d444',
                'SubnetAvailabilityZone': { 'Name': 'us-east-1d' }
            },
            {
                'SubnetIdentifier': 'subnet-3333a33be3ef3e333',
                'SubnetAvailabilityZone': { 'Name': 'us-east-1c' }
            },
            {
                'SubnetIdentifier': 'subnet-66eea6666fb66d66c',
                'SubnetAvailabilityZone': { 'Name': 'us-east-1f' }
            }
        ]
    }
}

これで、サブネットと DB サブネットグループが設定されました。次の例は、クラスターをクローンする restore-db-cluster-to-point-in-time を示しています。--db-subnet-group-name オプションは、クローンを元のクラスターの正しい AZ セットにマッピングする正しいサブネットのセットに関連付けます。


$ aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier original-cluster \
  --db-cluster-identifier clone-in-other-vpc \
  --restore-type copy-on-write --use-latest-restorable-time \
  --db-subnet-group-name subnet-group-in-other-vpc

{
  'DBClusterIdentifier': 'clone-in-other-vpc',
  'DBSubnetGroup': 'subnet-group-in-other-vpc',
  'Engine': 'aurora-postgresql',
  'EngineVersion': '15.4',
  'Status': 'creating',
  'Endpoint': 'clone-in-other-vpc.cluster-c0abcdef.us-east-1.rds.amazonaws.com'
}

次の例では、クローンの Aurora ストレージが元のクラスターと同じ AZ セットを使用することを確認します。


$ aws rds describe-db-clusters --db-cluster-identifier clone-in-other-vpc \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1c
us-east-1d
us-east-1f

この時点で、クローンの DB インスタンスを作成できます。各インスタンスに関連付けられた VPC セキュリティグループが、デスティネーション VPC 内の EC2 インスタンス、アプリケーションサーバーなどに使用する IP アドレス範囲からの接続を許可していることを確認します。

AWS RAM および Amazon Aurora を使用したクロスアカウントのクローン作成

Amazon Aurora とともに AWS Resource Access Manager (AWS RAM) を使用して、自分の AWS アカウントにある Aurora DB クラスターとクローンを別の AWS アカウントまたは組織と共有できます。このようなクロスアカウントのクローン作成は、データベーススナップショットを作成および復元するよりもはるかに高速です。Aurora DB クラスターの 1 つのクローンを作成し、そのクローンを共有できます。また、Aurora DB クラスターを別の AWS アカウントと共有し、そのアカウント所有者にクローンを作成させることもできます。選択するアプローチは、ユースケースによって異なります。

例えば、財務データベースのクローンを組織の内部監査チームと定期的に共有する必要がある場合があります。この場合、監査チームには使用しているアプリケーション用の独自の AWS アカウントがあります。監査チームの AWS アカウントに、Aurora DB クラスターにアクセスし、必要に応じてクローンを作成するアクセス許可を付与できます。

一方、外部ベンダーが財務データを監査する場合は、自分でクローンを作成することをお勧めします。次に、外部ベンダーにクローンのみへのアクセス権を付与します。

また、クロスアカウントのクローン作成を使用して、開発やテストなど、同じ AWS アカウントでクローンを作成する多くの同じユースケースをサポートできます。例えば、組織では、本番、開発、テストなどに、別々の AWS アカウントを使用していることがあります。詳細については、「Aurora クローン作成の概要」を参照してください。

したがって、クローンを別の AWS アカウントと共有したり、別の AWS アカウントで Aurora DB クラスターのクローンを作成したりできるようにする必要があることがあります。どちらの場合も、まず AWS RAM を使用して、共有オブジェクトを作成します。AWS アカウント間での AWS リソースの共有の詳細については、「AWS RAM ユーザーガイド」を参照してください。

クロスアカウントのクローンを作成するには、元のクラスターを所有する AWS アカウントと、クローンを作成する AWS アカウントによるアクションが必要です。まず、元のクラスターの所有者が他の 1 つ以上のアカウントによるクローンの作成を許可するようにクラスターを変更します。アカウントのいずれかが別の AWS 組織に属している場合は、AWS は、共有の招待を生成します。先に進む前に、もう一方のアカウントは招待を受け入れる必要があります。招待を受け入れた、承認済みのアカウントはそれぞれ、クラスターのクローンを作成することができます。このプロセスを通じて、クラスターは一意の Amazon リソースネーム (ARN) で識別されます。

同じAWSアカウント内のクローン作成と同様に、追加のストレージ領域が使用されるのは、ソースまたはクローンによってデータに変更が加えられた場合のみです。ストレージ料金は、その時点で適用されます。ソースクラスターが削除された場合、ストレージコストは残りのクローンクラスター間で均等に分散されます。

トピック

クロスアカウントのクローン作成の制約事項
他の AWS アカウントによるクラスターのクローン作成を許可する
別の AWS アカウントが所有するクラスターのクローンを作成する

クロスアカウントのクローン作成の制約事項

Aurora クロスアカウントのクローン作成には、次の制約事項があります。

Aurora Serverless v1 アカウント間で AWS クラスターを複製することはできません
AWS Management Console で、共有リソースへの招待を表示したり受け入れたりすることはできません。AWS CLI、Amazon RDS API、または AWS RAM コンソールを使用して、共有リソースへの招待を表示し受け入れます。
自分の AWS アカウントと共有されているクローンから新しいクローンを作成することはできます。
自分の AWS アカウントと共有されているリソース (クローンまたは Aurora DB クラスター) を共有することはできません。
1 つの Aurora DB クラスターから最大 15 のクロスアカウントクローンを作成することができます。
15 のクローンは、それぞれ異なる AWS アカウントが所有する必要があります。つまり、クラスターのクロスアカウントクローンは AWS アカウントに 1 つしか作成できません。
クラスターのクローンを作成した後、クロスアカウントクローンに制限を適用する目的で、元のクラスターとそのクローンは同じと見なされます。元のクラスターとクローンされたクラスターの両方のクロスアカウントクローンを同じ AWS アカウント内に作成することはできません。元のクラスターとそのクローンのクロスアカウントクローンの合計数は 15 を超えることはできません。
Aurora DB クラスターは、そのクラスターが ACTIVE 状態でなければ、他の AWS アカウントと共有できません。
他の AWS アカウントと共有されている Aurora DB クラスターの名前を変更することはできません。
デフォルトの RDS キーで暗号化されているクラスターのクロスアカウントクローンを作成することはできません。
ある AWS アカウントと共有されている暗号化された Aurora DB クラスターから、暗号化されていないクローンを別の AWS アカウントに作成することはできません。クラスター所有者は、ソースクラスターの AWS KMS key にアクセスするアクセス許可を付与する必要があります。ただし、クローンを作成するときに別のキーを使用できます。

他の AWS アカウントによるクラスターのクローン作成を許可する

他の AWS アカウントで、所有しているクラスターのクローンを作成できるようにするには、AWS RAM を使用して共有のアクセス許可を設定します。そのようにすることで、異なる AWS 組織の他の各アカウントに招待が送信されます。

所有しているリソースを AWS RAM コンソールで共有する手順については、AWS RAM ユーザーガイドの「お客様が所有しているリソースの共有」を参照してください。

トピック

クラスターのクローンを作成するためのアクセス許可を他の AWS アカウントに付与する
所有しているクラスターが他の AWS アカウントと共有されているかどうかを確認する

クラスターのクローンを作成するためのアクセス許可を他の AWS アカウントに付与する

共有しているクラスターが暗号化されている場合は、そのクラスターの AWS KMS key も共有します。ある AWS アカウントの AWS Identity and Access Management (IAM) ユーザーまたはロールに、別のアカウントの KMS キーの使用を許可できます。

これを行うには、まず AWS KMS を使用して、外部アカウント (ルートユーザー) を KMS キーのキーポリシーに追加します。個別のユーザーまたはロールをキーポリシーに追加するのではなく、それらを所有する外部アカウントのみを追加します。作成する KMS キーのみ共有することができます。デフォルトの RDS サービスキーを共有することはできません。KMS キーのアクセス制御については、「AWS KMS に対する認証とアクセス制御」を参照してください。

クラスターのクローンを作成するためのアクセス許可を付与するには

AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
ナビゲーションペインで、[データベース] を選択します。
[詳細] ページを表示するために共有する DB クラスターを選択後、[接続とセキュリティ] タブを選択します。
「DB クラスターを他のAWSアカウントと共有する」セクションで、このクラスターの複製を許可するAWSアカウントの数値アカウントIDを入力します。同じ組織のアカウント ID の場合は、ボックスに入力をスタートし、メニューから選択することができます。

重要
場合によっては、アカウントと同じ AWS 組織にないアカウントで、クラスターのクローンを作成することがあります。このような場合は、セキュリティ上の理由により、コンソールで、アカウント ID を所有しているユーザーや、アカウントの有無はレポートされません。
AWS アカウントと同じ AWS 組織にないアカウントの数値は慎重に入力してください。目的のアカウントと共有されたことをすぐに確認します。
確認ページで、指定したアカウント ID が正しいことを確認します。確認するには、確認ボックスに「share」と入力します。

[詳細] ページの [この DB クラスターが共有されているアカウント] に、指定した AWS アカウント ID を示すエントリが表示されます。[ステータス] 列には初期、[Pending (保留中)] のステータスが表示されます。
他の AWS アカウントの所有者に連絡するか、両方を所有している場合はそのアカウントにサインインしてください。以下の説明に従って、共有の招待を受け入れ、DB クラスターのクローンを作成するように他のアカウントの所有者に指示します。

クラスターのクローンを作成するためのアクセス許可を付与するには

必須パラメータに関する情報を収集します。クラスターの ARN と他の AWS アカウントの数値 ID が必要です。
AWS RAM CLI コマンド create-resource-share を実行します。

Linux、macOS、Unix の場合:
```
aws ram create-resource-share --name descriptive_name \
  --region region \
  --resource-arns cluster_arn \
  --principals other_account_ids
```
Windows の場合:
```
aws ram create-resource-share --name descriptive_name ^
  --region region ^
  --resource-arns cluster_arn ^
  --principals other_account_ids
```
--principals パラメータに複数アカウント ID を含めるには、ID をスペースで区切ります。許可されたアカウント ID が、AWS 組織の外部かどうかを指定するには、--allow-external-principals に --no-allow-external-principals または create-resource-share パラメータを含めます。

クラスターのクローンを作成するためのアクセス許可を付与するには

必須パラメータに関する情報を収集します。クラスターの ARN と他の AWS アカウントの数値 ID が必要です。
AWS RAM API オペレーション CreateResourceShare を呼び出し、次の値を指定します。
- 1 つ以上の AWS アカウントのアカウント ID を principals パラメータとして指定します。
- 1 つ以上の Aurora DB クラスターの ARN を resourceArns パラメータとして指定します。
- 許可されたアカウント ID が、AWS 組織の外部かどうかを指定するには、allowExternalPrincipals パラメータにブール値を含めます。

デフォルトの RDS キーを使用するクラスターを再作成する

共有する予定の暗号化クラスターでデフォルトの RDS キーを使用している場合は、クラスターを再作成します。これを行うには、DB クラスターの手動スナップショットを作成し、AWS KMS key を使用して、クラスターを新しいクラスターに復元します。その後、新しいクラスターを共有します。このプロセスを実行するには、次のステップを実行します。

デフォルトの RDS キーを使用する暗号化クラスターを再作成するには

AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
ナビゲーションペインから、[スナップショット] を選択します。
スナップショットを選択します。
[アクション] で、[スナップショットのコピー] を選択後、[暗号化の有効化] を選択します。
[AWS KMS key] では、使用する新しい暗号化キーを選択します。
コピーしたスナップショットを復元します。これを行うには、「DB クラスターのスナップショットからの復元」の手順に従います。新しい DB インスタンスでは、新しい暗号化キーが使用されます。
(オプション) 不要になった古い DB クラスターは削除します。これを行うには、「DB クラスターのスナップショットの削除」の手順に従います。削除する前に、新しいクラスターに必要なデータがすべて揃っていることと、アプリケーションでそれらに問題なくアクセスできることを確認します。

所有しているクラスターが他の AWS アカウントと共有されているかどうかを確認する

クラスターを共有するためのアクセス許可が他のユーザーに付与されているかどうかを確認することができます。確認することで、クラスターがクロスアカウントのクローンの最大数の制限に近づいているかどうかを把握することができます。

AWS RAM コンソールを使用してリソースを共有する手順については、AWS RAM ユーザーガイドの「お客様が所有しているリソースの共有」を参照してください。

所有しているクラスターが他の AWS アカウントと共有されているかどうかを確認するには

AWS RAM CLI コマンド list-principals を呼び出します。この際、アカウント ID をリソースの所有者として、クラスターの ARN をリソース ARN として使用します。共有はすべて、次のコマンドで確認することができます。クラスターのクローン作成を許可されている AWS アカウントが結果で示されます。
```
aws ram list-principals \
    --resource-arns your_cluster_arn \
    --principals your_aws_id
```

所有しているクラスターが他の AWS アカウントと共有されているかどうかを確認するには

AWS RAM API オペレーション ListPrincipals を呼び出します。アカウント ID をリソースの所有者として、クラスターの ARN をリソース ARN として使用します。

別の AWS アカウントが所有するクラスターのクローンを作成する

別の AWS アカウントが所有するクラスターのクローンを作成するには、AWS RAM を使用して、クローンを作成するためのアクセス許可を取得します。必要なアクセス許可を取得したら、Aurora クラスターのクローンを作成するためのスタンダード的な手順を行います。

また、所有しているクラスターが、別の AWS アカウントが所有するクラスターのクローンであるかどうかを確認することもできます。

AWS RAM コンソールで、別のアカウントが所有するリソースを使用する手順については、AWS RAM ユーザーガイドの「お客様が共有先になっているリソースへのアクセス」を参照してください。

トピック

他の AWS アカウントが所有するクラスターのクローン作成の招待を表示する
他の AWS アカウントが所有するクラスターを共有する招待を承諾する
別の AWS アカウントが所有する Aurora クラスターのクローンを作成する
DB クラスターがクロスアカウントのクローンであるかどうかを確認する

他の AWS アカウントが所有するクラスターのクローン作成の招待を表示する

他の AWS 組織の AWS アカウントが所有するクラスターのクローンを作成するための招待を表示するには、AWS CLI、AWS RAM コンソール、または AWS RAM API を使用します。現在、Amazon RDS コンソールを使用してこの手順を実行することはできません。

AWS RAM コンソールで招待を扱う手順については、AWS RAM ユーザーガイドの「お客様が共有先になっているリソースへのアクセス」を参照してください。

他の AWS アカウントが所有するクラスターのクローンを作成する招待を表示するには

AWS RAM CLI コマンド get-resource-share-invitations を実行します。
```
aws ram get-resource-share-invitations --region region_name
```
上記のコマンドの結果には、クラスターのクローンを作成するためのすべての招待が表示されます。これには、既に承認または却下されたものも含まれます。
(オプション) 自分のアクションが必要な招待のみ表示されるようにリストをフィルタリングするそのためには、--query 'resourceShareInvitations[?status==`PENDING`]' パラメータを追加します。

他の AWS アカウントが所有するクラスターのクローンを作成する招待を表示するには

AWS RAM API オペレーション GetResourceShareInvitations を呼び出します。このオペレーションでは、既に承認または却下されたものを含め、すべての招待が返ります。
(オプション) 自分のアクションが必要な招待のみを検索するには、resourceShareAssociations 戻りフィールドで値が status の PENDING を確認します。

他の AWS アカウントが所有するクラスターを共有する招待を承諾する

別の AWS 組織の他の AWS アカウントが所有するクラスターを共有するための招待を承認することができます。これらの招待を扱うには、AWS CLI、AWS RAM と RDS API、または AWS RAM コンソールを使用します。現在、RDS コンソールを使用してこの手順を実行することはできません。

別の AWS アカウントからクラスターを共有するための招待を承認するには

招待 ARN を検索するには、前述されているように、AWS RAM CLI コマンド get-resource-share-invitations を実行します。

招待を承認するには、前述されているように、AWS RAM CLI コマンド accept-resource-share-invitation を呼び出します。

Linux、macOS、Unix の場合:


aws ram accept-resource-share-invitation \
  --resource-share-invitation-arn invitation_arn \
  --region region

Windows の場合:


aws ram accept-resource-share-invitation ^
  --resource-share-invitation-arn invitation_arn ^
  --region region

別のアカウントのクラスターを共有するための招待を承認するには

招待 ARN を検索するには、前述されているように、AWS RAM API オペレーション GetResourceShareInvitations を呼び出します。
resourceShareInvitationArn パラメータとして ARN を RDS API オペレーション AcceptResourceShareInvitation を渡します。

別の AWS アカウントが所有する Aurora クラスターのクローンを作成する

DB クラスターを所有する AWS アカウントからの招待を承認したら、前述のように、クラスターのクローンを作成することができます。

別の AWS アカウントが所有する Aurora クラスターのクローンを作成するには

AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
ナビゲーションペインで、[データベース] を選択します。

データベースリストの上部に、[ロール] 値が Shared from account #account_id の項目が 1 つ以上表示されます。セキュリティ上の理由により、元のクラスターに関する情報は一部のみ表示されます。表示されているプロパティ(データベースエンジン、バージョンなど) は、クローン作成されたクラスターのものと同じです。
クローンを作成するクラスターを選択します。
[Actions] の [クローンの作成] を選択します。
コンソールの手順に従って、クローンを作成したクラスターの設定を終了します。
必要に応じて、クローンを作成したクラスターの暗号化を有効にします。クローンを作成しているクラスターが暗号化されている場合は、クローンを作成したクラスターの暗号化を有効にする必要があります。また、お客様とクラスターを共有した AWS アカウントは、クラスターの暗号化に使用した KMS キーも共有する必要があります。同じ KMS キーを使用してクローンを暗号化したり、独自の KMS キーを暗号化したりすることもできます。デフォルトの KMS キーで暗号化されているクラスターのクロスアカウントクローンを作成することはできません。

暗号化キーを所有するアカウントは、キーポリシーを使用して送信先アカウントにキーを使用するためのアクセス許可を付与する必要があります。このプロセスは、暗号化されたスナップショットが共有される方法と似ています。つまり、キーポリシーを使用して、キーを使用するためのアクセス許可を送信先アカウントに付与します。

別の AWS アカウントが所有する Aurora クラスターのクローンを作成するには

前述のように、DB クラスターを所有する AWS アカウントからの招待を承認します。
クラスターのクローンを作成するには、前述のように、RDS CLI コマンド source-db-cluster-identifier の restore-db-cluster-to-point-in-time パラメータで、ソースクラスターのフル ARN を指定します。

source-db-cluster-identifier として渡した ARN が共有されていない場合は、指定されたクラスターが存在しないかのように同じエラーが返ります。

Linux、macOS、Unix の場合:
```
aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier=arn:aws:rds:arn_details \
  --db-cluster-identifier=new_cluster_id \
  --restore-type=copy-on-write \
  --use-latest-restorable-time
```
Windows の場合:
```
aws rds restore-db-cluster-to-point-in-time ^
  --source-db-cluster-identifier=arn:aws:rds:arn_details ^
  --db-cluster-identifier=new_cluster_id ^
  --restore-type=copy-on-write ^
  --use-latest-restorable-time
```

クローンを作成するクラスターが暗号化されている場合は、kms-key-id パラメータを含めて、クローンを作成したクラスターを暗号化します。この kms-key-id 値は、元の DB クラスターの暗号化に使用したのと同じ値か、独自の KMS キーになります。その暗号化キーを使用するためのアクセス許可が、お客様のアカウントに付与されている必要があります。

Linux、macOS、Unix の場合:


aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier=arn:aws:rds:arn_details \
  --db-cluster-identifier=new_cluster_id \
  --restore-type=copy-on-write \
  --use-latest-restorable-time \
  --kms-key-id=arn:aws:kms:arn_details

Windows の場合:


aws rds restore-db-cluster-to-point-in-time ^
  --source-db-cluster-identifier=arn:aws:rds:arn_details ^
  --db-cluster-identifier=new_cluster_id ^
  --restore-type=copy-on-write ^
  --use-latest-restorable-time ^
  --kms-key-id=arn:aws:kms:arn_details

暗号化キーを所有するアカウントは、キーポリシーを使用して送信先アカウントにキーを使用するためのアクセス許可を付与する必要があります。このプロセスは、暗号化されたスナップショットが共有される方法と似ています。つまり、キーポリシーを使用して、キーを使用するためのアクセス許可を送信先アカウントに付与します。キーポリシーの例を次に示します。


{
  "Id": "key-policy-1",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Allow use of the key",
      "Effect": "Allow",
      "Principal": {"AWS": [
        "arn:aws:iam::account_id:user/KeyUser",
        "arn:aws:iam::account_id:root"
      ]},
      "Action": [
        "kms:CreateGrant",
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Allow attachment of persistent resources",
      "Effect": "Allow",
      "Principal": {"AWS": [
        "arn:aws:iam::account_id:user/KeyUser",
        "arn:aws:iam::account_id:root"
      ]},
      "Action": [
        "kms:CreateGrant",
        "kms:ListGrants",
        "kms:RevokeGrant"
      ],
      "Resource": "*",
      "Condition": {"Bool": {"kms:GrantIsForAWSResource": true}}
    }
  ]
}

注記

restore-db-cluster-to-point-in-time AWS CLI コマンドは、その DB クラスターの DB インスタンスではなく、DB クラスターのみを復元します。復元された DB クラスターの DB インスタンスを作成するには、create-db-instanceコマンドを起動します。復元された DB クラスターの ID を --db-cluster-identifier に指定します。

restore-db-cluster-to-point-in-time コマンドが完了し、DB クラスターが使用可能になった後でのみ、DB インスタンスを作成できます。

別の AWS アカウントが所有する Aurora クラスターのクローンを作成するには

前述のように、DB クラスターを所有する AWS アカウントからの招待を承認します。
クラスターのクローンを作成するには、RDS API オペレーション SourceDBClusterIdentifier の RestoreDBClusterToPointInTime パラメータで、ソースクラスターのフル ARN を指定します。

SourceDBClusterIdentifier として渡した ARN が共有されていない場合は、指定されたクラスターが存在しないかのように同じエラーが返ります。
クローンを作成しているクラスターが暗号化されている場合は、クローン作成されたクラスターを暗号化するように KmsKeyId パラメータを含めます。この kms-key-id 値は、元の DB クラスターの暗号化に使用したのと同じ値か、独自の KMS キーになります。その暗号化キーを使用するためのアクセス許可が、お客様のアカウントに付与されている必要があります。

ボリュームのクローンを作成する場合は、ソースクラスターの暗号化に使用した暗号化キーを使用するためのアクセス許可が送信先アカウントに付与されている必要があります。Aurora は、KmsKeyId に指定した暗号化キーを使用して、新しいクローンクラスターを暗号化します。

暗号化キーを所有するアカウントは、キーポリシーを使用して送信先アカウントにキーを使用するためのアクセス許可を付与する必要があります。このプロセスは、暗号化されたスナップショットが共有される方法と似ています。つまり、キーポリシーを使用して、キーを使用するためのアクセス許可を送信先アカウントに付与します。キーポリシーの例を次に示します。
```
{
  "Id": "key-policy-1",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Allow use of the key",
      "Effect": "Allow",
      "Principal": {"AWS": [
        "arn:aws:iam::account_id:user/KeyUser",
        "arn:aws:iam::account_id:root"
      ]},
      "Action": [
        "kms:CreateGrant",
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Allow attachment of persistent resources",
      "Effect": "Allow",
      "Principal": {"AWS": [
        "arn:aws:iam::account_id:user/KeyUser",
        "arn:aws:iam::account_id:root"
      ]},
      "Action": [
        "kms:CreateGrant",
        "kms:ListGrants",
        "kms:RevokeGrant"
      ],
      "Resource": "*",
      "Condition": {"Bool": {"kms:GrantIsForAWSResource": true}}
    }
  ]
}
```

注記

RestoreDBClusterToPointInTime RDS API オペレーションでは、DB クラスターのみが復元され、その DB クラスターの DB インスタンスは復元されません。復元された DB クラスターの DB インスタンスを作成するには、RDS API オペレーション CreateDBInstance を呼び出します。復元された DB クラスターの ID を DBClusterIdentifier に指定します。RestoreDBClusterToPointInTime オペレーションが完了し、DB クラスターのスタータスが使用可能になった後でのみ、DB インスタンスを作成できます。

DB クラスターがクロスアカウントのクローンであるかどうかを確認する

DBClusters オブジェクトは、各クラスターがクロスアカウントのクローンであるかどうかを判別します。クローンを作成するアクセス許可が付与されているクラスターを確認するには、RDS CLI コマンド include-shared を実行するときに describe-db-clusters オプションを使用します。ただし、そのようなクラスターの設定詳細の大分部は確認できません。

DB クラスターがクロスアカウントのクローンであるかどうかを確認するには

RDS CLI コマンド describe-db-clusters を呼び出します。

以下の例では、実際または可能性のあるクロスアカウントクローンの DB クラスターが describe-db-clusters 出力に表示される様子を示します。お客様の AWS アカウントが所有する既存のクラスターの場合は CrossAccountClone フィールドに、クラスターがお客様の AWS アカウントが所有する DB クラスターのクローンかどうかが示されます。

場合によっては、エントリの AWS フィールドにお客様のアカウントとは異なる DBClusterArn アカウント番号が含まれていることがあります。この場合、そのエントリは別の AWS アカウントが所有し、クローン作成が可能なクラスターであることを表します。そのようなエントリには、DBClusterArn 以外のフィールドがいくつか含まれます。クローン作成されたクラスターを作成する際は、元のクラスターと同じ StorageEncrypted、Engine、および EngineVersion 値を指定します。
```
$aws rds describe-db-clusters --include-shared --region us-east-1
{
  "DBClusters": [
      {
          "EarliestRestorableTime": "2023-02-01T21:17:54.106Z",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0",
          "CrossAccountClone": false,
...
      },
      {
          "EarliestRestorableTime": "2023-02-09T16:01:07.398Z",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0",
          "CrossAccountClone": true,
...
      },
      {
          "StorageEncrypted": false,
          "DBClusterArn": "arn:aws:rds:us-east-1:12345678:cluster:cluster-abcdefgh",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0
  ]
}
```

DB クラスターがクロスアカウントのクローンであるかどうかを確認するには

RDS API オペレーション DescribeDBClusters を呼び出します。

お客様の AWS アカウントが所有する既存のクラスターの場合は CrossAccountClone フィールドに、クラスターが別の AWS アカウントが所有する DB クラスターのクローンかどうかが示されます。AWS フィールドに別の DBClusterArn アカウント番号を持つエントリは、クローン作成が可能で、他の AWS アカウントが所有するクラスターであることを表します。このようなエントリには、DBClusterArn 以外のフィールドがいくつか含まれます。クローン作成されたクラスターを作成する際は、元のクラスターと同じ StorageEncrypted、Engine、および EngineVersion 値を指定します。

次の例は、実際のクローンクラスターと潜在的なクローンクラスターの両方を示す戻り値を示しています。
```
{
  "DBClusters": [
      {
          "EarliestRestorableTime": "2023-02-01T21:17:54.106Z",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0",
          "CrossAccountClone": false,
...
      },
      {
          "EarliestRestorableTime": "2023-02-09T16:01:07.398Z",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0",
          "CrossAccountClone": true,
...
      },
      {
          "StorageEncrypted": false,
          "DBClusterArn": "arn:aws:rds:us-east-1:12345678:cluster:cluster-abcdefgh",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0"
      }
  ]
}
```

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

パフォーマンスとスケーリングの管理

AWS サービスとの統合