Amazon Aurora DB クラスターのボリュームのクローン作成
Aurora クローン作成を使用すると、元のクラスターと同じデータページを共有するものの、個別の独立したボリュームを持つ新しいクラスターを作成できます。このプロセスは、高速で、費用効果が高いように設計されています。関連付けられたデータボリュームを持つ新しいクラスターは、クローンと呼ばれます。クローンの作成は、スナップショットの復元など、他の手法を使用してデータを物理的にコピーするよりも、高速かつスペース効率に優れています。
Aurora は、さまざまな種類のクローン作成をサポートしています。
-
プロビジョニングされた Aurora DB クラスターから、Aurora プロビジョニングされたクローンを作成できます。
-
Aurora Serverless v1 DB クラスターから Aurora Serverless v1 クローンを作成できます。
-
Aurora プロビジョンド DB クラスターから Aurora Serverless v1 クローンを作成することも、Aurora Serverless v1 DB クラスターからプロビジョンドクローンを作成することもできます。
-
Aurora Serverless v2 インスタンスを持つクラスターは、プロビジョンドクラスターと同じルールに従います。
作成元とは異なるデプロイ設定を使用してクローンを作成すると、作成元の 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 のクローン作成には、現在、次の制約事項があります。
-
AWS リージョン で許可される DB クラスターの最大数まで、必要な数のクローンを作成できます。
コピーオンライトプロトコルまたはフルコピープロトコルを使用してクローンを作成できます。フルコピープロトコルは、ポイントインタイムリカバリのように機能します。
-
出典 Aurora DB クラスターとは異なる AWS リージョンにはクローンを作成できません。
暗号化されていないプロビジョニングされた Aurora DB クラスターからは Aurora Serverless v1 クローンを作成できません。
-
パラレルクエリ機能なしの Aurora DB クラスターから、パラレルクエリを使用するクラスターにクローンを作成することはできません。並行クエリを使用するクラスターにデータを格納するには、元のクラスターのスナップショットを作成して、並行クエリ機能を使用するクラスターにそれを復元します。
-
DB インスタンスを持たない Aurora DB クラスターからクローンを作成することはできません。少なくとも 1 つの DB インスタンスを持つ Aurora DB クラスターのクローン作成のみが可能です。
-
クローンは、Aurora DB クラスターとは異なる仮想プライベートクラウド (VPC) で作成できます。その場合、VPCのサブネットは同じアベイラビリティーゾーンにマッピングする必要があります。
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 を使用して動作中のコピーオンライトプロトコルの例を示します。Aurora DB クラスター (A) に変更を加えて、ページ 1 に保持されているデータが変更されたとします。元のページ 1 に書き込む代わりに、Aurora は新しいページ 1[A] を作成します。クラスター (A) の Aurora DB クラスターボリュームは、1[A]、2、3、4 ページを参照していますが、クローン (B) は引き続き元のページを参照しています。

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

時間が経過して出典 Aurora DB クラスターボリュームとクローンの両方で追加の変更があると、その変更をキャプチャして保存するためにさらにストレージが必要になります。
出典クラスターボリュームの削除
1 つ以上のクローンが関連付けられている出典クラスターボリュームを削除しても、そのクローンには影響しません。クローンは、出典クラスターボリュームが前に所有していたページをポイントし続けます。
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 クラスターのクローンを作成するには
AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/
) を開きます。 ナビゲーションペインで、[データベース] を選択します。
リストから Aurora DB クラスターを選択し、[アクション] で、[クローンの作成] を選択します。
[クローンの作成] ページが開きます。そこで、[設定]、[接続] などの Aurora DB クラスタークローンのオプションが設定できます。
設定 セクションで、以下の手順を実行します。
[DB インスタンス識別子] に、作成する Aurora DB クラスターのクローンに付ける名前を入力します。
[容量タイプ] で、[プロビジョニング] または [サーバーレス] を、ユースケースに応じて選択します。
出典 Aurora DB クラスターが Aurora Serverless v1 DB クラスターまたは暗号化されているプロビジョニングされた Aurora DB クラスターであるときのみ、[サーバーレス] を選択することができます。
-
クラスターストレージ構成に対して、Aurora I/O-OptimizedまたはAurora Standardのいずれかを選択します。詳細については、「Amazon Aurora DB クラスターのストレージ設定」を参照してください。
-
DB インスタンスのサイズまたは DB クラスターの容量を選択してください。
-
[容量タイプ] に [プロビジョニング済み] を選択すると、[DB インスタンスのサイズ] 設定カードが表示されます。
用意されている設定のままにすることも、クローンに別の DB インスタンスクラスを使用することもできます。
-
[容量タイプ] に [サーバーレス] を選択すると、[キャパシティ設定] 設定カードが表示されます。
用意されている設定のままにすることも、ユースケースに合わせて変更することもできます。
-
-
[その他の設定] で、Aurora DB クラスターに通常行うような設定を選択します。
その他の設定には、データベース名の選択や、多くのオプション機能を使用するかどうかなどがあります。これらの機能には、バックアップ、拡張モニタリング、Amazon CloudWatch へのログのエクスポート、削除保護などがあります。
表示される選択肢の一部は、作成するクローンのタイプによって異なります。例えば、Aurora Serverless は Amazon RDS Performance Insights をサポートしていないため、このオプションは表示されません。
暗号化は、その他の設定 で利用可能なスタンダードオプションです。Aurora Serverless DB クラスターは常に暗号化されます。Aurora Serverless クローンは、Aurora サーバーレス DB クラスターまたは暗号化されているプロビジョニングされた Aurora DB クラスターからのみ作成できます。ただし、Aurora Serverless クローンには、暗号化されているプロビジョニングされたクラスターに使用したキーとは別のキーを選択できます。
Aurora Serverless DB クラスターから Aurora Serverless クローンを作成する場合、クローンに別のキーを選択できます。
Aurora DB クラスターのクローンのすべての設定の入力を完了します。Aurora DB クラスターとインスタンスの設定の詳細については、「Amazon Aurora DB クラスターの作成」を参照してください。
-
[クローンの作成] をクリックして、選択した 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 ステップで、次のとおりです。
restore-db-cluster-to-point-in-time CLI コマンドを使用して、クローンを作成します。このコマンドで使用するパラメータで、作成する空の Aurora DB クラスター (クローン) の容量タイプなどの詳細が制御されます。
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-identifiermy-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-identifiermy-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-identifiermy-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-identifiermy-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 textaurora
$
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-identifiermy-clone
\ --db-instance-class db.r5.4xlarge \ --engine aurora-mysql
Windows の場合:
aws rds create-db-instance ^ --db-instance-identifier
my-new-db
^ --db-cluster-identifiermy-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-identifiermy-clone
\ --engine aurora-postgresql
Windows の場合:
aws rds create-db-instance ^ --db-instance-identifier
my-new-db
^ --db-cluster-identifiermy-clone
^ --engine aurora-postgresql
クローン作成に使用するパラメータ
次の表は restore-db-cluster-to-point-in-time
を使用して Aurora DB クラスターのクローンを作成する際に使用されるさまざまなパラメータをまとめたものです。
Parameter | 説明 |
---|---|
--source-db-cluster-identifier |
クローンを作成する出典 Aurora DB クラスターの名前を使用します。 |
--db-cluster-identifier |
クローン用に意味のある名前を選択します。 |
--engine-mode | このパラメータを使用して、出典 Aurora DB クラスターとは異なるタイプのクローンを作成します。次のように
|
--restore-type |
|
--scaling-configuration |
このパラメータを |
--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 つしか作成できません。
-
クラスターのクローンを作成した後、クロスアカウントクローンに制限を適用する目的で、元のクラスターとそのクローンは同じと見なされます。元のクラスターとクローンされたクラスターの両方のクロスアカウントクローンを同じ 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 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
\ --regionregion
\ --resource-arnscluster_arn
\ --principalsother_account_ids
Windows の場合:
aws ram create-resource-share --name
descriptive_name
^ --regionregion
^ --resource-arnscluster_arn
^ --principalsother_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
\ --principalsyour_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 アカウントが所有するクラスターのクローンを作成する招待を表示するには
-
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 RAM コンソールで招待を扱う手順については、AWS RAM ユーザーガイドの「お客様が共有先になっているリソースへのアクセス」を参照してください。
別の 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
\ --regionregion
Windows の場合:
aws ram accept-resource-share-invitation ^ --resource-share-invitation-arn
invitation_arn
^ --regionregion
別のアカウントのクラスターを共有するための招待を承認するには
-
招待 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 #
の項目が 1 つ以上表示されます。セキュリティ上の理由により、元のクラスターに関する情報は一部のみ表示されます。表示されているプロパティ(データベースエンジン、バージョンなど) は、クローン作成されたクラスターのものと同じです 。account_id
-
クローンを作成するクラスターを選択します。
-
[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-timeWindows の場合:
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" } ] }