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

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

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

Aurora は、さまざまな種類のクローン作成をサポートしています。プロビジョニングされた Aurora DB クラスターから、Aurora プロビジョニングされたクローンを作成できます。Aurora Serverless v1 DB クラスターから Aurora Serverless v1 クローンを作成できます。しかし、Aurora プロビジョニングされた DB クラスターから Aurora Serverless v1 クローンを作成することも、Aurora Serverless v1 DB クラスターからプロビジョニングされたクローンを作成することもできます。作成元とは異なるデプロイ設定を使用してクローンを作成すると、作成元の Aurora DB エンジンの最新のマイナーバージョンを使用してクローンが作成されます。

クローンの Aurora Serverless DB クラスターの動作と制限は、Aurora Serverless v1 DB クラスターと同じです。詳細については、「Amazon Aurora Serverless v1 の使用」を参照してください。

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

現在、Aurora Serverless v1 DB クラスターのクローン作成では、他のアカウントへのクローン作成はサポートされていません。詳細については、「クロスアカウントのクローン作成の制約事項」を参照してください。

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 クローン作成の制限

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

  • ソース Aurora DB クラスターとは異なる AWS リージョンにはクローンを作成できません。

  • 暗号化されていないプロビジョニングされた Aurora DB クラスターからは Aurora Serverless v1 クローンを作成できません。

  • MySQL 5.6 互換でプロビジョニングされたクラスターからは Aurora Serverless v1 クローンを作成できません。また、MySQL 5.6 互換 Aurora Serverless v1 クラスターのプロビジョニングされたクローンを作成することもできません。

  • 1 つのコピーまたは別のクローンに基づいて、15 個を超えるクローンを作成することはできません。15 個のクローンを作成した後は、コピーのみを作成できます。ただし、各コピーにつき最大 15 個のクローンを作成できます。

  • 並列クエリ機能なしの Aurora DB クラスターから、並列クエリを使用するクラスターにクローンを作成することはできません。並行クエリを使用するクラスターにデータを格納するには、元のクラスターのスナップショットを作成して、それを並行クエリ機能を使用するクラスターに復元します。

  • DB インスタンスを持たない Aurora DB クラスターからクローンを作成することはできません。少なくとも 1 つの DB インスタンスを持つ Aurora DB クラスターのクローン作成のみが可能です。

  • クローンは、Aurora DB クラスターとは異なる仮想プライベートクラウド (VPC) で作成できます。その場合、VPCのサブネットは同じアベイラビリティゾーンにマッピングする必要があります。

Aurora クローン作成の仕組み

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


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

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

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

1 つ以上のクローンが関連付けられているソースクラスターボリュームを削除しても、そのクローンには影響しません。クローンは、ソースクラスターボリュームが前に所有していたページをポイントし続けます。

Aurora クローン作成に関する推奨事項

Aurora クローンは、Aurora クローン作成の概要 に記載されているような短期的なユースケースに使用することをお勧めします。Aurora クローンは、すばやく簡単に作成でき、目的を果たした後で削除できます。

長期間クローンを使用しないでください。特に、ソース Aurora DB クラスターとクローンによる書き込みが多い場合は避けてください。コピーオンライトプロトコルで変更が管理される方法を考慮して、このようにお勧めしています。

ソース Aurora DB クラスターとクローンに変更が加えられると、Aurora はコピーオンライトプロトコルを使用して、変更されたページを作成し追跡します。つまり、Aurora DB クラスターとクローンで書き込み操作が増えるにつれて、Aurora ストレージボリュームには次々に多くのストレージが必要になります。ストレージは、変更をキャプチャして保存するために必要です。また、内部的には、ソース Aurora DB クラスターとクローンで異なるページが増え続け、Aurora はそのリストを追跡する必要があることを意味します。この関連するオーバーヘッドが、特定のクローンの利点を上回る時がくる可能性があります。

注記

クローン作成は非常に高速な操作ですが、全体としてかかる時間は、ソース Aurora DB クラスターに格納されているデータの量によって異なります。基盤となるストレージサブシステムが行う必要がある作業を考慮すると、データのテラバイト数が大きい Aurora DB クラスターでは、クローンを作成することで、かなりの時間がかかることがあります。

Amazon Aurora クローンの作成

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

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

Aurora クローン作成を使用すると、次の種類のクローン作成オペレーションを実行できます。

  • プロビジョニングされた Aurora DB クラスターから、プロビジョニングされた Aurora DB クラスターのクローンを作成する。

  • Aurora Serverless v1 DB クラスターから、Aurora Serverless v1 クラスターのクローンを作成する。

  • プロビジョニングされた Aurora DB クラスターから、Aurora Serverless v1 DB クラスターのクローンを作成する。

  • Aurora Serverless v1 DB クラスターから、Aurora プロビジョニングされた DB クラスターのクローンを作成する。

Aurora Serverless v1 DB クラスターは常に暗号化されます。クローンを作成するとき Aurora Serverless v1 DB クラスターをプロビジョニングされた Aurora DB クラスターに変換すると、プロビジョニングされた Aurora DB クラスターは暗号化されます。暗号化キーは選択できますが、暗号化を無効にすることはできません。プロビジョニングされた Aurora DB クラスターから Aurora Serverless v1 cluster, you need のクローンを作成するには、暗号化プロビジョニングされた Aurora DB クラスターが必要です。

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 クラスターのクローンを作成するには

  1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[データベース] を選択します。

  3. リストから Aurora DB クラスターを選択し、[アクション] で、[クローンの作成] を選択します。

    
                  クローンの作成には、まず Aurora DB クラスターを選択します。

    [クローンの作成] ページが開きます。そこで、[インスタンスの仕様]、[接続] などの Aurora DB クラスタークローンのオプションが設定できます。

  4. [インスタンスの仕様] セクションで、次の操作を行います。

    1. [DB クラスター識別子] に、作成する Aurora DB クラスターのクローンに付ける名前を入力します。

      
                  クローンの作成には、まず Aurora DB クラスターを選択します。
    2. [キャパシティータイプ] で、[プロビジョニング] または [サーバーレス] を、ユースケースに応じて選択します。

      ソース Aurora DB クラスターが Aurora Serverless v1 DB クラスターまたは暗号化されているプロビジョニングされた Aurora DB クラスターであるときのみ、[サーバーレス] を選択することができます。

      • [プロビジョニング] を選択すると、[DB インスタンスのサイズ] 設定カードが表示されます。

        
                          Aurora DB クラスターからプロビジョニングされたクローンを作成するには、DB インスタンスのサイズを指定します。

        用意されている設定のままにすることも、クローンに別の DB インスタンスクラスを使用することもできます。

      • [サーバーレス] を選択すると、[キャパシティー設定] 設定カードが表示されます。

        
                      Serverless クローンを Aurora DB クラスターから作成するには、キャパシティーを指定します。

        用意されている設定のままにすることも、ユースケースに合わせて変更することもできます。

    3. [その他の設定] で、Aurora DB クラスターに通常行うような設定を選択します。

      その他の設定には、データベース名の選択や、多くのオプション機能を使用するかどうかなどがあります。これらの機能には、バックアップ、拡張モニタリング、Amazon CloudWatch へのログのエクスポート、削除保護などがあります。

      表示される選択肢の一部は、作成するクローンのタイプによって異なります。例えば、Aurora Serverless は Amazon RDS Performance Insights をサポートしていないため、このオプションは表示されません。

      暗号化は、その他の設定 で利用可能なスタンダードオプションです。Aurora Serverless DB クラスターは常に暗号化されます。Aurora Serverless クローンは、Aurora サーバーレス DB クラスターまたは暗号化されているプロビジョニングされた Aurora DB クラスターからのみ作成できます。ただし、Aurora Serverless クローンには、暗号化されているプロビジョニングされたクラスターに使用したキーとは別のキーを選択できます。

      
                      Aurora Serverless クローンの作成には、暗号化されているプロビジョニングされた Aurora DB クラスターのみが使用できます。

      Aurora Serverless DB クラスターから Aurora Serverless クローンを作成する場合、クローンに別のキーを選択できます。

      
                      クローンには、ソース Aurora Serverless DB クラスターで使用されている暗号化キーとは異なる暗号化キーを使用できます。
    4. Aurora DB クラスターのクローンのすべての設定の入力を完了します。Aurora DB クラスターとインスタンスの設定の詳細については、「Amazon Aurora DB クラスターの作成」を参照してください。

  5. [クローンの作成] をクリックして、選択した Aurora DB クラスターの Aurora クローンを起動します。

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

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

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

  1. restore-db-cluster-to-point-in-time CLI コマンドを使用して、クローンを作成します。このコマンドで使用するパラメータで、作成する空の Aurora DB クラスター (クローン) のキャパシティータイプなどの詳細が制御されます。

  2. create-db-instance CLI コマンドを使用して、クローン用の Aurora DB インスタンスを作成し、復元された Aurora DB クラスターに Aurora DB インスタンスを再作成します。

以下のコマンドでは、デフォルトで AWS CLI は、AWS リージョンにセットアップされていると仮定しています。この方法では、--region の名前を各コマンドに入力する手間が省けます。詳細については、「AWS CLI の設定」を参照してください。また、以下の各 CLI コマンドで --region を指定することもできます。

クローンの作成

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

以下の手順に従って、Aurora Serverless DB クラスターから Aurora Serverless クローンを作成するか、プロビジョニングされた Aurora DB クラスターからプロビジョニングされた Aurora クローンを作成します。

ソース 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 – この値は、クローンの最新の復元可能なボリュームデータを指します。

次の例では、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 コマンドで、クローンの名前を渡します。

    • --engine-mode – このパラメータは、ソース Aurora DB クラスターとは異なるタイプのクローンを作成する場合にのみ使用します。次のように --engine-mode として渡す値を選択します。

      • Aurora Serverless DB クラスターからプロビジョニングされた Aurora DB クラスターのクローンを作成するには、provisioned を使用します。

      • プロビジョニングされた Aurora DB クラスターから Aurora Serverless DB クラスターのクローンを作成するには、serverless を使用します。serverless エンジンモードを指定すると、--scaling-configuration を選択することもできます。

    • --restore-type – ソース DB クラスターのクローンの作成に copy-on-write を使用します。このパラメータを指定しない場合、restore-db-cluster-to-point-in-time は、クローンを作成するのではなく、Aurora DB クラスターを復元します。

    • --scaling-configuration – (オプション) --engine-mode serverless の場合にのみ使用して、クローンの最小と最大のキャパシティーを設定します。このパラメータを使用しない場合、Aurora では、最小キャパシティー 1 を使用してクローンが作成されます。ソースのプロビジョニングされた Aurora DB クラスターのキャパシティーと同じ最大キャパシティーを使用します。

    • --source-db-cluster-identifier – クローンを作成するソース Aurora DB クラスターの名前を使用します。

    • --use-latest-restorable-time – この値は、クローンの最新の復元可能なボリュームデータを指します。

次の例では、my-source-cluster という名前のプロビジョニングされた Aurora DB クラスターから Aurora Serverless クローン (my-clone) を作成します。プロビジョニングされた 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 reinvent--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 $ aws rds create-db-instance \ --db-instance-identifier tpch100g-clone-instance \ --db-cluster-identifier tpch100g-clone \ --db-instance-class db.r5.4xlarge \ --engine aurora

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

次のコマンドを使用して、新しく作成した空の 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": "5.7.mysql_aurora.2.09.1", "EngineMode": "provisioned" } ]

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

クローン用の DB インスタンスを作成するには、create-db-instance CLI コマンドを使用します。

--db-instance-class パラメータは、プロビジョニングされた Aurora 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

Aurora Serverless DB クラスターから作成された Aurora Serverless クローンには、いくつかのパラメーターのみを指定します。DB インスタンスは、--engine-mode--master-username、および --master-user-password プロパティを、ソース DB クラスターから引き継ぎます。--scaling-configuration は変更できます。

Linux、macOS、Unix の場合:

aws rds create-db-instance \ --db-instance-identifier my-new-db \ --db-cluster-identifier my-clone \ --engine aurora-postgresql

Windows の場合:

aws rds create-db-instance ^ --db-instance-identifier my-new-db ^ --db-cluster-identifier my-clone ^ --engine aurora-postgresql

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

次の表は 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 コマンドに渡します。

--engine-mode

このパラメータを使用して、ソース Aurora DB クラスターとは異なるタイプのクローンを作成します。次のように --engine-mode として渡す値を選択します。

  • Aurora Serverless DB クラスターからプロビジョニングされた Aurora DB クラスターのクローンを作成するには、provisioned を使用します。

  • プロビジョニングされた Aurora DB クラスターから Aurora Serverless DB クラスターのクローンを作成するには、serverless を使用します。serverless エンジンモードを指定すると、--scaling-configuration も選択することができます。

--restore-type

--restore-type として copy-on-write を指定すると、ソース Aurora DB クラスターを復元するのではなく、ソース DB クラスターのクローンを作成します。

--scaling-configuration

このパラメータを --engine-mode serverless とともに使用して、クローンの最小と最大のキャパシティーを設定します。このパラメータを使用しない場合、Aurora では、最小キャパシティー 1、最大キャパシティー 16 を使用して Aurora Serverless クローンが作成されます。

--use-latest-restorable-time

この値は、クローンの最新の復元可能なボリュームデータを指します。

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

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

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

  • Aurora Serverless アカウント間で AWS クラスターを複製することはできません

  • AWS Management Console で、共有リソースへの招待を表示したり受け入れたりすることはできません。AWS CLI、Amazon RDS API、または AWS RAM コンソールを使用して、共有リソースへの招待を表示し受け入れます。

  • 自分の AWS アカウントと共有されているクローンから新しいクローンを作成することはできません。

  • 自分の AWS アカウントと共有されているリソース (クローンまたは Aurora DB クラスター) を共有することはできません。

  • 1 つの Aurora DB クラスターから 15 個を超えるクロスアカウントクローンを作成することはできません。これらの15個のクローンは、それぞれ異なる AWS アカウントが所有している必要があります。つまり、クラスターのクロスアカウントクローンは AWS アカウントに 1 つしか作成できません。

  • Aurora DB クラスターは、そのクラスターが ACTIVE 状態でなければ、他の AWS アカウントと共有できません。

  • 他の AWS アカウントと共有されている Aurora DB クラスターの名前を変更することはできません。

  • デフォルトの RDS キーで暗号化されているクラスターのクロスアカウントクローンを作成することはできません。

  • 別の AWS アカウントと共有されている暗号化された Aurora DB クラスターから、暗号化されていないクローンを 1 つの AWS アカウントに作成することはできません。クラスター所有者は、ソースクラスターの AWS Key Management Service (AWS KMS) カスタマーマスターキー (CMK) にアクセスするアクセス許可を付与する必要があります。ただし、クローンを作成するときに別のキーを使用できます。

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

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

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

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

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

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

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

  1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[データベース] を選択します。

  3. [詳細] ページを表示するために共有する DB クラスターを選択後、[接続とセキュリティ] タブを選択します。

  4. [Share DB cluster with other AWS accounts (他の AWS アカウントと DB クラスターを共有する)] セクションに、このクラスターのクローン作成を許可する AWS アカウントのアカウント ID の数値を入力します。同じ組織のアカウント ID の場合は、ボックスに入力を開始し、メニューから選択することができます。

    重要

    場合によっては、アカウントと同じ AWS 組織にないアカウントで、クラスターのクローンを作成することがあります。このような場合は、セキュリティ上の理由により、コンソールで、アカウント ID を所有しているユーザーや、アカウントの有無はレポートされません。

    AWS アカウントと同じ AWS 組織にないアカウントの数値は慎重に入力してください。目的のアカウントと共有されたことをすぐに確認します。

  5. 確認ページで、指定したアカウント ID が正しいことを確認します。確認するには、確認ボックスに「share」と入力します。

    [詳細] ページの [この DB クラスターが共有されているアカウント] に、指定した AWS アカウント ID を示すエントリが表示されます。[ステータス] 列には最初、[Pending (保留中)] のステータスが表示されます。

  6. 他の AWS アカウントの所有者に連絡するか、両方を所有している場合はそのアカウントにサインインしてください。以下の説明に従って、共有の招待を受け入れ、DB クラスターのクローンを作成するように他のアカウントの所有者に指示します。

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

  1. 必須パラメータに関する情報を収集します。クラスターの ARN と他の AWS アカウントの数値 ID が必要です。

  2. 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 パラメータを含めます。

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

  1. 必須パラメータに関する情報を収集します。クラスターの ARN と他の AWS アカウントの数値 ID が必要です。

  2. AWS RAM API オペレーション CreateResourceShare を呼び出し、次の値を指定します。

    • 1 つ以上の AWS アカウントのアカウント ID を principals パラメータとして指定します。

    • 1 つ以上の Aurora DB クラスターの ARN を resourceArns パラメータとして指定します。

    • 許可されたアカウント ID が、AWS 組織の外部かどうかを指定するには、allowExternalPrincipals パラメータにブール値を含めます。

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

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

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

  1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインから、[スナップショット] を選択します。

  3. スナップショットを選択します。

  4. [アクション] で、[スナップショットのコピー] を選択後、[暗号化の有効化] を選択します。

  5. [マスターキー] で、使用する新しい暗号化キーを選択します。

  6. コピーしたスナップショットを復元します。これを行うには、「DB clusterスナップショットからの復元」の手順に従います。新しい DB インスタンスでは、新しい暗号化キーが使用されます。

  7. (オプション) 不要になった古い 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 アカウントが所有するクラスターのクローンを作成するための招待を表示するには、AWS CLI、AWS RAM コンソール、または AWS RAM API を使用します。現在、Amazon RDS コンソールを使用してこの手順を実行することはできません。

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

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

  1. AWS RAM CLI コマンド get-resource-share-invitations を実行します。

    aws ram get-resource-share-invitations --region region_name

    上記のコマンドの結果には、クラスターのクローンを作成するためのすべての招待が表示されます。これには、既に承認または却下されたものも含まれます。

  2. (オプション) 自分のアクションが必要な招待のみ表示されるようにリストをフィルタリングする そのためには、--query 'resourceShareInvitations[?status==`PENDING`]' パラメータを追加します。

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

  1. AWS RAM API オペレーション GetResourceShareInvitations を呼び出します。このオペレーションでは、すでに承認または却下されたものを含め、すべての招待が返ります。

  2. (オプション) 自分のアクションが必要な招待のみを検索するには、resourceShareAssociations 戻りフィールドで値が statusPENDING を確認します。

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

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

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

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

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

  2. 招待を承認するには、前述されているように、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

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

  1. 招待 ARN を検索するには、前述されているように、AWS RAM API オペレーション GetResourceShareInvitations を呼び出します。

  2. resourceShareInvitationArn パラメータとして ARN を RDS API オペレーション AcceptResourceShareInvitation を渡します。

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

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

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

  1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[データベース] を選択します。

    データベースリストの上部に、[ロール] 値が Shared from account #account_id の項目が 1 つ以上表示されます。セキュリティ上の理由により、元のクラスターに関する情報は一部のみ表示されます。表示されているプロパティ(データベースエンジン、バージョンなど) は、クローン作成されたクラスターのものと同じです 。

  3. クローンを作成するクラスターを選択します。

  4. [Actions] の [クローンの作成] を選択します。

  5. Console の手順に従って、クローンを作成したクラスターの設定を終了します。

  6. 必要に応じて、クローンを作成したクラスターの暗号化を有効にします。クローンを作成しているクラスターが暗号化されている場合は、クローンを作成したクラスターの暗号化を有効にする必要があります。また、お客様とクラスターを共有した AWS アカウントは、クラスターの暗号化に使用した AWS KMS CMK も共有する必要があります。同じ CMK を使用してクローンを暗号化することも、独自の CMK を暗号化することもできます。デフォルトの RDS CMK で暗号化されているクラスターのクロスアカウントクローンを作成することはできません。

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

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

  1. 前述のように、DB クラスターを所有する AWS アカウントからの招待を承認します。

  2. クラスターのクローンを作成するには、前述のように、RDS CLI コマンド source-db-cluster-identifierrestore-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
  3. クローンを作成するクラスターが暗号化されている場合は、kms-key-id パラメータを含めて、クローンを作成したクラスターを暗号化します。この kms-key-id 値は、元の DB クラスターの暗号化に使用したのと同じ値か、独自の CMK になります。その暗号化キーを使用するためのアクセス許可が、お客様のアカウントに付与されている必要があります。

    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 クラスターのクローンを作成するには

  1. 前述のように、DB クラスターを所有する AWS アカウントからの招待を承認します。

  2. クラスターのクローンを作成するには、RDS API オペレーション SourceDBClusterIdentifierRestoreDBClusterToPointInTime パラメータで、ソースクラスターのフル ARN を指定します。

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

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

    ボリュームのクローンを作成する場合は、ソースクラスターの暗号化に使用した暗号化キーを使用するためのアクセス許可が宛先のアカウントに付与されている必要があります。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 以外のフィールドがいくつか含まれます。クローン作成されたクラスターを作成する際は、元のクラスターと同じ StorageEncryptedEngine、および EngineVersion 値を指定します。

    $ aws rds describe-db-clusters --include-shared --region us-east-1 { "DBClusters": [ { "EarliestRestorableTime": "2019-05-01T21:17:54.106Z", "Engine": "aurora", "EngineVersion": "5.6.10a", "CrossAccountClone": false, ... }, { "EarliestRestorableTime": "2019-04-09T16:01:07.398Z", "Engine": "aurora", "EngineVersion": "5.6.10a", "CrossAccountClone": true, ... }, { "StorageEncrypted": false, "DBClusterArn": "arn:aws:rds:us-east-1:12345678:cluster:cluster-abcdefgh", "Engine": "aurora", "EngineVersion": "5.6.10a", } ] }

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

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

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

    次の例は、実際のクローンクラスターと潜在的なクローンクラスターの両方を示す戻り値を示しています。

    { "DBClusters": [ { "EarliestRestorableTime": "2019-05-01T21:17:54.106Z", "Engine": "aurora", "EngineVersion": "5.6.10a", "CrossAccountClone": false, ... }, { "EarliestRestorableTime": "2019-04-09T16:01:07.398Z", "Engine": "aurora", "EngineVersion": "5.6.10a", "CrossAccountClone": true, ... }, { "StorageEncrypted": false, "DBClusterArn": "arn:aws:rds:us-east-1:12345678:cluster:cluster-abcdefgh", "Engine": "aurora", "EngineVersion": "5.6.10a" } ] }