시작하기 전 준비 사항 네트워크 환경에 대한 정보 수집 복제본을 위한 네트워크 리소스 생성 새 네트워크 설정으로 Aurora 복제본 생성 퍼블릭 서브넷에서 프라이빗 서브넷으로 클러스터 이동 VPC 간 복제본 생성의 엔드 투 엔드 예제

Amazon Aurora를 사용한 VPC 간 복제

원본 클러스터와 복제본에 서로 다른 네트워크 액세스 제어를 적용하고 싶다고 가정해 보겠습니다. 예를 들어 복제를 사용하여 개발 및 테스트를 위해 다른 VPC에 프로덕션 Aurora 클러스터의 복사본을 만들 수 있습니다. 또는 데이터베이스 보안을 강화하기 위해 퍼블릭 서브넷에서 프라이빗 서브넷으로의 마이그레이션의 일부로 복제본을 만들 수도 있습니다.

다음 섹션에서는 원본 클러스터와 복제본이 서로 다른 서브넷이나 다른 VPC에서도 동일한 Aurora 스토리지 노드에 액세스할 수 있도록 복제본의 네트워크 구성을 설정하는 방법을 설명합니다. 네트워크 리소스를 미리 확인하면 복제 중 진단하기 어려운 오류를 방지할 수 있습니다.

Aurora가 VPC, 서브넷 및 DB 서브넷 그룹과 상호 작용하는 방식에 익숙하지 않은 경우 먼저 Amazon VPC 및 Amazon Aurora 섹션을 참조하세요. 해당 섹션의 자습서를 통해 AWS에서 이러한 종류의 리소스를 생성하고 이러한 리소스가 서로 어떻게 결합되는지 이해할 수 있습니다.

이 단계에는 RDS와 EC2 서비스 간 전환이 포함되므로, 예제에서는 이러한 작업을 자동화하고 출력을 저장하는 방법을 이해하는 데 도움이 되도록 AWS CLI 명령을 사용합니다.

시작하기 전 준비 사항

VPC 간 복제 설정을 시작하기 전에 다음 리소스가 준비되어 있는지 확인하세요.

복제를 위한 소스로 사용할 Aurora DB 클러스터. Aurora DB 클러스터를 처음 만드는 경우, Amazon Aurora 시작하기의 자습서를 참조하여 MySQL 또는 PostgreSQL 데이터베이스 엔진을 사용하여 클러스터를 설정하세요.
VPC 간 복제본을 생성하려는 경우 두 번째 VPC. 복제본에 사용할 VPC가 없는 경우에는 자습서: DB 클러스터에 사용할 Amazon VPC 생성(IPv4 전용) 또는 자습서: DB 클러스터(듀얼 스택 모드)에 사용할 VPC 생성를 참조하세요.

네트워크 환경에 대한 정보 수집

VPC 간 복제를 사용하면 네트워크 환경이 원본 클러스터와 복제본 간에 크게 다를 수 있습니다. 복제본을 만들기 전에 원본 클러스터에서 사용된 VPC, 서브넷, DB 서브넷 그룹 및 AZ에 대한 정보를 수집하여 기록하세요. 이렇게 하면 문제 발생 가능성을 최소화할 수 있습니다. 네트워크 문제가 발생하는 경우 진단 정보를 검색하기 위해 문제 해결 활동을 중단할 필요가 없습니다. 다음 섹션에서는 이러한 유형의 정보를 수집하는 CLI 예제를 보여줍니다. 복제본을 만들고 문제 해결을 수행하는 동안 참조하기 편리한 형식으로 세부 정보를 저장할 수 있습니다.

1단계: 원본 클러스터의 가용 영역 확인
2단계: 원본 클러스터의 DB 서브넷 그룹 확인
3단계: 원본 클러스터의 서브넷 확인
4단계: 원본 클러스터에서 DB 인스턴스의 가용 영역 확인
5단계: 복제본에 사용할 수 있는 VPC 확인

1단계: 원본 클러스터의 가용 영역 확인

복제본을 생성하기 전에 원본 클러스터가 스토리지에 사용하는 AZ를 확인하세요. Amazon Aurora 스토리지에 설명된 대로, 각 Aurora 클러스터의 스토리지는 정확히 3개의 AZ와 연결되어 있습니다. Amazon Aurora DB 클러스터는 컴퓨팅과 스토리지의 분리를 활용하기 때문에 이 규칙은 클러스터에 있는 인스턴스 수에 관계없이 적용됩니다.

예를 들어, 다음과 같은 CLI 명령을 실행하여 my_cluster를 자신의 클러스터 이름으로 대체합니다. 다음 예제는 AZ 이름에 따라 알파벳순으로 정렬된 목록을 생성합니다.


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

다음 예제는 앞의 describe-db-clusters 명령의 샘플 출력을 보여줍니다. 이 그림은 Aurora 클러스터의 스토리지가 항상 3개의 AZ를 사용한다는 것을 보여줍니다.


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

이러한 AZ에 연결할 수 있는 모든 리소스가 준비되지 않은 네트워크 환경에서 복제본을 만들려면 해당 AZ 중 2개 이상과 연결된 서브넷을 만든 다음 해당 2~3개의 서브넷을 포함하는 DB 서브넷 그룹을 만들어야 합니다. 다음 예제에서는 그 방법을 보여줍니다.

2단계: 원본 클러스터의 DB 서브넷 그룹 확인

원본 클러스터와 동일한 수의 서브넷을 복제본에 사용하려면 원본 클러스터의 DB 서브넷 그룹에서 서브넷 수를 확인할 수 있습니다. Aurora DB 서브넷 그룹에는 각각 다른 AZ와 연결된 서브넷이 2개 이상 포함되어 있습니다. 서브넷이 어떤 AZ와 연결되어 있는지 기록해 두세요.

다음 예제는 원본 클러스터의 DB 서브넷 그룹을 찾은 다음 해당 AZ로 거꾸로 작업하는 방법을 보여줍니다. 첫 번째 명령의 my_cluster를 사용자 클러스터의 이름으로 대체합니다. 두 번째 명령에서 DB 서브넷 그룹의 이름을 my_subnet으로 대체합니다.


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

두 개의 서브넷을 포함하는 DB 서브넷 그룹이 있는 클러스터의 경우 샘플 출력은 다음과 유사하게 보일 수 있습니다. 이 경우 two-subnets은 DB 서브넷 그룹을 생성할 때 지정한 이름입니다.


two-subnets

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

DB 서브넷 그룹에 3개의 서브넷이 포함된 클러스터의 경우, 출력은 다음과 비슷하게 보일 수 있습니다.


three-subnets

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

3단계: 원본 클러스터의 서브넷 확인

원본 클러스터의 서브넷에 대한 자세한 정보가 필요한 경우 다음과 유사한 AWS CLI 명령을 실행하세요. P 주소 범위, 소유자 등과 같은 서브넷 속성을 확인할 수 있습니다. 이렇게 하면 동일한 VPC에서 다른 서브넷을 사용할지, 아니면 다른 VPC에 비슷한 특성을 가진 서브넷을 만들지 결정할 수 있습니다.

VPC에서 사용할 수 있는 모든 서브넷의 서브넷 ID를 찾습니다.


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

DB 서브넷 그룹에서 사용되는 정확한 서브넷을 찾습니다.


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

그리고 나서 다음 명령어와 같이 조사할 서브넷을 목록으로 지정합니다. 서브넷의 이름을 my_subnet_1 등으로 대체합니다.


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

다음 예제는 이러한 describe-subnets 명령의 일부 출력을 보여줍니다. 출력에는 각 서브넷에 대해 볼 수 있는 몇 가지 중요한 속성(예: 연결된 AZ 및 해당 서브넷이 속한 VPC)이 표시됩니다.


{
    'Subnets': [
        {
            'AvailabilityZone': 'us-east-1d',
            'AvailableIpAddressCount': 54,
            'CidrBlock': '10.0.0.64/26',
            'State': 'available',
            'SubnetId': 'subnet-000a0bca00e0b0000',
            'VpcId': 'vpc-3f3c3fc3333b3ffb3',
            ...
        },
        {
            'AvailabilityZone': 'us-east-1c',
            'AvailableIpAddressCount': 55,
            'CidrBlock': '10.0.0.0/26',
            'State': 'available',
            'SubnetId': 'subnet-4b4dbfe4d4a4fd4c4',
            'VpcId': 'vpc-3f3c3fc3333b3ffb3',
            ...

4단계: 원본 클러스터에서 DB 인스턴스의 가용 영역 확인

이 절차를 사용하여 원본 클러스터의 DB 인스턴스에 사용된 AZ를 파악할 수 있습니다. 이렇게 하면 복제본의 DB 인스턴스에 대해 정확히 동일한 AZ를 설정할 수 있습니다. 또한 복제본을 프로덕션, 개발, 테스트 등에 사용하는지 여부에 따라 복제본에 더 많은 또는 더 적은 수의 DB 인스턴스를 사용할 수 있습니다.

원본 클러스터의 각 인스턴스에 대해 다음과 같은 명령을 실행합니다. 먼저 인스턴스 생성이 완료되어 Available 상태가 되었는지 확인합니다. 인스턴스 식별자를 my_instance로 대체합니다.


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

다음 예제는 앞의 describe-db-instances 명령을 실행한 결과를 보여줍니다. Aurora 클러스터에는 4개의 데이터베이스 인스턴스가 있습니다. 따라서 매번 다른 DB 인스턴스 식별자로 대체하여 명령을 네 번 실행합니다. 출력은 이러한 DB 인스턴스가 최대 3개의 AZ에 어떻게 분산되어 있는지 보여줍니다.


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

복제본이 생성되고 DB 인스턴스를 추가하는 경우, create-db-instance 명령에서 동일한 AZ 이름을 지정할 수 있습니다. 이렇게 하면 원본 클러스터와 정확히 동일한 AZ로 구성된 새 클러스터에 DB 인스턴스를 설정할 수 있습니다.

5단계: 복제본에 사용할 수 있는 VPC 확인

원본과 다른 VPC에서 복제본을 만들려는 경우, 계정에 사용할 수 있는 VPC ID 목록을 확인할 수 있습니다. 원본 클러스터와 동일한 VPC에 추가 서브넷을 만들어야 하는 경우에도 이 단계를 수행할 수 있습니다. 서브넷을 만드는 명령을 실행할 때 파라미터로 VPC ID를 지정합니다.

계정의 모든 VPC를 나열하려면 다음 CLI 명령을 실행합니다.


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

다음 예제는 앞의 describe-vpcs 명령의 샘플 출력을 보여줍니다. 출력은 현재 AWS 계정에 VPC 간 복제를 위한 소스 또는 대상으로 사용할 수 있는 4개의 VPC가 있음을 보여줍니다.


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

복제 대상과 동일한 VPC를 사용하거나 다른 VPC를 사용할 수 있습니다. 원본 클러스터와 복제본이 동일한 VPC에 있는 경우, 복제본에 동일한 DB 서브넷 그룹을 재사용할 수 있습니다. 다른 DB 서브넷 그룹을 생성할 수도 있습니다. 예를 들어, 새 DB 서브넷 그룹은 프라이빗 서브넷을 사용하고 원본 클러스터의 DB 서브넷 그룹은 퍼블릭 서브넷을 사용할 수 있습니다. 다른 VPC에서 복제본을 생성하는 경우, 새 VPC에 서브넷이 충분한지, 서브넷이 원본 클러스터의 올바른 AZ와 연결되어 있는지 확인하세요.

복제본을 위한 네트워크 리소스 생성

네트워크 정보를 수집하는 동안 복제본에 추가 네트워크 리소스가 필요하다는 것을 발견한 경우, 복제본을 설정하기 전에 해당 리소스를 만들 수 있습니다. 예를 들어, 더 많은 서브넷, 특정 AZ와 연결된 서브넷 또는 새 DB 서브넷 그룹을 만들어야 할 수 있습니다.

1단계: 복제본의 서브넷 생성
2단계: 복제본에 대한 DB 서브넷 그룹 생성

1단계: 복제본의 서브넷 생성

복제본에 대한 새 서브넷을 만들어야 하는 경우 다음과 유사한 명령을 실행합니다. 다른 VPC에서 복제본을 만들거나 퍼블릭 서브넷 대신 프라이빗 서브넷을 사용하는 등 다른 네트워크를 변경할 때 이 작업을 수행해야 할 수 있습니다.

AWS는 서브넷의 ID를 자동으로 생성합니다. 복제본의 VPC 이름을 my_vpc로 대체합니다. --cidr-block 옵션의 주소 범위를 선택하여 해당 범위에서 최소 16개의 IP 주소를 허용합니다. 지정하려는 다른 속성을 포함할 수 있습니다. aws ec2 create-subnet help 명령을 실행하여 모든 선택 사항을 확인합니다.


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

다음 예제는 새로 생성된 서브넷의 몇 가지 중요한 속성을 보여줍니다.


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

2단계: 복제본에 대한 DB 서브넷 그룹 생성

다른 VPC에 복제본을 만들거나 동일한 VPC 내의 다른 서브넷 집합에 복제본을 만드는 경우 새 DB 서브넷 그룹을 만들고 복제본을 만들 때 지정합니다.

다음 세부 사항을 모두 알고 있는지 확인하세요. 앞선 예제의 출력에서 이 모든 것을 확인할 수 있습니다.

원본 클러스터의 VPC입니다. 자세한 내용은 3단계: 원본 클러스터의 서브넷 확인 섹션을 참조하세요.
다른 VPC에서 복제본을 만드는 경우 복제본의 VPC입니다. 지침은 5단계: 복제본에 사용할 수 있는 VPC 확인 단원을 참조하십시오.
원본 클러스터의 Aurora 스토리지와 연결된 3개의 AZ입니다. 지침은 1단계: 원본 클러스터의 가용 영역 확인 단원을 참조하십시오.
원본 클러스터의 DB 서브넷 그룹과 연결된 두세 개의 AZ입니다. 지침은 2단계: 원본 클러스터의 DB 서브넷 그룹 확인 단원을 참조하십시오.
복제본에 사용하려는 VPC에 있는 모든 서브넷의 서브넷 ID 및 연결된 AZ입니다. 3단계: 원본 클러스터의 서브넷 확인에서와 동일한 describe-subnets 명령을 사용하여 원본 클러스터의 서브넷을 확인하고 대상 VPC의 VPC ID를 대체합니다.

원본 클러스터의 스토리지와 연결되어 있고 대상 VPC의 서브넷과 연결되어 있는 AZ의 수를 확인합니다. 복제본을 성공적으로 생성하려면 두 개 또는 세 개의 AZ가 공통으로 있어야 합니다. 공통 AZ가 2개 미만인 경우 1단계: 복제본의 서브넷 생성으로 돌아가세요. 원본 클러스터의 스토리지와 연결된 AZ와 연결된 새 서브넷을 하나, 둘 또는 세 개 만듭니다.

대상 VPC에서 원본 클러스터의 Aurora 스토리지와 동일한 AZ와 연결된 서브넷을 선택합니다. 세 개의 AZ를 선택하는 것이 이상적입니다. 이렇게 하면 복제본의 DB 인스턴스를 여러 AZ에 분산하여 컴퓨팅 리소스의 고가용성을 가장 유연하게 확보할 수 있습니다.

다음과 유사한 명령을 실행하여 새 DB 서브넷 그룹을 생성합니다. 목록에 있는 서브넷의 ID를 대체합니다. 경 변수를 사용하여 서브넷 ID를 지정하는 경우, ID 주위에 큰따옴표가 유지되도록 --subnet-ids 파라미터 목록을 인용하도록 주의하세요.


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

다음 예제에서는 create-db-subnet-group 명령의 일부 출력을 보여줍니다


{
    'DBSubnetGroup': {
        'DBSubnetGroupName': 'my_subnet_group',
        'DBSubnetGroupDescription': 'DB subnet group with 3 subnets for clone',
        'VpcId': 'vpc-555fc5df555e555dc',
        'SubnetGroupStatus': 'Complete',
        'Subnets': [
            {
                'SubnetIdentifier': 'my_subnet_1',
                'SubnetAvailabilityZone': {
                    'Name': 'us-east-1c'
                },
                'SubnetStatus': 'Active'
            },
            {
                'SubnetIdentifier': 'my_subnet_2',
                'SubnetAvailabilityZone': {
                    'Name': 'us-east-1d'
                },
                'SubnetStatus': 'Active'
            }
            ...
        ],
        'SupportedNetworkTypes': [
            'IPV4'
        ]
    }
}

이 시점에서는 아직 복제본을 실제로 만들지 않았습니다. 복제본을 만들 때 restore-db-cluster-to-point-in-time 및 create-db-instance 명령에 적절한 파라미터를 지정할 수 있도록 관련 VPC 및 서브넷 리소스를 모두 만들었습니다.

새 네트워크 설정으로 Aurora 복제본 생성

새 클러스터에서 사용할 VPC, 서브넷, AZ 및 서브넷 그룹의 올바른 구성을 확인했으면 실제 복제 작업을 수행할 수 있습니다. 다음 CLI 예제에서는 복제 및 해당 DB 인스턴스를 설정하는 명령에 지정하는 --db-subnet-group-name, --availability-zone, --vpc-security-group-ids 등의 옵션을 중점적으로 설명합니다.

1단계: 복제본의 DB 서브넷 그룹 지정
2단계: 복제본의 인스턴스에 대한 네트워크 설정 지정
3단계: 클라이언트 시스템에서 복제본으로 연결 설정

1단계: 복제본의 DB 서브넷 그룹 지정

복제본을 생성할 때 DB 서브넷 그룹을 지정하여 올바른 VPC, 서브넷 및 AZ 설정을 모두 구성할 수 있습니다. 앞의 예제에 있는 명령을 사용하여 DB 서브넷 그룹에 들어가는 모든 관계와 매핑을 확인합니다.

예를 들어, 다음 명령은 원본 클러스터를 복제본으로 복제하는 것을 보여줍니다. 첫 번째 예제에서 원본 클러스터는 2개의 서브넷과 연결되고 복제본은 3개의 서브넷과 연결됩니다. 두 번째 예제에서는 서브넷이 3개인 클러스터에서 서브넷이 2개인 클러스터로 복제본을 복제하는 반대 사례를 보여줍니다.


aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier cluster-with-3-subnets \
  --db-cluster-identifier cluster-cloned-to-2-subnets \
  --restore-type copy-on-write --use-latest-restorable-time \
  --db-subnet-group-name two-subnets

복제본에서 Aurora 서버리스 v2 인스턴스를 사용하려는 경우, 그림과 같이 복제본을 생성할 때 --serverless-v2-scaling-configuration 옵션을 포함하세요. 이렇게 하면 복제본에서 DB 인스턴스를 생성할 때 db.serverless 클래스를 사용할 수 있습니다. 나중에 복제본을 수정하여 이 크기 조정 구성 속성을 추가할 수도 있습니다. 이 예제의 용량 숫자는 클러스터의 각 서버리스 v2 인스턴스를 2~32개의 Aurora 용량 단위(ACU)로 확장할 수 있도록 합니다. Aurora 서버리스 v2 기능 및 용량 범위를 선택하는 방법에 대한 자세한 내용은 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'

DB 인스턴스에서 사용하는 서브넷 수에 관계없이 소스 클러스터 및 복제본에 대한 Aurora 스토리지는 3개의 AZ와 연결됩니다. 음 예제에는 앞의 예제에서 restore-db-cluster-to-point-in-time 명령 모두에 대해 원본 클러스터 및 복제본과 연결된 AZ가 나열되어 있습니다.


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

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

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

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

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

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

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

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

원본 클러스터와 복제본 클러스터의 각 쌍 간에 적어도 두 개의 AZ가 겹치기 때문에 두 클러스터 모두 동일한 기본 Aurora 스토리지에 액세스할 수 있습니다.

2단계: 복제본의 인스턴스에 대한 네트워크 설정 지정

복제본에 DB 인스턴스를 생성하면 기본적으로 클러스터 자체에서 DB 서브넷 그룹을 상속받습니다. 이렇게 하면 Aurora는 각 인스턴스를 특정 서브넷에 자동으로 할당하고 서브넷과 연결된 AZ에 인스턴스를 만듭니다. 특히 개발 및 테스트 시스템의 경우, 복제본에 새 인스턴스를 추가하는 동안 서브넷 ID나 AZ를 추적할 필요가 없으므로 이 선택이 편리합니다.

다른 방법으로, 복제본에 대한 Aurora DB 인스턴스를 생성할 때 AZ를 지정할 수 있습니다. 지정하는 AZ는 복제본과 연결된 AZ 세트에서 가져와야 합니다. 복제본에 사용하는 DB 서브넷 그룹에 서브넷이 2개만 포함된 경우, 이 두 서브넷과 연결된 AZ 중에서만 선택할 수 있습니다. 이렇게 선택하면 쓰기 인스턴스와 대기 리더 인스턴스가 서로 다른 AZ에 있도록 할 수 있으므로 고가용성 시스템을 위한 유연성과 복원력을 제공합니다. 또는 클러스터에 리더를 추가하는 경우 리더가 3개의 AZ에 분산되도록 할 수 있습니다. 이렇게 하면 드물게 AZ에 장애가 발생하는 경우에도 다른 두 개의 AZ에 여전히 쓰기 인스턴스와 다른 리더 인스턴스가 있습니다.

다음 예제에서는 사용자 정의 DB 서브넷 그룹을 사용하는 프로비저닝된 DB 인스턴스를 복제본 Aurora PostgreSQL 클러스터에 추가합니다.


aws rds create-db-instance --db-cluster-identifier my_aurora_postgresql_clone \
  --db-instance-identifier my_postgres_instance \
  --db-subnet-group-name my_new_subnet \
  --engine aurora-postgresql \
  --db-instance-class db.t4g.medium

다음 예제는 이러한 명령의 일부 출력을 보여줍니다.


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

다음 예제에서는 사용자 정의 DB 서브넷 그룹을 사용하는 Aurora MySQL 복제본에 Aurora 서버리스 v2 DB 인스턴스를 추가합니다. 서버리스 v2 인스턴스를 사용하려면 앞의 예제에서와 같이 restore-db-cluster-to-point-in-time 명령에 --serverless-v2-scaling-configuration 옵션을 지정해야 합니다.


aws rds create-db-instance --db-cluster-identifier my_aurora_mysql_clone \
  --db-instance-identifier my_mysql_instance \
  --db-subnet-group-name my_other_new_subnet \
  --engine aurora-mysql \
  --db-instance-class db.serverless

다음 예제는 이러한 명령의 일부 출력을 보여줍니다.


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

3단계: 클라이언트 시스템에서 복제본으로 연결 설정

이미 클라이언트 시스템에서 Aurora 클러스터에 연결하고 있는 경우, 새 복제본에 동일한 유형의 연결을 허용하고 싶을 수 있습니다. 예를 들어 Amazon Cloud9 인스턴스 또는 EC2 인스턴스에서 원본 클러스터에 연결할 수 있습니다. 동일한 클라이언트 시스템 또는 대상 VPC에서 생성한 새 클라이언트 시스템의 연결을 허용하려면 VPC에서와 동일한 DB 서브넷 그룹 및 VPC 보안 그룹을 설정합니다. 그런 다음 복제본을 생성할 때 서브넷 그룹과 보안 그룹을 지정합니다.

다음 예제에서는 Aurora Serverless v2 복제본을 설정합니다. 이 구성은 DB 클러스터를 생성할 때 --engine-mode provisioned와 --serverless-v2-scaling-configuration을 조합한 다음 클러스터의 각 DB 인스턴스를 생성할 때 --db-instance-class db.serverless를 조합한 것을 기반으로 합니다. provisioned 엔진 모드가 기본값이므로 원하는 경우 해당 옵션을 생략할 수 있습니다.


aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier serverless-sql-postgres\
  --db-cluster-identifier serverless-sql-postgres-clone \
  --db-subnet-group-name 'default-vpc-1234' \
  --vpc-security-group-ids 'sg-4567' \
  --serverless-v2-scaling-configuration 'MinCapacity=0.5,MaxCapacity=16' \
  --restore-type copy-on-write \
  --use-latest-restorable-time

그런 다음 복제본에서 DB 인스턴스를 생성할 때 동일한 --db-subnet-group-name 옵션을 지정합니다. 선택적으로 --availability-zone 옵션을 포함하여 해당 서브넷 그룹의 서브넷과 연결된 AZ 중 하나를 지정할 수 있습니다. 해당 AZ는 원본 클러스터와 연결된 AZ 중 하나이기도 해야 합니다.


aws rds create-db-instance \
  --db-cluster-identifier serverless-sql-postgres-clone \
  --db-instance-identifier serverless-sql-postgres-clone-instance \
  --db-instance-class db.serverless \
  --db-subnet-group-name 'default-vpc-987zyx654' \
  --availability-zone 'us-east-1c' \
  --engine aurora-postgresql

퍼블릭 서브넷에서 프라이빗 서브넷으로 클러스터 이동

복제본을 사용하여 퍼블릭 서브넷과 프라이빗 서브넷 간에 클러스터를 마이그레이션할 수 있습니다. 애플리케이션을 프로덕션에 배포하기 전에 애플리케이션에 보안 계층을 추가할 때 이 작업을 수행할 수 있습니다. 이 예제에서는 Aurora로 복제본 프로세스를 시작하기 전에 프라이빗 서브넷과 NAT 게이트웨이가 이미 설정되어 있어야 합니다.

Aurora와 관련된 단계는 앞의 예제에서 네트워크 환경에 대한 정보 수집 및 새 네트워크 설정으로 Aurora 복제본 생성에 대한 일반적인 단계와 동일하게 따를 수 있습니다. 가장 큰 차이점은 원본 클러스터의 모든 AZ에 매핑되는 퍼블릭 서브넷이 있더라도 이제 Aurora 클러스터를 위한 프라이빗 서브넷이 충분한지, 그리고 이러한 서브넷이 원본 클러스터의 Aurora 스토리지에 사용되는 것과 동일한 모든 AZ와 연결되어 있는지 확인해야 한다는 것입니다. 다른 복제 사용 사례와 마찬가지로, 필요한 AZ와 연결된 프라이빗 서브넷을 3개 또는 2개로 복제본에 대한 DB 서브넷 그룹을 만들 수 있습니다. 그러나 DB 서브넷 그룹에 2개의 프라이빗 서브넷을 사용하는 경우, 원본 클러스터의 Aurora 스토리지에 사용되는 세 번째 AZ와 연결된 세 번째 프라이빗 서브넷이 있어야 합니다.

이 체크리스트를 참조하여 이러한 유형의 복제본 작업을 수행하기 위한 모든 요구 사항이 갖추어져 있는지 확인할 수 있습니다.

원본 클러스터와 연결된 세 개의 AZ를 기록합니다. 지침은 1단계: 원본 클러스터의 가용 영역 확인 단원을 참조하십시오.
원본 클러스터의 DB 서브넷 그룹에 있는 퍼블릭 서브넷과 연결된 AZ를 3개 또는 2개 기록합니다. 지침은 3단계: 원본 클러스터의 서브넷 확인 단원을 참조하십시오.
원본 클러스터와 연결된 세 개의 AZ 모두에 매핑되는 프라이빗 서브넷을 만듭니다. 또한 프라이빗 서브넷과 통신할 수 있도록 NAT 게이트웨이 생성 등 기타 네트워킹 설정을 수행합니다. 관련 지침은 Amazon Virtual Private Cloud 사용 설명서의 서브넷 생성을 참조하세요.
첫 번째 지점의 AZ와 연결된 프라이빗 서브넷 중 3개 또는 2개가 포함된 새 DB 서브넷 그룹을 생성합니다. 지침은 2단계: 복제본에 대한 DB 서브넷 그룹 생성 단원을 참조하십시오.

모든 필수 요건이 갖추어지면 복제본을 만드는 동안 원본 클러스터의 데이터베이스 활동을 일시 중지하고 애플리케이션을 사용하도록 전환할 수 있습니다. 복제본이 만들어지고 연결할 수 있는지, 애플리케이션 코드를 실행할 수 있는지 등을 확인한 후에는 원본 클러스터의 사용을 중단할 수 있습니다.

VPC 간 복제본 생성의 엔드 투 엔드 예제

원본과 다른 VPC에 복제본을 만드는 것은 앞의 예와 동일한 일반 단계를 사용합니다. VPC ID는 서브넷의 속성이므로 실제로 RDS CLI 명령을 실행할 때 파라미터로 VPC ID를 지정하지 않습니다. 가장 큰 차이점은 새 서브넷, 특정 AZ에 매핑된 새 서브넷, VPC 보안 그룹 및 새 DB 서브넷 그룹을 만들어야 할 가능성이 더 높다는 것입니다. 특히 해당 VPC에서 만드는 첫 번째 Aurora 클러스터인 경우 더욱 그렇습니다.

이 체크리스트를 참조하여 이러한 유형의 복제본 작업을 수행하기 위한 모든 요구 사항이 갖추어져 있는지 확인할 수 있습니다.

원본 클러스터와 연결된 세 개의 AZ를 기록합니다. 지침은 1단계: 원본 클러스터의 가용 영역 확인 단원을 참조하십시오.
원본 클러스터의 DB 서브넷 그룹에 있는 서브넷과 연결된 AZ를 3개 또는 2개 기록합니다. 지침은 2단계: 원본 클러스터의 DB 서브넷 그룹 확인 단원을 참조하십시오.
원본 클러스터와 연결된 세 개의 AZ 모두에 매핑되는 서브넷을 만듭니다. 지침은 1단계: 복제본의 서브넷 생성 단원을 참조하십시오.
클라이언트 시스템, 애플리케이션 서버 등이 복제본의 DB 인스턴스와 통신할 수 있도록 VPC 보안 그룹 설정 등 기타 네트워킹 설정을 수행합니다. 지침은 보안 그룹을 통한 액세스 제어 단원을 참조하십시오.
첫 번째 지점의 AZ와 연결된 서브넷 중 3개 또는 2개의 서브넷을 포함하는 새 DB 서브넷 그룹을 만듭니다. 지침은 2단계: 복제본에 대한 DB 서브넷 그룹 생성 단원을 참조하십시오.

모든 필수 요건이 갖추어지면 복제본을 만드는 동안 원본 클러스터의 데이터베이스 활동을 일시 중지하고 애플리케이션을 사용하도록 전환할 수 있습니다. 복제본이 생성되고 연결, 애플리케이션 코드 실행 등이 가능한지 확인한 후에는 원본과 복제본을 모두 계속 실행할지, 아니면 원본 클러스터의 사용을 중단할지 고려할 수 있습니다.

다음 Linux 예제는 한 VPC에서 다른 VPC로 Aurora DB 클러스터를 복제본으로 생성하기 위한 AWS CLI 작업 순서를 보여줍니다. 예시와 관련이 없는 일부 필드는 명령 출력에 표시되지 않습니다.

먼저 소스 및 대상 VPC의 ID를 확인합니다. VPC를 생성할 때 할당하는 설명적인 이름은 VPC 메타데이터에 태그로 표시됩니다.


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

원본 클러스터는 이미 소스 VPC에 존재합니다. Aurora 스토리지에 대해 동일한 AZ 세트를 사용하여 복제본을 설정하려면 원본 클러스터에서 사용하는 AZ를 확인합니다.


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

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

원래 클러스터에서 사용하는 AZ에 해당하는 서브넷이 있는지 확인합니다(us-east-1c, us-east-1d, us-east-1f).


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

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

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

이 예제에서는 대상 VPC에 필요한 AZ에 매핑되는 서브넷이 있는지 확인합니다.


aws ec2 describe-subnets --query 'sort_by(*[] | [?VpcId == `vpc-9e99d9f99a999bd99`] |
[].{SubnetId:SubnetId,VpcId:VpcId,AvailabilityZone:AvailabilityZone}, &AvailabilityZone)' --output table

---------------------------------------------------------------------------
|                             DescribeSubnets                             |
+------------------+----------------------------+-------------------------+
| AvailabilityZone |         SubnetId           |          VpcId          |
+------------------+----------------------------+-------------------------+
|  us-east-1a      |  subnet-000ff0e00000c0aea  |  vpc-9e99d9f99a999bd99  |
|  us-east-1b      |  subnet-1111d111111ca11b1  |  vpc-9e99d9f99a999bd99  |
|  us-east-1c      | subnet-3333a33be3ef3e333   |  vpc-9e99d9f99a999bd99  |
|  us-east-1d      | subnet-4eeb444cd44b4d444   |  vpc-9e99d9f99a999bd99  |
|  us-east-1f      | subnet-66eea6666fb66d66c   |  vpc-9e99d9f99a999bd99  |
+------------------+----------------------------+-------------------------+

VPC에서 Aurora DB 클러스터를 생성하기 전에 Aurora 스토리지에 사용되는 AZ에 매핑되는 서브넷이 있는 DB 서브넷 그룹이 있어야 합니다. 일반 클러스터를 생성할 때는 3개의 AZ 중 원하는 세트를 사용할 수 있습니다. 기존 클러스터를 복제본으로 생성하는 경우, 서브넷 그룹은 Aurora 스토리지에 사용하는 3개의 AZ 중 2개 이상과 일치해야 합니다.


$ aws rds create-db-subnet-group \
  --db-subnet-group-name subnet-group-in-other-vpc \
  --subnet-ids '["subnet-3333a33be3ef3e333","subnet-4eeb444cd44b4d444","subnet-66eea6666fb66d66c"]' \
  --db-subnet-group-description 'DB subnet group with 3 subnets: subnet-3333a33be3ef3e333,subnet-4eeb444cd44b4d444,subnet-66eea6666fb66d66c'

{
    'DBSubnetGroup': {
        'DBSubnetGroupName': 'subnet-group-in-other-vpc',
        'DBSubnetGroupDescription': 'DB subnet group with 3 subnets: subnet-3333a33be3ef3e333,subnet-4eeb444cd44b4d444,subnet-66eea6666fb66d66c',
        'VpcId': 'vpc-9e99d9f99a999bd99',
        'SubnetGroupStatus': 'Complete',
        'Subnets': [
            {
                'SubnetIdentifier': 'subnet-4eeb444cd44b4d444',
                'SubnetAvailabilityZone': { 'Name': 'us-east-1d' }
            },
            {
                'SubnetIdentifier': 'subnet-3333a33be3ef3e333',
                'SubnetAvailabilityZone': { 'Name': 'us-east-1c' }
            },
            {
                'SubnetIdentifier': 'subnet-66eea6666fb66d66c',
                'SubnetAvailabilityZone': { 'Name': 'us-east-1f' }
            }
        ]
    }
}

이제 서브넷과 DB 서브넷 그룹이 준비되었습니다. 다음 예제에서는 클러스터를 복제본으로 복원하는 restore-db-cluster-to-point-in-time을 보여줍니다. --db-subnet-group-name 옵션은 원본 클러스터의 올바른 AZ 세트에 매핑되는 올바른 서브넷 세트와 복제본을 연결합니다.


$ aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier original-cluster \
  --db-cluster-identifier clone-in-other-vpc \
  --restore-type copy-on-write --use-latest-restorable-time \
  --db-subnet-group-name subnet-group-in-other-vpc

{
  'DBClusterIdentifier': 'clone-in-other-vpc',
  'DBSubnetGroup': 'subnet-group-in-other-vpc',
  'Engine': 'aurora-postgresql',
  'EngineVersion': '15.4',
  'Status': 'creating',
  'Endpoint': 'clone-in-other-vpc.cluster-c0abcdef.us-east-1.rds.amazonaws.com'
}

다음 예제에서는 복제본의 Aurora 스토리지가 원본 클러스터와 동일한 AZ 세트를 사용하는 것을 확인합니다.


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

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

이 시점에서 복제본에 대한 DB 인스턴스를 생성할 수 있습니다. 각 인스턴스와 연결된 VPC 보안 그룹이 대상 VPC에 있는 EC2 인스턴스, 애플리케이션 서버 등에 사용하는 IP 주소 범위의 연결을 허용하는지 확인합니다.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

Aurora DB 클러스터에 대한 볼륨 복제

계정 간 복제