Clonación entre VPC con Amazon Aurora

Imagine que quiere imponer diferentes controles de acceso a la red en el clúster original y en el clon. Por ejemplo, podría utilizar la clonación para hacer una copia de un clúster Aurora de producción en una VPC diferente para el desarrollo y las pruebas. O bien podría crear un clon como parte de una migración de subredes públicas a subredes privadas para mejorar la seguridad de su base de datos.

En las siguientes secciones, se muestra cómo configurar la red del clon para que el clúster original y el clon puedan acceder a los mismos nodos de almacenamiento de Aurora, incluso desde subredes o VPC diferentes. Verificar los recursos de la red con antelación puede evitar errores durante la clonación que podrían ser difíciles de diagnosticar.

Si no conoce la forma en que Aurora interactúa con las VPC, las subredes y los grupos de subredes de base de datos, consulte primero VPC de Amazon y Amazon Aurora. Puede consultar los tutoriales de esa sección para crear este tipo de recursos en la consola de AWS y comprender cómo encajan entre sí.

Dado que los pasos implican cambiar entre los servicios de RDS y EC2, los ejemplos utilizan comandos de AWS CLI para ayudarle a entender cómo automatizar dichas operaciones y guardar el resultado.

Antes de empezar

Antes de empezar a configurar un clon entre VPC, asegúrese de tener preparados los siguientes recursos:

Recopilación de información sobre el entorno de red

Con la clonación entre VPC, el entorno de red puede diferir en gran medida entre el clúster original y su clon. Antes de crear el clon, recopile y registre información sobre la VPC, las subredes, el grupo de subredes de base de datos y las AZ utilizadas en el clúster original. De esta forma, puede minimizar las probabilidades de que surjan problemas. Si se produce un problema en la red, no tendrá que interrumpir ninguna actividad de solución de problemas para buscar información de diagnóstico. Las siguientes secciones muestran ejemplos de CLI para recopilar este tipo de información. Puede guardar los detalles en el formato que le resulte útil para consultar al crear el clon y solucionar cualquier problema.

Paso 1: comprobación de las zonas de disponibilidad del clúster original

Antes de crear el clon, compruebe qué zonas de disponibilidad utiliza el clúster original para su almacenamiento. Como se explica en Almacenamiento de Amazon Aurora, el almacenamiento de cada clúster Aurora está asociado exactamente a tres zonas de disponibilidad (AZ). Como Clústeres de base de datos de Amazon Aurora aprovecha la separación entre la computación y el almacenamiento, esta regla es válida independientemente de cuántas instancias haya en el clúster.

Por ejemplo, ejecute un comando de la CLI como el siguiente y sustituya el nombre de su propio clúster por my_cluster. El siguiente ejemplo genera una lista ordenada alfabéticamente por el nombre de la AZ.

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

En el siguiente ejemplo, se muestra el resultado del comando describe-db-clusters anterior. Demuestra que el almacenamiento del clúster Aurora siempre usa tres AZ.

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

Para crear un clon en un entorno de red que no cuente con todos los recursos necesarios para conectarse a estas AZ, debe crear subredes asociadas al menos a dos de esas AZ y, a continuación, crear un grupo de subredes de base de datos que contenga esas dos o tres subredes. Los siguientes ejemplos muestran cómo hacerlo.

Paso 2: comprobación del grupo de subredes de base de datos del clúster original

Si desea utilizar el mismo número de subredes para el clon que en el clúster original, puede obtener el número de subredes del grupo de subredes de base de datos del clúster original. Un grupo de subredes de base de datos Aurora contiene al menos dos subredes, cada una asociada a una AZ diferente. Anote las AZ a las que están asociadas las subredes.

En el siguiente ejemplo, se muestra cómo encontrar el grupo de subredes de base de datos del clúster original y, a continuación, retroceder hasta las AZ correspondientes. Sustituya el nombre de su clúster por my_cluster en el primer comando. Sustituya el nombre del grupo de subredes de base de datos por my_subnet en el segundo comando.

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

El resultado de un ejemplo podría ser similar al siguiente para un clúster con un grupo de subredes de base de datos que contenga dos subredes. En este caso, two-subnets es un nombre que se especificó al crear el grupo de subredes de base de datos.

two-subnets

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

Para un clúster con un grupo de subredes de base de datos que contenga tres subredes, el resultado podría ser similar al siguiente.

three-subnets

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

Paso 3: comprobación de las subredes del clúster original

Si necesita más detalles sobre las subredes del clúster original, ejecute comandos de AWS CLI similares a los siguientes. Puede examinar los atributos de las subredes, como los rangos de direcciones IP, el propietario, etc. De esta forma, puede determinar si desea utilizar subredes diferentes en la misma VPC o crear subredes con características similares en una VPC diferente.

Busque los ID de subred de todas las subredes que están disponibles en su VPC.

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

Busque las subredes exactas que se utilizan en el grupo de subredes de base de datos.

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

A continuación, especifique las subredes que quiere investigar en una lista, como en el siguiente comando. Sustituya los nombres de las subredes por my_subnet_1, etc.

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

El siguiente ejemplo muestra el resultado parcial de un comando describe-subnets de este tipo. El resultado muestra algunos de los atributos importantes que puede ver en cada subred, como su AZ y la VPC de la que forma parte.

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

Paso 4: comprobación de las zonas de disponibilidad de las instancias de base de datos en el clúster original

Puede utilizar este procedimiento para comprender las AZ utilizadas para las instancias de base de datos del clúster original. De esta forma, puede configurar exactamente las mismas AZ para las instancias de base de datos del clon. También puede utilizar más o menos instancias de base de datos en el clon, en función de si el clon se utiliza para la producción, el desarrollo y las pruebas, etc.

Para cada instancia del clúster original, ejecute un comando como el siguiente. Asegúrese de que la instancia haya terminado de crearse y de que esté en el estado Available primero. Sustituya el identificador de instancia por my_instance.

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

El siguiente ejemplo muestra el resultado de ejecutar el comando describe-db-instances anterior. El clúster Aurora tiene cuatro instancias de base de datos. Por lo tanto, ejecutamos el comando cuatro veces y lo sustituimos por un identificador de instancia de base de datos diferente cada vez. El resultado muestra cómo se distribuyen esas instancias de base de datos en un máximo de tres AZ.

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

Después de crear el clon y de agregarle instancias de base de datos, puede especificar estos mismos nombres de las AZ en los comandos create-db-instance. Puede hacerlo para configurar las instancias de base de datos en el nuevo clúster configurado exactamente para las mismas AZ que en el clúster original.

Paso 5: comprobación de las VPC que puede utilizar para el clon

Si tiene pensado crear el clon en una VPC diferente a la original, puede obtener una lista de los ID de VPC disponibles para su cuenta. También puede realizar este paso si necesita crear subredes adicionales en la misma VPC que el clúster original. Al ejecutar el comando para crear una subred, se especifica el ID de VPC como parámetro.

Para enumerar todas las VPC de la cuenta, ejecute el siguiente comando de CLI:

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

En el siguiente ejemplo, se muestra el resultado de muestra del comando describe-vpcs anterior. El resultado demuestra que hay cuatro VPC en la cuenta de AWS actual que se pueden usar como origen o destino para la clonación entre VPC.

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

Puede usar la misma VPC como destino para el clon o una VPC diferente. Si el clúster original y el clon están en la misma VPC, puede reutilizar el mismo grupo de subredes de base de datos para el clon. También puede crear un grupo de subredes de base de datos diferente. Por ejemplo, el nuevo grupo de subredes de base de datos podría usar subredes privadas, mientras que el grupo de subredes de base de datos del clúster original podría usar subredes públicas. Si crea el clon en una VPC diferente, asegúrese de que haya suficientes subredes en la nueva VPC y de que las subredes estén asociadas a las AZ correctas del clúster original.

Creación de recursos de red para el clon

Si al recopilar la información de la red ha descubierto que se necesitan recursos de red adicionales para el clon, puede crear esos recursos antes de intentar configurar el clon. Por ejemplo, podría necesitar crear más subredes, subredes asociadas a zonas de disponibilidad concretas o un nuevo grupo de subredes de base de datos.

Paso 1: creación de las subredes para el clon

Si necesita crear nuevas subredes para el clon, ejecute un comando similar al siguiente. Es posible que tenga que hacerlo al crear el clon en una VPC diferente o al realizar algún otro cambio en la red, como usar subredes privadas en lugar de subredes públicas.

AWS genera automáticamente el ID de la subred. Sustituya el nombre de la VPC del clon por my_vpc. Elija el rango de direcciones para la opción --cidr-block para permitir al menos 16 direcciones IP en el rango. Puede incluir cualquier otra propiedad que desee especificar. Ejecute el comando aws ec2 create-subnet help para ver todas las opciones.

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

El siguiente ejemplo muestra algunos atributos importantes de una subred recién creada.

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

Paso 2: creación del grupo de subredes de base de datos para el clon

Si va a crear el clon en una VPC diferente o en un conjunto diferente de subredes dentro de la misma VPC, debe crear un nuevo grupo de subredes de base de datos y especificarlo al crear el clon.

Asegúrese de conocer todos los siguientes detalles. Puede encontrarlos todos en el resultado de los ejemplos anteriores.

Compruebe cuántas AZ están asociadas al almacenamiento del clúster original y a las subredes de la VPC de destino. Para crear el clon correctamente, debe haber dos o tres AZ en común. Si tiene menos de dos AZ en común, vuelva a Paso 1: creación de las subredes para el clon. Cree una, dos o tres subredes nuevas asociadas a las AZ asociadas al almacenamiento del clúster original.

Elija subredes en la VPC de destino que estén asociadas a las mismas AZ que el almacenamiento de Aurora en el clúster original. Lo ideal sería elegir tres zonas de disponibilidad (AZ). De este modo, dispondrá de la máxima flexibilidad para distribuir las instancias de base de datos del clon en varias zonas de disponibilidad y conseguir una alta disponibilidad de los recursos de computación.

Ejecute un comando similar al siguiente para crear el nuevo grupo de subredes de base de datos. Sustituya los ID de las subredes en la lista. Si especifica los ID de subred mediante variables de entorno, asegúrese de citar la lista de parámetros --subnet-ids, de forma que se conserven las comillas dobles alrededor de los ID.

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'

El siguiente ejemplo muestra el resultado parcial del comando 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'
        ]
    }
}

En este momento, todavía no ha creado el clon. Ha creado todos los recursos de subred y VPC relevantes para poder especificar los parámetros adecuados para los comandos restore-db-cluster-to-point-in-time y create-db-instance al crear el clon.

Creación de un clon de Aurora con una nueva configuración de red

Una vez que se haya asegurado de que se ha establecido la configuración correcta de VPC, subredes, AZ y grupos de subredes para que la utilice el nuevo clúster, podrá realizar la operación de clonación propiamente dicha. Los siguientes ejemplos de CLI destacan opciones como --db-subnet-group-name, --availability-zone y --vpc-security-group-ids que se especifican en los comandos para configurar el clon y sus instancias de base de datos.

Paso 1: especificación del grupo de subredes de base de datos para el clon

Al crear el clon, puede configurar todos los ajustes correctos de VPC, subred y AZ especificando un grupo de subredes de base de datos. Utilice los comandos de los ejemplos anteriores para comprobar todas las relaciones y asignaciones que entran en el grupo de subredes de base de datos.

Por ejemplo, los siguientes comandos muestran cómo clonar un clúster original en un clon. En el primer ejemplo, el clúster de origen está asociado a dos subredes y el clon a tres subredes. El segundo ejemplo muestra el caso contrario: la clonación de un clúster con tres subredes a un clúster con dos subredes.

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 tiene pensado utilizar instancias Aurora sin servidor v2 en el clon, incluya una opción --serverless-v2-scaling-configuration al crear el clon, tal y como se muestra. De este modo, podrá utilizar la clase db.serverless al crear instancias de base de datos en el clon. También puede modificar el clon más adelante para añadir este atributo de configuración de escalado. Los números de capacidad de este ejemplo permiten que cada instancia sin servidor v2 en el clúster escale entre 2 y 32 unidades de capacidad (ACU) de Aurora. Para obtener información sobre la característica Aurora sin servidor v2 y sobre cómo elegir el rango de capacidad, consulte Uso de 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'

Independientemente del número de subredes utilizadas por las instancias de base de datos, el almacenamiento de Aurora para el clúster de origen y el clon está asociado a tres AZ. En el siguiente ejemplo, se enumeran las AZ asociadas al clúster original y al clon, para los dos comandos restore-db-cluster-to-point-in-time de los ejemplos anteriores.

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

Como al menos dos de las AZ se superponen entre cada par de clústeres originales y clonados, ambos clústeres pueden acceder al mismo almacenamiento subyacente de Aurora.

Paso 2: especificación de la configuración de red para las instancias del clon

Al crear instancias de base de datos en el clon, de forma predeterminada, estas heredan el grupo de subredes de base de datos del propio clúster. De esta forma, Aurora asigna automáticamente cada instancia a una subred concreta y la crea en la AZ asociada a la subred. Esta opción resulta práctica, sobre todo para los sistemas de desarrollo y prueba, ya que no es necesario realizar un seguimiento de los ID de subred ni de las AZ al agregar nuevas instancias al clon.

Como alternativa, puede especificar la zona de disponibilidad (AZ) al crear una instancia de base de datos Aurora para el clon. La AZ que especifique debe ser del conjunto de las AZ asociadas al clon. Si el grupo de subredes de base de datos que utiliza para el clon solo contiene dos subredes, solo podrá elegir entre las AZ asociadas a esas dos subredes. Esta opción ofrece flexibilidad y resiliencia para sistemas de alta disponibilidad, ya que puede asegurarse de que la instancia de escritor y la instancia de lector en espera estén en diferentes zonas de disponibilidad. O bien si añade lectores adicionales al clúster, puede asegurarse de que estén distribuidos en tres zonas de disponibilidad. De esta forma, incluso en el caso inusual de que se produzca un error en la zona de distribución, seguirá teniendo una instancia de escritor y otra de lector en otras dos zonas de disponibilidad.

En el siguiente ejemplo, se agrega una instancia de base de datos aprovisionada a un clúster de Aurora PostgreSQL clonado que usa un grupo de subredes de base de datos personalizado.

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

El siguiente ejemplo muestra el resultado parcial de un comando de este tipo.

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

El siguiente ejemplo agrega una instancia de base de datos Aurora sin servidor v2 a un clon de Aurora MySQL que usa un grupo de subredes de base de datos personalizado. Para poder utilizar instancias de sin servidor v2, asegúrese de especificar la opción --serverless-v2-scaling-configuration para el comando restore-db-cluster-to-point-in-time, tal y como se muestra en los ejemplos anteriores.

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

El siguiente ejemplo muestra el resultado parcial de un comando de este tipo.

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

Paso 3: establecimiento de la conectividad de un sistema cliente a un clon

Si ya se está conectando a un clúster de Aurora desde un sistema cliente, es posible que desee permitir el mismo tipo de conectividad a un clon nuevo. Por ejemplo, podría conectarse al clúster original desde una instancia de Amazon Cloud9 o EC2. Para permitir conexiones desde los mismos sistemas cliente o desde otros nuevos que cree en la VPC de destino, configure grupos de subredes de base de datos y grupos de seguridad de VPC equivalentes a los de la VPC. A continuación, especifique el grupo de subredes y los grupos de seguridad al crear el clon.

Los siguientes ejemplos configuran un clon de Aurora sin servidor v2. Esa configuración se basa en la combinación de --engine-mode provisioned y --serverless-v2-scaling-configuration al crear el clúster de base de datos y, después, --db-instance-class db.serverless al crear cada instancia de base de datos del clúster. El modo de motor provisioned es el predeterminado, por lo que puede omitir esa opción si lo prefiere.

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

A continuación, al crear las instancias de base de datos en el clon, especifique la misma opción --db-subnet-group-name. Si lo desea, puede incluir la opción --availability-zone y especificar una de las AZ asociadas a las subredes de ese grupo de subredes. Esa AZ también debe ser una de las AZ asociadas al clúster original.

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

Traslado de un clúster de subredes públicas a subredes privadas

Puede usar la clonación para migrar un clúster entre subredes públicas y privadas. Podría hacerlo al agregar capas de seguridad adicionales a su aplicación antes de implementarla en producción. Para este ejemplo, debe tener configuradas las subredes privadas y la puerta de enlace de NAT antes de iniciar el proceso de clonación con Aurora.

Para los pasos relacionados con Aurora, puede seguir los mismos pasos generales que en los ejemplos anteriores para Recopilación de información sobre el entorno de red yCreación de un clon de Aurora con una nueva configuración de red. La diferencia principal es que, incluso si tiene subredes públicas que se asignan a todas las AZ del clúster original, ahora debe comprobar que tiene suficientes subredes privadas para un clúster de Aurora y que esas subredes están asociadas a todas las mismas AZ que se utilizan para el almacenamiento de Aurora en el clúster original. Al igual que en otros casos de uso de clonación, puede crear el grupo de subredes de base de datos del clon con tres o dos subredes privadas asociadas a las AZ requeridas. Sin embargo, si usa dos subredes privadas en el grupo de subredes de base de datos, debe tener una tercera subred privada asociada a la tercera AZ utilizada para el almacenamiento de Aurora en el clúster original.

Puede consultar esta lista de comprobación para verificar que se cumplen todos los requisitos para realizar este tipo de operación de clonación.

Cuando se cumplan todos los requisitos previos, puede pausar la actividad de la base de datos en el clúster original mientras crea el clon y cambiar la aplicación para usarlo. Tras crear el clon y verificar que puede conectarse a él, ejecutar el código de la aplicación, etc., podrá dejar de utilizar el clúster original.

Ejemplo de extremo a extremo de creación de un clon entre VPC

Para crear un clon en una VPC diferente a la original, se siguen los mismos pasos generales que en los ejemplos anteriores. Dado que el ID de VPC es una propiedad de las subredes, en realidad no se especifica el ID de VPC como parámetro al ejecutar cualquiera de los comandos de la CLI de RDS. La principal diferencia es que es más probable que necesite crear nuevas subredes, nuevas subredes asignadas a zonas de disponibilidad específicas, un grupo de seguridad de VPC y un nuevo grupo de subredes de base de datos. Esto es especialmente cierto si se trata del primer clúster de Aurora que se crea en esa VPC.

Puede consultar esta lista de comprobación para verificar que se cumplen todos los requisitos para realizar este tipo de operación de clonación.

Cuando se cumplan todos los requisitos previos, puede pausar la actividad de la base de datos en el clúster original mientras crea el clon y cambiar la aplicación para usarlo. Tras crear el clon y verificar que puede conectarse a él, ejecutar el código de la aplicación, etc., podrá plantearse si va a mantener tanto el original como los clones ejecutándose, o bien si va a dejar de utilizar el clúster original.

Los siguientes ejemplos de Linux muestran la secuencia de operaciones de AWS CLI para clonar un clúster de base de datos Aurora de una VPC a otra. Algunos campos que no son relevantes para los ejemplos no se muestran en el resultado del comando.

En primer lugar, comprobamos los ID de las VPC de origen y destino. El nombre descriptivo que se asigna a una VPC al crearla se representa como una etiqueta en los metadatos de la VPC.

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

El clúster original ya existe en la VPC de origen. Para configurar el clon con el mismo conjunto de AZ para el almacenamiento de Aurora, verificamos las AZ utilizadas por el clúster original.

$ 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

Nos aseguramos de que haya subredes que correspondan a las AZ utilizadas por el clúster original: us-east-1c, us-east-1d yus-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',
    }
}

Este ejemplo confirma que hay subredes que se asignan a las AZ necesarias en la VPC de destino.

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

Antes de crear un clúster de base de datos Aurora en la VPC, debe tener un grupo de subredes de base de datos con subredes que se asignen a las AZ utilizadas para el almacenamiento de Aurora. Al crear un clúster normal, puede usar cualquier conjunto de tres zonas de disponibilidad (AZ). Al clonar un clúster existente, el grupo de subredes debe coincidir con al menos dos de las tres zonas de disponibilidad que utiliza para el almacenamiento de 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' }
            }
        ]
    }
}

Ahora las subredes y el grupo de subredes de base de datos están en su lugar. En el siguiente ejemplo, se muestra el restore-db-cluster-to-point-in-time que clona el clúster. La opción --db-subnet-group-name asocia el clon al conjunto correcto de subredes que se asignan al conjunto correcto de AZ del clúster original.

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

El siguiente ejemplo confirma que el almacenamiento de Aurora en el clon usa el mismo conjunto de AZ que en el clúster original.

$ 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

En este momento, puede crear instancias de base de datos para el clon. Asegúrese de que el grupo de seguridad de VPC asociado a cada instancia permita las conexiones desde los rangos de direcciones IP que utiliza para las instancias EC2, los servidores de aplicaciones, etc., que se encuentran en la VPC de destino.