Clonage entre VPC avec Amazon Aurora - Amazon Aurora
Avant de commencerCollecte d’informations sur l’environnement réseauCréation de ressources réseau pour le cloneCréation d’un clone Aurora avec de nouveaux paramètres réseauRemplacement des sous-réseaux publics par des sous-réseaux privés pour un clusterExemple complet de création d’un clone entre VPC

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Clonage entre VPC avec Amazon Aurora

Supposons que vous souhaitiez imposer des contrôles d’accès réseau différents au cluster d’origine et au clone. Par exemple, vous pouvez utiliser le clonage pour créer une copie d’un cluster Aurora de production dans un autre VPC à des fins de développement et de test. Vous pouvez également créer un clone dans le cadre d’une migration de sous-réseaux publics vers des sous-réseaux privés, afin d’améliorer la sécurité de votre base de données.

Les sections suivantes montrent comment définir la configuration réseau du clone afin que le cluster d’origine et le clone puissent accéder aux mêmes nœuds de stockage Aurora, même à partir de sous-réseaux ou de VPC différents. La vérification préalable des ressources du réseau permet d’éviter des erreurs difficiles à diagnostiquer lors du clonage.

Si vous ne connaissez pas la façon dont Aurora interagit avec les VPC, les sous-réseaux et les groupes de sous-réseaux de base de données, consultez d’abord Amazon VPC et Amazon Aurora. Vous pouvez suivre les didacticiels de cette section pour créer ce type de ressources dans la console AWS et comprendre comment elles s’intègrent.

Comme les étapes impliquent de basculer entre les services RDS et EC2, les exemples utilisent des commandes AWS de la CLI pour vous aider à comprendre comment automatiser ces opérations et enregistrer la sortie.

Avant de commencer

Avant de commencer à configurer un clone entre VPC, assurez-vous d’avoir les ressources suivantes :

Collecte d’informations sur l’environnement réseau

Avec le clonage entre VPC, l’environnement réseau peut être très différent entre le cluster d’origine et son clone. Avant de créer le clone, collectez et enregistrez les informations relatives au VPC, aux sous-réseaux, au groupe de sous-réseaux de base de données et aux zones de disponibilité utilisés dans le cluster d’origine. De cette façon, vous minimiserez les risques de problèmes. En cas de problème réseau, vous n’aurez pas à interrompre les activités de dépannage pour rechercher des informations de diagnostic. Les sections suivantes présentent des exemples permettant de recueillir ce type d’informations à l’aide de la CLI. Vous pouvez enregistrer ces informations dans le format qui vous convient le mieux lors de la création du clone et de la résolution des problèmes.

Étape 1 : vérifier les zones de disponibilité du cluster d’origine

Avant de créer le clone, vérifiez les zones de disponibilité que le cluster d’origine utilise pour son stockage. Comme expliqué dans Stockage Amazon Aurora, le stockage de chaque cluster Aurora est associé à exactement trois zones de disponibilité. Dans la mesure où Clusters de bases de données Amazon Aurora tire parti de la séparation du calcul et du stockage, cette règle s’applique quel que soit le nombre d’instances présentes dans le cluster.

Par exemple, exécutez une commande d’interface de ligne de commande comme dans cet exemple, en remplaçant my_cluster par le nom de votre propre cluster. L’exemple suivant génère une liste de zones de disponibilité triée par ordre alphabétique. 

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

L’exemple suivant montre un exemple de sortie de la commande describe-db-clusters précédente. Cela montre que le stockage du cluster Aurora utilise toujours trois zones de disponibilité. 

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

Pour créer un clone dans un environnement réseau ne disposant pas de toutes les ressources nécessaires pour se connecter à ces zones de disponibilité, vous devrez créer des sous-réseaux associés à au moins deux de ces zones, puis créer un groupe de sous-réseaux de base de données contenant ces deux ou trois sous-réseaux. Les exemples suivants montrent comment procéder.

Étape 2 : vérifier le groupe de sous-réseaux de base de données du cluster d’origine

Si vous souhaitez utiliser le même nombre de sous-réseaux pour le clone que dans le cluster d’origine, vous pouvez obtenir le nombre de sous-réseaux à partir du groupe de sous-réseaux de base de données du cluster d’origine. Un groupe de sous-réseaux de base de données Aurora contient au moins deux sous-réseaux, chacun étant associé à une zone de disponibilité différente. Notez à quelles zones de disponibilité les sous-réseaux sont associés.

L’exemple suivant montre comment trouver le groupe de sous-réseaux de base de données du cluster d’origine, puis comment remonter aux zones de disponibilité correspondants. Remplacez my_cluster par le nom de votre cluster dans la première commande. Remplacez my_subnet par le nom du groupe de sous-réseaux de base de données dans la deuxième commande. 

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

L’exemple de sortie peut ressembler à ce qui suit, pour un cluster avec un groupe de sous-réseaux de base de données contenant deux sous-réseaux. Dans ce cas, two-subnets est un nom qui a été spécifié lors de la création du groupe de sous-réseaux de base de données. 

two-subnets

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

Pour un cluster où le groupe de sous-réseaux de base de données contient trois sous-réseaux, la sortie peut ressembler à ce qui suit. 

three-subnets

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

Étape 3 : vérifier les sous-réseaux du cluster d’origine

Si vous avez besoin de plus de détails sur les sous-réseaux du cluster d’origine, exécutez des commandes AWS similaires aux suivantes dans l’interface de ligne de commande. Vous pouvez examiner les attributs des sous-réseaux tels que les plages d’adresses IP, le propriétaire, etc. Vous pouvez ainsi déterminer s’il convient d’utiliser différents sous-réseaux dans le même VPC ou de créer des sous-réseaux présentant des caractéristiques similaires dans un VPC différent.

Identifiez les ID de tous les sous-réseaux disponibles dans votre VPC. 

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

Identifiez les sous-réseaux exacts utilisés dans votre groupe de sous-réseaux de base de données. 

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

Spécifiez ensuite les sous-réseaux que vous souhaitez examiner dans une liste, comme dans la commande suivante. Remplacez my_subnet_1 et ainsi de suite par le nom de vos sous-réseaux. 

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

L’exemple suivant montre une sortie partielle de ce type de commande describe-subnets. La sortie montre certains des attributs importants que vous pouvez voir pour chaque sous-réseau, tels que la zone de disponibilité associée et le VPC dont il fait partie. 

{
    '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',
            ...

Étape 4 : vérifier les zones de disponibilité des instances de base de données dans le cluster d’origine

Vous pouvez utiliser cette procédure pour déterminer les zones de disponibilité utilisées pour les instances de base de données du cluster d’origine. Vous pouvez ainsi configurer exactement les mêmes zones de disponibilité pour les instances de base de données du clone. Vous pouvez également utiliser plus ou moins d’instances de base de données dans le clone selon que le clone sera utilisé pour la production, le développement et les tests, etc.

Pour chaque instance du cluster d’origine, exécutez une commande comme la suivante. Assurez-vous d’abord que l’instance a terminé de se créer et que son état indique Available. Remplacez my_instance par l’identifiant de l’instance. 

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

L’exemple suivant illustre la sortie de l’exécution de la commande describe-db-instances précédente. Le cluster Aurora possède quatre instances de base de données. Par conséquent, nous exécutons la commande quatre fois, en indiquant à chaque fois un identifiant d’instance de base de données différent. La sortie montre comment ces instances de base de données sont réparties sur un maximum de trois zones de disponibilité. 

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

Une fois que le clone est créé et que vous y avez ajouté des instances de base de données, vous pouvez spécifier le nom de ces mêmes zones de disponibilité dans les commandes create-db-instance. Cela vous permet de configurer les instances de base de données dans le nouveau cluster exactement pour les mêmes zones de disponibilité que le cluster d’origine.

Étape 5 : vérifier les VPC que vous pouvez utiliser pour le clone

Si vous avez l’intention de créer le clone dans un VPC différent de celui d’origine, vous pouvez obtenir une liste des identifiants de VPC disponibles pour votre compte. Vous pouvez également effectuer cette étape si vous devez créer des sous-réseaux supplémentaires dans le même VPC que le cluster d’origine. Lorsque vous exécutez la commande permettant de créer un sous-réseau, vous spécifiez l’identifiant du VPC en tant que paramètre.

Pour dresser la liste de tous les VPC figurant dans votre compte, exécutez la commande suivante dans l’interface de ligne de commande : 

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

L’exemple suivant montre un exemple de sortie de la commande describe-vpcs précédente. La sortie montre que le compte AWS actuel contient quatre VPC qui peuvent être utilisés comme source ou destination pour le clonage entre VPC. 

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

Vous pouvez utiliser le même VPC que la destination pour le clone, ou un VPC différent. Si le cluster d’origine et le clone se trouvent dans le même VPC, vous pouvez réutiliser le même groupe de sous-réseaux de base de données pour le clone. Vous pouvez également créer un autre groupe de sous-réseaux de base de données. Par exemple, le nouveau groupe de sous-réseaux de base de données peut utiliser des sous-réseaux privés, tandis que le groupe de sous-réseaux de base de données du cluster d’origine peut utiliser des sous-réseaux publics. Si vous créez le clone dans un autre VPC, assurez-vous qu’il y a suffisamment de sous-réseaux dans le nouveau VPC et que les sous-réseaux sont associés aux zones de disponibilité appropriées du cluster d’origine.

Création de ressources réseau pour le clone

Si, lors de la collecte des informations réseau, vous avez découvert que des ressources réseau supplémentaires sont nécessaires pour le clone, vous pouvez les créer avant d’essayer de configurer le clone. Par exemple, vous devrez peut-être créer d’autres sous-réseaux, des sous-réseaux associés à des zones de disponibilité spécifiques ou un groupe de sous-réseaux de base de données.

Étape 1 : créer les sous-réseaux pour le clone

Si vous devez créer des sous-réseaux pour le clone, exécutez une commande similaire à ce qui suit. Vous devrez peut-être procéder de la sorte lors de la création du clone dans un autre VPC ou lors d’une autre modification du réseau, telle que l’utilisation de sous-réseaux privés au lieu de sous-réseaux publics.

AWS génère automatiquement l’identifiant du sous-réseau. Remplacez my_vpc par le nom du VPC du clone. Choisissez la plage d’adresses pour l’option --cidr-block pour y autoriser au moins 16 adresses IP. Vous pouvez inclure toutes les autres propriétés que vous souhaitez spécifier. Exécutez la commande aws ec2 create-subnet help pour voir tous les choix. 

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

L’exemple suivant montre certains attributs importants d’un sous-réseau nouvellement créé. 

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

Étape 2 : créer le groupe de sous-réseaux de base de données pour le clone

Si vous créez le clone dans un autre VPC ou dans un ensemble différent de sous-réseaux au sein du même VPC, vous devez créer un nouveau groupe de sous-réseaux de base de données et le spécifier lors de la création du clone.

Veillez à connaître tous les détails suivants. Ils sont tous visibles dans la sortie des exemples précédents.

  1. VPC du cluster d’origine. Pour obtenir des instructions, consultez Étape 3 : vérifier les sous-réseaux du cluster d’origine.

  2. VPC du clone, si vous le créez dans un autre VPC. Pour obtenir des instructions, consultez Étape 5 : vérifier les VPC que vous pouvez utiliser pour le clone.

  3. Trois zones de disponibilité associées au stockage Aurora pour le cluster d’origine. Pour obtenir des instructions, consultez Étape 1 : vérifier les zones de disponibilité du cluster d’origine.

  4. Deux ou trois zones de disponibilité associées au groupe de sous-réseaux de base de données pour le cluster d’origine. Pour obtenir des instructions, consultez Étape 2 : vérifier le groupe de sous-réseaux de base de données du cluster d’origine.

  5. ID de sous-réseau et zones de disponibilité associées de tous les sous-réseaux du VPC que vous souhaitez utiliser pour le clone. Utilisez la même commande describe-subnets que dans Étape 3 : vérifier les sous-réseaux du cluster d’origine, en remplaçant l’ID du VPC de destination.

Vérifiez combien de zones de disponibilité sont à la fois associées au stockage du cluster d’origine et aux sous-réseaux du VPC de destination. Pour que le clone soit créé, deux ou trois zones de disponibilité en commun sont nécessaires. Si vous avez moins de deux zones de disponibilité en commun, revenez à Étape 1 : créer les sous-réseaux pour le clone. Créez un, deux ou trois sous-réseaux liés aux zones de disponibilité associés au stockage du cluster d’origine.

Choisissez dans le VPC de destination des sous-réseaux associés aux mêmes zones de disponibilité que le stockage Aurora dans le cluster d’origine. Idéalement, choisissez trois zones de disponibilité. Cela vous laissera la liberté de répartir les instances de base de données du clone sur plusieurs zones de disponibilité pour assurer une haute disponibilité des ressources de calcul.

Exécutez une commande similaire à ce qui suit afin de créer le groupe de sous-réseaux de base de données. Remplacez les identifiants de vos sous-réseaux dans la liste. Si vous spécifiez les identifiants de sous-réseau à l’aide de variables d’environnement, veillez à citer la liste des paramètres --subnet-ids de manière à conserver les guillemets doubles autour des identifiants. 

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'

L’exemple suivant illustre la sortie partielle de la commande 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'
        ]
    }
}

À ce stade, vous n’avez pas encore créé le clone. Vous avez créé toutes les ressources de VPC et de sous-réseau pertinentes afin de pouvoir spécifier les paramètres appropriés pour les commandes restore-db-cluster-to-point-in-time et create-db-instance lors de la création du clone.

Création d’un clone Aurora avec de nouveaux paramètres réseau

Une fois que vous vous êtes assuré que vous avez bien configuré les VPC, les sous-réseaux, les zones de disponibilité et les groupes de sous-réseaux pour le nouveau cluster, vous pouvez effectuer l’opération de clonage proprement dite. Les exemples suivants de la CLI mettent en évidence les options telles que --db-subnet-group-name, --availability-zone et --vpc-security-group-ids que vous spécifiez dans les commandes pour configurer le clone et ses instances de base de données.

Étape 1 : spécifier le groupe de sous-réseaux de base de données pour le clone

Lorsque vous créez le clone, vous pouvez configurer tous les paramètres appropriés pour les VPC, les sous-réseaux et les zones de disponibilité en spécifiant un groupe de sous-réseaux de base de données. Utilisez les commandes des exemples précédents pour vérifier toutes les relations et tous les mappages inhérents au groupe de sous-réseaux de base de données.

Par exemple, les commandes suivantes illustrent le clonage d’un cluster d’origine vers un clone. Dans le premier exemple, le cluster source est associé à deux sous-réseaux et le clone est associé à trois sous-réseaux. Le deuxième exemple montre le cas contraire, à savoir le clonage d’un cluster de trois sous-réseaux vers un cluster de deux sous-réseaux. 

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

Si vous avez l’intention d’utiliser des instances Aurora sans serveur v2 dans le clone, incluez une option --serverless-v2-scaling-configuration lors de la création du clone, comme indiqué. Cela vous permet d’utiliser la classe db.serverless lors de la création d’instances de base de données dans le clone. Vous pourrez également modifier le clone ultérieurement pour ajouter cet attribut de configuration de mise à l’échelle. Les valeurs de capacité indiquées dans cet exemple permettent à chaque instance sans serveur v2 du cluster de se mettre à l’échelle avec des unités de capacité Aurora (ACU) comprises entre 2 et 32. Pour en savoir plus sur la fonctionnalité Aurora sans serveur v2 et sur le choix de la plage de capacité, consultez Utiliser Aurora Serverless v2. 

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

Quel que soit le nombre de sous-réseaux utilisés par les instances de base de données, le stockage Aurora pour le cluster source et le clone est associé à trois zones de disponibilité. L’exemple suivant répertorie les zones de disponibilité associées au cluster d’origine et au clone, pour les deux commandes restore-db-cluster-to-point-in-time des exemples précédents. 

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

Comme au moins deux des zones de disponibilité sont les mêmes entre chaque paire de clusters d’origine et de clone, les deux clusters peuvent accéder au même stockage Aurora sous-jacent.

Étape 2 : spécifier les paramètres réseau des instances du clone

Lorsque vous créez des instances de base de données dans le clone, elles héritent par défaut du groupe de sous-réseaux de base de données du cluster lui-même. De cette façon, Aurora assigne automatiquement chaque instance à un sous-réseau particulier et la crée dans la zone de disponibilité associée au sous-réseau. Ce choix est pratique, en particulier pour les systèmes de développement et de test, car vous n’avez pas à suivre les identifiants de sous-réseau ni les zones de disponibilité lors de l’ajout de nouvelles instances au clone.

Vous pouvez également spécifier la zone de disponibilité lorsque vous créez une instance de base de données Aurora pour le clone. La zone de disponibilité que vous spécifiez doit faire partie de l’ensemble de zones de disponibilité associées au clone. Si le groupe de sous-réseaux de base de données que vous utilisez pour le clone ne contient que deux sous-réseaux, vous ne pouvez choisir que parmi les zones de disponibilité associées à ces deux sous-réseaux. Ce choix offre flexibilité et résilience pour des systèmes à haute disponibilité, car vous pouvez vous assurer que l’instance d’enregistreur et l’instance de lecteur de secours se trouvent dans des zones de disponibilité différentes. Ou si vous ajoutez des lecteurs supplémentaires au cluster, vous pouvez vous assurer qu’ils sont répartis sur trois zones de disponibilité. Ainsi, même dans les rares cas d’échec d’une zone de disponibilité, vous disposez toujours d’une instance d’enregistreur et d’une autre instance de lecteur dans deux autres zones de disponibilité.

L’exemple suivant ajoute une instance de base de données provisionnée à un cluster Aurora PostgreSQL cloné qui utilise un groupe de sous-réseaux de base de données personnalisé. 

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

L’exemple suivant montre une sortie partielle de ce type de commande. 

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

L’exemple suivant ajoute une instance de base de données Aurora sans serveur v2 à un clone Aurora MySQL qui utilise un groupe de sous-réseaux de base de données personnalisé. Pour pouvoir utiliser les instances sans serveur v2, assurez-vous de spécifier l’option --serverless-v2-scaling-configuration pour la commande restore-db-cluster-to-point-in-time, comme indiqué dans les exemples précédents. 

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

L’exemple suivant montre une sortie partielle de ce type de commande. 

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

Étape 3 : établir la connectivité entre un système client et un clone

Si vous vous connectez déjà à un cluster Aurora à partir d’un système client, vous souhaiterez peut-être autoriser le même type de connectivité à un nouveau clone. Par exemple, vous pouvez vous connecter au cluster d’origine à partir d’une instance Amazon Cloud9 ou d’une instance EC2. Pour autoriser les connexions à partir des mêmes systèmes clients ou de nouveaux systèmes que vous créerez dans le VPC de destination, configurez des groupes de sous-réseaux de base de données et des groupes de sécurité VPC équivalents à ceux du VPC. Spécifiez ensuite le groupe de sous-réseaux et les groupes de sécurité lorsque vous créez le clone.

Les exemples suivants configurent un clone Aurora sans serveur v2. Cette configuration est basée sur la combinaison de --engine-mode provisioned et --serverless-v2-scaling-configuration lors de la création du cluster de bases de données, puis --db-instance-class db.serverless lors de la création de chaque instance de base de données du cluster. Le mode moteur provisioned étant le mode par défaut, vous pouvez omettre cette option si vous le souhaitez. 

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

Ensuite, lors de la création des instances de base de données dans le clone, spécifiez la même option --db-subnet-group-name. Vous pouvez éventuellement inclure l’option --availability-zone et spécifier l’une des zones de disponibilité associées aux sous-réseaux de ce groupe de sous-réseaux. Cette zone de disponibilité doit également être l’une des zones de disponibilité associées au cluster d’origine. 

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

Remplacement des sous-réseaux publics par des sous-réseaux privés pour un cluster

Vous pouvez utiliser le clonage pour remplacer les sous-réseaux publics d’un cluster par des sous-réseaux privés. Cette opération peut être utile lorsque vous ajoutez des couches de sécurité supplémentaires à votre application avant de la déployer en production. Pour cet exemple, les sous-réseaux privés et la passerelle NAT devraient déjà être configurés avant que vous ne démarriez le processus de clonage avec Aurora.

Pour les étapes impliquant Aurora, vous pouvez suivre les mêmes étapes générales que dans les exemples précédents pour Collecte d’informations sur l’environnement réseau et Création d’un clone Aurora avec de nouveaux paramètres réseau. La principale différence est que même si vous avez des sous-réseaux publics mappés à toutes les zones de disponibilité du cluster d’origine, vous devez maintenant vérifier que vous disposez de suffisamment de sous-réseaux privés pour un cluster Aurora et que ces sous-réseaux sont associés aux mêmes zones de disponibilité que celles utilisées pour le stockage Aurora dans le cluster d’origine. Comme dans d’autres cas d’utilisation du clonage, vous pouvez créer le groupe de sous-réseaux de base de données pour le clone avec trois ou deux sous-réseaux privés associés aux zones de disponibilité requises. Toutefois, si vous utilisez deux sous-réseaux privés dans le groupe de sous-réseaux de base de données, vous devrez disposer d’un troisième sous-réseau privé associé à la troisième zone de disponibilité utilisée pour le stockage Aurora dans le cluster d’origine.

Vous pouvez consulter cette liste de contrôle pour vérifier que toutes les exigences sont satisfaites pour effectuer ce type d’opération de clonage.

Lorsque toutes les conditions requises sont réunies, vous pouvez suspendre l’activité de la base de données sur le cluster d’origine pendant que vous créez le clone et que vous changez d’application pour l’utiliser. Une fois que le clone est créé et que vous avez vérifié que vous pouvez vous y connecter, exécuter le code de votre application, etc., vous pouvez cesser d’utiliser le cluster d’origine.

Exemple complet de création d’un clone entre VPC

La création d’un clone dans un VPC différent de celui d’origine suit les mêmes étapes générales que dans les exemples précédents. L’ID du VPC étant une propriété des sous-réseaux, vous ne spécifiez pas cet ID en tant que paramètre lorsque vous exécutez l’une des commandes de la CLI RDS. La principale différence est que vous aurez probablement besoin de créer des sous-réseaux, des sous-réseaux mappés à des zones de disponibilité spécifiques, un groupe de sécurité VPC et un groupe de sous-réseaux de base de données. Cela est particulièrement vrai s’il s’agit du premier cluster Aurora que vous créez dans ce VPC.

Vous pouvez consulter cette liste de contrôle pour vérifier que toutes les exigences sont satisfaites pour effectuer ce type d’opération de clonage.

Lorsque toutes les conditions requises sont réunies, vous pouvez suspendre l’activité de la base de données sur le cluster d’origine pendant que vous créez le clone et que vous changez d’application pour l’utiliser. Une fois que le clone est créé et que vous avez vérifié que vous pouvez vous y connecter, exécuter le code de votre application, etc., vous pouvez décider de continuer à exécuter le cluster d’origine ainsi que les clones ou de cesser d’utiliser le cluster d’origine.

Les exemples Linux suivants montrent la séquence d’opérations de l’AWS CLI permettant de cloner un cluster de bases de données Aurora d’un VPC à un autre. Certains champs qui ne sont pas pertinents pour ces exemples ne sont pas affichés dans la sortie de la commande.

Tout d’abord, vérifions les identifiants des VPC source et de destination. Le nom descriptif que vous attribuez à un VPC lorsque vous le créez est représenté sous forme de balise dans les métadonnées du VPC. 

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

Le cluster d’origine existe déjà dans le VPC source. Pour configurer le clone en utilisant le même ensemble de zones de disponibilité pour le stockage Aurora, nous devons vérifier les zones de disponibilité utilisées par le cluster d’origine. 

$ 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

Nous nous assurons que certains sous-réseaux correspondent aux zones de disponibilité utilisées par le cluster d’origine : us-east-1c, us-east-1d et 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',
    }
}

Cet exemple confirme que des sous-réseaux sont mappés aux zones de disponibilité nécessaires dans le VPC de destination. 

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  |
+------------------+----------------------------+-------------------------+

Avant de créer un cluster de bases de données Aurora dans le VPC, vous devez disposer d’un groupe de sous-réseaux de base de données avec des sous-réseaux mappés aux zones de disponibilité utilisées pour le stockage Aurora. Lorsque vous créez un cluster standard, vous pouvez utiliser n’importe quel ensemble de trois zones de disponibilité. Lorsque vous clonez un cluster, le groupe de sous-réseaux doit correspondre à au moins deux des trois zones de disponibilité qu’il utilise pour le stockage Aurora. 

$ 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' }
            }
        ]
    }
}

Les sous-réseaux et le groupe de sous-réseaux de base de données sont maintenant en place. L’exemple suivant montre l’opération restore-db-cluster-to-point-in-time qui clone le cluster. L’option --db-subnet-group-name associe le clone à l’ensemble approprié de sous-réseaux mappés à l’ensemble approprié de zones de disponibilité du cluster d’origine. 

$ 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'
}

L’exemple suivant confirme que le stockage Aurora du clone utilise le même ensemble de zones de disponibilité que dans le cluster d’origine. 

$ 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

À ce stade, vous pouvez créer des instances de base de données pour le clone. Assurez-vous que le groupe de sécurité VPC associé à chaque instance autorise les connexions à partir des plages d’adresses IP que vous utilisez pour les instances EC2, les serveurs d’applications, etc. qui se trouvent dans le VPC de destination.