# Aurora DB 클러스터에 대한 볼륨 복제
Aurora 복제를 사용하면 처음에는 원본과 동일한 데이터 페이지를 공유하지만 별도의 독립적인 볼륨인 새 클러스터를 생성할 수 있습니다. 이 프로세스는 빠르고 비용 효율적으로 진행되도록 설계되었습니다. 연결된 데이터 볼륨이 있는 새 클러스터를 *복제본*이라고 합니다. 복제본 생성은 스냅샷 복원과 같은 다른 기술을 사용하여 데이터를 물리적으로 복사하는 것보다 빠르고 공간 효율적입니다.
**Topics**
+ [Aurora 복제 개요](#Aurora.Clone.Overview)
+ [Aurora 복제의 제한 사항](#Aurora.Managing.Clone.Limitations)
+ [Aurora 복제 작동 방식](#Aurora.Managing.Clone.Protocol)
+ [Amazon Aurora 복제 생성](#Aurora.Managing.Clone.create)
+ [Amazon Aurora를 사용한 VPC 간 복제](Aurora.Managing.Clone.Cross-VPC.md)
+ [AWS RAM과 Amazon Aurora에서 교차 계정 복제](Aurora.Managing.Clone.Cross-Account.md)
## Aurora 복제 개요
Aurora는 *기록 중 복사(Copy-on-Write) 프로토콜*을 사용하여 복제본을 생성합니다. 이 메커니즘은 최소한의 추가 공간을 사용하여 초기 복제를 만듭니다. 복제가 처음 생성되면 Aurora는 소스 Aurora DB 클러스터와 새로운(복제된) Aurora DB 클러스터에서 사용하는 데이터의 단일 복사본을 유지합니다. 소스 Aurora DB 클러스터 또는 Aurora DB 클러스터 복제가 Aurora 스토리지 볼륨의 데이터를 변경한 경우에만 추가 스토리지가 할당됩니다. 기록 중 복사(Copy-on-Write) 프로토콜에 대한 자세한 내용은 [Aurora 복제 작동 방식](#Aurora.Managing.Clone.Protocol) 섹션을 참조하세요.
Aurora 복제 작업은 데이터 손상 위험 없이 프로덕션 데이터를 사용하여 테스트 환경을 신속하게 설정하는 데 특히 유용합니다. 다음과 같은 여러 유형의 애플리케이션에 복제본을 사용할 수 있습니다.
+ 잠재적 변경 사항(예: 스키마 변경 및 파라미터 그룹 변경)을 실험하여 모든 영향을 평가합니다.
+ 데이터 내보내기 또는 복제본에서 분석 쿼리 실행과 같은 워크로드 집약적인 작업을 수행하는 경우
+ 개발, 테스트 또는 기타 용도로 프로덕션 DB 클러스터의 복사본을 생성합니다.
동일한 Aurora DB 클러스터에서 둘 이상의 복제본을 생성할 수 있습니다. 다른 복제본에서 여러 복제본을 생성할 수도 있습니다.
Aurora 복제본을 생성한 후 Aurora DB 인스턴스를 소스 Aurora DB 클러스터와 다르게 구성할 수 있습니다. 예를 들어 소스 프로덕션 Aurora DB 클러스터와 동일한 고가용성 요구 사항을 충족하기 위해 개발 목적으로 복제본이 필요하지 않을 수 있습니다. 이 경우 Aurora DB 클러스터에서 사용하는 여러 DB 인스턴스가 아닌 단일 Aurora DB 인스턴스로 복제본을 구성할 수 있습니다.
소스와 다른 배포 구성을 사용하여 복제를 생성하면 소스 Aurora DB 엔진의 최신 마이너 버전을 사용하여 복제본이 생성됩니다.
Aurora DB 클러스터에서 복제를 생성하면 소스 Aurora DB 클러스터를 소유하는 계정과 동일한 AWS 계정에서 복제본이 생성됩니다. 그러나 Aurora Serverless v2 및 프로비저닝된 Aurora DB 클러스터와 복제본을 다른 AWS 계정에 공유할 수도 있습니다. 자세한 내용은 [AWS RAM과 Amazon Aurora에서 교차 계정 복제](Aurora.Managing.Clone.Cross-Account.md) 단원을 참조하십시오.
복제본을 테스트, 개발 또는 다른 용도로 사용한 후 삭제할 수 있습니다.
## Aurora 복제의 제한 사항
Aurora 복제는 다음과 같은 제한 사항이 있습니다.
+ AWS 리전에서 허용하는 최대 DB 클러스터 개수까지 원하는 만큼 복제본을 생성할 수 있습니다.
+ copy-on-write 프로토콜을 사용하여 최대 15개의 복제본을 만들 수 있습니다. 그러나 15개의 복제본을 생성한 후에는 다음에 생성하는 복제본이 전체 복제본이 됩니다. 전체 복사 프로토콜은 특정 시점 복구와 같은 역할을 합니다.
+ 소스 Aurora DB 클러스터에서 다른 AWS 리전에 복제본을 생성할 수 없습니다.
+ 병렬 쿼리 기능이 없는 Aurora DB 클러스터에서 병렬 쿼리를 사용하는 클러스터로의 복제본을 생성할 수 없습니다. 병렬 쿼리를 사용하는 클러스터에 데이터를 가져오려면 원본 클러스터의 스냅샷을 생성하여 병렬 쿼리 기능을 사용하는 클러스터에 복원합니다.
+ DB 인스턴스가 없는 Aurora DB 클러스터에서 복제본을 생성할 수 없습니다. 하나 이상의 DB 인스턴스가 있는 Aurora DB 클러스터만 복제할 수 있습니다.
+ 복제본을 Aurora DB 클러스터의 Virtual Private Cloud(VPC)와 다른 Virtual Private Cloud(VPC)에 생성할 수 있습니다. 이렇게 하면 VPC의 서브넷을 동일한 가용 영역에 매핑해야 합니다.
+ 프로비저닝된 Aurora DB 클러스터에서 Aurora 프로비저닝된 복제본을 생성할 수 있습니다.
+ Aurora Serverless v2 인스턴스가 있는 클러스터는 프로비저닝된 클러스터와 동일한 규칙을 따릅니다.
+ Aurora Serverless v1의 경우:
+ Aurora Serverless v1 DB 클러스터에서 프로비저닝된 복제본을 생성할 수 있습니다.
+ Aurora Serverless v1 또는 프로비저닝된 DB 클러스터에서 Aurora Serverless v1 복제본을 생성할 수 있습니다.
+ 암호화되지 않은 프로비저닝된 Aurora DB 클러스터에서는 Aurora Serverless v1 복제본을 생성할 수 없습니다.
+ 교차 계정 복제는 현재 Aurora Serverless v1 DB 클러스터 복제를 지원하지 않습니다. 자세한 내용은 [계정 간 복제 제한 사항](Aurora.Managing.Clone.Cross-Account.md#Aurora.Managing.Clone.CrossAccount.Limitations) 단원을 참조하십시오.
+ 복제된 Aurora Serverless v1 DB 클러스터는 Aurora Serverless v1 DB 클러스터와 동일한 동작과 제한 사항이 있습니다. 자세한 내용은 [Amazon Aurora Serverless v1 사용](aurora-serverless.md) 단원을 참조하십시오.
+ Aurora Serverless v1 DB 클러스터는 항상 암호화됩니다. Aurora Serverless v1 DB 클러스터를 프로비저닝된 Aurora DB 클러스터로 복제하는 경우 프로비저닝된 Aurora DB 클러스터가 암호화됩니다. 암호화 키를 선택할 수 있지만 암호화를 비활성화할 수는 없습니다. 프로비저닝된 Aurora DB 클러스터에서 Aurora Serverless v1로 복제하려면 암호화되고 프로비저닝된 Aurora DB 클러스터로 시작해야 합니다.
## Aurora 복제 작동 방식
Aurora 복제는 Aurora DB 클러스터의 스토리지 계층에서 작동합니다. 이는 Aurora 스토리지 볼륨을 지원하는 기본 내구 미디어 측면에서 빠르고 공간 효율적인 *기록 중 복사(copy-on-write)* 프로토콜을 사용합니다. [Amazon Aurora 스토리지 개요](Aurora.Overview.StorageReliability.md#Aurora.Overview.Storage)에서 Aurora 클러스터 볼륨에 대해 자세히 알아보세요.
**Topics**
+ [기록 중 복사(copy-on-write) 이해](#Aurora.Managing.Clone.Protocol.Before)
+ [원본 클러스터 볼륨 삭제](#Aurora.Managing.Clone.Deleting)
### 기록 중 복사(copy-on-write) 이해
Aurora DB 클러스터는 기본 Aurora 스토리지 볼륨의 페이지에 데이터를 저장합니다.
예를 들어, 다음 다이어그램에서 데이터 페이지(1, 2, 3, 4)가 네 개인 Aurora DB 클러스터(A)를 찾을 수 있습니다. 복제본 B가 Aurora DB 클러스터에서 생성된다고 가정해 보겠습니다. 복제본이 생성되면 데이터가 복사되지 않습니다. 대신 복제본은 소스 Aurora DB 클러스터와 동일한 페이지 집합을 가리킵니다.
![\[소스 클러스터 A 및 복제본 B에 대해 4개의 페이지가 포함된 Amazon Aurora 클러스터 볼륨\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/aurora-cloning-copy-on-write-protocol-1.png)
복제본이 생성되면 일반적으로 추가 스토리지가 필요하지 않습니다. 기록 중 복사(copy-on-write) 프로토콜은 물리적 스토리지 미디어에서 소스 세그먼트와 동일한 세그먼트를 사용합니다. 소스 세그먼트의 용량이 전체 복제본 세그먼트에 충분하지 않은 경우에만 추가 스토리지가 필요합니다. 이 경우 소스 세그먼트는 다른 물리적 디바이스로 복사됩니다.
다음 다이어그램에서는 앞에서와 같이 동일한 클러스터 A와 해당 복제본 B를 사용하여 작동하는 기록 중 복사(copy-on-write) 프로토콜의 예를 찾을 수 있습니다. Aurora DB 클러스터(A)를 변경하여 페이지 1에 보관된 데이터가 변경된다고 가정해 보겠습니다. Aurora는 원본 페이지 1에 기록하는 대신 새 페이지 1[A]을 생성합니다. 클러스터(A)에 대한 Aurora DB 클러스터 볼륨은 이제 페이지 1[A], 2, 3, 4를 가리키고 복제본(B)은 여전히 원본 페이지를 참조합니다.
![\[Amazon Aurora 소스 DB 클러스터 볼륨과 해당 복제본 모두 변경 사항이 있습니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/aurora-cloning-copy-on-write-protocol-2.png)
복제본에서 스토리지 볼륨의 페이지 4가 변경됩니다. 원본 페이지 4에 기록하는 대신 Aurora는 새 페이지 4[B]를 생성합니다. 이제 복제본은 페이지 1, 2, 3 및 페이지 4[B]를 가리키고 클러스터(A)는 계속해서 1[A], 2, 3 및 4를 가리킵니다.
![\[Amazon Aurora 소스 DB 클러스터 볼륨과 해당 복제본 모두 변경 사항이 있습니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/aurora-cloning-copy-on-write-protocol-3.png)
시간이 경과하여 소스 Aurora DB 클러스터 볼륨과 복제본 모두가 변경될 경우 변경 사항을 캡처하고 저장하기 위해 점점 더 많은 스토리지가 필요합니다.
### 원본 클러스터 볼륨 삭제
처음에 복제 볼륨은 복제가 생성된 원본 볼륨과 동일한 데이터 페이지를 공유합니다. 원본 볼륨이 존재하는 한 복제 볼륨은 복제본이 생성하거나 수정한 페이지의 소유자로만 간주됩니다. 따라서 복제 볼륨의 `VolumeBytesUsed` 지표는 작게 시작해서 데이터가 원본 클러스터와 복제본 간에 분산될 때만 커집니다. 소스 볼륨과 복제 간에 동일한 페이지가 있는 경우 스토리지 요금은 원본 클러스터에만 적용됩니다. `VolumeBytesUsed` 지표에 대한 자세한 내용은 [Amazon Aurora에 대한 클러스터 수준 지표](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.clusters)를 참고하세요.
하나 이상의 복제본이 연결된 소스 클러스터 볼륨을 삭제해도 복제본의 클러스터 볼륨에 있는 데이터는 변경되지 않습니다. Aurora는 이전에 소스 클러스터 볼륨이 소유하던 페이지를 보존합니다. Aurora는 삭제된 클러스터가 소유한 페이지에 대한 스토리지 요금을 재분배합니다. 예를 들어 원본 클러스터에 두 개의 복제본이 있었는데 원본 클러스터가 삭제되었다고 가정해 보겠습니다. 이제 원본 클러스터가 소유한 데이터 페이지 중 절반을 하나의 복제본이 소유하게 됩니다. 페이지의 나머지 절반은 다른 복제본이 소유하게 됩니다.
원본 클러스터를 삭제한 다음 복제본을 더 생성하거나 삭제하면 Aurora는 동일한 페이지를 공유하는 모든 복제본에 데이터 페이지의 소유권을 계속 재분배합니다. 따라서 복제본의 클러스터 볼륨에 따라 `VolumeBytesUsed` 지표 값이 변경되는 것을 확인할 수 있습니다. 더 많은 복제본이 생성되고 페이지 소유권이 더 많은 클러스터에 분산됨에 따라 지표 값이 감소할 수 있습니다. 복제본이 삭제되고 페이지 소유권이 더 적은 수의 클러스터에 할당됨에 따라 지표 값이 증가할 수도 있습니다. 쓰기 작업이 복제 볼륨의 데이터 페이지에 미치는 영향에 대한 자세한 내용은 [기록 중 복사(copy-on-write) 이해](#Aurora.Managing.Clone.Protocol.Before) 섹션을 참조하세요.
원본 클러스터와 복제본을 동일한 AWS 계정에서 소유한 경우 해당 클러스터에 대한 모든 스토리지 요금이 동일한 AWS 계정에 적용됩니다. 클러스터 중 일부가 크로스 계정 복제본인 경우 원본 클러스터를 삭제하면 크로스 계정 복제본을 소유한 AWS 계정에 추가 스토리지 요금이 부과될 수 있습니다.
예를 들어 복제본을 생성하기 전에 먼저 클러스터 볼륨에 1,000개의 사용된 데이터 페이지가 있다고 가정해 보겠습니다. 해당 클러스터를 복제하면 처음에는 복제 볼륨의 사용된 페이지가 0으로 나타납니다. 복제본이 100개의 데이터 페이지를 수정하면 해당 100페이지만 복제본 볼륨에 저장되고 사용된 것으로 표시됩니다. 상위 볼륨의 변경되지 않은 나머지 900개 페이지는 두 클러스터에서 모두 공유됩니다. 이 경우 상위 클러스터의 스토리지 요금은 1,000페이지, 복제본 볼륨은 100페이지에 대한 스토리지 요금이 부과됩니다.
소스 볼륨을 삭제하는 경우 복제본에 대한 스토리지 요금에는 변경된 100페이지와 원본 볼륨의 공유 페이지 900개(총 1,000페이지)가 포함됩니다.
## Amazon Aurora 복제 생성
소스 Aurora DB 클러스터와 같은 AWS 계정에서 복제본을 생성합니다. 이를 위해 AWS Management Console 또는 AWS CLI 및 다음 절차를 사용할 수 있습니다.
다른 AWS 계정에서 복제본을 생성하거나 다른 AWS 계정과 복제본을 공유하도록 허용하려면 [AWS RAM과 Amazon Aurora에서 교차 계정 복제](Aurora.Managing.Clone.Cross-Account.md)의 절차를 사용합니다.
### 콘솔
다음 프로시저에서는 AWS Management Console을 사용하여 Aurora DB 클러스터를 복제하는 방법에 대해 설명합니다.
AWS Management Console을 사용하여 복제본을 생성하면 하나의 Aurora DB 인스턴스가 있는 하나의 Aurora DB 클러스터가 생성됩니다.
이번 지침은 복제본을 생성하는 것과 동일한 AWS 계정에서 소유하고 있는 DB 클러스터에 적용됩니다. DB 클러스터를 다른 AWS 계정에서 소유하고 있다면 [AWS RAM과 Amazon Aurora에서 교차 계정 복제](Aurora.Managing.Clone.Cross-Account.md) 섹션을 참조하세요.
**AWS을 사용해 AWS Management Console 계정에서 소유하는 DB 클러스터 복제본을 생성하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **데이터베이스**를 선택합니다.
1. 목록에서 Aurora DB 클러스터를 선택하고 [**작업(Actions)**]에서 [**복제본 생성(Create clone)**]을 선택합니다.
![\[Aurora DB 클러스터를 선택하여 복제본 생성을 시작합니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/aurora-cloning-create-clone-1.png)
**설정**, **연결성** 및 Aurora DB 클러스터 복제본에 대한 기타 옵션을 구성할 수 있는 복제본 생성 페이지가 열립니다.
1. **DB 인스턴스 식별자**에 복제된 Aurora DB 클러스터에 부여할 이름을 입력합니다.
1. Aurora Serverless v1 DB 클러스터의 경우 **용량 유형**에서 **프로비저닝됨** 또는 **서버리스**를 선택합니다.
소스 Aurora DB 클러스터가 Aurora Serverless v1 DB 클러스터이거나 암호화되고 프로비저닝된 Aurora DB 클러스터인 경우 [**서버리스(Serverless)**]를 선택합니다.
1. Aurora Serverless v2 또는 프로비저닝된 DB 클러스터의 경우 **클러스터 스토리지 구성**에서 **Aurora I/O-Optimized** 또는 **Aurora Standard** 중 하나를 선택합니다.
자세한 내용은 [Amazon Aurora DB 클러스터의 스토리지 구성](Aurora.Overview.StorageReliability.md#aurora-storage-type) 단원을 참조하십시오.
1. DB 인스턴스 크기 또는 DB 클러스터 용량을 선택합니다.
+ 프로비저닝된 복제본의 경우 **DB 인스턴스 클래스**를 선택합니다.
![\[프로비저닝된 복제본을 생성하려면 DB 인스턴스 크기를 지정합니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/aurora-cloning-create-clone-3-provisioned.png)
제공된 설정을 수락하거나 복제본에 다른 DB 인스턴스 클래스를 사용할 수 있습니다.
+ Aurora Serverless v1 또는 Aurora Serverless v2 복제본의 경우 **용량 설정**을 선택합니다.
![\[Aurora DB 클러스터에서 Serverless 복제본을 생성하려면 용량을 지정합니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/aurora-cloning-create-clone-3-serverless.png)
제공된 설정을 수락하거나 복제본에 맞게 설정을 변경할 수 있습니다.
1. 복제본에 필요에 따라 다른 설정을 선택하세요. Aurora DB 클러스터 및 인스턴스 설정에 대한 자세한 내용은 [Amazon Aurora DB 클러스터 생성](Aurora.CreateInstance.md) 섹션에서 참조하세요.
1. **복제본 생성**을 선택합니다.
복제본이 생성되면 복제본은 콘솔의 [**데이터베이스(Databases)**] 섹션에 다른 Aurora DB 클러스터와 함께 나열되고 현재 상태가 표시됩니다. 상태가 [**사용 가능(Available)**]이면 복제본을 사용할 준비가 된 것입니다.
### AWS CLI
AWS CLI를 사용하여 Aurora DB 클러스터를 복제하려면 클론 클러스터를 만들고 여기에 하나 이상의 DB 인스턴스를 추가하는 별도의 단계가 필요합니다.
`restore-db-cluster-to-point-in-time` AWS CLI 명령을 사용하면 원래 클러스터와 동일한 스토리지 데이터를 가진 Aurora DB 클러스터가 생성되지만 Aurora DB 인스턴스는 생성되지 않습니다. 클론이 사용 가능해지면 별도로 DB 인스턴스를 생성합니다. DB 인스턴스와 해당 인스턴스 클래스의 수를 선택하여 클론에 원래 클러스터보다 더 많거나 적은 컴퓨팅 파워를 제공할 수 있습니다. 프로세스의 단계는 다음과 같습니다.
1. [restore-db-cluster-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-to-point-in-time.html) CLI 명령을 사용하여 복제본을 생성합니다.
1. [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) CLI 명령을 사용하여 클론에 대한 라이터 DB 인스턴스를 생성합니다.
1. (선택 사항) 추가 [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) CLI 명령을 실행하여 하나 이상의 리더 인스턴스를 클론 클러스터에 추가합니다. 리더 인스턴스를 사용하면 클론의 고가용성 및 읽기 확장성 측면을 개선하는 데 도움이 됩니다. 개발 및 테스트용으로만 클론을 사용하려는 경우에는 이 단계를 건너뛰어도 됩니다.
**Topics**
+ [복제본 생성](#Aurora.Managing.Clone.CLI.create-empty-clone)
+ [상태 확인 및 복제본 세부 정보 가져오기](#Aurora.Managing.Clone.CLI.check-status-get-details)
+ [복제본에 대한 Aurora DB 인스턴스 생성](#Aurora.Managing.Clone.CLI.create-db-instance)
+ [복제본에 사용할 파라미터](#Aurora.Managing.Clone.CLI.parameter-summary)
#### 복제본 생성
`[restore-db-cluster-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-to-point-in-time.html)` CLI 명령을 사용하여 초기 클론 클러스터를 생성합니다.
**소스 Aurora DB 클러스터로부터 클론을 생성하는 방법**
+ `[restore-db-cluster-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-to-point-in-time.html)` CLI 명령을 사용합니다. 다음 파라미터의 값을 지정합니다. 이 일반적인 경우에는 클론이 원래 클러스터와 동일한 엔진 모드(프로비저닝된 모드 또는 Aurora Serverless v1)를 사용합니다.
+ `--db-cluster-identifier` - 복제본에 대해 의미 있는 이름을 선택합니다. 복제본의 이름을 지정할 때 [restore-db-cluster-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-to-point-in-time.html) CLI 명령을 사용합니다. 그런 다음 [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) CLI 명령에 복제본 이름을 전달합니다.
+ `--restore-type` – `copy-on-write`을 사용하여 소스 DB 클러스터의 복제본을 생성합니다. 이 파라미터가 없으면 `restore-db-cluster-to-point-in-time`은 복제본을 생성하는 대신 Aurora DB 클러스터를 복원합니다.
+ `--source-db-cluster-identifier` - 복제할 소스 Aurora DB 클러스터의 이름을 사용합니다.
+ `--use-latest-restorable-time` - 이 값은 소스 DB 클러스터에 대해 복원 가능한 최신 볼륨 데이터를 가리킵니다. 이를 사용하여 클론을 생성할 수 있습니다.
다음 예제에서는 `my-source-cluster`라는 이름의 클러스터에서 `my-clone`라는 이름의 복제본을 생성합니다.
대상 LinuxmacOS, 또는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
```
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
```
이 명령은 복제본의 세부 사항을 포함하는 JSON 객체를 반환합니다. 클론에 대한 DB 인스턴스를 생성하기 전에 복제된 DB 클러스터를 사용할 수 있는지 확인합니다. 자세한 내용은 [상태 확인 및 복제본 세부 정보 가져오기](#Aurora.Managing.Clone.CLI.check-status-get-details) 단원을 참조하십시오.
예를 들어 복제하고자 하는 `tpch100g`라는 이름의 클러스터가 있다고 가정합니다. 다음 Linux 예제는 `tpch100g-clone`이라는 복제된 클러스터, `tpch100g-clone-instance`라는 Aurora Serverless v2 라이터 인스턴스 및 새 클러스터를 위한 `tpch100g-clone-instance-2`라는 프로비저닝된 리더 인스턴스를 만듭니다.
`--master-username` 및 `--master-user-password`와 같은 일부 파라미터를 제공할 필요가 없습니다. Aurora는 원본 클러스터에서 파라미터를 자동으로 결정합니다. 사용할 DB 엔진을 지정해야 합니다. 따라서 이 예제는 새 클러스터를 테스트하여 `--engine` 파라미터에 사용할 올바른 값을 결정합니다.
이 예에는 클론 클러스터를 생성할 때의 `--serverless-v2-scaling-configuration` 옵션도 포함되어 있습니다. 이렇게 하면 원래 클러스터에서 Aurora Serverless v2를 사용하지 않았더라도 클론에 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
```
**소스 Aurora DB 클러스터와 다른 엔진 모드를 사용하여 복제본을 생성하는 방법**
+ 이 절차는 Aurora Serverless v1을 지원하는 이전 엔진 버전에만 적용됩니다. Aurora Serverless v1 클러스터가 있고 프로비저닝된 클러스터인 클론을 생성하려고 한다고 가정해 보겠습니다. 이 경우 `[restore-db-cluster-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-to-point-in-time.html)` CLI 명령을 사용하여 이전 예제와 유사한 파라미터 값과 함께 다음 추가 파라미터를 지정합니다.
+ `--engine-mode` - 소스 Aurora DB 클러스터와 다른 엔진 모드를 사용하는 클론을 생성하는 경우에만 이 파라미터를 사용합니다. 이 파라미터는 Aurora Serverless v1을 지원하는 이전 엔진 버전에만 적용됩니다. 다음과 같이 `--engine-mode`를 사용하여 전달할 값을 선택합니다.
+ `--engine-mode provisioned`을 사용하여 Aurora Serverless DB 클러스터에서 프로비저닝된 Aurora DB 클러스터 복제본을 생성합니다.
**참고**
Aurora Serverless v1에서 복제된 클러스터와 함께 Aurora Serverless v2를 사용하려는 경우에도 클론의 엔진 모드를 `provisioned`로 지정해야 합니다. 그런 다음 이후에 추가 업그레이드 및 마이그레이션 단계를 수행합니다.
+ `--engine-mode serverless`를 사용하여 프로비저닝된 Aurora DB 클러스터에서 Aurora Serverless v1 클론을 생성합니다. `serverless` 엔진 모드를 지정할 때 `--scaling-configuration`을 선택할 수도 있습니다.
+ `--scaling-configuration` - (선택 사항) `--engine-mode serverless`를 사용하여 Aurora Serverless v1 복제본의 최소 및 최대 용량을 구성합니다. 이 파라미터를 사용하지 않는 경우 Aurora가 DB 엔진의 기본 Aurora Serverless v1 용량 값을 사용하여 Aurora Serverless v1 클론을 생성합니다.
다음 예제에서는 `my-source-cluster`라는 이름의 Aurora Serverless v1 DB 클러스터에서 `my-clone`이라는 이름의 프로비저닝된 클론을 생성합니다.
대상 LinuxmacOS, 또는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
```
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
```
이 명령은 DB 인스턴스를 생성하는 데 필요한 복제본의 세부 정보가 포함된 JSON 객체를 반환합니다. 복제본 상태(빈 Aurora DB 클러스터)가 **사용 가능(Available)** 상태가 될 때까지는 작업을 수행할 수 있습니다.
**참고**
[restore-db-cluster-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-to-point-in-time.html) AWS CLI 명령은 해당 DB 클러스터의 DB 인스턴스가 아닌 DB 클러스터만 복원합니다. 복원된 DB 클러스터에 대한 DB 인스턴스를 생성하려면 [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) 명령을 실행합니다. 해당 명령으로 복원된 DB 클러스터의 식별자를 `--db-cluster-identifier` 파라미터로 지정합니다. `restore-db-cluster-to-point-in-time` 명령이 완료되고 DB 클러스터를 사용 가능할 때만 DB 인스턴스를 생성할 수 있습니다.
Aurora Serverless v1 클러스터로 시작해서 Aurora Serverless v2 클러스터로 마이그레이션하려고 한다고 가정해 보겠습니다. 마이그레이션의 초기 단계로 Aurora Serverless v1 클러스터의 프로비저닝된 클론을 생성합니다. 필요한 버전 업그레이드를 포함한 전체 절차는 [Aurora Serverless v1 클러스터에서 Aurora Serverless v2로 업그레이드](aurora-serverless-v2.upgrade.md#aurora-serverless-v2.upgrade-from-serverless-v1-procedure) 단원을 참조하세요.
#### 상태 확인 및 복제본 세부 정보 가져오기
다음 명령을 사용하여 새로 생성된 클론 클러스터의 상태를 확인할 수 있습니다.
```
$ aws rds describe-db-clusters --db-cluster-identifier my-clone --query '*[].[Status]' --output text
```
또는 다음 AWS CLI 쿼리를 사용하여 [복제본에 대한 DB 인스턴스를 생성](#Aurora.Managing.Clone.CLI.create-db-instance)하는 데 필요한 다른 값 및 상태를 가져올 수 있습니다.
대상 LinuxmacOS, 또는Unix:
```
aws rds describe-db-clusters --db-cluster-identifier my-clone \
--query '*[].{Status:Status,Engine:Engine,EngineVersion:EngineVersion,EngineMode:EngineMode}'
```
Windows의 경우:
```
aws rds describe-db-clusters --db-cluster-identifier my-clone ^
--query "*[].{Status:Status,Engine:Engine,EngineVersion:EngineVersion,EngineMode:EngineMode}"
```
이 쿼리는 다음과 비슷한 출력을 반환합니다.
```
[
{
"Status": "available",
"Engine": "aurora-mysql",
"EngineVersion": "8.0.mysql_aurora.3.04.1",
"EngineMode": "provisioned"
}
]
```
#### 복제본에 대한 Aurora DB 인스턴스 생성
[create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) CLI 명령을 사용하여 Aurora Serverless v2 또는 프로비저닝된 복제본에 대한 DB 인스턴스를 생성합니다. Aurora Serverless v1 클론을 위한 DB 인스턴스는 만들지 않습니다.
DB 인스턴스는 소스 DB 클러스터에서 `--master-username` 및 `--master-user-password` 속성을 상속합니다.
다음은 프로비저닝된 복제본에 대한 DB 인스턴스를 생성하는 예제입니다.
대상 LinuxmacOS, 또는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
```
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
```
다음 예제에서는 Aurora Serverless v2를 지원하는 엔진 버전을 사용하는 클론을 위해 Aurora Serverless v2 DB 인스턴스를 만듭니다.
대상 LinuxmacOS, 또는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
```
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
```
#### 복제본에 사용할 파라미터
다음 표에는 `restore-db-cluster-to-point-in-time`에서 Aurora DB 클러스터를 복제하는 데 사용되는 다양한 파라미터가 요약되어 있습니다.
| 파라미터 | 설명 |
| --- | --- |
| `--source-db-cluster-identifier` | 복제할 소스 Aurora DB 클러스터의 이름을 사용합니다. |
| `--db-cluster-identifier` | `restore-db-cluster-to-point-in-time` 명령을 사용하여 복제본을 생성할 때는 의미가 있는 이름을 지정하세요. 그런 다음 이 이름을 `create-db-instance` 명령으로 전달합니다. |
| `--restore-type` | `copy-on-write`를 `--restore-type`로 지정하여 소스 Aurora DB 클러스터를 복원하는 대신 소스 DB 클러스터의 복제본을 생성합니다. |
| `--use-latest-restorable-time` | 이 값은 소스 DB 클러스터에 대해 복원 가능한 최신 볼륨 데이터를 가리킵니다. 이를 사용하여 클론을 생성할 수 있습니다. |
| `--serverless-v2-scaling-configuration` | (Aurora Serverless v2를 지원하는 최신 버전) 이 파라미터를 사용하여 Aurora Serverless v2 클론의 최소 및 최대 용량을 구성합니다. 이 파라미터를 지정하지 않으면 클러스터를 수정하여 이 속성을 추가하기 전까지는 클론 클러스터에 Aurora Serverless v2 인스턴스를 만들 수 없습니다. |
| `--engine-mode` | (Aurora Serverless v1만 지원하는 이전 버전) 이 파라미터를 사용하여 소스 Aurora DB 클러스터와 다른 유형의 클론을 생성합니다. 클론에는 다음 값 중 하나가 포함되어야 합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Clone.html) |
| `--scaling-configuration` | (Aurora Serverless v1만 지원하는 이전 버전) 이 파라미터를 사용하여 Aurora Serverless v1 클론의 최소 및 최대 용량을 구성합니다. 이 파라미터를 지정하지 않는 경우 Aurora가 DB 엔진의 기본 용량 값을 사용하여 복제본을 생성합니다. |
VPC 간 및 계정 간 복제에 대한 자세한 내용은 다음 섹션을 참조하세요.
**Topics**
+ [Aurora 복제 개요](#Aurora.Clone.Overview)
+ [Aurora 복제의 제한 사항](#Aurora.Managing.Clone.Limitations)
+ [Aurora 복제 작동 방식](#Aurora.Managing.Clone.Protocol)
+ [Amazon Aurora 복제 생성](#Aurora.Managing.Clone.create)
+ [Amazon Aurora를 사용한 VPC 간 복제](Aurora.Managing.Clone.Cross-VPC.md)
+ [AWS RAM과 Amazon Aurora에서 교차 계정 복제](Aurora.Managing.Clone.Cross-Account.md)
# Amazon Aurora를 사용한 VPC 간 복제
원본 클러스터와 복제본에 서로 다른 네트워크 액세스 제어를 적용하고 싶다고 가정해 보겠습니다. 예를 들어 복제를 사용하여 개발 및 테스트를 위해 다른 VPC에 프로덕션 Aurora 클러스터의 복사본을 만들 수 있습니다. 또는 데이터베이스 보안을 강화하기 위해 퍼블릭 서브넷에서 프라이빗 서브넷으로의 마이그레이션의 일부로 복제본을 만들 수도 있습니다.
다음 섹션에서는 원본 클러스터와 복제본이 서로 다른 서브넷이나 다른 VPC에서도 동일한 Aurora 스토리지 노드에 액세스할 수 있도록 복제본의 네트워크 구성을 설정하는 방법을 설명합니다. 네트워크 리소스를 미리 확인하면 복제 중 진단하기 어려운 오류를 방지할 수 있습니다.
Aurora가 VPC, 서브넷 및 DB 서브넷 그룹과 상호 작용하는 방식에 익숙하지 않은 경우 먼저 [Amazon VPC 및 Amazon Aurora](USER_VPC.md) 섹션을 참조하세요. 해당 섹션의 자습서를 통해 AWS에서 이러한 종류의 리소스를 생성하고 이러한 리소스가 서로 어떻게 결합되는지 이해할 수 있습니다.
이 단계에는 RDS와 EC2 서비스 간 전환이 포함되므로, 예제에서는 이러한 작업을 자동화하고 출력을 저장하는 방법을 이해하는 데 도움이 되도록 AWS CLI 명령을 사용합니다.
**Topics**
+ [시작하기 전 준비 사항](#before-you-begin)
+ [네트워크 환경에 대한 정보 수집](#gathering-information-about-the-network-environment)
+ [복제본을 위한 네트워크 리소스 생성](#creating-network-resources-for-the-clone)
+ [새 네트워크 설정으로 Aurora 복제본 생성](#creating-an-aurora-clone-with-new-network-settings)
+ [퍼블릭 서브넷에서 프라이빗 서브넷으로 클러스터 이동](#moving-a-cluster-from-public-subnets-to-private-ones)
+ [VPC 간 복제본 생성의 엔드 투 엔드 예제](#end-to-end-example-of-creating-a-cross-vpc-clone)
## 시작하기 전 준비 사항
VPC 간 복제 설정을 시작하기 전에 다음 리소스가 준비되어 있는지 확인하세요.
+ 복제를 위한 소스로 사용할 Aurora DB 클러스터. Aurora DB 클러스터를 처음 만드는 경우, [Amazon Aurora 시작하기](CHAP_GettingStartedAurora.md)의 자습서를 참조하여 MySQL 또는 PostgreSQL 데이터베이스 엔진을 사용하여 클러스터를 설정하세요.
+ VPC 간 복제본을 생성하려는 경우 두 번째 VPC. 복제본에 사용할 VPC가 없는 경우에는 [자습서: DB 클러스터에 사용할 Amazon VPC 생성(IPv4 전용)](CHAP_Tutorials.WebServerDB.CreateVPC.md) 또는 [자습서: DB 클러스터(듀얼 스택 모드)에 사용할 VPC 생성](CHAP_Tutorials.CreateVPCDualStack.md)를 참조하세요.
## 네트워크 환경에 대한 정보 수집
VPC 간 복제를 사용하면 네트워크 환경이 원본 클러스터와 복제본 간에 크게 다를 수 있습니다. 복제본을 만들기 전에 원본 클러스터에서 사용된 VPC, 서브넷, DB 서브넷 그룹 및 AZ에 대한 정보를 수집하여 기록하세요. 이렇게 하면 문제 발생 가능성을 최소화할 수 있습니다. 네트워크 문제가 발생하는 경우 진단 정보를 검색하기 위해 문제 해결 활동을 중단할 필요가 없습니다. 다음 섹션에서는 이러한 유형의 정보를 수집하는 CLI 예제를 보여줍니다. 복제본을 만들고 문제 해결을 수행하는 동안 참조하기 편리한 형식으로 세부 정보를 저장할 수 있습니다.
+ [1단계: 원본 클러스터의 가용 영역 확인](#cross-vpc-cloning-check-original-azs)
+ [2단계: 원본 클러스터의 DB 서브넷 그룹 확인](#cross-vpc-cloning-check-original-subnet-group)
+ [3단계: 원본 클러스터의 서브넷 확인](#cross-vpc-cloning-check-original-subnets)
+ [4단계: 원본 클러스터에서 DB 인스턴스의 가용 영역 확인](#cross-vpc-cloning-check-original-instance-azs)
+ [5단계: 복제본에 사용할 수 있는 VPC 확인](#cross-vpc-cloning-check-vpcs)
### 1단계: 원본 클러스터의 가용 영역 확인
복제본을 생성하기 전에 원본 클러스터가 스토리지에 사용하는 AZ를 확인하세요. [Amazon Aurora 스토리지](Aurora.Overview.StorageReliability.md)에 설명된 대로, 각 Aurora 클러스터의 스토리지는 정확히 3개의 AZ와 연결되어 있습니다. [Amazon Aurora DB 클러스터](Aurora.Overview.md)는 컴퓨팅과 스토리지의 분리를 활용하기 때문에 이 규칙은 클러스터에 있는 인스턴스 수에 관계없이 적용됩니다.
예를 들어, 다음과 같은 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\$13개의 서브넷을 포함하는 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단계: 복제본의 서브넷 생성](#cross-vpc-cloning-create-clone-subnets)
+ [2단계: 복제본에 대한 DB 서브넷 그룹 생성](#cross-vpc-cloning-create-subnet-group)
### 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 서브넷 그룹을 만들고 복제본을 만들 때 지정합니다.
다음 세부 사항을 모두 알고 있는지 확인하세요. 앞선 예제의 출력에서 이 모든 것을 확인할 수 있습니다.
1. 원본 클러스터의 VPC입니다. 자세한 내용은 [3단계: 원본 클러스터의 서브넷 확인](#cross-vpc-cloning-check-original-subnets) 섹션을 참조하세요.
1. 다른 VPC에서 복제본을 만드는 경우 복제본의 VPC입니다. 지침은 [5단계: 복제본에 사용할 수 있는 VPC 확인](#cross-vpc-cloning-check-vpcs) 단원을 참조하십시오.
1. 원본 클러스터의 Aurora 스토리지와 연결된 3개의 AZ입니다. 지침은 [1단계: 원본 클러스터의 가용 영역 확인](#cross-vpc-cloning-check-original-azs) 단원을 참조하십시오.
1. 원본 클러스터의 DB 서브넷 그룹과 연결된 두세 개의 AZ입니다. 지침은 [2단계: 원본 클러스터의 DB 서브넷 그룹 확인](#cross-vpc-cloning-check-original-subnet-group) 단원을 참조하십시오.
1. 복제본에 사용하려는 VPC에 있는 모든 서브넷의 서브넷 ID 및 연결된 AZ입니다. [3단계: 원본 클러스터의 서브넷 확인](#cross-vpc-cloning-check-original-subnets)에서와 동일한 `describe-subnets` 명령을 사용하여 원본 클러스터의 서브넷을 확인하고 대상 VPC의 VPC ID를 대체합니다.
원본 클러스터의 스토리지와 연결되어 있고 대상 VPC의 서브넷과 연결되어 있는 AZ의 수를 확인합니다. 복제본을 성공적으로 생성하려면 두 개 또는 세 개의 AZ가 공통으로 있어야 합니다. 공통 AZ가 2개 미만인 경우 [1단계: 복제본의 서브넷 생성](#cross-vpc-cloning-create-clone-subnets)으로 돌아가세요. 원본 클러스터의 스토리지와 연결된 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 서브넷 그룹 지정](#cross-vpc-cloning-specify-clone-subnet-group)
+ [2단계: 복제본의 인스턴스에 대한 네트워크 설정 지정](#cross-vpc-cloning-configure-clone-instance-network)
+ [3단계: 클라이언트 시스템에서 복제본으로 연결 설정](#cross-vpc-cloning-connect-to-clone)
### 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\$132개의 Aurora 용량 단위(ACU)로 확장할 수 있도록 합니다. Aurora 서버리스 v2 기능 및 용량 범위를 선택하는 방법에 대한 자세한 내용은 [Aurora Serverless v2 사용하기](aurora-serverless-v2.md) 섹션을 참조하세요.
```
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와 관련된 단계는 앞의 예제에서 [네트워크 환경에 대한 정보 수집](#gathering-information-about-the-network-environment) 및 [새 네트워크 설정으로 Aurora 복제본 생성](#creating-an-aurora-clone-with-new-network-settings)에 대한 일반적인 단계와 동일하게 따를 수 있습니다. 가장 큰 차이점은 원본 클러스터의 모든 AZ에 매핑되는 퍼블릭 서브넷이 있더라도 이제 Aurora 클러스터를 위한 프라이빗 서브넷이 충분한지, 그리고 이러한 서브넷이 원본 클러스터의 Aurora 스토리지에 사용되는 것과 동일한 모든 AZ와 연결되어 있는지 확인해야 한다는 것입니다. 다른 복제 사용 사례와 마찬가지로, 필요한 AZ와 연결된 프라이빗 서브넷을 3개 또는 2개로 복제본에 대한 DB 서브넷 그룹을 만들 수 있습니다. 그러나 DB 서브넷 그룹에 2개의 프라이빗 서브넷을 사용하는 경우, 원본 클러스터의 Aurora 스토리지에 사용되는 세 번째 AZ와 연결된 세 번째 프라이빗 서브넷이 있어야 합니다.
이 체크리스트를 참조하여 이러한 유형의 복제본 작업을 수행하기 위한 모든 요구 사항이 갖추어져 있는지 확인할 수 있습니다.
+ 원본 클러스터와 연결된 세 개의 AZ를 기록합니다. 지침은 [1단계: 원본 클러스터의 가용 영역 확인](#cross-vpc-cloning-check-original-azs) 단원을 참조하십시오.
+ 원본 클러스터의 DB 서브넷 그룹에 있는 퍼블릭 서브넷과 연결된 AZ를 3개 또는 2개 기록합니다. 지침은 [3단계: 원본 클러스터의 서브넷 확인](#cross-vpc-cloning-check-original-subnets) 단원을 참조하십시오.
+ 원본 클러스터와 연결된 세 개의 AZ 모두에 매핑되는 프라이빗 서브넷을 만듭니다. 또한 프라이빗 서브넷과 통신할 수 있도록 NAT 게이트웨이 생성 등 기타 네트워킹 설정을 수행합니다. 관련 지침은 **Amazon Virtual Private Cloud 사용 설명서의 [서브넷 생성](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html)을 참조하세요.
+ 첫 번째 지점의 AZ와 연결된 프라이빗 서브넷 중 3개 또는 2개가 포함된 새 DB 서브넷 그룹을 생성합니다. 지침은 [2단계: 복제본에 대한 DB 서브넷 그룹 생성](#cross-vpc-cloning-create-subnet-group) 단원을 참조하십시오.
모든 필수 요건이 갖추어지면 복제본을 만드는 동안 원본 클러스터의 데이터베이스 활동을 일시 중지하고 애플리케이션을 사용하도록 전환할 수 있습니다. 복제본이 만들어지고 연결할 수 있는지, 애플리케이션 코드를 실행할 수 있는지 등을 확인한 후에는 원본 클러스터의 사용을 중단할 수 있습니다.
## VPC 간 복제본 생성의 엔드 투 엔드 예제
원본과 다른 VPC에 복제본을 만드는 것은 앞의 예와 동일한 일반 단계를 사용합니다. VPC ID는 서브넷의 속성이므로 실제로 RDS CLI 명령을 실행할 때 파라미터로 VPC ID를 지정하지 않습니다. 가장 큰 차이점은 새 서브넷, 특정 AZ에 매핑된 새 서브넷, VPC 보안 그룹 및 새 DB 서브넷 그룹을 만들어야 할 가능성이 더 높다는 것입니다. 특히 해당 VPC에서 만드는 첫 번째 Aurora 클러스터인 경우 더욱 그렇습니다.
이 체크리스트를 참조하여 이러한 유형의 복제본 작업을 수행하기 위한 모든 요구 사항이 갖추어져 있는지 확인할 수 있습니다.
+ 원본 클러스터와 연결된 세 개의 AZ를 기록합니다. 지침은 [1단계: 원본 클러스터의 가용 영역 확인](#cross-vpc-cloning-check-original-azs) 단원을 참조하십시오.
+ 원본 클러스터의 DB 서브넷 그룹에 있는 서브넷과 연결된 AZ를 3개 또는 2개 기록합니다. 지침은 [2단계: 원본 클러스터의 DB 서브넷 그룹 확인](#cross-vpc-cloning-check-original-subnet-group) 단원을 참조하십시오.
+ 원본 클러스터와 연결된 세 개의 AZ 모두에 매핑되는 서브넷을 만듭니다. 지침은 [1단계: 복제본의 서브넷 생성](#cross-vpc-cloning-create-clone-subnets) 단원을 참조하십시오.
+ 클라이언트 시스템, 애플리케이션 서버 등이 복제본의 DB 인스턴스와 통신할 수 있도록 VPC 보안 그룹 설정 등 기타 네트워킹 설정을 수행합니다. 지침은 [보안 그룹을 통한 액세스 제어](Overview.RDSSecurityGroups.md) 단원을 참조하십시오.
+ 첫 번째 지점의 AZ와 연결된 서브넷 중 3개 또는 2개의 서브넷을 포함하는 새 DB 서브넷 그룹을 만듭니다. 지침은 [2단계: 복제본에 대한 DB 서브넷 그룹 생성](#cross-vpc-cloning-create-subnet-group) 단원을 참조하십시오.
모든 필수 요건이 갖추어지면 복제본을 만드는 동안 원본 클러스터의 데이터베이스 활동을 일시 중지하고 애플리케이션을 사용하도록 전환할 수 있습니다. 복제본이 생성되고 연결, 애플리케이션 코드 실행 등이 가능한지 확인한 후에는 원본과 복제본을 모두 계속 실행할지, 아니면 원본 클러스터의 사용을 중단할지 고려할 수 있습니다.
다음 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 주소 범위의 연결을 허용하는지 확인합니다.
# AWS RAM과 Amazon Aurora에서 교차 계정 복제
Amazon Aurora에서 AWS Resource Access Manager(AWS RAM)를 사용하여 사용자 AWS 계정에 속한 Aurora DB 클러스터와 복제본을 다른 AWS 계정 또는 조직과 공유할 수 있습니다. 이러한 *교차 계정 복제*는 데이터베이스 스냅샷을 생성하여 복원하는 것보다 훨씬 빠릅니다. Aurora DB 클러스터 중 하나의 복제본을 생성하고 복제본을 공유할 수 있습니다. 또는 Aurora DB 클러스터를 다른 AWS 계정과 공유하고 계정 소유자가 복제본을 생성하도록 합니다. 선택한 접근 방식은 사용 사례에 따라 다릅니다.
예를 들어 재무 데이터베이스의 복제본을 조직의 내부 감사 팀과 정기적으로 공유해야 할 수 있습니다. 이 경우 감사 팀은 사용하는 애플리케이션에 대한 자체 AWS 계정을 갖게 됩니다. 감사 팀의 AWS 계정에 Aurora DB 클러스터에 액세스하고 필요에 따라 복제할 수 있는 권한을 부여할 수 있습니다.
반면 외부 공급업체가 재무 데이터를 감사하는 경우 복제본을 직접 생성하는 것이 좋습니다. 그런 다음 외부 공급업체에게 복제본에 대한 액세스 권한만 부여합니다.
교차 계정 복제를 사용하여 개발 및 테스트와 같은 동일한 AWS 계정 내의 복제에 대해 동일한 사용 사례를 지원할 수 있습니다. 예를 들어 조직에서 프로덕션, 개발 및 테스트 등에 대해 다른 AWS 계정을 사용할 수 있습니다. 자세한 내용은 [Aurora 복제 개요](Aurora.Managing.Clone.md#Aurora.Clone.Overview) 섹션을 참조하세요.
따라서 복제본을 다른 AWS 계정과 공유하거나 다른 AWS 계정에서 Aurora DB 클러스터의 복제본을 만들 수 있도록 허용할 수 있습니다. 두 경우 모두 AWS RAM을 사용하여 공유 객체를 생성합니다. AWS 계정 간의 AWS 리소스 공유에 대한 전체 내용은 [AWS RAM 사용 설명서](https://docs.aws.amazon.com/ram/latest/userguide/)를 참조하세요.
계정 간 복제본을 만들려면 원본 클러스터를 소유하고 있는 AWS 계정과 복제본을 생성하는 AWS 계정에서 몇 가지 작업이 필요합니다. 먼저 원본 클러스터 소유자가 클러스터를 수정하여 하나 이상의 계정에서 클러스터를 복제할 수 있도록 합니다. 계정 중 하나라도 다른 AWS 조직에 있으면 AWS는 공유 초대를 생성합니다. 다른 계정은 진행하기 전에 초대를 수락해야 합니다. 그러면 승인된 계정에서 클러스터를 복제할 수 있습니다. 이러한 프로세스 전체에서 클러스터는 고유한 Amazon 리소스 이름(ARN)으로 식별합니다.
동일한 AWS 계정 내의 복제와 마찬가지로 소스 또는 복제본에서 데이터를 변경한 경우에만 추가 스토리지 공간이 사용됩니다. 그런 다음 해당 시점에 스토리지 요금이 적용됩니다. 원본 클러스터가 삭제되면 스토리지 비용이 나머지 복제된 클러스터로 동일하게 배분됩니다.
**Topics**
+ [계정 간 복제 제한 사항](#Aurora.Managing.Clone.CrossAccount.Limitations)
+ [다른 AWS 계정에서 클러스터를 복제하도록 허용](#Aurora.Managing.Clone.CrossAccount.yours)
+ [다른 AWS 계정에서 소유하고 있는 클러스터 복제](#Aurora.Managing.Clone.CrossAccount.theirs)
## 계정 간 복제 제한 사항
Aurora 계정 간 복제는 다음과 같은 제한 사항이 있습니다.
+ Aurora Serverless v1 클러스터는 AWS 계정 간 복제가 불가능합니다.
+ AWS Management Console을 사용하여 공유 리소스에 대한 초대를 보거나 수락할 수 없습니다. AWS CLI, Amazon RDS API 또는 AWS RAM 콘솔을 사용하여 공유 리소스에 대한 초대를 보고 수락할 수 있습니다.
+ AWS 계정과 공유된 리소스에서 새 복제본을 하나만 생성할 수 있습니다. 이는 공유 리소스가 원래 Aurora DB 클러스터인지 이전에 생성된 복제본인지에 관계없이 적용됩니다.
+ 새 복제본은 AWS 계정과 공유 중인 복제본에서만 생성할 수 없습니다.
+ AWS 계정과 공유 중인 리소스(복제본 또는 Aurora DB 클러스터)를 공유할 수 없습니다.
+ 단일 Aurora DB 클러스터에서 최대 15개의 교차 계정 복제본을 생성할 수 있습니다.
+ 이 15개의 교차 계정 복제본은 각각 다른 AWS 계정에서 소유해야 합니다. 즉, AWS 계정 내 클러스터의 교차 계정 복제본을 하나만 생성할 수 있습니다.
+ 클러스터를 복제한 후 교차 계정 복제본에 대한 제한을 적용하기 위해 원래 클러스터와 복제본이 동일한 것으로 간주됩니다. 동일한 AWS 계정 내에서 원래 클러스터와 복제된 클러스터의 교차 계정 복제본을 생성할 수 없습니다. 원래 클러스터와 해당 복제본의 총 교차 계정 복제본 수는 15개를 초과할 수 없습니다.
+ 클러스터가 `ACTIVE` 상태에 있을 때만 Aurora DB 클러스터를 다른 AWS 계정과 공유할 수 있습니다.
+ 다른 AWS 계정과 공유 중인 Aurora DB 클러스터의 이름은 변경할 수 없습니다.
+ 클러스터가 기본 RDS 키로 암호화되어 있으면 계정 간 복제본을 생성할 수 없습니다.
+ 다른 AWS 계정이 공유한 암호화된 Aurora DB 클러스터에서는 하나의 AWS 계정에 암호화되지 않은 복제본을 만들 수 없습니다. 또한 클러스터 소유자는 소스 클러스터의 AWS KMS key에 액세스할 수 있는 권한을 부여해야 합니다. 하지만 복제본을 생성할 때는 다른 키를 사용해도 됩니다.
## 다른 AWS 계정에서 클러스터를 복제하도록 허용
다른 AWS 계정에서 자신이 소유한 클러스터를 복제하도록 허용하려면 AWS RAM을 사용해 공유 권한을 설정합니다. 이때 다른 AWS 조직에 속한 나머지 계정 모두에게 초대장을 전송합니다.
AWS RAM 콘솔에서 자신이 소유한 리소스를 공유하는 방법에 대한 자세한 내용은 *AWS RAM 사용 설명서*에서 [자신이 소유한 리소스 공유](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing.html)를 참조하세요.
**Topics**
+ [다른 AWS 계정에 클러스터를 복제할 수 있는 권한 부여](#Aurora.Managing.Clone.CrossAccount.granting)
+ [소유하고 있는 클러스터가 다른 AWS 계정과 공유하는지 확인](#Aurora.Managing.Clone.CrossAccount.confirming)
### 다른 AWS 계정에 클러스터를 복제할 수 있는 권한 부여
공유하고 있는 클러스터가 암호화되어 있으면 해당 클러스터의 AWS KMS key도 공유합니다. 한 AWS 계정의 AWS Identity and Access Management(IAM) 사용자 또는 역할이 다른 계정의 KMS 키를 사용하도록 허용할 수 있습니다.
이를 위해서는 먼저 외부 계정(루트 사용자)을 AWS KMS을(를) 통해 KMS 키의 키 정책에 추가합니다. 개별 사용자 또는 역할이 아니고 사용자 또는 역할을 소유한 외부 계정을 추가하는 것입니다. 또한 사용자가 생성하는 KMS 키만 공유할 수 있으며, 기본 RDS 서비스 키는 공유하지 못합니다. KMS 키 액세스 제어에 대한 자세한 내용은 [AWS KMS에 대한 인증 및 액세스 제어](https://docs.aws.amazon.com/kms/latest/developerguide/control-access.html)를 참조하세요.
#### 콘솔
**클러스터를 복제할 수 있는 권한을 부여하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **데이터베이스**를 선택합니다.
1. **세부 정보** 페이지를 볼 수 있도록 공유할 DB 클러스터와 **Connectivity & security(연결 및 보안)** 탭을 차례대로 선택합니다.
1. **다른 AWS 계정과 DB 클러스터 공유** 섹션에서 해당 클러스터의 복제를 허용할 AWS 계정의 숫자 계정 ID를 입력합니다. 동일한 조직의 계정 ID라면 입력란에 입력을 시작한 후 메뉴에서 선택할 수 있습니다.
**중요**
경우에 따라 자신의 계정과 다른 AWS 조직에 속하는 계정에게 클러스터 복제를 허용해야 할 수도 있습니다. 이때는 보안을 이유로 콘솔은 해당 계정 ID의 소유자 또는 계정 존재 여부를 보고하지 않습니다.
자신의 AWS 계정과 다른 AWS 조직에 속하는 계정 숫자를 입력할 때는 주의해야 합니다. 원하는 계정과의 공유 여부를 바로 확인하십시오.
1. 확인 페이지에서 지정한 계정 ID가 정확한지 확인합니다. 확인 입력란에 `share`를 입력하여 확인합니다.
[**세부 정보(Details)**] 페이지에서 [**이 DB 클러스터를 공유하는 계정(Accounts that this DB cluster is shared with)**] 아래 지정된 AWS 계정 ID를 보여 주는 항목이 나타납니다. **상태** 열이 처음에는 **대기 중**으로 표시됩니다.
1. 해당 AWS 계정 소유자에게 연락하거나, 혹은 두 계정을 모두 소유하고 있다면 해당 계정에 로그인합니다. 해당 계정 소유자에게 공유 초대장을 승인한 후 다음과 같이 DB 클러스터를 복제하도록 지시합니다.
#### AWS CLI
**클러스터를 복제할 수 있는 권한을 부여하려면**
1. 필요한 파라미터 정보를 수집합니다. 클러스터 ARN과 다른 AWS 계정의 숫자 ID가 필요합니다.
1. AWS RAM CLI 명령인 [https://docs.aws.amazon.com/cli/latest/reference/ram/create-resource-share.html](https://docs.aws.amazon.com/cli/latest/reference/ram/create-resource-share.html)를 실행합니다.
대상 LinuxmacOS, 또는Unix:
```
aws ram create-resource-share --name descriptive_name \
--region region \
--resource-arns cluster_arn \
--principals other_account_ids
```
Windows의 경우:
```
aws ram create-resource-share --name descriptive_name ^
--region region ^
--resource-arns cluster_arn ^
--principals other_account_ids
```
`--principals` 파라미터에서 다수의 계정 ID를 추가하려면 공백으로 각 ID를 구분하십시오. 자신의 AWS 조직 외부에 존재하는 계정 ID의 허용 여부를 지정하려면 `--allow-external-principals`에서 `--no-allow-external-principals` 또는 `create-resource-share` 파라미터를 추가합니다.
#### AWS RAM API
**클러스터를 복제할 수 있는 권한을 부여하려면**
1. 필요한 파라미터 정보를 수집합니다. 클러스터 ARN과 다른 AWS 계정의 숫자 ID가 필요합니다.
1. AWS RAM API 작업인 [CreateResourceShare](https://docs.aws.amazon.com/ram/latest/APIReference/API_CreateResourceShare.html)를 호출한 후 다음 값을 지정합니다.
+ 하나 이상의 AWS 계정에 대한 계정 ID를 `principals` 파라미터로 지정합니다.
+ 하나 이상의 Aurora DB 클러스터의 ARN을 `resourceArns` 파라미터로 지정합니다.
+ `allowExternalPrincipals` 파라미터에 부울 값을 추가하여 자신의 AWS 조직 외부에 존재하는 계정 ID의 허용 여부를 지정합니다.
#### 기본 RDS 키를 사용하는 클러스터 재생성
공유하려는 암호화된 클러스터가 기본 RDS 키를 사용하는 경우 클러스터를 재생성해야 합니다. 이렇게 하려면 DB 클러스터의 수동 스냅샷을 생성하고 AWS KMS key을(를) 사용한 다음 클러스터를 새 클러스터로 복원합니다. 그런 다음 새 클러스터를 공유합니다. 이 프로세스를 수행하려면 다음 단계를 수행합니다.
**기본 RDS 키를 사용해 암호화된 클러스터를 재생성하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **스냅샷**을 선택합니다.
1. 자신의 스냅샷을 선택합니다.
1. **작업**에서 **스냅샷 복사**와 **암호화 활성화**를 차례대로 선택합니다.
1. **AWS KMS key**에서 새롭게 사용할 암호화 키를 선택합니다.
1. 복사된 스냅샷을 복원합니다. 이 작업을 수행하려면 의 절차를 수행합니다[DB 클러스터 스냅샷에서 복원](aurora-restore-snapshot.md) 새로운 DB 인스턴스는 새로운 암호화 키를 사용합니다.
1. (선택 사항) 더 이상 필요 없다면 이전 DB 클러스터를 삭제합니다. 이 작업을 수행하려면 의 절차를 수행합니다[DB 클러스터 스냅샷 삭제](aurora-delete-snapshot.md#DeleteDBClusterSnapshot) 단, 삭제 전에 새로운 클러스터에 필요한 데이터가 모두 있는지, 그리고 애플리케이션이 새로운 클러스터에 성공적으로 액세스하는지 확인하십시오.
### 소유하고 있는 클러스터가 다른 AWS 계정과 공유하는지 확인
다른 사용자에게 클러스터 공유 권한이 있는지 확인할 수 있습니다. 따라서 클러스터가 계정 간 최대 복제 수 제한에 접근하는지 파악하는 데 효과적입니다.
AWS RAM 콘솔을 사용하여 리소스를 공유하는 절차는 *AWS RAM 사용 설명서*에서 [자신이 소유한 리소스 공유](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing.html)를 참조하세요.
#### AWS CLI
**소유한 클러스터가 다른 AWS 계정과 공유되는지 확인하려면 다음을 수행하세요.**
+ 자신의 계정 ID를 리소스 소유자로, 그리고 클러스터 ARN을 리소스 ARN으로 사용하여 AWS RAM CLI 명령인 [https://docs.aws.amazon.com/cli/latest/reference/ram/list-principals.html](https://docs.aws.amazon.com/cli/latest/reference/ram/list-principals.html)를 호출합니다. 다음 명령을 사용해 모든 공유 내역을 확인할 수 있습니다. 명령을 실행한 결과에서 클러스터 복제가 허용되는 AWS 계정을 알 수 있습니다.
```
aws ram list-principals \
--resource-arns your_cluster_arn \
--principals your_aws_id
```
#### AWS RAM API
**소유한 클러스터가 다른 AWS 계정과 공유되는지 확인하려면 다음을 수행하세요.**
+ AWS RAM API 작업 [ListPrincipals](https://docs.aws.amazon.com/ram/latest/APIReference/API_ListPrincipals.html)를 호출합니다. 자신의 계정 ID를 리소스 소유자로, 그리고 클러스터 ARN을 리소스 ARN으로 사용합니다.
## 다른 AWS 계정에서 소유하고 있는 클러스터 복제
다른 AWS 계정에서 소유한 클러스터를 복제하려면 AWS RAM을 사용해 복제 권한을 획득해야 합니다. 필요한 권한을 가져온 후에는 표준 절차에 따라 Aurora 클러스터를 복제합니다.
또한 현재 소유하고 있는 클러스터가 다른 AWS 계정에서 소유하고 있는 클러스터의 복제본인지 알 수도 있습니다.
AWS RAM 콘솔에서 다른 계정이 소유하고 있는 리소스를 사용해 작업하는 방법은 *AWS RAM 사용 설명서*에서 [공유 리소스에 대한 액세스](https://docs.aws.amazon.com/ram/latest/userguide/working-with-shared.html)를 참조하세요.
**Topics**
+ [다른 AWS 계정에서 소유하고 있는 클러스터 복제 초대장 보기](#Aurora.Managing.Clone.CrossAccount.viewing)
+ [다른 AWS 계정에서 소유하고 있는 클러스터에 대한 공유 초대장 승인](#Aurora.Managing.Clone.CrossAccount.accepting)
+ [다른 AWS 계정에서 소유하고 있는 Aurora 클러스터 복제](#Aurora.Managing.Clone.CrossAccount.cloning)
+ [DB 클러스터의 계정 간 복제본 여부 확인](#Aurora.Managing.Clone.CrossAccount.checking)
### 다른 AWS 계정에서 소유하고 있는 클러스터 복제 초대장 보기
다른 AWS 조직의 AWS 계정에서 소유하고 있는 클러스터에 대한 복제 초대장 작업을 할 때는 AWS CLI, AWS RAM 콘솔 또는 AWS RAM API를 사용합니다. 현재 Amazon RDS 콘솔에서는 이러한 절차를 수행할 수 없습니다.
AWS RAM 콘솔에서 초대장 작업에 대한 절차는 *AWS RAM 사용 설명서*에서 [공유 리소스에 대한 액세스](https://docs.aws.amazon.com/ram/latest/userguide/working-with-shared.html)를 참조하세요.
#### AWS CLI
**다른 AWS 계정에서 소유하고 있는 클러스터 복제 초대장을 보려면**
1. AWS RAM CLI 명령인 [https://docs.aws.amazon.com/cli/latest/reference/ram/get-resource-share-invitations.html](https://docs.aws.amazon.com/cli/latest/reference/ram/get-resource-share-invitations.html)를 실행합니다.
```
aws ram get-resource-share-invitations --region region_name
```
위 명령을 실행한 결과에서 이전에 승인하거나 거부한 초대장을 포함해 클러스터 복제 초대장을 모두 볼 수 있습니다.
1. (선택 사항) 자신의 작업이 필요한 초대장만 표시되도록 목록을 필터링할 수 있습니다. 파라미터로 `--query 'resourceShareInvitations[?status==`PENDING`]'`를 추가하기만 하면 됩니다.
#### AWS RAM API
**다른 AWS 계정에서 소유하고 있는 클러스터 복제 초대장을 보려면**
1. AWS RAM API 작업 [https://docs.aws.amazon.com/ram/latest/APIReference/API_GetResourceShareInvitations.html](https://docs.aws.amazon.com/ram/latest/APIReference/API_GetResourceShareInvitations.html)를 호출합니다. 그러면 이전에 승인하거나 거부한 초대장을 포함해 해당하는 초대장이 모두 반환됩니다.
1. (선택 사항) `resourceShareAssociations` 반환 필드에서 `status` 값의 `PENDING` 유무를 확인하여 자신의 작업이 필요한 초대장만 찾아볼 수 있습니다.
### 다른 AWS 계정에서 소유하고 있는 클러스터에 대한 공유 초대장 승인
다른 AWS 조직의 AWS 계정에서 소유하고 있는 클러스터에 대한 공유 초대장을 승인할 수 있습니다. 해당 초대장 작업은 AWS CLI, AWS RAM 및 RDS API 또는 AWS RAM 콘솔을 사용합니다. 현재 RDS 콘솔에서는 이러한 절차를 수행할 수 없습니다.
AWS RAM 콘솔에서 초대장 작업에 대한 절차는 *AWS RAM 사용 설명서*에서 [공유 리소스에 대한 액세스](https://docs.aws.amazon.com/ram/latest/userguide/working-with-shared.html)를 참조하세요.
#### AWS CLI
**다른 AWS 계정에서 클러스터 공유 초대장을 승인하려면**
1. 앞에서 한 것처럼 AWS RAM CLI 명령인 [https://docs.aws.amazon.com/cli/latest/reference/ram/get-resource-share-invitations.html](https://docs.aws.amazon.com/cli/latest/reference/ram/get-resource-share-invitations.html)를 실행하여 초대장 ARN을 찾습니다.
1. 다음과 같이 AWS RAM CLI 명령인 [https://docs.aws.amazon.com/cli/latest/reference/ram/accept-resource-share-invitation.html](https://docs.aws.amazon.com/cli/latest/reference/ram/accept-resource-share-invitation.html)을 호출하여 초대장을 승인합니다.
대상 LinuxmacOS, 또는Unix:
```
aws ram accept-resource-share-invitation \
--resource-share-invitation-arn invitation_arn \
--region region
```
Windows의 경우:
```
aws ram accept-resource-share-invitation ^
--resource-share-invitation-arn invitation_arn ^
--region region
```
#### AWS RAM 및 RDS API
**다른 사용자의 클러스터 공유 초대장을 승인하려면**
1. 앞에서 한 것처럼 AWS RAM API 작업 [https://docs.aws.amazon.com/ram/latest/APIReference/API_GetResourceShareInvitations.html](https://docs.aws.amazon.com/ram/latest/APIReference/API_GetResourceShareInvitations.html)를 호출하여 초대장 ARN을 찾습니다.
1. 해당 ARN을 `resourceShareInvitationArn` 파라미터로 RDS API 작업인 [AcceptResourceShareInvitation](https://docs.aws.amazon.com/ram/latest/APIReference/API_AcceptResourceShareInvitation.html)에게 전달합니다.
### 다른 AWS 계정에서 소유하고 있는 Aurora 클러스터 복제
위와 같이 DB 클러스터를 소유하고 있는 AWS 계정의 초대장을 승인하였다면 이제 클러스터를 복제할 수 있습니다.
#### 콘솔
**다른 AWS 계정에서 소유하고 있는 Aurora 클러스터를 복제하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **데이터베이스**를 선택합니다.
데이터베이스 목록 상단에서 **역할** 값이 `Shared from account #account_id`인 항목이 1개 이상 표시됩니다. 보안을 이유로 직접 확인할 수 있는 원본 클러스터 정보는 제한적입니다. 확인할 수 있는 속성은 복제 클러스터에서 동일해야 하는 데이터베이스 엔진 및 버전 등입니다.
1. 복제할 클러스터를 선택합니다.
1. **작업**에서 **복제본 생성**을 선택합니다.
1. [콘솔](Aurora.Managing.Clone.md#Aurora.Managing.Clone.Console) 단원의 절차에 따라 복제 클러스터의 설정을 마칩니다.
1. 필요하다면 복제 클러스터의 암호화를 활성화합니다. 복제할 클러스터가 암호화되어 있다면 복제 클러스터에서도 암호화를 활성화해야 합니다. 사용자와 클러스터를 공유한 AWS 계정 역시 클러스터를 암호화하는 데 사용된 KMS 키를 공유해야 합니다. 복제본을 암호화할 때는 동일한 KMS 키를 사용하거나, 사용자 고유의 KMS 키를 사용해도 좋습니다. 클러스터가 기본 KMS 키로 암호화되어 있으면 계정 간 복제본을 생성할 수 없습니다.
암호화 키를 소유한 계정은 키 정책에 따라 대상 계정에게 키를 사용할 수 있는 권한을 부여해야 합니다. 이러한 프로세스는 대상 계정에게 키 사용 권한을 부여하는 키 정책에 따라 암호화된 스냅샷을 공유하는 방법과 비슷합니다.
#### AWS CLI
**다른 AWS 계정에서 소유하고 있는 Aurora 클러스터를 복제하려면**
1. 위와 같이 DB 클러스터를 소유하고 있는 AWS 계정의 초대장을 승인합니다.
1. 다음과 같이 RDS CLI 명령인 [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-to-point-in-time.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-to-point-in-time.html)의 `restore-db-cluster-to-point-in-time` 파라미터에서 원본 클러스터의 전체 ARN을 지정하여 클러스터를 복제합니다.
`source-db-cluster-identifier`로 전달된 ARN을 아직 공유하지 않았다면 마치 지정된 클러스터가 존재하지 않는 것처럼 동일한 오류 메시지가 반환됩니다.
대상 LinuxmacOS, 또는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
```
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
```
1. 복제할 클러스터가 암호화되어 있으면 `kms-key-id` 파라미터를 추가하여 복제 클러스터도 암호화합니다. `kms-key-id` 값은 원본 DB 클러스터를 암호화할 때 사용한 것과 동일하거나, 혹은 사용자 고유의 KMS 키가 될 수도 있습니다. 단, 암호화 키를 사용할 수 있는 권한이 계정에게 있어야 합니다.
대상 LinuxmacOS, 또는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
```
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
```
암호화 키를 소유한 계정은 키 정책에 따라 대상 계정에게 키를 사용할 수 있는 권한을 부여해야 합니다. 이러한 프로세스는 대상 계정에게 키 사용 권한을 부여하는 키 정책에 따라 암호화된 스냅샷을 공유하는 방법과 비슷합니다. 키 정책 예제는 다음과 같습니다.
------
#### [ JSON ]
****
```
{
"Id": "key-policy-1",
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:user/KeyUser",
"arn:aws:iam::111122223333: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::111122223333:user/KeyUser",
"arn:aws:iam::111122223333:root"
]
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": true
}
}
}
]
}
```
------
**참고**
[restore-db-cluster-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-to-point-in-time.html) AWS CLI 명령은 해당 DB 클러스터의 DB 인스턴스가 아닌 DB 클러스터만 복원합니다. 복원된 DB 클러스터에 대한 DB 인스턴스를 생성하려면 [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) 명령을 호출합니다. `--db-cluster-identifier`에서 복원된 DB 클러스터의 식별자를 지정합니다.
`restore-db-cluster-to-point-in-time` 명령이 완료되고 DB 클러스터를 사용 가능할 때만 DB 인스턴스를 생성할 수 있습니다.
#### RDS API
**다른 AWS 계정에서 소유하고 있는 Aurora 클러스터를 복제하려면**
1. 위와 같이 DB 클러스터를 소유하고 있는 AWS 계정의 초대장을 승인합니다.
1. RDS API 작업인 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterToPointInTime.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterToPointInTime.html)의 `RestoreDBClusterToPointInTime` 파라미터에서 원본 클러스터의 전체 ARN을 지정하여 클러스터를 복제합니다.
`SourceDBClusterIdentifier`로 전달된 ARN을 아직 공유하지 않았다면 마치 지정된 클러스터가 존재하지 않는 것처럼 동일한 오류 메시지가 반환됩니다.
1. 복제할 클러스터가 암호화되어 있으면 `KmsKeyId` 파라미터를 추가하여 복제 클러스터도 암호화합니다. `kms-key-id` 값은 원본 DB 클러스터를 암호화할 때 사용한 것과 동일하거나, 혹은 사용자 고유의 KMS 키가 될 수도 있습니다. 단, 암호화 키를 사용할 수 있는 권한이 계정에게 있어야 합니다.
볼륨을 복제할 때는 원본 클러스터를 암호화할 때 사용한 암호화 키를 사용할 수 있는 권한이 대상 계정에게 필요합니다. Aurora는 `KmsKeyId`에 지정된 암호화 키를 사용하여 새로 복제된 클러스터를 암호화합니다.
암호화 키를 소유한 계정은 키 정책에 따라 대상 계정에게 키를 사용할 수 있는 권한을 부여해야 합니다. 이러한 프로세스는 대상 계정에게 키 사용 권한을 부여하는 키 정책에 따라 암호화된 스냅샷을 공유하는 방법과 비슷합니다. 키 정책 예제는 다음과 같습니다.
------
#### [ JSON ]
****
```
{
"Id": "key-policy-1",
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:user/KeyUser",
"arn:aws:iam::111122223333: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::111122223333:user/KeyUser",
"arn:aws:iam::111122223333:root"
]
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": true
}
}
}
]
}
```
------
**참고**
[RestoreDBClusterToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterToPointInTime.html) RDS API 작업은 DB 클러스터만 복원하고, 해당 DB 클러스터의 DB 인스턴스는 복원하지 않습니다. RDS API 작업 [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html)를 호출하여 복원된 DB 클러스터의 기본 인스턴스를 만듭니다. `DBClusterIdentifier`에서 복원된 DB 클러스터의 식별자를 지정합니다. `RestoreDBClusterToPointInTime` 작업이 완료되고 DB 클러스터를 사용할 수 있어야만 DB 인스턴스를 생성할 수 있습니다.
### DB 클러스터의 계정 간 복제본 여부 확인
`DBClusters` 객체는 각 클러스터의 계정 간 복제본 여부를 식별합니다. RDS CLI 명령인 [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html)를 실행할 때 `describe-db-clusters` 옵션을 사용해 자신에게 복제 권한이 있는 클러스터를 알아볼 수 있습니다. 하지만 해당 클러스터의 구성 세부 정보는 대부분 볼 수 없습니다.
#### AWS CLI
**DB 클러스터가 교차 계정 복제인지 확인하려면**
+ RDS CLI 명령인 [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html)를 호출합니다.
다음 예제는 실제 또는 잠재적 계정 간 복제 DB 클러스터가 `describe-db-clusters` 출력 시 어떻게 표시되는지 나타낸 것입니다. AWS 계정에서 소유하고 있는 기존 계정이라면 `CrossAccountClone` 필드에서 클러스터가 다른 AWS 계정에서 소유하고 있는 DB 클러스터의 복제본인지 알 수 있습니다.
경우에 따라 AWS 필드에 자신과 다른 `DBClusterArn` 계정 번호의 항목이 존재할 수 있습니다. 이러한 경우 해당 항목은 다른 AWS 계정에서 소유하고 있지만 자신이 복제할 수 있는 클러스터라는 것을 의미합니다. 이러한 항목은 `DBClusterArn` 외에 다른 필드가 거의 없습니다. 복제 클러스터를 생성할 때는 `StorageEncrypted`, `Engine` 및 `EngineVersion` 값을 원본 클러스터와 동일하게 지정합니다.
```
$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
]
}
```
#### RDS API
**DB 클러스터가 교차 계정 복제인지 확인하려면**
+ RDS API 작업인 [DescribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html)를 호출합니다.
AWS 계정에서 소유하고 있는 기존 계정이라면 `CrossAccountClone` 필드에서 클러스터가 다른 AWS 계정에서 소유하고 있는 DB 클러스터의 복제본인지 알 수 있습니다. AWS 필드에서 `DBClusterArn` 계정 번호가 다른 항목은 복제가 가능하지만 다른 AWS 계정에서 소유하고 있는 클러스터라는 것을 의미합니다. 이러한 항목은 `DBClusterArn` 외에 다른 필드가 거의 없습니다. 복제 클러스터를 생성할 때는 `StorageEncrypted`, `Engine` 및 `EngineVersion` 값을 원본 클러스터와 동일하게 지정합니다.
다음 예제는 실제 복제 클러스터와 잠재적 복제 클러스터를 모두 시연한 반환 값을 나타낸 것입니다.
```
{
"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"
}
]
}
```