# Amazon Aurora を使用したクロス VPC クローニング
元のクラスターとクローンに異なるネットワークアクセスコントロールを課すとします。例えば、クローニングを使用して、開発用とテスト用に異なる VPC に本番稼働用 Aurora クラスターのコピーを作成できます。または、パブリックサブネットからプライベートサブネットへの移行の一環としてクローンを作成し、データベースのセキュリティを強化することもできます。
以下のセクションでは、元のクラスターとクローンの両方が、異なるサブネットまたは異なる VPC からでも同じ Aurora ストレージノードにアクセスできるように、クローンのネットワーク設定をセットアップする方法を示します。ネットワークリソースを事前に検証すると、診断が困難なクローニング時のエラーを回避できることがあります。
Aurora が VPC、サブネット、および DB サブネットグループとどのように連携するかを十分に理解していない場合は、まず、「[Amazon VPC と Amazon Aurora](USER_VPC.md)」を参照してください。そのセクションのチュートリアルでは、これらの種類のリソースを AWS コンソールで作成し、それらの組み合わせを理解できます。
ステップでは RDS サービスと EC2 サービスを切り替える必要があるため、例では AWS CLI コマンドを使用して、このような操作を自動化して出力を保存する方法を理解します。
**Topics**
+ [[開始する前に]](#before-you-begin)
+ [ネットワーク環境に関する情報の収集](#gathering-information-about-the-network-environment)
+ [クローンのネットワークリソースの作成](#creating-network-resources-for-the-clone)
+ [新しいネットワーク設定で Aurora クローンを作成する](#creating-an-aurora-clone-with-new-network-settings)
+ [クラスターをパブリックサブネットからプライベートサブネットに移動する](#moving-a-cluster-from-public-subnets-to-private-ones)
+ [クロス VPC クローンを作成するエンドツーエンドの例](#end-to-end-example-of-creating-a-cross-vpc-clone)
## [開始する前に]
クロス VPC クローンの設定を開始する前に、次のリソースがあることを確認してください。
+ クローニングのソースとして使用する Aurora DB クラスター。Aurora DB クラスターを初めて作成する場合は、「[Amazon Aurora の開始方法](CHAP_GettingStartedAurora.md)」のチュートリアルを参照して、MySQL または PostgreSQL データベースエンジンを使用してクラスターを設定します。
+ クロス VPC クローンを作成する場合は、2 番目の VPC。クローンに使用する VPC がない場合は、「[チュートリアル: DB クラスターで使用する VPC を作成する (IPv4 専用)](CHAP_Tutorials.WebServerDB.CreateVPC.md)」または「[チュートリアル: DB クラスター用の VPC を作成する (デュアルスタックモード)](CHAP_Tutorials.CreateVPCDualStack.md)」を参照してください。
## ネットワーク環境に関する情報の収集
クロス VPC クローニングでは、ネットワーク環境は元のクラスターとそのクローンの間で大きく異なる場合があります。クローンを作成する前に、元のクラスターで使用される VPC、サブネット、DB サブネットグループ、および AZ に関する情報を収集して記録します。これにより、問題発生の可能性を最小限に抑えることができます。ネットワーク問題が発生した場合は、診断情報を検索するためにトラブルシューティングアクティビティを中断する必要はありません。以下のセクションでは、これらのタイプの情報を収集するための CLI の例を示します。クローンの作成時やトラブルシューティング時に参照しやすい形式で詳細を保存できます。
+ [ステップ 1: 元のクラスターのアベイラビリティーゾーンを確認する](#cross-vpc-cloning-check-original-azs)
+ [ステップ 2: 元のクラスターの DB サブネットグループを確認する](#cross-vpc-cloning-check-original-subnet-group)
+ [ステップ 3: 元のクラスターのサブネットを確認する](#cross-vpc-cloning-check-original-subnets)
+ [ステップ 4: 元のクラスターの DB インスタンスのアベイラビリティーゾーンを確認する](#cross-vpc-cloning-check-original-instance-azs)
+ [ステップ 5: クローンに使用できる VPC を確認する](#cross-vpc-cloning-check-vpcs)
### ステップ 1: 元のクラスターのアベイラビリティーゾーンを確認する
クローンを作成する前に、元のクラスターがストレージに使用する AZ を確認してください。「[Amazon Aurora ストレージ](Aurora.Overview.StorageReliability.md)」で説明されているように、各 Aurora クラスターのストレージは、厳密に 3 つの AZ に関連付けられます。[Amazon Aurora DB クラスター](Aurora.Overview.md) はコンピューティングとストレージの分離を利用するため、このルールはクラスター内のインスタンス数に関係なく当てはまります。
例えば、次のような 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: クローンのサブネットを作成する](#cross-vpc-cloning-create-clone-subnets)
+ [ステップ 2: クローンの DB サブネットグループを作成する](#cross-vpc-cloning-create-subnet-group)
### ステップ 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 サブネットグループを作成し、クローンの作成時に指定します。
以下の詳細がすべてわかっていることを確認してください。これらはすべて、前の例の出力から確認できます。
1. 元のクラスターの VPC。手順については、[ステップ 3: 元のクラスターのサブネットを確認する](#cross-vpc-cloning-check-original-subnets) を参照してください。
1. 別の VPC で作成する場合は、クローンの VPC。手順については、[ステップ 5: クローンに使用できる VPC を確認する](#cross-vpc-cloning-check-vpcs) を参照してください。
1. 元のクラスターの Aurora ストレージに関連付けられている 3 つの AZ。手順については、[ステップ 1: 元のクラスターのアベイラビリティーゾーンを確認する](#cross-vpc-cloning-check-original-azs) を参照してください。
1. 元のクラスターの DB サブネットグループに関連付けられている 2 つまたは 3 つの AZ。手順については、[ステップ 2: 元のクラスターの DB サブネットグループを確認する](#cross-vpc-cloning-check-original-subnet-group) を参照してください。
1. クローンに使用する VPC 内のすべてのサブネットのサブネット ID および関連付られている AZ。[ステップ 3: 元のクラスターのサブネットを確認する](#cross-vpc-cloning-check-original-subnets) と同じ `describe-subnets` コマンドを使用して、デスティネーション VPC の VPC ID を置き換えます。
元のクラスターのストレージに関連付けられ、デスティネーション VPC のサブネットに関連付けられている AZ の数を確認します。クローンを正常に作成するには、2 つまたは 3 つの AZ が共通している必要があります。共通する AZ が 2 つ未満の場合は、[ステップ 1: クローンのサブネットを作成する](#cross-vpc-cloning-create-clone-subnets) に戻ります。元のクラスターのストレージに関連付けられた 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 サブネットグループを指定する](#cross-vpc-cloning-specify-clone-subnet-group)
+ [ステップ 2: クローン内のインスタンスのネットワーク設定を指定する](#cross-vpc-cloning-configure-clone-instance-network)
+ [ステップ 3: クライアントシステムからクローンへの接続を確立する](#cross-vpc-cloning-connect-to-clone)
### ステップ 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 の使用](aurora-serverless-v2.md)」を参照してください。
```
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 に関連するステップについては、前述の例と同じ一般的なステップを [ネットワーク環境に関する情報の収集](#gathering-information-about-the-network-environment) および [新しいネットワーク設定で Aurora クローンを作成する](#creating-an-aurora-clone-with-new-network-settings) に実行できます。主な違いは、元のクラスターのすべての AZ にマッピングするパブリックサブネットがある場合でも、Aurora クラスターに十分なプライベートサブネットがあり、それらのサブネットが元のクラスターの Aurora ストレージに使用されるすべての同じ AZ に関連付けられていることを確認する必要があることです。他のクローニングのユースケースと同様に、必要な AZ に関連付けられている 3 つまたは 2 つのプライベートサブネットを使用して、クローンの DB サブネットグループを作成できます。ただし、DB サブネットグループで 2 つのプライベートサブネットを使用する場合は、元のクラスターで Aurora ストレージに使用される 3 番目の AZ に関連付けられた 3 番目のプライベートサブネットが必要です。
このチェックリストを参照して、このタイプのクローニング操作を実行するためのすべての要件が満たされていることを確認できます。
+ 元のクラスターに関連付けられている 3 つの AZ を記録します。手順については、[ステップ 1: 元のクラスターのアベイラビリティーゾーンを確認する](#cross-vpc-cloning-check-original-azs) を参照してください。
+ 元のクラスターの DB サブネットグループ内のパブリックサブネットに関連付けられている 3 つまたは 2 つの AZ を記録します。手順については、[ステップ 3: 元のクラスターのサブネットを確認する](#cross-vpc-cloning-check-original-subnets) を参照してください。
+ 元のクラスターに関連付けられている 3 つの AZ すべてにマッピングされるプライベートサブネットを作成します。また、NAT ゲートウェイの作成など、その他のネットワーク設定を行って、プライベートサブネットと通信できるようにします。詳細な手順については、「*Amazon Virtual Private Cloud ユーザーガイド*」の「[サブネットの作成](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html)」を参照してください。
+ 最初のポイントから AZ に関連付けられている 3 つまたは 2 つのプライベートサブネットを含む新しい DB サブネットグループを作成します。手順については、[ステップ 2: クローンの DB サブネットグループを作成する](#cross-vpc-cloning-create-subnet-group) を参照してください。
すべての前提条件が満たされたら、クローンを作成し、それを使用するようにアプリケーションを切り替える間、元のクラスターでのデータベースアクティビティを一時停止できます。クローンが作成され、クローンに接続してアプリケーションコードを実行できることを確認してから、元のクラスターの使用を中止できます。
## クロス VPC クローンを作成するエンドツーエンドの例
元の VPC とは異なる VPC でクローンを作成する場合、前の例と同じ一般的な手順を使用します。VPC ID はサブネットのプロパティであるため、RDS CLI コマンドを実行するときに実際にはパラメータとして VPC ID を指定しません。主な違いは、新しいサブネット、特定の AZ にマッピングされた新しいサブネット、VPC セキュリティグループ、および新しい DB サブネットグループを作成する必要があることです。これは、この VPC で作成する最初の Aurora クラスターである場合に特に当てはまります。
このチェックリストを参照して、このタイプのクローニング操作を実行するためのすべての要件が満たされていることを確認できます。
+ 元のクラスターに関連付けられている 3 つの AZ を記録します。手順については、[ステップ 1: 元のクラスターのアベイラビリティーゾーンを確認する](#cross-vpc-cloning-check-original-azs) を参照してください。
+ 元のクラスターの DB サブネットグループ内のサブネットに関連付けられている 3 つまたは 2 つの AZ を記録します。手順については、[ステップ 2: 元のクラスターの DB サブネットグループを確認する](#cross-vpc-cloning-check-original-subnet-group) を参照してください。
+ 元のクラスターに関連付けられている 3 つの AZ すべてにマッピングされるサブネットを作成します。手順については、[ステップ 1: クローンのサブネットを作成する](#cross-vpc-cloning-create-clone-subnets) を参照してください。
+ クローン内の DB インスタンスと通信できるようにするには、クライアントシステム、アプリケーションサーバーなどの VPC セキュリティグループの設定など、その他のネットワーク設定を行います。手順については、[セキュリティグループによるアクセス制御](Overview.RDSSecurityGroups.md) を参照してください。
+ 最初のポイントから AZ に関連付けられている 3 つまたは 2 つのサブネットを含む新しい DB サブネットグループを作成します。手順については、[ステップ 2: クローンの DB サブネットグループを作成する](#cross-vpc-cloning-create-subnet-group) を参照してください。
すべての前提条件が満たされたら、クローンを作成し、それを使用するようにアプリケーションを切り替える間、元のクラスターでのデータベースアクティビティを一時停止できます。クローンが作成され、クローンに接続してアプリケーションコードを実行できることを確認してから、元のクラスターとクローンの両方の実行を続けるか、元のクラスターの使用を中止するかを考慮できます。
次の 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 アドレス範囲からの接続を許可していることを確認します。