Clonagem entre VPCs com o Amazon Aurora

Suponha que você queira impor diferentes controles de acesso à rede no cluster original e no clone. Por exemplo, é possível usar a clonagem para fazer uma cópia de um cluster do Aurora de produção em uma VPC diferente para desenvolvimento e testes. Ou você pode criar um clone como parte de uma migração de sub-redes públicas para privadas a fim de melhorar a segurança do banco de dados.

As seções a seguir demonstram como definir a configuração de rede do clone para que o cluster original e o clone possam acessar os mesmos nós de armazenamento do Aurora, mesmo de sub-redes ou VPCs diferentes. A verificação prévia de recursos da rede pode evitar erros durante a clonagem que talvez sejam difíceis de diagnosticar.

Se você não souber como o Aurora interage com VPCs, sub-redes e grupos de sub-redes de banco de dados, consulte Amazon VPC e Amazon Aurora primeiro. Você pode seguir os tutoriais dessa seção para criar esses tipos de recurso no console da AWS e entender como eles se encaixam.

Como as etapas exigem a alternância entre os serviços RDS e EC2, os exemplos usam comandos da AWS CLI para ajudar a entender como automatizar essas operações e salvar o resultado.

Antes de começar

Antes de começar a configurar um clone entre VPCs, verifique se você tem os seguintes recursos:

Reunir informações sobre o ambiente de rede

Com a clonagem entre VPCs, o ambiente de rede pode diferir substancialmente entre o cluster original e o clone. Antes de criar o clone, colete e registre informações sobre a VPC, as sub-redes, o grupo de sub-redes de banco de dados e as AZs usadas no cluster original. Dessa forma, é possível minimizar a possibilidade de problemas. Se ocorrer um problema de rede, você não precisará interromper nenhuma atividade de solução de problemas para pesquisar informações de diagnóstico. As seções a seguir mostram exemplos da CLI para coletar esses tipos de informação. É possível salvar os detalhes em qualquer formato conveniente para consulta ao criar o clone e solucionar qualquer problema.

Etapa 1: verificar as zonas de disponibilidade do cluster original

Antes de criar o clone, verifique quais AZs o cluster original usa para armazenamento. Conforme explicado em Armazenamento do Amazon Aurora, o armazenamento de cada cluster do Aurora está associado a exatamente três AZs. Como o Clusters de banco de dados do Amazon Aurora aproveita a separação entre computação e armazenamento, essa regra se aplica independentemente de quantas instâncias estão no cluster.

Por exemplo, execute um comando da CLI como o indicado a seguir, substituindo o nome do seu cluster por my_cluster. O exemplo a seguir produz uma lista classificada alfabeticamente pelo nome da AZ.

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

O exemplo a seguir mostra a saída de amostra do comando describe-db-clusters anterior. Isso demonstra que o armazenamento do cluster do Aurora sempre usa três AZs.

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

Para criar um clone em um ambiente de rede que não tenha todos os recursos disponíveis para estabelecer conexão com essas AZs, é necessário criar sub-redes associadas a pelo menos duas dessas AZs e, depois, criar um grupo de sub-redes de banco de dados contendo essas duas ou três sub-redes. Os exemplos a seguir mostram o procedimento.

Etapa 2: verificar o grupo de sub-redes de banco de dados do cluster original

Se você quiser usar o mesmo número de sub-redes do cluster original para o clone, identifique o número de sub-redes do grupo de sub-redes de banco de dados do cluster original. Um grupo de sub-redes de banco de dados do Aurora contém pelo menos duas sub-redes, cada uma associada a uma AZ diferente. Anote a quais AZs as sub-redes estão associadas.

O exemplo a seguir mostra como encontrar o grupo de sub-redes de banco de dados do cluster original e, depois, voltar para as AZs correspondentes. Substitua o nome do cluster por my_cluster no primeiro comando. Substitua o nome do grupo de sub-redes de banco de dados por my_subnet no 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

O exemplo de saída para um cluster com um grupo de sub-redes de banco de dados contendo duas sub-redes pode ser semelhante ao indicado a seguir. Nesse caso, two-subnets é um nome que foi especificado ao criar o grupo de sub-redes de banco de dados.

two-subnets

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

Com relação a um cluster em que o grupo de sub-redes de banco de dados contém três sub-redes, a saída pode ser semelhante à indicada a seguir.

three-subnets

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

Etapa 3: verificar as sub-redes do cluster original

Se você precisar de mais detalhes sobre as sub-redes no cluster original, execute comandos da AWS CLI semelhantes aos indicados a seguir. É possível examinar os atributos da sub-rede, como intervalos de endereços IP, proprietário e assim por diante. Dessa forma, você pode determinar se deve usar sub-redes diferentes na mesma VPC ou criar sub-redes com características semelhantes em uma VPC diferente.

Encontre os IDs de todas as sub-redes que estão disponíveis na VPC.

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

Encontre as sub-redes exatas usadas no grupo de sub-redes de banco de dados.

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

Depois, especifique as sub-redes que você deseja investigar em uma lista, como no comando a seguir. Substitua os nomes das sub-redes por my_subnet_1 e assim por diante.

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

O exemplo a seguir mostra a saída parcial desse comando describe-subnets. A saída mostra alguns dos atributos importantes que você pode ver em cada sub-rede, como a AZ associada e a VPC da qual ela faz 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',
            ...

Etapa 4: verificar as zonas de disponibilidade das instâncias de banco de dados no cluster original

É possível usar esse procedimento para entender as AZs usadas com as instâncias de banco de dados no cluster original. Dessa forma, você pode configurar exatamente as mesmas AZs para as instâncias de banco de dados no clone. Também é possível usar mais ou menos instâncias de banco de dados no clone, dependendo se ele é usado para produção, desenvolvimento e testes etc.

Para cada instância no cluster original, execute um comando como o indicado a seguir. Primeiro verifique se a criação da instância já foi concluída e ela está no estado Available. Substitua o identificador da instância por my_instance.

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

O exemplo a seguir mostra a saída da execução do comando describe-db-instances anterior. O cluster do Aurora tem quatro instâncias de banco de dados. Portanto, executamos o comando quatro vezes, substituindo um identificador de instância de banco de dados diferente a cada vez. O resultado mostra como essas instâncias de banco de dados estão distribuídas em no máximo três AZs.

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

Depois que o clone é criado e você adiciona instâncias de banco de dados a ele, é possível especificar esses mesmos nomes de AZ nos comandos create-db-instance. Isso pode ser feito para configurar instâncias de banco de dados no novo cluster configurado exatamente para as mesmas AZs do cluster original.

Etapa 5: verificar as VPCs que você pode usar para o clone

Se pretende criar o clone em uma VPC diferente da original, é possível obter uma lista de IDs de VPC disponíveis para a conta. Você também pode executar essa etapa se precisar criar outras sub-redes na mesma VPC do cluster original. Ao executar o comando para criar uma sub-rede, você especifica o ID da VPC como parâmetro.

Para listar todas as VPCs da sua conta, execute este comando da CLI:

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

O exemplo a seguir mostra a saída de amostra do comando describe-vpcs anterior. O resultado demonstra que há quatro VPCs na conta da AWS atual que podem ser usadas como origem ou destino para clonagem entre VPCs.

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

É possível usar a mesma VPC como destino para o clone ou uma VPC diferente. Se o cluster original e o clone estiverem na mesma VPC, você poderá reutilizar o mesmo grupo de sub-redes de banco de dados para o clone. Também é possível criar um grupo de sub-redes de banco de dados. Por exemplo, o novo grupo de sub-redes de banco de dados pode usar sub-redes privadas, enquanto o grupo de sub-redes de banco de dados do cluster original pode usar sub-redes públicas. Se você criar o clone em uma VPC diferente, verifique se há sub-redes suficientes na nova VPC e se elas estão associadas às AZs corretas do cluster original.

Criar recursos de rede para o clone

Se, ao coletar as informações da rede, você descobrir que são necessários recursos de rede adicionais para o clone, crie-os antes de tentar configurar o clone. Por exemplo, talvez seja necessário criar mais sub-redes, sub-redes associadas a AZs específicas ou um grupo de sub-redes de banco de dados.

Etapa 1: criar sub-redes para o clone

Se você precisar criar sub-redes para o clone, execute um comando semelhante ao apresentado a seguir. Talvez seja necessário fazer isso ao criar o clone em uma VPC diferente ou ao fazer alguma outra alteração na rede, como usar sub-redes privadas em vez de públicas.

A AWS gera automaticamente o ID da sub-rede. Substitua o nome da VPC do clone por my_vpc. Escolha o intervalo de endereços para a opção --cidr-block a fim de permitir pelo menos 16 endereços IP no intervalo. É possível incluir qualquer outra propriedade que você queira especificar. Execute o comando aws ec2 create-subnet help para ver todas as opções.

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

O exemplo a seguir mostra alguns atributos importantes de uma sub-rede recém-criada.

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

Etapa 2: criar o grupo de sub-redes de banco de dados para o clone

Se você estiver criando o clone em uma VPC diferente ou em um conjunto distinto de sub-redes na mesma VPC, crie um grupo de sub-redes de banco de dados e o especifique ao criar o clone.

Verifique se você conhece todos os detalhes a seguir. É possível encontrar tudo isso na saída dos exemplos anteriores.

Verifique quantas AZs estão associadas ao armazenamento do cluster original e às sub-redes na VPC de destino. Para conseguir criar o clone, deve haver duas ou três AZs em comum. Se você tiver menos de duas AZs em comum, volte para Etapa 1: criar sub-redes para o clone. Crie uma, duas ou três sub-redes associadas às AZs correspondentes ao armazenamento do cluster original.

Escolha sub-redes na VPC de destino que estejam associadas às mesmas AZs do armazenamento do Aurora no cluster original. O ideal é escolher três AZs. Essa é opção que oferece o mais alto nível de flexibilidade para distribuir as instâncias de banco de dados do clone em várias AZs e ter alta disponibilidade de recursos de computação.

Execute um comando semelhante ao indicado a seguir para criar o grupo de sub-redes de banco de dados. Substitua os IDs das sub-redes na lista. Se você especificar os IDs de sub-rede usando variáveis de ambiente, tenha o cuidado de citar a lista de parâmetros --subnet-ids de uma forma que mantenha as aspas duplas ao redor dos IDs.

aws rds create-db-subnet-group --db-subnet-group-name my_subnet_group \
  --subnet-ids '["my_subnet_1","my_subnet_2","my_subnet3"]' \
  --db-subnet-group-description 'DB subnet group with 3 subnets for clone'

O exemplo a seguir mostra a saída parcial do 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'
        ]
    }
}

Nesse momento, o clone ainda não foi criado. Você criou todos os recursos relevantes de VPC e sub-rede para poder especificar os parâmetros apropriados para os comandos restore-db-cluster-to-point-in-time e create-db-instance ao criar o clone.

Criar um clone do Aurora com novas configurações de rede

Depois de verificar se a configuração correta de VPCs, sub-redes, AZs e grupos de sub-redes está disponível para o novo cluster usar, você pode realizar a operação de clonagem. Os exemplos de CLI a seguir destacam as opções que você especifica nos comandos, como --db-subnet-group-name, --availability-zone e --vpc-security-group-ids, para configurar o clone e as respectivas instâncias de banco de dados.

Etapa 1: especificar o grupo de sub-redes de banco de dados para o clone

Ao criar o clone, é possível definir todas as configurações corretas de VPC, sub-rede e AZ especificando um grupo de sub-redes de banco de dados. Use os comandos nos exemplos anteriores para verificar todas as relações e associações que entram no grupo de sub-redes do banco de dados.

Por exemplo, os comandos a seguir demonstram a clonagem de um cluster original em um clone. No primeiro exemplo, o cluster de origem está associado a duas sub-redes e o clone a três. O segundo exemplo mostra o caso oposto, a clonagem de um cluster com três sub-redes para um cluster com duas.

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

Se você pretende usar instâncias do Aurora Sem Servidor v2 no clone, inclua uma opção --serverless-v2-scaling-configuration ao criar o clone, conforme mostrado. Isso permite que você use a classe db.serverless ao criar instâncias de banco de dados no clone. Você também pode modificar o clone posteriormente para adicionar esse atributo de configuração de escalabilidade. Os números de capacidade nesse exemplo permitem que cada instância do Aurora Sem Servidor v2 no cluster escale entre 2 e 32 unidades de capacidade do Aurora (ACUs). Consulte informações sobre o recurso Aurora Sem Servidor v2 e como escolher o intervalo de capacidade em Usar o 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'

Independentemente do número de sub-redes usadas pelas instâncias de banco de dados, o armazenamento do Aurora para o cluster de origem e o clone está associado a três AZs. O exemplo a seguir lista as AZs associadas ao cluster original e ao clone, para ambos os comandos restore-db-cluster-to-point-in-time nos exemplos 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 pelo menos duas das AZs se sobrepõem entre cada par de clusters originais e clones, os dois clusters podem acessar o mesmo armazenamento subjacente do Aurora.

Etapa 2: especificar as configurações de rede para instâncias no clone

Quando você cria instâncias de banco de dados no clone, elas herdam o grupo de sub-redes de banco de dados do próprio cluster por padrão. Dessa forma, o Aurora atribui automaticamente cada instância a uma sub-rede específica e a cria na AZ associada à sub-rede. Essa opção é conveniente, especialmente para sistemas de desenvolvimento e teste, porque você não precisa monitorar os IDs de sub-rede ou as AZs ao adicionar novas instâncias ao clone.

Também é possível especificar a AZ ao criar uma instância de banco de dados Aurora para o clone. A AZ que você especifica deve ser do conjunto de AZs associadas ao clone. Se o grupo de sub-redes de banco de dados que você usa para o clone tiver apenas duas sub-redes, só será possível escolher entre as AZs associadas a essas duas sub-redes. Essa opção oferece flexibilidade e resiliência para sistemas altamente disponíveis, porque é possível garantir que a instância de gravador e a instância de leitor em espera estejam em AZs diferentes. Ou, se você adicionar mais leitores ao cluster, poderá garantir que eles estejam distribuídos em três AZs. Dessa forma, mesmo no caso raro de uma falha de AZ, você ainda tem uma instância de gravador e outra instância de leitor em duas outras AZs.

O exemplo a seguir adiciona uma instância de banco de dados provisionada a um cluster clonado do Aurora PostgreSQL que usa um grupo de sub-redes de banco de dados 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

O exemplo a seguir mostra a saída parcial desse comando.

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

O exemplo a seguir adiciona uma instância de banco de dados do Aurora Sem Servidor v2 a um clone do Aurora MySQL que usa um grupo de sub-redes de banco de dados personalizado. Para poder usar instâncias do Aurora Sem Servidor v2, especifique a opção --serverless-v2-scaling-configuration para o comando restore-db-cluster-to-point-in-time, conforme mostrado nos exemplos 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

O exemplo a seguir mostra a saída parcial desse comando.

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

Etapa 3: estabelecer a conectividade de um sistema cliente com um clone

Se você já estiver se conectando a um cluster do Aurora por um sistema cliente, talvez queira permitir o mesmo tipo de conectividade a um novo clone. Por exemplo, você pode se conectar ao cluster original por uma instância do Amazon Cloud9 ou do EC2. Para permitir conexões dos mesmos sistemas cliente ou de novos sistemas que você cria na VPC de destino, configure grupos de sub-rede de banco de dados e grupos de segurança de VPC equivalentes aos da VPC. Depois, especifique o grupo de sub-redes e grupos de segurança ao criar o clone.

Os exemplos a seguir configuram um clone do Aurora Sem Servidor v2. Essa configuração é baseada na combinação de --engine-mode provisioned e --serverless-v2-scaling-configuration ao criar o cluster de banco de dados e de --db-instance-class db.serverless ao criar cada instância de banco de dados no cluster. O modo provisioned do mecanismo é o padrão, então você poderá omitir essa opção se assim preferir.

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

Depois, ao criar as instâncias de banco de dados no clone, especifique a mesma opção --db-subnet-group-name. Se preferir, você poderá incluir a opção --availability-zone e especificar uma das AZs associadas às sub-redes nesse grupo de sub-redes. Essa AZ também deve ser uma das AZs associadas ao cluster 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

Mover um cluster de sub-redes públicas para privadas

É possível usar a clonagem para migrar um cluster entre sub-redes públicas e privadas. Você pode fazer isso ao adicionar outras camadas de segurança à aplicação antes de implantá-la na produção. Nesse exemplo, antes de iniciar o processo de clonagem com o Aurora, você já deve ter as sub-redes privadas e o gateway NAT configurados.

Com relação às etapas que envolvem o Aurora, siga as mesmas etapas gerais dos exemplos anteriores para Reunir informações sobre o ambiente de rede e Criar um clone do Aurora com novas configurações de rede. A principal diferença é que, mesmo que você tenha sub-redes públicas associadas a todas as AZs do cluster original, agora é necessário verificar se há sub-redes privadas suficientes para um cluster do Aurora e se elas estão associadas às mesmas AZs usadas para o armazenamento do Aurora no cluster original. De modo semelhante a outros casos de uso de clonagem, é possível criar o grupo de sub-redes de banco de dados para o clone com três ou duas sub-redes privadas associadas às AZs necessárias. No entanto, se você usar duas sub-redes privadas no grupo de sub-redes de banco de dados, deverá ter uma terceira sub-rede privada associada à terceira AZ usada para armazenamento do Aurora no cluster original.

É possível consultar nessa lista de verificação se todos os requisitos estão em vigor para realizar esse tipo de operação de clonagem.

Quando todos os pré-requisitos forem cumpridos, será possível pausar a atividade do banco de dados no cluster original enquanto você cria o clone e troca a aplicação para usá-lo. Depois que o clone for criado e você confirmar que consegue se conectar a ele, executar o código da aplicação e assim por diante, será possível interromper o uso do cluster original.

Exemplo completo da criação de um clone entre VPCs

A criação de um clone em uma VPC diferente da original usa as mesmas etapas gerais dos exemplos anteriores. Como o ID da VPC é uma propriedade das sub-redes, você não especifica o ID da VPC como um parâmetro ao executar qualquer um dos comandos da CLI do RDS. A principal diferença é que é mais provável que você precise criar sub-redes, sub-redes associadas a AZs específicas, um grupo de segurança de VPC e um grupo de sub-redes de banco de dados. Isso se aplica principalmente se esse for o primeiro cluster do Aurora que está sendo criado nessa VPC.

É possível consultar nessa lista de verificação se todos os requisitos estão em vigor para realizar esse tipo de operação de clonagem.

Quando todos os pré-requisitos forem cumpridos, será possível pausar a atividade do banco de dados no cluster original enquanto você cria o clone e troca a aplicação para usá-lo. Depois que o clone for criado e você confirmar que consegue se conectar a ele, executar o código da aplicação e assim por diante, considere se deseja manter o original e os clones em execução ou interromper o uso do cluster original.

Os exemplos do Linux a seguir mostram a sequência de operações da AWS CLI para clonar um cluster de banco de dados do Aurora de uma VPC para outra. Alguns campos que não são relevantes para os exemplos não são mostrados na saída do comando.

Primeiro, verificamos os IDs das VPCs de origem e destino. O nome descritivo que você atribui a uma VPC ao criá-la é representado como uma tag nos metadados da VPC.

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

O cluster original já existe na VPC de origem. Para configurar o clone usando o mesmo conjunto de AZs para o armazenamento do Aurora, selecionamos as AZs usadas pelo cluster 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

Garantimos que haja sub-redes que correspondam às AZs usadas pelo cluster original: us-east-1c, us-east-1d e us-east-1f.

$ aws ec2 create-subnet --vpc-id vpc-9e99d9f99a999bd99 \
  --availability-zone us-east-1c --cidr-block 10.0.0.128/28
{
    'Subnet': {
        'AvailabilityZone': 'us-east-1c',
        'SubnetId': 'subnet-3333a33be3ef3e333',
        'VpcId': 'vpc-9e99d9f99a999bd99',
    }
}

$ aws ec2 create-subnet --vpc-id vpc-9e99d9f99a999bd99 \
--availability-zone us-east-1d --cidr-block 10.0.0.160/28
{
    'Subnet': {
        'AvailabilityZone': 'us-east-1d',
        'SubnetId': 'subnet-4eeb444cd44b4d444',
        'VpcId': 'vpc-9e99d9f99a999bd99',
    }
}

$ aws ec2 create-subnet --vpc-id vpc-9e99d9f99a999bd99 \
--availability-zone us-east-1f --cidr-block 10.0.0.224/28
{
    'Subnet': {
        'AvailabilityZone': 'us-east-1f',
        'SubnetId': 'subnet-66eea6666fb66d66c',
        'VpcId': 'vpc-9e99d9f99a999bd99',
    }
}

Este exemplo confirma que há sub-redes que correspondem às AZs necessárias na 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 criar um cluster de banco de dados do Aurora na VPC, você deve ter um grupo de sub-redes de banco de dados com sub-redes que correspondam às AZs usadas para armazenamento do Aurora. Ao criar um cluster normal, você pode usar qualquer conjunto de três AZs. Quando você clona um cluster existente, o grupo de sub-redes deve corresponder a pelo menos duas das três AZs que ele usa para armazenamento do 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' }
            }
        ]
    }
}

Agora as sub-redes e o grupo de sub-redes de banco de dados estão prontos. O exemplo a seguir mostra o restore-db-cluster-to-point-in-time que clona o cluster. A opção --db-subnet-group-name associa o clone ao conjunto correto de sub-redes que correspondem ao conjunto correto de AZs do cluster 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'
}

O exemplo a seguir confirma que o armazenamento do Aurora no clone usa o mesmo conjunto de AZs do cluster 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

Neste ponto, você poderá criar instâncias de banco de dados para o clone. O grupo de segurança da VPC associado a cada instância deve permitir conexões dos intervalos de endereços IP que você usa para as instâncias do EC2, os servidores de aplicações e assim por diante que estão na VPC de destino.