Clonación de un volumen de clúster de base de datos de Amazon Aurora

Con la clonación de Aurora, puede crear un nuevo clúster que utilice inicialmente las mismas páginas de datos que el original y sea un volumen independiente. El proceso está diseñado para ser rápido y rentable. El nuevo clúster con su volumen de datos asociado se conoce como clon. La creación de un clon es más rápido y más eficiente en el espacio que copiar físicamente los datos mediante una técnica diferente, como la restauración de una instantánea.

Información general de la clonación de Aurora

Aurora utiliza un protocolo de copia en escritura para crear un clon. Este mecanismo utiliza un espacio adicional mínimo para crear un clon inicial. Cuando se crea el clon por primera vez, Aurora guarda una sola copia de los datos que utiliza el clúster de base de datos de Aurora de origen y el nuevo clúster de base de datos de Aurora (clonado). El almacenamiento adicional solo se asigna cuando el clúster de base de datos de Aurora de origen o el clon del clúster de base de datos de Aurora realizan cambios en los datos (en el volumen de almacenamiento de Aurora). Para obtener más información sobre el protocolo de copia en escritura, consulte Cómo funciona la clonación de Aurora.

La clonación de Aurora es especialmente útil para configurar rápidamente entornos de prueba mediante sus datos de producción, sin riesgo de corrupción de datos. Puede utilizar clones para muchos tipos de aplicaciones de corta duración, como las siguientes:

• Experimente con cambios potenciales (por ejemplo, cambios de esquema y cambios de grupo de parámetros) para evaluar todos los impactos.

• Realice operaciones intensivas de carga de trabajo, como exportar datos o ejecutar consultas analíticas en el clon.

• Cree una copia del clúster de base de datos de producción para desarrollo, pruebas u otros fines.

Puede crear más de un clon desde el mismo clúster de base de datos de Aurora. También puede crear varios clones desde otro clon.

Después de crear un clon de Aurora, puede configurar las instancias de base de datos de Aurora de forma diferente al clúster de base de datos de Aurora de origen. Por ejemplo, es posible que no necesite un clon con fines de desarrollo para cumplir con los mismos requisitos de alta disponibilidad que el clúster de base de datos Aurora de producción de origen. En este caso, puede configurar el clon con una única instancia de base de datos de Aurora en lugar de las múltiples instancias de base de datos utilizadas por el clúster de base de datos de Aurora.

Cuando crea un clon con una configuración de implementación diferente a la de origen, el clon se crea con la versión secundaria más reciente del motor de base de datos Aurora.

Cuando crea clones desde sus clústeres de base de datos de Aurora, los clones se crean en su cuenta de AWS: la misma cuenta que posee el clúster de base de datos de Aurora de origen. Sin embargo, también puede compartir clústeres y clones de base de datos de Aurora DB aprovisionados y de Aurora Serverless v2 con otras cuentas de AWS. Para obtener más información, consulte Clonación entre cuentas con AWS RAM y Amazon Aurora.

Cuando termine de utilizar el clon para realizar pruebas, desarrollo u otros fines, puede eliminarlo.

Limitaciones de la clonación de Aurora

La clonación de Aurora tiene las siguientes limitaciones:

• Puede crear tantos clones como desee, hasta el número máximo de clústeres de base de datos permitido en la Región de AWS.

  Puede crear clones mediante el protocolo de copia en escritura o el protocolo de copia completa. El protocolo de copia completa actúa como una recuperación en un momento dado.

• No se puede crear un clon en una región de AWS distinta a la del clúster de base de datos de Aurora de origen.

• No se puede crear un clon desde un clúster de base de datos de Aurora sin la característica de consulta paralela a un clúster que utiliza consulta paralela. Para llevar datos a un clúster que utiliza la consulta paralela, cree una instantánea del clúster original y restáurela al clúster donde está habilitada la característica de consulta paralela.

• No se puede crear un clon desde un clúster de base de datos de Aurora que no tiene instancias de base de datos. Solo se pueden clonar clústeres de base de datos de Aurora que tengan al menos una instancia de base de datos.

• Se puede crear un clon en una Virtual Private Cloud (VPC) diferente de la del clúster de base de datos de Aurora. Sin embargo, las subredes de esas VPC deben estar asignadas al mismo conjunto de zonas de disponibilidad.

• Puede crear un clon aprovisionado de Aurora desde un clúster de base de datos de Aurora aprovisionado.

• Los clústeres con instancias de Aurora Serverless v2 siguen las mismas reglas que los clústeres aprovisionados.

• En Aurora Serverless v1:

  • Puede crear un clon aprovisionado desde un clúster de base de datos de Aurora Serverless v1.

  • Puede crear un clon de Aurora Serverless v1 desde un clúster de base de datos aprovisionado o de Aurora Serverless v1.

  • No se puede crear un clon de Aurora Serverless v1 a partir de un clúster de base de datos de Aurora aprovisionado no cifrado.

  • La clonación entre cuentas actualmente no admite la clonación de clústeres de base de datos de Aurora Serverless v1. Para obtener más información, consulte Limitaciones de la clonación entre cuentas.

  • Un clúster de base de datos de Aurora Serverless v1 clonado tiene el mismo comportamiento y limitaciones que cualquier clúster de base de datos de Aurora Serverless v1. Para obtener más información, consulte Uso de Amazon Aurora Serverless v1.

  • Los clústeres de base de datos de Aurora Serverless v1 están siempre cifrados. Cuando clona un clúster de base de datos de de Aurora Serverless v1 en un clúster de base de datos de Aurora aprovisionado, el clúster de de base de datos de Aurora aprovisionado está cifrado. Puede elegir la clave de cifrado, pero no puede desactivar el cifrado. Para crear un clon aprovisionado de base de datos de Aurora a un Aurora Serverless v1, debe hacerlo a partir de un clúster de base de datos de Aurora cifrado y aprovisionado.

Cómo funciona la clonación de Aurora

La clonación de Aurora funciona en la capa de almacenamiento de un clúster de base de datos de Aurora. Utiliza un protocolo copy-on-write que es rápido y eficiente en el espacio en términos de los medios permanentes subyacentes que soportan el volumen de almacenamiento de Aurora. Puede obtener más información sobre volúmenes de clúster de Aurora en Información general del almacenamiento de Amazon Aurora.

Temas

• Descripción del protocolo de copia en escritura
• Eliminación de un volumen del clúster de origen

Descripción del protocolo de copia en escritura

Un clúster de base de datos de Aurora almacena datos en páginas en el volumen de almacenamiento de Aurora subyacente.

Por ejemplo, en el siguiente diagrama puede encontrar un clúster de base de datos de Aurora (A) que tiene cuatro páginas de datos, 1, 2, 3 y 4. Imagine que un clon, B, se crea desde del clúster de base de datos de Aurora. Cuando se crea el clon, no se copian datos. Más bien, el clon apunta al mismo conjunto de páginas que el clúster de base de datos de Aurora de origen.

Cuando se crea el clon, generalmente no se necesita almacenamiento adicional. El protocolo de copia en escritura utiliza el mismo segmento en los medios de almacenamiento físico que el segmento de origen. Solo se requiere almacenamiento adicional si la capacidad del segmento de origen no es suficiente para todo el segmento de clones. Si ese es el caso, el segmento de origen se copia en otro dispositivo físico.

En los diagramas siguientes, puede encontrar un ejemplo del protocolo de copia en escritura en acción utilizando el mismo clúster A y su clon B, como se muestra anteriormente. Supongamos que realiza un cambio en su clúster de base de datos de Aurora (A) que da lugar a un cambio en los datos almacenados en la página 1. En lugar de escribir en la página original 1, Aurora crea una nueva página 1 [A]. El volumen del clúster de base de datos de Aurora para el clúster (A) ahora apunta a la página 1 [A], 2, 3 y 4, mientras que el clon (B) sigue haciendo referencia a las páginas originales.

En el clon, se realiza un cambio en la página 4 del volumen de almacenamiento. En lugar de escribir en la página original 4, Aurora crea una nueva página 4 [B]. El clon ahora apunta a las páginas 1, 2, 3 y a la página 4 [B], mientras que el clúster (A) continúa apuntando a 1 [A], 2, 3 y 4.

A medida que se producen más cambios a lo largo del tiempo en el clon y el volumen del clúster de base de datos de Aurora de origen, necesitará cada vez más almacenamiento para capturar y almacenar los cambios.

Eliminación de un volumen del clúster de origen

Inicialmente, el volumen de clon comparte las mismas páginas de datos que el volumen original a partir del cual se crea el clon. Mientras exista el volumen original, el volumen del clon solo se considera propietario de las páginas que el clon ha creado o modificado. Por lo tanto, la métrica VolumeBytesUsed del volumen del clon comienza siendo pequeña y solo aumenta a medida que los datos divergen entre el clúster original y el clon. En el caso de páginas idénticas entre el volumen de origen y el clon, los cargos de almacenamiento se aplican únicamente al clúster original. Para obtener más información acerca de la métrica VolumeBytesUsed, consulte Métricas de nivel de clúster para Amazon Aurora.

Cuando elimina un volumen de clúster de origen que tiene uno o más clones asociados, los datos en los volúmenes del clúster de los clones no cambian. Aurora conserva las páginas que antes pertenecían al volumen del clúster de origen. Aurora redistribuye la facturación del almacenamiento de las páginas que pertenecían al clúster eliminado. Por ejemplo, supongamos que un clúster original tenía dos clones y, después, se eliminó el clúster original. La mitad de las páginas de datos que pertenecían al clúster original ahora pertenecerían a un clon. La otra mitad de las páginas pertenecería al otro clon.

Si elimina el clúster original, a medida que crea o elimina más clones, Aurora sigue redistribuyendo la propiedad de las páginas de datos entre todos los clones que comparten las mismas páginas. Por lo tanto, es posible que observe que el valor de la métrica VolumeBytesUsed cambia para el volumen del clúster de un clon. El valor de la métrica puede disminuir a medida que se crean más clones y la propiedad de la página se distribuye entre más clústeres. El valor de la métrica también puede aumentar a medida que se eliminan los clones y se asigna la propiedad de la página a una cantidad menor de clústeres. Para obtener información sobre cómo afectan las operaciones de escritura a las páginas de datos de los volúmenes de clones, consulte Descripción del protocolo de copia en escritura.

Cuando el clúster original y los clones pertenecen a la misma cuenta de AWS, todos los cargos de almacenamiento de esos clústeres se aplican a esa misma cuenta de AWS. Si algunos de los clústeres son clones entre cuentas, eliminar el clúster original puede conllevar cargos de almacenamiento adicionales a las cuentas de AWS que poseen los clones entre cuentas.

Por ejemplo, supongamos que un volumen de clúster tiene 1000 páginas de datos usados antes de crear cualquier clon. Al clonar ese clúster, inicialmente el volumen del clon no tiene ninguna página utilizada. Si el clon modifica 100 páginas de datos, solo esas 100 páginas se almacenan en el volumen del clon y se marcan como usadas. Las otras 900 páginas sin cambios del volumen principal se comparten entre ambos clústeres. En este caso, el clúster principal tiene cargos de almacenamiento para 1000 páginas y el volumen del clon para 100 páginas.

Si elimina el volumen de origen, los cargos de almacenamiento del clon incluyen las 100 páginas modificadas, más las 900 páginas compartidas del volumen original, lo que da un total de 1000 páginas.

Creación de un clon de Amazon Aurora

Puede crear un clon en la misma cuenta de AWS como clúster de base de datos de Aurora de origen. Para ello, puede utilizar la AWS Management Console o la AWS CLI, y los procedimientos siguientes.

Para permitir que otra cuenta de AWS cree un clon o comparta un clon con otra cuenta de AWS, utilice los procedimientos en Clonación entre cuentas con AWS RAM y Amazon Aurora.

Consola

El siguiente procedimiento describe cómo clonar un clúster de base de datos de Aurora mediante la AWS Management Console.

Al crear un clon con la AWS Management Console resulta en un clúster de base de datos de Aurora con una instancia de base de datos de Aurora.

Estas instrucciones se aplican a los clústeres de base de datos que pertenecen a la misma AWS cuenta que crea la clonación. Si el clúster de base de datos es propiedad de otra AWS cuenta, consulte Clonación entre cuentas con AWS RAM y Amazon Aurora en su lugar.

Para crear un clon de un clúster de base de datos propiedad de la AWS cuenta mediante el comando AWS Management Console

1. Inicie sesión en la AWS Management Console y abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/.

2. En el panel de navegación, seleccione Databases (Bases de datos).

3. Elija su clúster de base de datos de Aurora de la lista y para Actions (Acciones), elija Create clone (Crear clon).

   

   Se abre la página Crear clon donde puede configurar Configuración, Conectividad y otras opciones para el clon del clúster de base de datos de Aurora.

4. Para el identificador de instancia de base de datos, indique el nombre que desea asignar a su clúster de base de datos de Aurora clonado.

5. Para los clústeres de bases de datos de Aurora Serverless v1, elija Aprovisionado o Sin servidor como Tipo de capacidad.

   Puede elegir Serverless (Sin servidor) solo si el clúster de base de datos de Aurora de origen es una clúster de base de datos de Aurora Serverless v1 o es un clúster de base de datos de Aurora aprovisionado que está cifrado.

6. Para los clústeres de bases de datos de Aurora Serverless v2 o aprovisionados, elija Aurora I/O-Optimized o Aurora Standard para Configuración de almacenamiento del clúster.

   Para obtener más información, consulte Configuraciones de almacenamiento para los clústeres de base de datos de Amazon Aurora.

7. Elija el tamaño de la instancia de base de datos o la capacidad del clúster de base de datos:

   • Para un clon aprovisionado, elija una Clase de instancia de base de datos.

     

     Puede aceptar la configuración proporcionada o puede usar una clase de instancia de base de datos diferente para su clon.

   • Para un clon de Aurora Serverless v1 o Aurora Serverless v2, elija la Configuración de capacidad.

     

     Puede aceptar la configuración proporcionada o cambiarla para su clon.

8. Seleccione el resto de ajustes según sea necesario para su clon. Para obtener más información sobre la configuración del clúster y de la instancia de base de datos de Aurora, consulte Creación de un clúster de base de datos de Amazon Aurora.

9. Elija Crear clon.

Cuando se crea el clon, aparece junto con los otros clústeres de base de datos de Aurora en la sección Databases (Bases de datos) de la consola y muestra su estado actual. Su clon está listo para utilizar cuando su estado es Available (Disponible).

AWS CLI

El uso de la AWS CLI para clonar el clúster de base de datos de Aurora implica pasos separados para crear el clúster de clones y agregarle una o más instancias de base de datos.

El comando restore-db-cluster-to-point-in-time de la AWS CLI que utiliza produce un clúster de base de datos de Aurora con los mismos datos de almacenamiento que el clúster original, pero ninguna instancia de base de datos Aurora. Se crean instancias de base de datos por separado después de que el clon esté disponible. Puede elegir el número de instancias de base de datos y sus clases de instancias para dar al clon una capacidad de procesamiento mayor o menor que la del clúster original. Los pasos del proceso son los siguientes:

1. Cree el clon mediante el comando restore-db-cluster-to-point-in-time de la CLI.

2. Cree la instancia de base de datos de escritor para el clon con el comando de la CLI create-db-instance.

3. (Opcional) Ejecute comandos de la CLI create-db-instance adicionales para agregar una o más instancias de lector al clúster de clones. El uso de instancias de lector ayuda a mejorar los aspectos de alta disponibilidad y escalabilidad de lectura del clon. Puede omitir este paso si tiene pensado utilizar el clon para el desarrollo y las pruebas.

Temas

• Creación del clon
• Comprobación del estado y obtención de detalles del clon
• Crear la instancia de base de datos de Aurora para su clon
• Parámetros para utilizar durante la clonación

Creación del clon

Utilice el comando de la CLI restore-db-cluster-to-point-in-time para crear el clúster de clones inicial.

Creación de un clon desde un clúster de base de datos de Aurora de origen

• Utilice el comando CLI restore-db-cluster-to-point-in-time. Especifique los valores de los siguientes parámetros. En este caso típico, el clon utiliza el mismo modo de motor que el clúster original, ya sea aprovisionado o Aurora Serverless v1.

  • --db-cluster-identifier: elija un nombre significativo para su clon. Se asigna un nombre al clon cuando se utiliza el comando restore-db-cluster-to-point-in-time de la CLI. A continuación, pase el nombre del clon en el comando create-db-instance de la CLI.

  • --restore-type: utilice copy-on-write para crear un clon del clúster de base de datos de origen. Sin este parámetro, restore-db-cluster-to-point-in-time restaura el clúster de base de datos de Aurora en lugar de crear un clon.

  • --source-db-cluster-identifier: utilice el nombre del clúster de base de datos de Aurora de origen que desea clonar.

  • --use-latest-restorable-time: este valor apunta a los datos de volumen restaurables más recientes para el clúster de base de datos de origen. Úselo para crear clones.

El siguiente ejemplo crea un clon del clúster de denominado my-clone desde un clúster denominado my-source-cluster.

Para Linux, macOS o Unix:

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

En Windows:

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

El comando devuelve el objeto JSON que contiene detalles del clon. Compruebe que su clúster de base de datos clonado está disponible antes de intentar crear la instancia de base de datos para su clon. Para obtener más información, consulte Comprobación del estado y obtención de detalles del clon.

Por ejemplo, supongamos que tiene un clúster llamado tpch100g que desea clonar. En el siguiente ejemplo de Linux, se crea un clúster clonado denominado tpch100g-clone, una instancia de escritor de Aurora Serverless v2 denominada tpch100g-clone-instance y una instancia de lector aprovisionada denominada tpch100g-clone-instance-2 para el nuevo clúster.

No es necesario proporcionar algunos parámetros, como --master-username y --master-user-password. Aurora determina automáticamente los parámetros del clúster original. Es necesario especificar el motor de base de datos que se va a utilizar. Por lo tanto, el ejemplo prueba el nuevo clúster para determinar el valor correcto a utilizar para el parámetro --engine.

En este ejemplo también se incluye la opción --serverless-v2-scaling-configuration al crear el clúster de clones. De esta forma, puede agregar instancias de Aurora Serverless v2 al clon aunque el clúster original no usara Aurora Serverless v2.

$ aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier tpch100g \
  --db-cluster-identifier tpch100g-clone \
  --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16 \
  --restore-type copy-on-write \
  --use-latest-restorable-time

$ aws rds describe-db-clusters \
  --db-cluster-identifier tpch100g-clone \
    --query '*[].[Engine]' \
    --output text
aurora-mysql

$ aws rds create-db-instance \
  --db-instance-identifier tpch100g-clone-instance \
  --db-cluster-identifier tpch100g-clone \
  --db-instance-class db.serverless \
  --engine aurora-mysql

$ aws rds create-db-instance \
  --db-instance-identifier tpch100g-clone-instance-2 \
  --db-cluster-identifier tpch100g-clone \
  --db-instance-class db.r6g.2xlarge \
  --engine aurora-mysql

Para crear un clon en un modo de motor distinto al del clúster de base de datos de Aurora de origen.

• Este procedimiento solo se aplica a las versiones de motor anteriores que admitan Aurora Serverless v1. Supongamos que tiene un clúster de Aurora Serverless v1 y quiere crear un clon que sea un clúster aprovisionado. En ese caso, utilice el comando de la CLI restore-db-cluster-to-point-in-time y especifique valores de parámetros similares a los del ejemplo anterior, además de estos parámetros adicionales:

  • --engine-mode: utilice este parámetro solo para crear clones que sean de un modo de motor diferente al del clúster de base de datos de Aurora de origen. Este parámetro solo se aplica a las versiones de motor anteriores que admitan Aurora Serverless v1. Elija el valor con el que se va a pasar --engine-mode de la siguiente manera:

    • Utilice --engine-mode provisioned para crear un clon de clúster de base de datos de Aurora aprovisionado desde un clúster de base de datos de Aurora Serverless.

      nota

      Si tiene pensado utilizar Aurora Serverless v2 con un clúster que se clonó desde Aurora Serverless v1, siga especificando el modo de motor del clon como provisioned. A continuación, debe realizar pasos adicionales de actualización y migración.

    • Utilice --engine-mode serverless para crear un clon de Aurora Serverless v1 desde un clúster de base de datos de Aurora aprovisionado. Cuando se especifica el modo de motor serverless, también puede elegir la --scaling-configuration.

  • --scaling-configuration: (opcional) se utiliza con --engine-mode serverless para configurar la capacidad mínima y máxima de un clon de Aurora Serverless v1. Si no utiliza este parámetro, Aurora crea un clon de Aurora Serverless v1 con los valores de capacidad de Aurora Serverless v1 predeterminados del motor de base de datos.

El siguiente ejemplo crea un clon aprovisionado denominado my-clone desde un clúster de base de datos de Aurora Serverless v1 denominado my-source-cluster.

Para Linux, macOS o Unix:

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

En Windows:

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

Estos comandos devuelven el objeto JSON que contiene detalles del clon que necesita para crear la instancia de base de datos. No puede hacer eso hasta que el estado del clon (el clúster vacío de base de datos de Aurora) tenga el estado Available (Disponible).

nota

El comando restore-db-cluster-to-point-in-time de la CLI de AWS solo restaura el clúster de la base de datos, no las instancias de base de datos dicho clúster. Ejecute el comando create-db-instance para crear instancias de base de datos para el clúster de base de datos restaurado. Con ese comando, especifique el identificador del clúster de base de datos restaurado como parámetro --db-cluster-identifier. Solo puede crear instancias de base de datos después de que se haya completado el comando restore-db-cluster-to-point-in-time y de que el clúster de base de datos esté disponible.

Suponga que comienza con un clúster de Aurora Serverless v1 y tiene la intención de migrarlo a un clúster de Aurora Serverless v2. Como paso inicial de la migración, debe crear un clon aprovisionado del clúster de Aurora Serverless v1. Para ver el procedimiento completo, incluidas las actualizaciones de la versión necesarias, consulte Actualización de un clúster de Aurora Serverless v1 a Aurora Serverless v2.

Comprobación del estado y obtención de detalles del clon

Puede utilizar el siguiente comando para verificar el estado del clúster de clones recién creado.

$ aws rds describe-db-clusters --db-cluster-identifier my-clone --query '*[].[Status]' --output text

O puede obtener el estado y los otros valores que necesita paracrear la instancia de base de datos para su clon mediante el uso de la siguiente consulta de la AWS CLI.

Para Linux, macOS o Unix:

aws rds describe-db-clusters --db-cluster-identifier my-clone \
  --query '*[].{Status:Status,Engine:Engine,EngineVersion:EngineVersion,EngineMode:EngineMode}'

En Windows:

aws rds describe-db-clusters --db-cluster-identifier my-clone ^
  --query "*[].{Status:Status,Engine:Engine,EngineVersion:EngineVersion,EngineMode:EngineMode}"

Esta consulta devuelve un resultado similar al siguiente:

[
  {
        "Status": "available",
        "Engine": "aurora-mysql",
        "EngineVersion": "8.0.mysql_aurora.3.04.1",
        "EngineMode": "provisioned"
    }
]

Crear la instancia de base de datos de Aurora para su clon

Use el comando create-db-instance de la CLI para crear la instancia de base de datos para su clon de Aurora Serverless v2 o aprovisionado. No se crea una instancia de base de datos para un clon de Aurora Serverless v1.

La instancia de base de datos hereda las propiedades --master-username y --master-user-password del clúster de base de datos de origen.

El siguiente ejemplo crea una instancia de base de datos para un clon aprovisionado.

Para Linux, macOS o Unix:

aws rds create-db-instance \
    --db-instance-identifier my-new-db \
    --db-cluster-identifier my-clone \
    --db-instance-class db.r6g.2xlarge \
    --engine aurora-mysql

En Windows:

aws rds create-db-instance ^
    --db-instance-identifier my-new-db ^
    --db-cluster-identifier my-clone ^
    --db-instance-class db.r6g.2xlarge ^
    --engine aurora-mysql

En el siguiente ejemplo, se crea una instancia de base de datos de Aurora Serverless v2 para un clon que utiliza una versión del motor que admite Aurora Serverless v2.

Para Linux, macOS o Unix:

aws rds create-db-instance \
    --db-instance-identifier my-new-db \
    --db-cluster-identifier my-clone \
    --db-instance-class db.serverless \
  --engine aurora-postgresql

En Windows:

aws rds create-db-instance ^
    --db-instance-identifier my-new-db ^
    --db-cluster-identifier my-clone ^
    --db-instance-class db.serverless ^
    --engine aurora-mysql

Parámetros para utilizar durante la clonación

En la siguiente tabla se resumen los diversos parámetros utilizados con restore-db-cluster-to-point-in-time para clonar clústeres de base de datos de Aurora.

Parámetro	Descripción
--source-db-cluster-identifier	Utilice el nombre del clúster de base de datos de Aurora de origen que desea clonar.
--db-cluster-identifier	Elija un nombre significativo para su clon al crearlo con el comando restore-db-cluster-to-point-in-time. A continuación, pase este nombre al comando create-db-instance.
--restore-type	Especifique copy-on-write como el --restore-type para crear un clon del clúster de base de datos de origen en lugar de restaurar el clúster de base de datos de Aurora de origen.
--use-latest-restorable-time	Este valor apunta a los datos de volumen restaurables más recientes para el clúster de base de datos de origen. Úselo para crear clones.
--serverless-v2-scaling-configuration	(Versiones más recientes que admiten Aurora Serverless v2) Utilice este parámetro para configurar la capacidad mínima y máxima de un clon de Aurora Serverless v2. Si no especifica este parámetro, no podrá crear ninguna instancia de Aurora Serverless v2 en el clúster de clones hasta que modifique el clúster para agregar este atributo.
--engine-mode	(Versiones anteriores que admiten solo Aurora Serverless v1) Utilice este parámetro para crear clones que sean de un tipo diferente al del clúster de base de datos de Aurora de origen, con uno de los siguientes valores: Utilice provisioned para crear un clon aprovisionado desde un clúster de base de datos de Aurora Serverless v1. Utilice serverless para crear un clon de Aurora Serverless v1 desde un clúster de base de datos aprovisionado o de Aurora Serverless v2. Cuando se especifica el modo de motor serverless, también puede elegir la --scaling-configuration.
--scaling-configuration	(Versiones anteriores que admiten solo Aurora Serverless v1) Utilice este parámetro para configurar la capacidad mínima y máxima de un clon de Aurora Serverless v1. Si no especifica este parámetro, Aurora crea el clon con los valores de capacidad predeterminados del motor de base de datos.

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

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

• Creación de recursos de red para el clon

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

Antes de empezar

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

• Un clúster de base de datos Aurora para usarlo como origen de clonación. Si es la primera vez que crea un clúster de base de datos Aurora, consulte los tutoriales de Introducción a Amazon Aurora para configurar un clúster mediante el motor de base de datos MySQL o PostgreSQL.

• Una segunda VPC, si tiene pensado crear un clon entre VPC. Si no tiene una VPC que usar para el clon, consulte Tutorial: Creación de una VPC para utilizarla con un clúster de base de datos (solo IPv4) o Tutorial: Creación de una VPC para utilizarla con un clúster de base de datos (modo de pila doble).

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

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

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

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

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

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 y fiabilidad 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 a al menos 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 zona de disponibilidad (AZ) asociada 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

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

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.

1. VPC del clúster original. Para obtener instrucciones, consulte Paso 3: comprobación de las subredes del clúster original.

2. VPC del clon, si lo está creando en una VPC diferente. Para obtener instrucciones, consulte Paso 5: comprobación de las VPC que puede utilizar para el clon.

3. Tres zonas de disponibilidad (AZ) asociadas al almacenamiento de Aurora del clúster original. Para obtener instrucciones, consulte Paso 1: comprobación de las zonas de disponibilidad del clúster original.

4. Dos o tres AZ asociadas al grupo de subredes de base de datos del clúster original. Para obtener instrucciones, consulte Paso 2: comprobación del grupo de subredes de base de datos del clúster original.

5. Los ID de subred y las AZ asociadas de todas las subredes de la VPC que tiene pensado usar para el clon. Utilice el mismo comando describe-subnets que en Paso 3: comprobación de las subredes del clúster original, sustituyendo el ID de VPC de la VPC de destino.

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

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

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

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 zona de disponibilidad 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 añadir 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 zona de disponibilidad (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.

• Registre las tres AZ asociadas al clúster original. Para obtener instrucciones, consulte Paso 1: comprobación de las zonas de disponibilidad del clúster original.

• Registre las dos o tres AZ asociadas a las subredes públicas en el grupo de subredes de base de datos del clúster original. Para obtener instrucciones, consulte Paso 3: comprobación de las subredes del clúster original.

• Cree subredes privadas que se asignen a las tres AZ asociadas al clúster original. Realice también cualquier otra configuración de red, como crear una puerta de enlace de NAT, para poder comunicarse con las subredes privadas. Para obtener instrucciones detalladas, consulte Crear una subred en la Guía del usuario de Amazon Virtual Private Cloud.

• Cree un nuevo grupo de subredes de base de datos que contenga tres o dos de las subredes privadas que están asociadas a las AZ desde el primer punto. Para obtener instrucciones, consulte Paso 2: creación del grupo de subredes de base de datos para el clon.

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.

• Registre las tres AZ asociadas al clúster original. Para obtener instrucciones, consulte Paso 1: comprobación de las zonas de disponibilidad del clúster original.

• Registre las tres o dos AZ asociadas a las subredes en el grupo de subredes de base de datos del clúster original. Para obtener instrucciones, consulte Paso 2: comprobación del grupo de subredes de base de datos del clúster original.

• Cree subredes que se asignen a las tres AZ asociadas al clúster original. Para obtener instrucciones, consulte Paso 1: creación de las subredes para el clon.

• Realice cualquier otra configuración de red, como configurar un grupo de seguridad de VPC, para los sistemas cliente, los servidores de aplicaciones, etc., para poder comunicarse con las instancias de base de datos del clon. Para obtener instrucciones, consulte Control de acceso con grupos de seguridad.

• Cree un nuevo grupo de subredes de base de datos que contenga tres o dos de las subredes que están asociadas a las AZ desde el primer punto. Para obtener instrucciones, consulte Paso 2: creación del grupo de subredes de base de datos para el clon.

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.

Clonación entre cuentas con AWS RAM y Amazon Aurora

Al usar AWS Resource Access Manager (AWS RAM) con Amazon Aurora, puede compartir clústeres de base de datos de Aurora y clones que pertenecen a su cuenta de AWS con otra cuenta de AWS u organización. La clonación entre cuentas es mucho más rápida en dichas situaciones que crear y restaurar una instantánea de base de datos. Puede crear un clon de uno de sus clústeres de base de datos de Aurora y compartir el clon. O puede compartir su clúster de base de datos de Aurora con otra cuenta de AWS y dejar que el titular de la cuenta cree el clon. El enfoque que elija depende de su caso de uso.

Por ejemplo, puede que necesite compartir regularmente un clon de su base de datos financiera con el equipo de auditoría interna de su organización. En este caso, su equipo de auditoría tiene su propia cuenta de AWS para las aplicaciones que utiliza. Puede darle permiso al equipo de auditoría de la cuenta de AWS para acceder a su clúster de base de datos de Aurora y clonarlo según sea necesario.

Por otro lado, si un proveedor externo audita sus datos financieros, es posible que prefiera crear el clon usted mismo. Luego, conceda al proveedor externo acceso solo al clon.

También puede utilizar la clonación entre cuentas para admitir muchos de los mismos casos de uso para la clonación dentro de la misma cuenta de AWS, como desarrollo y pruebas. Por ejemplo, su organización podría utilizar diferentes cuentas de AWS para la producción, el desarrollo, las pruebas, etc. Para obtener más información, consulte Información general de la clonación de Aurora.

Por lo tanto, podría ser necesario compartir un clon con otra cuenta de AWS o permitirle a otra cuenta de AWS crear clones de los clústeres de base de datos de Aurora. En cualquier caso, comience por usar AWS RAM para crear un objeto compartido. Para obtener información completa sobre cómo compartir recursos de AWS entre cuentas de AWS, consulte la guía del usuario de AWS RAM.

La creación de un clon entre cuentas requiere acciones de la cuenta de AWS propietaria del clúster original y la cuenta de AWS que crea el clon. En primer lugar, el propietario modifica el clúster para permitir que una o más cuentas lo clonen. Si alguna de las cuentas está en una organización de AWS diferente, AWS genera una invitación para compartir. La otra cuenta debe aceptar la invitación antes de continuar. A continuación, cada cuenta autorizada puede clonar el clúster. En todo este proceso, el clúster se identifica mediante su nombre de recurso de Amazon (ARN) único.

Al igual que con la clonación dentro de la misma cuenta de AWS, el espacio de almacenamiento adicional solo si el origen o el clon realizan cambios a los datos. Los cargos por almacenamiento se aplican entonces en ese momento. Si se borra el clúster de origen, los costes de almacenamiento se distribuyen por igual entre el resto de clústeres clonados.

Temas

• Limitaciones de la clonación entre cuentas
• Permitir a otras cuentas de AWS clonar su clúster
• Clonar un clúster que es propiedad de otra cuenta de AWS

Limitaciones de la clonación entre cuentas

La clonación entre cuentas de Aurora tiene las siguientes limitaciones:

• No puede clonar un clúster de Aurora Serverless v1 en cuentas de AWS.

• No puede ver ni aceptar invitaciones a recursos compartidos con la AWS Management Console. Utilice la AWS CLI, la API de Amazon RDS o la consola de AWS RAM para ver y aceptar invitaciones a recursos compartidos.

• Solo puede crear un clon nuevo desde un clon que se ha compartido con su cuenta de AWS.

• No puede compartir recursos (clones o clústeres de base de datos de Aurora) que se han compartido con su cuenta de AWS.

• Puede crear un máximo de 15 clones entre cuentas desde cualquier clúster de base de datos de Aurora.

• Cada uno de estos 15 clones de diferentes cuentas debe ser propiedad de una cuenta de AWS diferente. Es decir, solo puede crear un clon entre cuentas de un clúster dentro de cualquier cuenta de AWS.

• Después de clonar un clúster, se considera que el clúster original y su clon son los mismos a efectos de aplicar los límites de los clones entre cuentas. No se pueden crear clones entre cuentas tanto del clúster original como del clúster clonado dentro de la misma cuenta de AWS. El número total de clones entre cuentas para el clúster original y cualquiera de sus clones no puede superar los 15.

• No puede compartir un clúster de base de datos de Aurora con otras cuentas de AWS a menos que el clúster esté en un estado ACTIVE.

• No puede cambiar el nombre de un clúster de base de datos de Aurora que se ha compartido con otras cuentas de AWS.

• No puede crear un clon entre cuentas de un clúster que esté cifrado con la clave de RDS predeterminada.

• No puede crear clones no cifrados en una cuenta de AWS desde clústeres de base de datos de Aurora cifrados que han sido compartidos por otra cuenta de AWS. El propietario del clúster también debe concederle permiso para obtener acceso a la AWS KMS key del clúster fuente. Ahora bien, puede utilizar una clave distinta cuando cree el clon.

Permitir a otras cuentas de AWS clonar su clúster

Para permitir a otras cuentas de AWS clonar un clúster de su propiedad, utilice AWS RAM para establecer el permiso de uso compartido. Al hacerlo, también se envía una invitación a cada una de las otras cuentas que está en una organización de AWS diferente.

Para que los procedimientos compartan recursos de su propiedad en la consola de AWS RAM, consulte Compartir recursos de su propiedad en la guía del usuario de AWS RAM.

Temas

• Conceder permisos a otras cuentas de AWS para clonar su clúster
• Verificar si un clúster de su propiedad se comparte con otras cuentas de AWS

Conceder permisos a otras cuentas de AWS para clonar su clúster

Si el clúster que está compartiendo está cifrado, también se comparte la AWS KMS key del clúster. Puede permitir que los usuarios o roles de AWS Identity and Access Management (IAM) de una cuenta de AWS utilicen una clave de KMS en una cuenta diferente.

Para hacer esto, primero tiene que agregar la cuenta externa (usuario raíz) a la política de claves de KMS a través de AWS KMS. No se añaden los usuarios o roles individuales a la política de claves, solo la cuenta externa que los posee. Solo puede compartir una clave de KMS que cree, no la clave de servicio de RDS predeterminada. Para obtener más información sobre el control de acceso de las claves de KMS, consulte Autenticación y control de acceso de AWS KMS.

Consola

Para conceder permisos para clonar su clúster

1. Inicie sesión en la AWS Management Console y abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/.

2. En el panel de navegación, seleccione Databases (Bases de datos).

3. Elija el clúster de base de datos que quiera compartir para ver su página Details (Detalles) y elija la pestaña Connectivity & security (Conectividad y seguridad).

4. En la sección Share DB cluster with other accounts (Compartir clúster de base de datos con otras cuentas de AWS), ingrese el ID numérico de la cuenta para la cuenta de AWS que quiera permitir clonar este clúster. Para los ID de cuenta en la misma organización, puede comenzar a escribir en el cuadro y luego elegir en el menú.

   importante

   En algunos casos, es posible que desee una cuenta que no esté en la misma organización de AWS que su cuenta para clonar un clúster. En estos casos, por razones de seguridad la consola no notifica el propietario de ese ID de cuenta o si existe la cuenta.

   Tenga cuidado de introducir números de cuenta que no estén en la misma organización de AWS que su cuenta de AWS. Verifique inmediatamente que ha compartido con la cuenta pretendida.

5. En la página de confirmación, verifique que el ID de cuenta que ha especificado sea correcto. Introduzca share en el cuadro de confirmación para confirmar.

   En la página Details (Detalles), aparece una entrada que muestra el ID de cuenta de AWS especificado en Accounts that this DB cluster is shared with (Cuentas con las que se comparte este clúster de base de datos). La columna Status (Estado) inicialmente muestra el estado Pending (Pendiente).

6. Póngase en contacto con el propietario de la otra cuenta de AWS o inicie sesión en dicha cuenta si es propietario de ambas. Pida al propietario de la otra cuenta que acepte la invitación de uso compartido y clone el clúster de base de datos, como se describe a continuación.

AWS CLI

Para conceder permisos para clonar su clúster

1. Recopile la información de los parámetros requeridos. Necesita el ARN de su clúster y el ID numérico de la otra cuenta de AWS.

2. Ejecute el comando AWS RAM de la CLI create-resource-share.

   Para Linux, macOS o Unix:

   aws ram create-resource-share --name descriptive_name \
     --region region \
     --resource-arns cluster_arn \
     --principals other_account_ids
   

   En Windows:

   aws ram create-resource-share --name descriptive_name ^
     --region region ^
     --resource-arns cluster_arn ^
     --principals other_account_ids
   

   Para incluir varios ID de cuenta para el parámetro --principals, separe los ID entre sí con espacios. Para especificar si los ID de cuenta permitidos pueden estar fuera de la organización de AWS, incluya el parámetro --allow-external-principals o --no-allow-external-principals para create-resource-share.

AWS RAMAPI de

Para conceder permisos para clonar su clúster

1. Recopile la información de los parámetros requeridos. Necesita el ARN de su clúster y el ID numérico de la otra cuenta de AWS.

2. Llame a la operación CreateResourceShare de la API de AWS RAM y especifique los siguientes valores:

   • Especifique los ID de cuenta de una o más cuentas de AWS en el parámetro principals.

   • Especifique los ARN de uno o más clústeres de base de datos de Aurora en el parámetro resourceArns.

   • Especifique si los ID de cuenta permitidos pueden estar fuera de la organización de AWS o no, incluyendo un valor booleano para el parámetro allowExternalPrincipals.

Recreación de un clúster que utiliza la clave predeterminada de RDS

Si el clúster cifrado que desea compartir utiliza la clave predeterminada de RDS, asegúrese de volver a crear el clúster. Para ello, cree una instantánea manual del clúster de base de datos, utilice una AWS KMS key y, a continuación, restaure el clúster a un clúster nuevo. A continuación, comparta el nuevo clúster. Para ello, siga estos pasos:

Para volver a crear un clúster cifrado que utiliza la clave de RDS predeterminada

1. Inicie sesión en la AWS Management Console y abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/.

2. En el panel de navegación, elija Snapshots (Instantáneas).

3. Elija una instantánea.

4. En Actions (Acciones), elija Copy Snapshot (Copiar instantánea) y, a continuación, elija Enable encryption (Habilitar cifrado).

5. En AWS KMS key, elija la nueva clave de cifrado que desee utilizar.

6. Restaure la instantánea copiada. Para ello, siga el procedimiento en Restauración de una instantánea de clúster de base de datos. La nueva instancia de base de datos utiliza su clave de cifrado nueva.

7. (Opcional) Elimine el clúster de base de datos antiguo si ya no lo necesita más. Para ello, siga el procedimiento en Eliminación de una instantánea de clúster de base de datos. Antes de hacerlo, confirme que su nuevo clúster tiene todos los datos necesarios y que su aplicación puede acceder a ellos correctamente.

Verificar si un clúster de su propiedad se comparte con otras cuentas de AWS

Puede comprobar si otros usuarios tienen permiso para compartir un clúster. Hacerlo puede ayudarle a comprender si el clúster se acerca al límite del número máximo de clones entre cuentas.

Para que los procedimientos compartan recursos utilizando la consola de AWS RAM, consulte Compartir recursos de su propiedad en la guía del usuario de AWS RAM.

AWS CLI

Para descubrir si un clúster de su propiedad se comparte con otras cuentas de AWS

• Llame al comando list-principals de la CLI de AWS RAM mediante su ID de cuenta como el propietario del recurso y el ARN de su clúster como el ARN del recurso. Puede ver todas las unidades compartidas con el siguiente comando. Los resultados indican qué cuentas de AWS tienen permiso para clonar el clúster.

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

AWS RAMAPI de

Para descubrir si un clúster de su propiedad se comparte con otras cuentas de AWS

• Llame a la operación ListPrincipals de la API de AWS RAM. Utilice su ID de cuenta como el propietario del recurso y el ARN de su clúster como el ARN del recurso.

Clonar un clúster que es propiedad de otra cuenta de AWS

Para clonar un clúster propiedad de otra cuenta de AWS, utilice AWS RAM para obtener permiso para crear un clon. Una vez que tenga el permiso requerido, utilice el procedimiento estándar para clonar un clúster de Aurora.

También puede comprobar si un clúster de su propiedad es un clon de un clúster propiedad de una cuenta de AWS diferente.

Para que funcionen los procedimientos con recursos que son propiedad de otros en la consola de AWS RAM, consulte Acceso a los recursos compartidos con usted en la guía del usuario de AWS RAM.

Temas

• Visualización de invitaciones para clonar clústeres propiedad de otras cuentas de AWS
• Aceptación de invitaciones para compartir clústeres propiedad de otras cuentas de AWS
• Clonar un clúster de Aurora que es propiedad de otra cuenta de AWS
• Comprobar si un clúster de base de datos es un clon entre cuentas

Visualización de invitaciones para clonar clústeres propiedad de otras cuentas de AWS

Para trabajar con invitaciones para clonar clústeres propiedad de cuentas de AWS en otras organizaciones de AWS, utilice la AWS CLI, la consola de AWS RAM o la API de AWS RAM. Actualmente, no puede realizar este procedimiento utilizando la consola de Amazon RDS.

Para que funcionen los procedimientos con invitaciones en la consola de AWS RAM, consulte Acceso a los recursos compartidos con usted en la guía del usuario de AWS RAM.

AWS CLI

Para ver invitaciones para clonar clústeres propiedad de otras cuentas de AWS

1. Ejecute el comando AWS RAM de la CLI get-resource-share-invitations.

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

   Los resultados del comando anterior muestran todas las invitaciones para clonar clústeres, incluidas las que ya haya aceptado o rechazado.

2. (Opcional) Filtre la lista de forma que vea solo las invitaciones que requieren una acción por su parte. Para hacerlo, añada el parámetro --query 'resourceShareInvitations[?status==`PENDING`]'.

AWS RAMAPI de

Para ver invitaciones para clonar clústeres propiedad de otras cuentas de AWS

1. Llame a la operación GetResourceShareInvitations de la API de AWS RAM. Esta operación devuelve estas invitaciones, incluidas las que ya haya aceptado o rechazado.

2. (Opcional) Busque solo invitaciones que requieran de una acción por su parte comprobando que el campo de devolución resourceShareAssociations tenga un valor de status de PENDING.

Aceptación de invitaciones para compartir clústeres propiedad de otras cuentas de AWS

Puede aceptar invitaciones para compartir clústeres propiedad de otras cuentas de AWS que estén en diferentes organizaciones de AWS. Para trabajar con estas invitaciones, utilice la AWS CLI, las API de AWS RAM y RDS o la consola de AWS RAM. Actualmente, no puede realizar este procedimiento utilizando la consola de RDS.

Para que funcionen los procedimientos con invitaciones en la consola de AWS RAM, consulte Acceso a los recursos compartidos con usted en la guía del usuario de AWS RAM.

AWS CLI

Para aceptar una invitación para compartir un clúster desde otra cuenta de AWS

1. Busque el ARN de la invitación ejecutando el comando get-resource-share-invitations de la CLI de AWS RAM, como se ha mostrado anteriormente.

2. Acepte la invitación llamando al comando accept-resource-share-invitation de la CLI de AWS RAM, como se muestra a continuación.

   Para Linux, macOS o Unix:

   aws ram accept-resource-share-invitation \
     --resource-share-invitation-arn invitation_arn \
     --region region
   

   En Windows:

   aws ram accept-resource-share-invitation ^
     --resource-share-invitation-arn invitation_arn ^
     --region region
   

AWS RAM y API de RDS

Para aceptar invitaciones para compartir el clúster de alguien

1. Busque el ARN de la invitación llamando a la operación GetResourceShareInvitations de la API AWS RAM, como se ha mostrado anteriormente.

2. Pase ese ARN como el parámetro resourceShareInvitationArn a la operación AcceptResourceShareInvitation de la API de RDS.

Clonar un clúster de Aurora que es propiedad de otra cuenta de AWS

Después de aceptar la invitación de otra cuenta de AWS propiedad del clúster de base de datos, como se ha mostrado anteriormente, puede clonar el clúster.

Consola

Para clonar un clúster de Aurora que es propiedad de otra cuenta de AWS

1. Inicie sesión en la AWS Management Console y abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/.

2. En el panel de navegación, seleccione Databases (Bases de datos).

   En la parte superior de la lista de bases de datos, debe ver uno o más elementos con un valor de Role (Role) de Shared from account #account_id. Por razones de seguridad, solo puede ver información limitada sobre los clústeres originales. Las propiedades que puede ver son las de motor de base de datos y versión que deben ser las mismas en su clúster clonado.

3. Elija el clúster que pretende clonar.

4. En Actions (Acciones), elija Create alias (Crear alias).

5. Siga el procedimiento de Consola para finalizar la configuración del clúster clonado.

6. Según sea necesario, habilite el cifrado del clúster clonado. Si el clúster que esté clonando está cifrado, debe habilitar el cifrado del clúster clonado. La cuenta de AWS que compartió el clúster con usted también debe compartir la clave de KMS que se utilizó para cifrar el clúster. Puede utilizar la misma clave de KMS para cifrar el clon, o bien puede utilizar su propia clave de KMS. No puede crear un clon entre cuentas para un clúster que esté cifrado con la clave de KMS predeterminada.

   La cuenta que posee la clave de cifrado debe conceder permiso a la cuenta de destino para utilizar la clave mediante una política de claves. Este proceso es similar al utilizado para compartir las instantáneas cifradas, utilizando una política de claves que otorga permiso a la cuenta de destino para utilizar la clave.

AWS CLI

Para clonar un clúster de Aurora que es propiedad de otra cuenta de AWS

1. Acepte la invitación de otra cuenta de AWS propiedad del clúster de base de datos, como se ha mostrado anteriormente.

2. Clone el clúster especificando el ARN completo del clúster de origen en el parámetro source-db-cluster-identifier del comando restore-db-cluster-to-point-in-time de la CLI de RDS, como se muestra a continuación.

   Si el ARN pasado como el source-db-cluster-identifier no se ha compartido, se devuelve el mismo error que si no existiera el clúster especificado.

   Para Linux, macOS o Unix:

   aws rds restore-db-cluster-to-point-in-time \
     --source-db-cluster-identifier=arn:aws:rds:arn_details \
     --db-cluster-identifier=new_cluster_id \
     --restore-type=copy-on-write \
     --use-latest-restorable-time
   

   En Windows:

   aws rds restore-db-cluster-to-point-in-time ^
     --source-db-cluster-identifier=arn:aws:rds:arn_details ^
     --db-cluster-identifier=new_cluster_id ^
     --restore-type=copy-on-write ^
     --use-latest-restorable-time
   

3. Si el clúster que está clonando está cifrado, cifre su clúster clonado incluyendo un parámetro kms-key-id. Este valor kms-key-id puede ser el mismo que el utilizado para cifrar el clúster de base de datos original o su propia clave de KMS. Su cuenta debe tener permiso para utilizar dicha clave de cifrado.

   Para Linux, macOS o Unix:

   aws rds restore-db-cluster-to-point-in-time \
     --source-db-cluster-identifier=arn:aws:rds:arn_details \
     --db-cluster-identifier=new_cluster_id \
     --restore-type=copy-on-write \
     --use-latest-restorable-time \
     --kms-key-id=arn:aws:kms:arn_details
   

   En Windows:

   aws rds restore-db-cluster-to-point-in-time ^
     --source-db-cluster-identifier=arn:aws:rds:arn_details ^
     --db-cluster-identifier=new_cluster_id ^
     --restore-type=copy-on-write ^
     --use-latest-restorable-time ^
     --kms-key-id=arn:aws:kms:arn_details
   

   La cuenta que posee la clave de cifrado debe conceder permiso a la cuenta de destino para utilizar la clave mediante una política de claves. Este proceso es similar al utilizado para compartir las instantáneas cifradas, utilizando una política de claves que otorga permiso a la cuenta de destino para utilizar la clave. A continuación se incluye una política de claves.

   {
     "Id": "key-policy-1",
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "Allow use of the key",
         "Effect": "Allow",
         "Principal": {"AWS": [
           "arn:aws:iam::account_id:user/KeyUser",
           "arn:aws:iam::account_id:root"
         ]},
         "Action": [
           "kms:CreateGrant",
           "kms:Encrypt",
           "kms:Decrypt",
           "kms:ReEncrypt*",
           "kms:GenerateDataKey*",
           "kms:DescribeKey"
         ],
         "Resource": "*"
       },
       {
         "Sid": "Allow attachment of persistent resources",
         "Effect": "Allow",
         "Principal": {"AWS": [
           "arn:aws:iam::account_id:user/KeyUser",
           "arn:aws:iam::account_id:root"
         ]},
         "Action": [
           "kms:CreateGrant",
           "kms:ListGrants",
           "kms:RevokeGrant"
         ],
         "Resource": "*",
         "Condition": {"Bool": {"kms:GrantIsForAWSResource": true}}
       }
     ]
   }
   

nota

El comando restore-db-cluster-to-point-in-time de la CLI de AWS solo restaura el clúster de base de datos, no las instancias de base de datos de dicho clúster. Para crear instancias de base de datos para el clúster de base de datos restaurado, invoque el comando create-db-instance. Especifique el identificador del clúster de base de datos restaurado en --db-cluster-identifier.

Solo puede crear instancias de base de datos después de que se haya completado el comando restore-db-cluster-to-point-in-time y de que el clúster de base de datos esté disponible.

API de RDS

Para clonar un clúster de Aurora que es propiedad de otra cuenta de AWS

1. Acepte la invitación de otra cuenta de AWS propiedad del clúster de base de datos, como se ha mostrado anteriormente.

2. Clone el clúster especificando el ARN completo del clúster de origen en el parámetro SourceDBClusterIdentifier de la operación RestoreDBClusterToPointInTime de la API de RDS.

   Si el ARN pasado como el SourceDBClusterIdentifier no se ha compartido, se devuelve el mismo error que se el clúster especificado no exista.

3. Si el clúster que está clonando está cifrado, incluya un parámetro KmsKeyId para cifrar el clúster clonado. Este valor kms-key-id puede ser el mismo que el utilizado para cifrar el clúster de base de datos original o su propia clave de KMS. Su cuenta debe tener permiso para utilizar dicha clave de cifrado.

   Al clonar un volumen, la cuenta de destino debe tener permiso para utilizar la clave de cifrado utilizada para cifrar el clúster de origen. Aurora cifra el nuevo clúster clonado con la clave de cifrado especificada en KmsKeyId.

   La cuenta que posee la clave de cifrado debe conceder permiso a la cuenta de destino para utilizar la clave mediante una política de claves. Este proceso es similar al utilizado para compartir las instantáneas cifradas, utilizando una política de claves que otorga permiso a la cuenta de destino para utilizar la clave. A continuación se incluye una política de claves.

   {
     "Id": "key-policy-1",
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "Allow use of the key",
         "Effect": "Allow",
         "Principal": {"AWS": [
           "arn:aws:iam::account_id:user/KeyUser",
           "arn:aws:iam::account_id:root"
         ]},
         "Action": [
           "kms:CreateGrant",
           "kms:Encrypt",
           "kms:Decrypt",
           "kms:ReEncrypt*",
           "kms:GenerateDataKey*",
           "kms:DescribeKey"
         ],
         "Resource": "*"
       },
       {
         "Sid": "Allow attachment of persistent resources",
         "Effect": "Allow",
         "Principal": {"AWS": [
           "arn:aws:iam::account_id:user/KeyUser",
           "arn:aws:iam::account_id:root"
         ]},
         "Action": [
           "kms:CreateGrant",
           "kms:ListGrants",
           "kms:RevokeGrant"
         ],
         "Resource": "*",
         "Condition": {"Bool": {"kms:GrantIsForAWSResource": true}}
       }
     ]
   }
   

nota

La operación RestoreDBClusterToPointInTime de la API de RDS solo restaura el clúster de base de datos, no las instancias de base de datos de dicho clúster. Para crear instancias de base de datos para el clúster de base de datos restaurado, invoque la operación CreateDBInstance de la API de RDS. Especifique el identificador del clúster de base de datos restaurado en DBClusterIdentifier. Solo puede crear instancias de base de datos después de que se haya completado la operación RestoreDBClusterToPointInTime y el clúster de base de datos esté disponible.

Comprobar si un clúster de base de datos es un clon entre cuentas

El objeto DBClusters identifica si cada clúster es un clon entre cuentas. Puede ver los clústeres que tienen permiso para clonar utilizando el la opción include-shared cuando ejecute el comando describe-db-clusters de la CLI de RDS. Sin embargo, no puede ver la mayoría de los detalles de configuración de dichos clústeres.

AWS CLI

Verificar si un clúster de base de datos es un clon entre cuentas

• Llame al comando de CLI de RDS describe-db-clusters.

  El siguiente ejemplo muestra cómo los clústeres de base de datos de clonación entre cuentas reales o potenciales aparece en la salida de describe-db-clusters. Para clústeres existentes propiedad de su cuenta de AWS, el campo CrossAccountClone indica si el clúster es un clon de un clúster de base de datos propiedad de otra cuenta de AWS.

  En algunos casos, una entrada podría tener un número de cuenta de AWS diferente al suyo en el campo DBClusterArn. En este caso, dicha entrada representa un clúster propiedad de una cuenta de AWS diferente y que se puede clonar. Dichas entradas tienen pocos cambios aparte de DBClusterArn. Al crear el clúster clonado, especifique los mismos valores de StorageEncrypted, Engine y EngineVersion que el clúster original.

  $aws rds describe-db-clusters --include-shared --region us-east-1
  {
    "DBClusters": [
        {
            "EarliestRestorableTime": "2023-02-01T21:17:54.106Z",
            "Engine": "aurora-mysql",
            "EngineVersion": "8.0.mysql_aurora.3.02.0",
            "CrossAccountClone": false,
  ...
        },
        {
            "EarliestRestorableTime": "2023-02-09T16:01:07.398Z",
            "Engine": "aurora-mysql",
            "EngineVersion": "8.0.mysql_aurora.3.02.0",
            "CrossAccountClone": true,
  ...
        },
        {
            "StorageEncrypted": false,
            "DBClusterArn": "arn:aws:rds:us-east-1:12345678:cluster:cluster-abcdefgh",
            "Engine": "aurora-mysql",
            "EngineVersion": "8.0.mysql_aurora.3.02.0
    ]
  }
  

API de RDS

Verificar si un clúster de base de datos es un clon entre cuentas

• Llame a la operación DescribeDBClusters de la API de RDS.

  Para clústeres existentes propiedad de su cuenta de AWS, el campo CrossAccountClone indica si el clúster es un clon de un clúster de base de datos propiedad de otra cuenta de AWS. Las entradas con un número de cuenta de AWS diferente en el campo DBClusterArn representan clústeres que puede clonar y que son propiedad de otras cuentas de AWS. Estas entradas tienen pocos cambios aparte de DBClusterArn. Al crear el clúster clonado, especifique los mismos valores de StorageEncrypted, Engine y EngineVersion que el clúster original.

  El siguiente ejemplo muestra un valor de devolución que demuestra los clústeres clonados tanto reales como potenciales.

  {
    "DBClusters": [
        {
            "EarliestRestorableTime": "2023-02-01T21:17:54.106Z",
            "Engine": "aurora-mysql",
            "EngineVersion": "8.0.mysql_aurora.3.02.0",
            "CrossAccountClone": false,
  ...
        },
        {
            "EarliestRestorableTime": "2023-02-09T16:01:07.398Z",
            "Engine": "aurora-mysql",
            "EngineVersion": "8.0.mysql_aurora.3.02.0",
            "CrossAccountClone": true,
  ...
        },
        {
            "StorageEncrypted": false,
            "DBClusterArn": "arn:aws:rds:us-east-1:12345678:cluster:cluster-abcdefgh",
            "Engine": "aurora-mysql",
            "EngineVersion": "8.0.mysql_aurora.3.02.0"
        }
    ]
  }