Amazon Aurora
Aurora のユーザーガイド (API バージョン 2014-10-31)

Aurora DB クラスターでのデータベースのクローン作成

データベースのクローン作成を使用すると、Aurora DB クラスター内のすべてのデータベースのクローンを迅速かつ高いコスト効率で作成できます。クローンデータベースの初回作成時に必要な追加スペースは最小限です。

データベースのクローン作成で使用されるコピーオンライトプロトコルでは、ソースデータベースまたはクローンデータベースのいずれかでそのときに変更されたデータがコピーされます。同じ DB クラスターから複数のクローンを作成できます。また、そのほかのクローンから追加のクローンを作成することもできます。Aurora ストレージのコンテキストにおけるコピーオンライトプロトコルの詳しい動作については、「データベースクローンのコピーオンライトプロトコル」を参照してください。

データベースのクローン作成は、特に本稼働環境に影響を及ぼさない、さまざまなユースケースで使用できます。以下に例をいくつか示します:

  • スキーマの変更やパラメータグループの変更など、変更の影響を試したり評価したりする場合。

  • データのエクスポートや分析クエリの実行など、大量のワークロードを扱うオペレーションを実行する場合。

  • 開発やテストの目的で試験的な環境で本番稼働用の DB クラスターのコピーを作成する場合。

制約事項

データベースのクローン作成には、以下に説明するような制約があります。

  • AWS リージョンをまたぐクローンデータベースは作成できません。クローンデータベースはソース データベースと同じリージョンで作成する必要があります。

  • 現在のところ、そのほかのクローンからのクローンを含め、1 つのコピーから 15 までのクローン作成に制限されます。最大数に達した場合、1 つのコピーのみ作成できます。ただし、各コピーは最大で 15 までのクローンを作成できます。

  • Aurora MySQL では、アカウント間でのデータベースのクローン作成は現在サポートされていません。

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

  • クローンに異なる virtual private cloud (VPC) を提供できます。ただし、この VPCのサブネットは同じアベイラビリティゾーンにマッピングする必要があります。

データベースクローンのコピーオンライトプロトコル

以下の例で、コピーオンライトプロトコルの動作について説明します。

データベースのクローンを作成する前に

ソースデータベースのデータはページに保存されています。次の図では、ソースデータベースに 4 つのページがあります。


                     Amazon Aurora ソースデータベース (データベースのクローン作成前)

データベースのクローン作成後に

次の図に示すように、データベースのクローン後、ソースデータベースに変更はありません。ソースデータベースとクローンデータベースの両方が同じ 4 つのページを指しています。どのページも物理的にコピーされていないため、追加のストレージは不要です。


                     Amazon Aurora ソースデータベースとクローンデータベース (データベースのクローン作成後)

ソースデータベースで変更があった場合

次の例では、ソースデータベースの Page 1 のデータに変更があります。元の Page 1 に書き込む代わりに、追加のストレージを使用して Page 1' という新しいページが作成されます。ソースデータベースはこれで新しい Page 1'、および Page 2Page 3Page 4 を指すようになります。クローンデータベースは、これまでと同じく Page 1 から Page 4 を指します。


                     Amazon Aurora ソースデータベースとクローンデータベース (ソースデータベースでの変更後)

クローンデータベースで変更があった場合

次の図では、クローンデータベースにも変更があります。今回の変更は Page 4 です。元の Page 4 に書き込む代わりに、追加のストレージを使用して Page 4' という新しいページが作成されます。ソースデータベースはこれまで同様、Page 1' および Page 2 から Page 4 を指しますが、クローンデータベースは Page 1 から Page 3 までと Page 4' を指すようになります。


                     Amazon Aurora ソースデータベースとクローンデータベース (クローンデータベースでの変更後)

2 番目の例で示すように、データベースのクローン作成時点では追加のストレージは不要です。ただし、例 3 と例 4 で示すように、ソースデータベースとクローンデータベースで変更があると、変更があったページだけが作成されます。時間が経過してソースデータベースとクローンデータベースの両方で追加の変更があると、その変更をキャプチャして保存するために増分のストレージが必要になります。

ソースデータベースの削除

ソースデータベースを削除しても、それに関連付けられているクローンデータベースには影響がありません。クローンデータベースは、ソースデータベースが前に所有していたページを指し続けます。

AWS マネジメントコンソール で Aurora クラスターのクローンを作成する

AWS マネジメントコンソールを使用して Aurora DB クラスターのクローンを作成する手順を以下に示します。

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

AWS マネジメントコンソール を使用して、お客様の AWS アカウントが所有している DB クラスターのクローンを作成するには

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

  2. ナビゲーションペインで、[データベース] を選択します。クローンを作成する DB クラスターを選択します。

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

  4. [クローンの作成] ページで、[DB インスタンス識別子] としてクローン DB クラスターのプライマリインスタンスの名前を入力します。

    希望する場合には、クローン DB クラスターのそのほかの設定を行います。各種の DB クラスターの設定についての詳細は、「コンソール」を参照してください。

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

AWS CLI で Aurora クラスターのクローンを作成する

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

AWS CLI を使用して DB クラスターのクローンを作成するには

  • restore-db-cluster-to-point-in-time AWS CLI コマンドを呼び出し、以下の値を指定します。

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

    • --db-cluster-identifier – クローン DB クラスターの名前。

    • --restore-type copy-on-write – クローン DB クラスターを作成するように示す値。

    • --use-latest-restorable-time – 最新の復元可能なバックアップ時間を使用することを指定します。

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

    Linux、OS X、Unix の場合:

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

    Windows の場合:

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

注記

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

クロスアカウントのクローン作成

Amazon Aurora では、Aurora DB クラスターを別の AWS アカウントまたは AWS 組織と共有することができます。このように共有することで、DB クラスターのクローンを作成し、他のアカウントまたは組織からそのクローンにアクセスできます。

たとえば、本稼働用とテスト用に別々のアカウントを使用する場合は、テスト用のアカウントに本稼働データのクローンを作成できます。このクローンを使用して、本稼働環境に影響を及ぼすことなく、さまざまなパラメータを試したり、高価なオンライン分析処理 (OLAP) クエリを実行したりできます。たとえば、外部ベンダーが機械学習モデルをトレーニングできるように、データベースへのアクセス権を外部の企業に付与することができます。このような状況では、データベーススナップショットを作成および復元するよりも、クロスアカウントのクローン作成の方がはるかに高速です。

共有を許可するには、AWS Resource Access Manager (AWS RAM) を使用します。AWS RAM へのアクセスの制御方法については、「AWS RAM ユーザーガイド」を参照してください。

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

データの変更を行った場合にのみ、追加のストレージ容量に対する料金が請求されます。ソースクラスターが削除された場合、ストレージコストは残りのクローンクラスター間で均等に分散されます。

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

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

  • Aurora サーバーレスクラスターのクローンは、複数の AWS アカウントにまたがって作成することはできません。

  • Aurora グローバルデータベースクラスターのクローンは、複数の AWS アカウントにまたがって作成することはできません。

  • 共有の招待を表示または承認するには、AWS CLI、Amazon RDS API、または AWS RAM コンソールを使用する必要があります。現在、Amazon RDS コンソールを使用してこの手順を実行することはできません。

  • クロスアカウントのクラスターを作成する場合、その新しいクラスターの追加クローンを作成したり、クローンクラスターを他の AWS アカウントと共有したりすることはできません。

  • 任意の Aurora クラスターに対して作成できるクロスアカウントのクローンの最大数は 15 です。

  • 他の AWS アカウントとの共有時、クラスターが ACTIVE 状態になっている必要があります。

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

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

  • 暗号化されたクラスターが共有されている場合は、クローン作成されたクラスターを暗号化する必要があります。使用するキーは、元のクラスターの暗号化キーとは異なる場合があります。また、クラスターの所有者は、元のクラスターの AWS Key Management Service (AWS KMS) キーにアクセスするためのアクセス許可を付与する必要があります。

他の 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 に対する認証とアクセスコントロール」を参照してください。

コンソール

AWS マネジメントコンソール を使用してクラスターのクローンを作成するためのアクセス許可を付与するには

  1. AWS マネジメントコンソールにサインインし、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 組織にないアカウントで、クラスターのクローンを作成することがあります。このような場合は、セキュリティ上の理由により、AWS マネジメントコンソール で、アカウント ID を所有しているユーザーや、アカウントの有無はレポートされません。

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

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

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

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

AWS CLI

AWS CLI を使用してクラスターのクローンを作成するためのアクセス許可を付与するには

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

  2. CLI の create-resource-share コマンドを実行します。

    Linux、OS X、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 組織の外部かどうかを指定するには、create-resource-share--allow-external-principals または --no-allow-external-principals パラメータを含めます。

RAM API

RAM API を使用してクラスターのクローンを作成するためのアクセス許可を付与するには

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  7. (オプション) 不要になった古い DB クラスターは削除します。これを行うには、「DB クラスタースナップショットの削除」の手順に従います。削除する前に、新しいクラスターに必要なデータがすべて揃っていることと、アプリケーションでそれらに問題なくアクセスできることを確認します。

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

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

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

AWS CLI

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

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

    aws ram list-principals \ --resource-arns your_cluster_arn \ --principals your_aws_id
RAM API

RAM API を使用して、所有しているクラスターが他の 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 CLI

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

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

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

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

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

RAM API

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

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

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

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

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

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

コンソール

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

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

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

    Linux、OS X、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
RAM および RDS API

RAM および RDS API を使用して、別のアカウントが共有するクラスターを共有するための招待を承認するには

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

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

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

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

コンソール

AWS マネジメントコンソール を使用して、別の AWS アカウントが所有する Aurora クラスターのクローンを作成するには

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

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

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

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

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

  5. AWS マネジメントコンソール で Aurora クラスターのクローンを作成する の手順に従って、クローンを作成したクラスターの設定を終了します。

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

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

AWS CLI

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

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

  2. クラスターのクローンを作成するには、前述のように、RDS CLI コマンド restore-db-cluster-to-point-in-timesource-db-cluster-identifier パラメータで、ソースクラスターのフル ARN を指定します。

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

    Linux、OS X、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、OS X、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}} } ] }
RDS API

RDS API を使用して、別の AWS アカウントが所有する Aurora クラスターのクローンを作成するには

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

  2. クラスターのクローンを作成するには、RDS API オペレーション RestoreDBClusterToPointInTimeSourceDBClusterIdentifier パラメータで、ソースクラスターのフル 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}} } ] }

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

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

AWS CLI

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

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

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

    場合によっては、エントリの DBClusterArn フィールドにお客様のアカウントとは異なる AWS アカウント番号が含まれていることがあります。この場合、そのエントリは別の 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", } ] }
RDS API

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

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

    お客様の AWS アカウントが所有する既存のクラスターの場合は CrossAccountClone フィールドに、クラスターが別の AWS アカウントが所有する DB クラスターのクローンかどうかが示されます。DBClusterArn フィールドに別の AWS アカウント番号を持つエントリは、クローン作成が可能で、別の 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" } ] }