

# Amazon Aurora DB 클러스터 관리
<a name="CHAP_Aurora"></a>

 이번 섹션에서는 Aurora DB 클러스터를 관리하고 유지하는 방법에 대해 설명합니다. Aurora는 복제 토폴로지에서 연결된 데이터베이스 서버의 클러스터와 관련 있습니다. 따라서 Aurora 관리를 위해서는 여러 개의 서버로 변경 사항을 배포하고 모든 Aurora 복제본이 소스 서버를 따라잡는지 확인해야 하는 경우가 종종 있습니다. Aurora은 데이터 증가에 따라 기반 스토리지를 투명하게 확장하기 때문에 Aurora 관리 시 디스크 스토리지를 관리할 필요가 거의 없습니다. 마찬가지로 Aurora은 연속 백업을 자동으로 수행하기 때문에 Aurora 클러스터에서는 백업 수행을 위한 광범위한 계획 또는 다운타임이 필요하지 않습니다.

**Topics**
+ [Amazon Aurora DB 클러스터 중지 및 시작](aurora-cluster-stop-start.md)
+ [EC2 인스턴스와 Aurora DB 클러스터를 자동으로 연결](ec2-rds-connect.md)
+ [Lambda 함수와 Aurora DB 클러스터 자동 연결](lambda-rds-connect.md)
+ [Amazon Aurora DB 클러스터 수정](Aurora.Modifying.md)
+ [DB 클러스터에 Aurora 복제본 추가](aurora-replicas-adding.md)
+ [Aurora DB 클러스터의 성능 및 확장 관리](Aurora.Managing.Performance.md)
+ [Aurora DB 클러스터에 대한 볼륨 복제](Aurora.Managing.Clone.md)
+ [Aurora를 다른 AWS 서비스와 통합](Aurora.Integrating.md)
+ [Amazon Aurora DB 클러스터 유지 관리](USER_UpgradeDBInstance.Maintenance.md)
+ [Amazon Aurora DB 클러스터 또는 Amazon Aurora DB 인스턴스 재부팅](USER_RebootCluster.md)
+ [Amazon Aurora DB 클러스터 장애 조치](aurora-failover.md)
+ [Aurora DB 클러스터 및 DB 인스턴스 삭제](USER_DeleteCluster.md)
+ [Amazon Aurora 및Amazon RDS 리소스에 태그 지정](USER_Tagging.md)
+ [Amazon RDS의 Amazon 리소스 이름(ARN)](USER_Tagging.ARN.md)
+ [Amazon Aurora 업데이트](Aurora.Updates.md)

# Amazon Aurora DB 클러스터 중지 및 시작
<a name="aurora-cluster-stop-start"></a>

Aurora DB 클러스터를 중지하고 시작하면 개발 및 테스트 환경 비용을 관리하는 데 도움이 됩니다. 클러스터를 사용할 때마다 모든 DB 인스턴스를 설정 및 해제하는 대신 클러스터의 모든 DB 인스턴스를 일시적으로 중지할 수 있습니다.

**Topics**
+ [Aurora DB 클러스터의 중지 및 시작 개요](#aurora-cluster-start-stop-overview)
+ [Aurora DB 클러스터 중지 및 시작에 대한 제한 사항](#aurora-cluster-stop-limitations)
+ [Aurora DB 클러스터 중지](#aurora-cluster-stop)
+ [Aurora DB 클러스터가 중지된 상태에서 가능한 작업](#aurora-cluster-stopped)
+ [Aurora DB 클러스터 시작](#aurora-cluster-start)

## Aurora DB 클러스터의 중지 및 시작 개요
<a name="aurora-cluster-start-stop-overview"></a>

Aurora DB 클러스터가 필요하지 않은 기간에는 이 클러스터의 모든 인스턴스를 한번에 중지할 수 있습니다. 사용해야 할 때는 언제든지 클러스터를 다시 시작할 수 있습니다. 시작 및 중지를 사용하면 개발, 테스트 또는 연속 가용성을 필요로 하지 않는 유사한 활동에 사용되는 클러스터의 설정 및 해제 프로세스가 간소화됩니다. 클러스터 내의 인스턴스 수와 관계없이 단일 작업만 관련된 모든 AWS Management Console 절차를 수행할 수 있습니다.

DB 클러스터가 중지되어 있는 동안에는 지정된 보존 기간 내 클러스터 스토리지, 수동 스냅샷 및 자동 백업 스토리지에 대한 비용만 청구됩니다. DB 인스턴스 시간에 대해서는 요금이 부과되지 않습니다

**중요**  
DB 클러스터는 최대 7일간 중지할 수 있습니다. 7일이 경과한 후 DB 클러스터를 수동으로 시작하지 않으면 DB 클러스터가 자동으로 시작되므로 필요한 유지 관리 업데이트가 지체되지 않습니다.

로드가 적은 Aurora 클러스터의 요금을 최소화하려면 Aurora 복제본을 모두 삭제하는 대신 클러스터를 중지할 수 있습니다. 1\$12개 이상의 인스턴스가 있는 클러스터의 경우 AWS CLI 또는 Amazon RDS API를 사용하여 DB 인스턴스를 자주 삭제하고 다시 생성하는 방법만 실용적입니다. 이러한 일련의 작업은 올바른 순서대로 수행하기 어려울 수도 있습니다(예를 들어 기본 인스턴스를 삭제하기 전에 모든 Aurora 복제본을 삭제하여 장애 조치 메커니즘 활성화를 방지).

DB 클러스터를 계속 실행해야 하지만 필요 이상 용량이 크면 시작 및 중지를 사용하지 마십시오. 클러스터의 비용이 너무 많이 들거나 사용량이 많지 않은 경우 하나 이상의 DB 인스턴스를 삭제하거나 모든 DB 인스턴스를 스몰 인스턴스 클래스로 변경하십시오. 개별 Aurora DB 인스턴스는 중지할 수 없습니다.

DB 클러스터를 중지하는 데 걸리는 시간은 DB 인스턴스 클래스, 네트워크 상태, DB 엔진 유형, 데이터베이스 상태 등의 요인에 따라 달라집니다. 프로세스에는 몇 분이 걸릴 수 있습니다. Amazon RDS 서비스가 수행하는 작업은 다음과 같습니다.
+ 데이터베이스 엔진 프로세스를 종료합니다.
+ RDS 플랫폼 프로세스를 종료합니다.
+ 기본 Amazon EC2 인스턴스를 종료합니다.

DB 클러스터를 재시작하는 데 걸리는 시간은 데이터베이스 크기, DB 인스턴스 클래스, 네트워크 상태, DB 엔진 유형 및 클러스터 종료 시 데이터베이스 상태 등의 요인에 따라 달라집니다. 시작 프로세스는 몇 분에서 몇 시간이 걸릴 수 있지만, 일반적으로 몇 분이면 완료됩니다. 가용성 계획을 세울 때는 시작 시간의 변동성을 고려하는 것이 좋습니다.

서비스는 DB 클러스터를 시작하기 위해 다음과 같은 작업을 수행합니다.
+ 기본 Amazon EC2 인스턴스를 제공합니다.
+ RDS 플랫폼 프로세스를 시작합니다.
+ 데이터베이스 엔진 프로세스를 시작합니다.
+ DB 인스턴스를 복구합니다(정상 종료 후에도 복구 수행).

## Aurora DB 클러스터 중지 및 시작에 대한 제한 사항
<a name="aurora-cluster-stop-limitations"></a>

다음과 같은 일부 Aurora 클러스터는 중지 및 시작이 불가능합니다.
+ [Aurora Global Database](aurora-global-database.md)의 일부인 클러스터는 글로벌 데이터베이스의 유일한 클러스터인 경우에만 중지하고 시작할 수 있습니다.
+ 리전 간 읽기 전용 복제본이 있는 클러스터를 중지하고 시작할 수 없습니다.
+ [블루/그린](blue-green-deployments.md) 배포의 일부인 클러스터는 중지 및 시작이 불가능합니다.
+ [Aurora Serverless v1 클러스터](aurora-serverless.md)를 중지하거나 시작할 수 없습니다. [Aurora Serverless v2](aurora-serverless-v2.md)에서는 클러스터를 중지하거나 시작할 수 없습니다.

## Aurora DB 클러스터 중지
<a name="aurora-cluster-stop"></a>

Aurora DB 클러스터를 사용하거나 관리를 수행하려면 항상 실행 중인 Aurora DB 클러스터로 실행한 후 클러스터를 중지한 다음 클러스터를 다시 시작하십시오. 클러스터가 중지되어 있는 동안에는 DB 인스턴스 시간이 아니라 지정된 보존 기간 내 클러스터 스토리지, 수동 스냅샷 및 자동 백업 스토리지에 대한 비용이 청구됩니다.

중지 작업은 장애 조치 메커니즘 활성화를 피하기 위해 Aurora 복제본 인스턴스를 먼저 중지한 후 기본 인스턴스를 중지합니다.

### 콘솔
<a name="aurora-stop-cluster.CON"></a>

**Aurora 클러스터를 중지하려면**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.

1. 탐색 창에서 **Databases(데이터베이스)**를 선택한 후 클러스터를 선택합니다. 이 페이지에서 중지 작업을 수행하거나 중지하려는 DB 클러스터의 세부 정보 페이지로 이동하세요.

1. **Actions**(작업)에서 **Stop temporarily**(일시적으로 중지)를 선택합니다.

1. **Stop DB cluster temporarily**(DB 클러스터 일시적으로 중지) 창에서 DB 클러스터가 7일 후에 자동으로 다시 시작된다는 확인을 선택합니다.

1. **Stop temporarily**(일시적으로 중지)를 선택하여 DB 클러스터를 중지하거나 **Cancel**(취소)을 선택하여 작업을 취소합니다.

### AWS CLI
<a name="aurora-stop-cluster.CLI"></a>

AWS CLI를 사용하여 DB 인스턴스를 중지하려면 다음 파라미터와 함께 [stop-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/stop-db-cluster.html) 명령을 호출하십시오.
+ `--db-cluster-identifier` – Aurora 클러스터의 이름입니다.

**Example**  

```
aws rds stop-db-cluster --db-cluster-identifier mydbcluster
```

### RDS API
<a name="aurora-stop-cluster.API"></a>

Amazon RDS API를 사용하여 DB 인스턴스를 중지하려면 다음 파라미터와 함께 [StopDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_StopDBCluster.html) 작업을 호출하십시오.
+ `DBClusterIdentifier` – Aurora 클러스터의 이름입니다.

## Aurora DB 클러스터가 중지된 상태에서 가능한 작업
<a name="aurora-cluster-stopped"></a>

 Aurora 클러스터가 중지되어 있는 동안, 지정된 자동 백업 보존 기간 내에서 원하는 시점으로 특정 시점 복원을 수행할 수 있습니다. 특정 시점으로 복원에 대한 세부 정보는 [데이터 복구](Aurora.Managing.Backups.md#Aurora.Managing.Backups.Restore) 단원을 참조하십시오.

 클러스터가 중지된 동안 Aurora DB 클러스터 또는 해당 DB 인스턴스의 구성을 수정할 수 없습니다. 또한 클러스터에서 DB 인스턴스를 추가하거나 제거할 수 없으며 연결된 DB 인스턴스가 있는 경우에도 클러스터를 삭제할 수 없습니다. 이러한 관리 작업을 수행하기 전에 클러스터를 시작해야 합니다.

DB 클러스터를 중지하면 DB 클러스터 파라미터 그룹 또는 DB 클러스터 인스턴스의 DB 파라미터 그룹을 제외한 보류 중인 작업이 제거됩니다.

 Aurora은 다시 시작한 후 중지된 클러스터에 예약 유지보수를 적용합니다. 7일 후 Aurora은 중지된 클러스터를 자동으로 시작하므로 유지 관리 상태에서 너무 늦어지지 않는다는 점을 기억하십시오.

 Aurora는 클러스터가 중지된 동안 기본 데이터를 변경할 수 없기 때문에 백업 자동화도 수행하지 않습니다. Aurora는 클러스터가 중지되는 동안 백업 보존 기간을 연장하지 않습니다.

## Aurora DB 클러스터 시작
<a name="aurora-cluster-start"></a>

항상 이미 중지 상태인 Aurora 클러스터로 시작하는 Aurora DB 클러스터를 시작합니다. 클러스터를 시작하면 모든 DB 인스턴스가 다시 사용 가능하게 됩니다. 클러스터는 엔드포인트, 파라미터 그룹 및 VPC 보안 그룹과 같은 구성 설정을 유지합니다.

DB 클러스터를 시작하는 데는 보통 몇 분 정도 걸립니다.

### 콘솔
<a name="aurora-start-cluster.CON"></a>

**Aurora 클러스터를 시작하려면**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.

1.  탐색 창에서 **Databases(데이터베이스)**를 선택한 후 클러스터를 선택합니다. 이 페이지에서 시작 작업을 수행하거나 시작하려는 DB 클러스터의 세부 정보 페이지로 이동하세요.

1.  **Actions(작업)**에는 **Start(시작)**을 선택합니다.

### AWS CLI
<a name="aurora-start-cluster.CLI"></a>

AWS CLI를 사용하여 DB 클러스터를 시작하려면 다음 파라미터와 함께 [start-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/start-db-cluster.html) 명령을 호출하십시오.
+ `--db-cluster-identifier` – Aurora 클러스터의 이름입니다. 이 이름은 클러스터를 생성할 때 선택한 특정 클러스터 식별자이거나 끝에 `-cluster`가 추가된 상태에서 선택한 DB 인스턴스 식별자입니다.

**Example**  

```
aws rds start-db-cluster --db-cluster-identifier mydbcluster
```

### RDS API
<a name="aurora-start-cluster.API"></a>

Amazon RDS API를 사용하여 Aurora DB 클러스터를 시작하려면 다음 파라미터와 함께 [StartDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_StartDBCluster.html) 작업을 호출하십시오 
+ `DBCluster` – Aurora 클러스터의 이름입니다. 이 이름은 클러스터를 생성할 때 선택한 특정 클러스터 식별자이거나 끝에 `-cluster`가 추가된 상태에서 선택한 DB 인스턴스 식별자입니다.

# EC2 인스턴스와 Aurora DB 클러스터를 자동으로 연결
<a name="ec2-rds-connect"></a>

Amazon RDS 콘솔을 사용하여 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스와 Aurora DB 클러스터 간의 연결 설정을 간소화할 수 있습니다. DB 클러스터는 프라이빗 서브넷에 있고, EC2 인스턴스는 VPC 내의 퍼블릭 서브넷에 있는 경우가 많습니다. EC2 인스턴스의 SQL 클라이언트를 사용하여 DB 클러스터에 연결할 수 있습니다. EC2 인스턴스는 프라이빗 DB 클러스터에 액세스하는 웹 서버 또는 애플리케이션을 실행할 수도 있습니다. 

![\[Aurora DB 클러스터와 EC2 인스턴스를 자동으로 연결합니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/auto-connect-aurora-ec2.png)


Aurora DB 클러스터와 동일한 VPC에 있지 않은 EC2 인스턴스에 연결하려는 경우 [VPC에서 DB 클러스터에 액세스하는 시나리오](USER_VPC.Scenarios.md)의 시나리오를 참조하세요.

**Topics**
+ [EC2 인스턴스와의 자동 연결 개요](#ec2-rds-connect-overview)
+ [EC2 인스턴스와 Aurora DB 클러스터 자동 연결](#ec2-rds-connect-connecting)
+ [연결된 컴퓨팅 리소스 보기](#ec2-rds-connect-viewing)
+ [특정 DB 엔진을 실행하는 DB 인스턴스에 연결](#ec2-rds-Connect-DBEngine)

## EC2 인스턴스와의 자동 연결 개요
<a name="ec2-rds-connect-overview"></a>

EC2 인스턴스와 Aurora DB 클러스터 간의 연결을 설정하는 경우 Amazon RDS는 EC2 인스턴스 및 DB 클러스터에 VPC 보안 그룹을 자동으로 구성합니다.

다음은 EC2 인스턴스를 Aurora DB 클러스터와 연결하기 위한 요구 사항입니다.
+ EC2 인스턴스는 DB 클러스터와 동일한 VPC 있어야 합니다.

  EC2 인스턴스가 동일한 VPC에 없는 경우 콘솔은 EC2 인스턴스를 생성하기 위한 링크를 제공합니다.
+ 현재 DB 클러스터는 Aurora Serverless DB 클러스터일 수 없으며 Aurora Global Database의 일부일 수도 없습니다.
+ 연결을 설정하는 사용자는 다음 Amazon EC2 작업을 수행할 수 있는 권한이 있어야 합니다.
  + `ec2:AuthorizeSecurityGroupEgress` 
  + `ec2:AuthorizeSecurityGroupIngress` 
  + `ec2:CreateSecurityGroup` 
  + `ec2:DescribeInstances` 
  + `ec2:DescribeNetworkInterfaces` 
  + `ec2:DescribeSecurityGroups` 
  + `ec2:ModifyNetworkInterfaceAttribute` 
  + `ec2:RevokeSecurityGroupEgress` 

DB 인스턴스와 EC2 인스턴스가 서로 다른 가용 영역에 있는 경우 계정에 교차 가용 영역 비용이 발생할 가능성이 있습니다.

EC2 인스턴스에 대한 연결을 설정하면 Amazon RDS는 다음 테이블에 설명된 대로 DB 클러스터 및 EC2 인스턴스와 연결된 보안 그룹의 현재 구성을 기반으로 조치를 취합니다.


****  

| 현재 RDS 보안 그룹 구성 | 현재 EC2 보안 그룹 구성 | RDS 작업 | 
| --- | --- | --- | 
|  `rds-ec2-n`(`n`은 숫자를 나타냄) 패턴과 일치하는 이름을 가진 DB 클러스터와 연결된 보안 그룹이 하나 이상 있습니다. 해당 패턴과 일치하는 보안 그룹이 수정되지 않았습니다. 이 보안 그룹에는 EC2 인스턴스의 VPC 보안 그룹을 소스로 하는 인바운드 규칙이 하나만 포함됩니다.  |  `ec2-rds-n`(`n`은 숫자를 나타냄) 패턴과 일치하는 이름을 가진 EC2 인스턴스와 연결된 보안 그룹이 하나 이상 있습니다. 해당 패턴과 일치하는 보안 그룹이 수정되지 않았습니다. 이 보안 그룹에는 DB 클러스터의 VPC 보안 그룹을 소스로 하는 아웃바운드 규칙이 하나만 포함됩니다.  |  RDS는 아무 작업도 수행하지 않습니다. EC2 인스턴스와 DB 클러스터 간의 연결이 이미 자동으로 구성되었습니다. EC2 인스턴스와 RDS 데이터베이스 사이에 이미 연결이 존재하기 때문에 보안 그룹은 수정되지 않습니다.  | 
|  다음 중 하나의 조건이 적용됩니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/ec2-rds-connect.html)  |  다음 중 하나의 조건이 적용됩니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/ec2-rds-connect.html)  |  [RDS action: create new security groups](#rds-action-create-new-security-groups)  | 
|  `rds-ec2-n` 패턴과 일치하는 이름을 가진 DB 클러스터와 연결된 보안 그룹이 하나 이상 있습니다. 해당 패턴과 일치하는 보안 그룹이 수정되지 않았습니다. 이 보안 그룹에는 EC2 인스턴스의 VPC 보안 그룹을 소스로 하는 인바운드 규칙이 하나만 포함됩니다.  |  `ec2-rds-n` 패턴과 일치하는 이름을 가진 EC2 인스턴스와 연결된 보안 그룹이 하나 이상 있습니다. 그러나 Amazon RDS는 DB 클러스터와의 연결에 이러한 보안 그룹을 사용할 수 없습니다. Amazon RDS는 DB 클러스터의 VPC 보안 그룹을 소스로 하는 아웃바운드 규칙 하나가 포함되지 않은 보안 그룹을 사용할 수 없습니다. 또한 수정된 보안 그룹을 사용할 수 없습니다.  |  [RDS action: create new security groups](#rds-action-create-new-security-groups)  | 
|  `rds-ec2-n` 패턴과 일치하는 이름을 가진 DB 클러스터와 연결된 보안 그룹이 하나 이상 있습니다. 해당 패턴과 일치하는 보안 그룹이 수정되지 않았습니다. 이 보안 그룹에는 EC2 인스턴스의 VPC 보안 그룹을 소스로 하는 인바운드 규칙이 하나만 포함됩니다.  |  연결에 유효한 EC2 보안 그룹이 있지만 EC2 인스턴스와 연결되어 있지 않습니다. 이 보안 그룹의 이름이 `ec2-rds-n` 패턴과 일치합니다. 수정되지 않았습니다. 여기에는 DB 클러스터의 VPC 보안 그룹을 소스로 하는 아웃바운드 규칙이 하나만 포함됩니다.  |  [RDS action: associate EC2 security group](#rds-action-associate-ec2-security-group)  | 
|  다음 중 하나의 조건이 적용됩니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/ec2-rds-connect.html)  |  `ec2-rds-n` 패턴과 일치하는 이름을 가진 EC2 인스턴스와 연결된 보안 그룹이 하나 이상 있습니다. 해당 패턴과 일치하는 보안 그룹이 수정되지 않았습니다. 이 보안 그룹에는 DB 클러스터의 VPC 보안 그룹을 소스로 하는 아웃바운드 규칙이 하나만 포함됩니다.  |  [RDS action: create new security groups](#rds-action-create-new-security-groups)  | 

**RDS 작업: 새 보안 그룹 생성**  
Amazon RDS에서 다음 작업을 수행합니다.
+ `rds-ec2-n` 패턴과 일치하는 새 보안 그룹을 생성합니다. 이 보안 그룹에는 EC2 인스턴스의 VPC 보안 그룹을 소스로 하는 인바운드 규칙이 하나 포함됩니다. 이 보안 그룹은 DB 클러스터와 연결되어 있으며 EC2 인스턴스가 DB 클러스터에 액세스하도록 허용합니다.
+ `ec2-rds-n` 패턴과 일치하는 새 보안 그룹을 생성합니다. 이 보안 그룹에는 DB 클러스터의 VPC 보안 그룹을 대상으로 하는 아웃바운드 규칙이 하나 포함됩니다. 이 보안 그룹은 EC2 인스턴스와 연결되어 있으며 EC2 인스턴스가 DB 클러스터에 트래픽을 보내도록 허용합니다.

**RDS 작업: EC2 보안 그룹 연결**  
Amazon RDS는 유효한 기존 EC2 보안 그룹을 EC2 인스턴스와 연결합니다. 이 보안 그룹은 EC2 인스턴스가 DB 클러스터에 트래픽을 보내도록 허용합니다.

## EC2 인스턴스와 Aurora DB 클러스터 자동 연결
<a name="ec2-rds-connect-connecting"></a>

EC2 인스턴스와 Aurora DB 클러스터 간의 연결을 설정하기 전에 [EC2 인스턴스와의 자동 연결 개요](#ec2-rds-connect-overview)에 설명된 요구 사항을 충족하는지 확인하세요.

연결을 구성한 후에 보안 그룹을 변경할 경우 변경 사항이 EC2 인스턴스와 Aurora DB 클러스터 간의 연결에 영향을 미칠 수 있습니다.

**참고**  
AWS Management Console을 사용해야만 EC2 인스턴스와 Aurora DB 클러스터 간의 연결을 자동으로 설정할 수 있습니다. AWS CLI 또는 RDS API로는 연결을 자동으로 설정할 수 없습니다.

**EC2 인스턴스와 Aurora DB 클러스터를 자동으로 연결하는 방법**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.

1. 탐색 창에서 **데이터베이스**를 선택하고 DB 클러스터를 선택합니다.

1. **작업**에서 **EC2 연결 설정**을 선택합니다.

   **EC2 연결 설정** 페이지가 나타납니다.

1. **EC2 연결 설정** 페이지에서 EC2 인스턴스를 선택합니다.  
![\[EC2 연결 설정 페이지.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/auto-connect-rds-ec2-set-up.png)

   동일한 VPC에 EC2 인스턴스가 없는 경우 **EC2 인스턴스 생성**을 선택하여 인스턴스를 생성합니다. 이 경우 새 EC2 인스턴스가 DB 클러스터와 동일한 VPC 있어야 합니다.

1. **계속**을 선택합니다.

   **검토 및 확인** 페이지가 나타납니다.  
![\[EC2 연결 검토 및 확인 페이지.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/auto-connect-rds-ec2-confirm.png)

1. **검토 및 확인** 페이지에서 RDS가 EC2 인스턴스와의 연결을 설정하기 위해 적용할 변경 사항을 검토합니다.

   변경 내용이 올바르면 **확인 및 설정**을 선택합니다.

   변경 내용이 올바르지 않으면 **이전** 또는 **취소**를 선택합니다.

## 연결된 컴퓨팅 리소스 보기
<a name="ec2-rds-connect-viewing"></a>

AWS Management Console을 사용하여 Aurora DB 클러스터에 연결된 컴퓨팅 리소스를 볼 수 있습니다. 표시되는 리소스에는 자동으로 설정된 컴퓨팅 리소스 연결이 포함됩니다. 다음과 같은 방법으로 컴퓨팅 리소스와의 연결을 자동으로 설정할 수 있습니다.
+ 데이터베이스를 생성할 때 컴퓨팅 리소스를 선택할 수 있습니다.

  자세한 내용은 [Amazon Aurora DB 클러스터 생성](Aurora.CreateInstance.md) 섹션을 참조하세요.
+ 기존 데이터베이스와 컴퓨팅 리소스 간의 연결을 설정할 수 있습니다.

  자세한 내용은 [EC2 인스턴스와 Aurora DB 클러스터 자동 연결](#ec2-rds-connect-connecting) 섹션을 참조하세요.

나열된 컴퓨팅 리소스에는 데이터베이스에 수동으로 연결된 리소스는 포함되지 않습니다. 예를 들어 데이터베이스와 연결된 VPC 보안 그룹에 규칙을 추가하여 컴퓨팅 리소스가 데이터베이스에 수동으로 액세스하도록 허용할 수 있습니다.

컴퓨팅 리소스가 나열되려면 다음 조건이 적용되어야 합니다.
+ 컴퓨팅 리소스와 연결된 보안 그룹의 이름은 패턴 `ec2-rds-n`(여기서`n`은 숫자)과 일치합니다.
+ 컴퓨팅 리소스와 연결된 보안 그룹에는 포트 범위가 DB 클러스터에서 사용하는 포트로 설정된 아웃바운드 규칙이 있습니다.
+ 컴퓨팅 리소스와 연결된 보안 그룹에는 소스가 DB 클러스터에 연결된 보안 그룹으로 설정된 아웃바운드 규칙이 있습니다.
+ DB 클러스터와 연결된 보안 그룹의 이름은 패턴 `rds-ec2-n`(여기서 `n`은 숫자)과 일치합니다.
+ DB 클러스터와 연결된 보안 그룹에는 포트 범위가 DB 클러스터에서 사용하는 포트로 설정된 인바운드 규칙이 있습니다.
+ DB 클러스터와 연결된 보안 그룹에는 소스가 컴퓨팅 리소스에 연결된 보안 그룹으로 설정된 인바운드 규칙이 있습니다.

**Aurora DB 클러스터에 연결된 컴퓨팅 리소스를 보는 방법**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.

1. 탐색 창에서 **데이터베이스**를 선택한 다음 DB 클러스터의 이름을 선택합니다.

1. **연결 및 보안** 탭의 **연결된 컴퓨팅 리소스**에서 컴퓨팅 리소스를 확인합니다.  
![\[연결된 컴퓨팅 리소스.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/ec2-connected-compute-resources.png)

## 특정 DB 엔진을 실행하는 DB 인스턴스에 연결
<a name="ec2-rds-Connect-DBEngine"></a>

특정 DB 엔진을 실행하는 DB 인스턴스에 연결하는 방법에 대한 자세한 내용은 DB 엔진의 지침을 따르세요.
+ [Amazon Aurora MySQL DB 클러스터에 연결](Aurora.Connecting.md#Aurora.Connecting.AuroraMySQL)
+ [Amazon Aurora PostgreSQL DB 클러스터에 연결](Aurora.Connecting.md#Aurora.Connecting.AuroraPostgreSQL)

# Lambda 함수와 Aurora DB 클러스터 자동 연결
<a name="lambda-rds-connect"></a>

Amazon RDS 콘솔을 사용하여 Lambda 함수와 Aurora DB 클러스터 간의 연결 설정을 간소화할 수 있습니다. DB 클러스터가 VPC 내 프라이빗 서브넷에 있는 경우가 많습니다. 애플리케이션에서 프라이빗 DB 클러스터에 액세스하는 데 Lambda 함수를 사용할 수 있습니다.



다음 이미지는 DB 클러스터와 Lambda 함수 간의 직접 연결을 보여줍니다.

![\[Aurora DB 클러스터와 Lambda 함수 자동 연결\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/auto-connect-aurora-lambda.png)


RDS 프록시를 통해 Lambda 함수와 DB 클러스터 간의 연결을 설정하여 데이터베이스 성능과 복원력을 개선할 수 있습니다. Lambda 함수는 RDS 프록시가 제공하는 연결 풀링의 이점을 누릴 수 있는 단기 데이터베이스 연결을 자주 만드는 경우가 많습니다. Lambda 애플리케이션 코드에서 데이터베이스 보안 인증 정보를 관리하는 대신 Lambda 함수에 대해 이미 가지고 있는 AWS Identity and Access Management(IAM) 인증을 활용할 수 있습니다. 자세한 내용은 [Aurora용 Amazon RDS Proxy](rds-proxy.md) 섹션을 참조하세요.

콘솔을 사용하여 기존 프록시에 연결하면 Amazon RDS가 DB 클러스터와 Lambda 함수 간의 연결을 허용하도록 프록시 보안 그룹을 업데이트합니다.

동일한 콘솔 페이지에서 새 프록시를 만들 수도 있습니다. 콘솔에서 프록시를 만들 때 DB 클러스터에 액세스하려면 데이터베이스 보안 인증 정보를 입력하거나 AWS Secrets Manager 보안 암호를 선택해야 합니다.

![\[RDS 프록시를 통해 Aurora DB 클러스터와 Lambda 함수 자동 연결\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/auto-connect-aurora-lambda-Proxy.png)


**작은 정보**  
Lambda 함수를 Aurora DB 클러스터에 빠르게 연결하려면 콘솔 내 안내 마법사를 사용할 수도 있습니다. 마법사에서 다음을 수행합니다.  
Lambda 콘솔의 [함수 페이지](https://console.aws.amazon.com/lambda/home#/functions)를 엽니다.
데이터베이스를 연결할 함수를 선택합니다.
**구성** 탭에서 **RDS 데이터베이스**를 선택합니다.
**RDS 데이터베이스에 연결**을 선택합니다.
함수를 데이터베이스에 연결한 후 **프록시 추가**를 선택하여 프록시를 생성할 수 있습니다.

**Topics**
+ [Lambda 함수와의 자동 연결 개요](#lambda-rds-connect-overview)
+ [Lambda 함수와 Aurora DB 클러스터 자동 연결](#lambda-rds-connect-connecting)
+ [연결된 컴퓨팅 리소스 보기](#lambda-rds-connect-viewing)

## Lambda 함수와의 자동 연결 개요
<a name="lambda-rds-connect-overview"></a>

다음은 Lambda 함수를 Aurora DB 클러스터와 연결하기 위한 요구 사항입니다.
+ Lambda 함수가 DB 클러스터와 같은 VPC에 있어야 합니다.
+ 현재 DB 클러스터는 Aurora Serverless DB 클러스터일 수 없으며 Aurora Global Database의 일부일 수도 없습니다.
+ 연결을 설정하는 사용자는 다음과 같은 Amazon RDS, Amazon EC2, Lambda, Secrets Manager 및 IAM 작업을 수행할 권한이 있어야 합니다.
  + Amazon RDS
    + `rds:CreateDBProxies`
    + `rds:DescribeDBClusters`
    + `rds:DescribeDBProxies`
    + `rds:ModifyDBCluster`
    + `rds:ModifyDBProxy`
    + `rds:RegisterProxyTargets`
  + Amazon EC2
    + `ec2:AuthorizeSecurityGroupEgress` 
    + `ec2:AuthorizeSecurityGroupIngress` 
    + `ec2:CreateSecurityGroup` 
    + `ec2:DeleteSecurityGroup`
    + `ec2:DescribeSecurityGroups` 
    + `ec2:RevokeSecurityGroupEgress` 
    + `ec2:RevokeSecurityGroupIngress`
  + Lambda
    + `lambda:CreateFunctions`
    + `lambda:ListFunctions`
    + `lambda:UpdateFunctionConfiguration`
  + Secrets Manager
    + `secretsmanager:CreateSecret`
    + `secretsmanager:DescribeSecret`
  + IAM
    + `iam:AttachPolicy`
    + `iam:CreateRole`
    + `iam:CreatePolicy`
  + AWS KMS
    + `kms:describeKey`

**참고**  
DB 클러스터 및 Lambda 함수가 서로 다른 가용 영역에 있는 경우 계정에 교차 가용 영역 비용이 발생할 수 있습니다.

Lambda 함수와 Aurora DB 클러스터 간의 연결을 자동으로 설정할 때 RDS는 함수 및 DB 클러스터에 대한 VPC 보안 그룹을 구성합니다. RDS 프록시를 사용하는 경우 Amazon RDS는 프록시에 대한 VPC 보안 그룹도 구성합니다. Amazon RDS는 다음 테이블에 설명된 것과 같이 DB 클러스터, Lambda 함수 및 프록시와 관련된 보안 그룹의 현재 구성에 따라 작동합니다.


| 현재 RDS 보안 그룹 구성 | 현재 Lambda 보안 그룹 구성 | 현재 프록시 보안 그룹 구성 | RDS 작업 | 
| --- | --- | --- | --- | 
|  이름이 `rds-lambda-n` 패턴과 일치하며 DB 클러스터와 연결된 보안 그룹이 하나 이상 있습니다. 또는 프록시가 이미 DB 클러스터에 연결되어 있는 경우, RDS는 연결된 프록시의 `TargetHealth`가 `AVAILABLE`인지 확인합니다. 해당 패턴과 일치하는 보안 그룹이 수정되지 않았습니다. 이 보안 그룹에는 Lambda 함수 또는 프록시의 VPC 보안 그룹을 소스로 하는 인바운드 규칙이 하나만 있습니다.  |  이름이 `lambda-rds-n` 또는 `lambda-rdsproxy-n`(`n`은 숫자를 나타냄) 패턴과 일치하며 Lambda 함수와 연결된 보안 그룹이 하나 이상 있습니다. 해당 패턴과 일치하는 보안 그룹이 수정되지 않았습니다. 이 보안 그룹에는 DB 클러스터 또는 프록시의 VPC 보안 그룹을 대상으로 하는 아웃바운드 규칙이 하나만 있습니다.  |  이름이 `rdsproxy-lambda-n`(`n`은 숫자를 나타냄) 패턴과 일치하며 프록시와 연결된 보안 그룹이 하나 이상 있습니다. 해당 패턴과 일치하는 보안 그룹이 수정되지 않았습니다. 이 보안 그룹에는 Lambda 함수 및 DB 클러스터의 VPC 보안 그룹이 포함된 인바운드 및 아웃바운드 규칙이 있습니다.  |  Amazon RDS는 아무런 조치도 취하지 않습니다. Lambda 함수, 프록시(선택 사항) 및 DB 클러스터 간에 연결이 이미 자동으로 구성되었습니다. 함수, 프록시, 데이터베이스 사이에 이미 연결이 존재하기 때문에 보안 그룹은 수정되지 않습니다.  | 
|  다음 중 하나의 조건이 적용됩니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/lambda-rds-connect.html) Amazon RDS는 Lambda 함수 또는 프록시의 VPC 보안 그룹을 소스로 하는 인바운드 규칙 하나가 포함되지 않은 보안 그룹을 사용할 수 없습니다. 또한 수정된 보안 그룹을 사용할 수 없습니다. 수정 사항의 예로는 규칙 추가 또는 기존 규칙의 포트 변경이 있습니다.  |  다음 중 하나의 조건이 적용됩니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/lambda-rds-connect.html) Amazon RDS는 DB 클러스터 또는 프록시의 VPC 보안 그룹을 대상으로 하는 아웃바운드 규칙 하나가 포함되지 않은 보안 그룹을 사용할 수 없습니다. 또한 수정된 보안 그룹을 사용할 수 없습니다.  | 다음 중 하나의 조건이 적용됩니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/lambda-rds-connect.html)Amazon RDS는 DB 클러스터 및 Lambda 함수의 VPC 보안 그룹을 대상으로 하는 인바운드 및 아웃바운드 규칙이 포함되지 않은 보안 그룹을 사용할 수 없습니다. 또한 수정된 보안 그룹을 사용할 수 없습니다. |  [RDS action: create new security groups](#rds-lam-action-create-new-security-groups) | 
|  이름이 `rds-lambda-n` 패턴과 일치하며 DB 클러스터와 연결된 보안 그룹이 없거나 연결된 프록시의 `TargetHealth`가 `AVAILABLE`입니다. 해당 패턴과 일치하는 보안 그룹이 수정되지 않았습니다. 이 보안 그룹에는 Lambda 함수 또는 프록시의 VPC 보안 그룹을 소스로 하는 인바운드 규칙이 하나만 있습니다.  |  이름이 `lambda-rds-n` 또는 `lambda-rdsproxy-n` 패턴과 일치하며 Lambda 함수와 연결된 보안 그룹이 하나 이상 있습니다. 그러나 Amazon RDS는 DB 클러스터와의 연결에 이러한 보안 그룹을 사용할 수 없습니다. Amazon RDS는 DB 클러스터 또는 프록시의 VPC 보안 그룹을 대상으로 하는 아웃바운드 규칙 하나가 포함되지 않은 보안 그룹을 사용할 수 없습니다. 또한 수정된 보안 그룹을 사용할 수 없습니다.  |  이름이 `rdsproxy-lambda-n` 패턴과 일치하며 프록시와 연결된 보안 그룹이 하나 이상 있습니다. 그러나 Amazon RDS는 DB 클러스터 또는 Lambda 함수와의 연결에 이러한 보안 그룹을 사용할 수 없습니다. Amazon RDS는 DB 클러스터 및 Lambda 함수의 VPC 보안 그룹을 대상으로 하는 인바운드 및 아웃바운드 규칙이 포함되지 않은 보안 그룹을 사용할 수 없습니다. 또한 수정된 보안 그룹을 사용할 수 없습니다.  |  [RDS action: create new security groups](#rds-lam-action-create-new-security-groups) | 
|  이름이 `rds-lambda-n` 패턴과 일치하며 DB 클러스터와 연결된 보안 그룹이 없거나 연결된 프록시의 `TargetHealth`가 `AVAILABLE`입니다. 해당 패턴과 일치하는 보안 그룹이 수정되지 않았습니다. 이 보안 그룹에는 Lambda 함수 또는 프록시의 VPC 보안 그룹을 소스로 하는 인바운드 규칙이 하나만 있습니다.  |  연결에 유효한 Lambda 보안 그룹이 존재하지만 Lambda 함수와 연결되어 있지 않습니다. 이 보안 그룹의 이름이 `lambda-rds-n` 또는 `lambda-rdsproxy-n` 패턴과 일치합니다. 수정되지 않았습니다. DB 클러스터 또는 프록시의 VPC 보안 그룹을 대상으로 하는 아웃바운드 규칙이 하나만 있습니다.  |  연결에 유효한 프록시 보안 그룹이 있지만 프록시와 연결되어 있지 않습니다. 이 보안 그룹의 이름이 `rdsproxy-lambda-n` 패턴과 일치합니다. 수정되지 않았습니다. DB 클러스터와 Lambda 함수의 VPC 보안 그룹이 포함된 인바운드 및 아웃바운드 규칙이 있습니다.  |  [RDS action: associate Lambda security group](#rds-lam-action-associate-lam-security-group)  | 
|  다음 중 하나의 조건이 적용됩니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/lambda-rds-connect.html) Amazon RDS는 Lambda 함수 또는 프록시의 VPC 보안 그룹을 소스로 하는 인바운드 규칙 하나가 포함되지 않은 보안 그룹을 사용할 수 없습니다. 또한 수정된 보안 그룹을 사용할 수 없습니다.  |  이름이 `lambda-rds-n` 또는 `lambda-rdsproxy-n` 패턴과 일치하며 Lambda 함수와 연결된 보안 그룹이 하나 이상 있습니다. 해당 패턴과 일치하는 보안 그룹이 수정되지 않았습니다. 이 보안 그룹에는 DB 인스턴스 또는 프록시의 VPC 보안 그룹을 대상으로 하는 아웃바운드 규칙이 하나만 있습니다.  |  이름이 `rdsproxy-lambda-n` 패턴과 일치하며 프록시와 연결된 보안 그룹이 하나 이상 있습니다. 해당 패턴과 일치하는 보안 그룹이 수정되지 않았습니다. 이 보안 그룹에는 DB 클러스터 및 Lambda 함수의 VPC 보안 그룹이 포함된 인바운드 및 아웃바운드 규칙이 있습니다.  |  [RDS action: create new security groups](#rds-lam-action-create-new-security-groups) | 
|  다음 중 하나의 조건이 적용됩니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/lambda-rds-connect.html) Amazon RDS는 Lambda 함수 또는 프록시의 VPC 보안 그룹을 소스로 하는 인바운드 규칙 하나가 포함되지 않은 보안 그룹을 사용할 수 없습니다. 또한 수정된 보안 그룹을 사용할 수 없습니다.  |  다음 중 하나의 조건이 적용됩니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/lambda-rds-connect.html) Amazon RDS는 DB 클러스터 또는 프록시의 VPC 보안 그룹을 소스로 하는 아웃바운드 규칙 하나가 포함되지 않은 보안 그룹을 사용할 수 없습니다. 또한 수정된 보안 그룹을 사용할 수 없습니다.  | 다음 중 하나의 조건이 적용됩니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/lambda-rds-connect.html)Amazon RDS는 DB 클러스터 및 Lambda 함수의 VPC 보안 그룹을 대상으로 하는 인바운드 및 아웃바운드 규칙이 포함되지 않은 보안 그룹을 사용할 수 없습니다. 또한 수정된 보안 그룹을 사용할 수 없습니다. | [RDS action: create new security groups](#rds-lam-action-create-new-security-groups) | 

**RDS 작업: 새 보안 그룹 생성**  
Amazon RDS에서 다음 작업을 수행합니다.
+ RDS 프록시를 사용하도록 선택하는 경우, `rds-lambda-n` 또는 `rds-rdsproxy-n` 패턴과 일치하는 새 보안 그룹을 생성합니다. 이 보안 그룹에는 Lambda 함수 또는 프록시의 VPC 보안 그룹을 소스로 하는 인바운드 규칙이 하나 있습니다. 이 보안 그룹은 DB 클러스터와 연결되어 있으며, 함수가 DB 클러스터에 액세스하도록 허용합니다.
+ `lambda-rds-n` 또는 `lambda-rdsproxy-n` 패턴과 일치하는 새 보안 그룹을 생성합니다. 이 보안 그룹에는 DB 클러스터 또는 프록시의 VPC 보안 그룹을 대상으로 하는 아웃바운드 규칙이 하나 있습니다. 이 보안 그룹은 Lambda 함수와 연결되어 있으며, 함수가 트래픽을 DB 클러스터로 보내거나 프록시를 통해 보내도록 허용합니다.
+ `rdsproxy-lambda-n` 패턴과 일치하는 새 보안 그룹을 생성합니다. 이 보안 그룹에는 DB 클러스터 및 Lambda 함수의 VPC 보안 그룹이 포함된 인바운드 및 아웃바운드 규칙이 있습니다.

**RDS 작업: Lambda 보안 그룹 연결**  
Amazon RDS는 유효한 기존 Lambda 보안 그룹을 Lambda 함수와 연결합니다. 이 보안 그룹은 함수가 트래픽을 DB 클러스터로 보내거나 프록시를 통해 보내도록 허용합니다.

## Lambda 함수와 Aurora DB 클러스터 자동 연결
<a name="lambda-rds-connect-connecting"></a>

Amazon RDS 콘솔을 사용하여 Lambda 함수를 DB 클러스터에 자동으로 연결할 수 있습니다. 이렇게 하면 이러한 리소스 간의 연결을 설정하는 프로세스가 간소화됩니다.

RDS 프록시를 사용하여 연결에 프록시를 포함할 수도 있습니다. Lambda 함수는 RDS 프록시가 제공하는 연결 풀링의 이점을 누릴 수 있는 단기 데이터베이스 연결을 자주 만듭니다. Lambda 애플리케이션 코드에서 데이터베이스 보안 인증 정보를 관리하는 대신 Lambda 함수에 대해 이미 설정한 IAM 인증을 사용할 수도 있습니다.

**Lambda 연결 설정** 페이지를 사용하여 기존 DB 클러스터를 신규 및 기존 Lambda 함수에 연결할 수 있습니다. 이 설정 프로세스는 필요한 보안 그룹을 자동으로 설정합니다.

Lambda 함수와 DB 클러스터 간의 연결을 설정하기 전에 다음 요구 사항을 충족해야 합니다.
+ Lambda 함수와 DB 클러스터가 동일한 VPC에 있습니다.
+ 사용자 계정에 대한 올바른 권한이 있습니다. 요구 사항에 대한 자세한 내용은 [Lambda 함수와의 자동 연결 개요](#lambda-rds-connect-overview) 섹션을 참조하세요.

연결을 구성한 후에 보안 그룹을 변경할 경우 변경 사항이 Lambda 함수와 DB 클러스터 간의 연결에 영향을 미칠 수 있습니다.

**참고**  
AWS Management Console에서만 DB 클러스터와 Lambda 함수의 연결을 자동으로 설정할 수 있습니다. Lambda 함수를 연결하려면 DB 클러스터의 모든 인스턴스가 **사용 가능** 상태여야 합니다.

**Lambda 함수와 DB 클러스터를 자동으로 연결하는 방법**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.

1. 탐색 창에서 **데이터베이스**를 선택한 다음, Lambda 함수에 연결할 DB 클러스터를 선택합니다.

1. **작업**에서 **Lambda 연결 설정**을 선택합니다.

1. **Lambda 연결 설정** 페이지의 **Lambda 함수 선택**에서 다음 중 하나를 수행합니다.
   + DB 클러스터와 동일한 VPC에 기존 Lambda 함수가 있는 경우 **기존 함수 선택**을 선택하고 해당 함수를 선택합니다.
   + 동일한 VPC에 Lambda 함수가 없는 경우 **새 함수 생성**을 선택한 다음 **함수 이름**을 입력합니다. 기본 런타임은 Nodejs.18로 설정되어 있습니다. 연결 설정을 완료한 후 Lambda 콘솔에서 새 Lambda 함수의 설정을 수정할 수 있습니다.

1. (선택 사항) **RDS 프록시**에서 **RDS 프록시를 사용하여 연결**을 선택하고 다음 중 하나를 수행합니다.
   + 사용하려는 기존 프록시가 있는 경우 **기존 프록시 선택**을 선택하고 해당 프록시를 선택합니다.
   + 프록시가 없고 Amazon RDS에서 자동으로 프록시를 생성하도록 하려면 **새 프록시 생성**을 선택합니다. 그런 다음, **데이터베이스 보안 인증 정보**에서 다음 중 하나를 수행합니다.

     1. **데이터베이스 사용자 이름 및 암호**를 선택한 다음, DB 클러스터의 **사용자 이름**과 **암호**를 입력합니다.

     1. **Secrets Manager 보안 암호**를 선택합니다. 그런 다음, **보안 암호 선택**에서 AWS Secrets Manager 보안 암호를 선택합니다. Secrets Manager 보안 암호가 없다면 **새 Secrets Manager 보안 암호 생성**을 선택하여 [새 보안 암호를 생성](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html)합니다. 보안 암호를 생성한 후 **보안 암호 선택**에서 새 보안 암호를 선택합니다.

     새 프록시를 생성한 후 **기존 프록시 선택**을 선택하고 해당 프록시를 선택합니다. 프록시를 연결에 사용하려면 다소 시간이 걸릴 수 있습니다.

1. (선택 사항) **연결 요약**을 확장하고 리소스에서 강조 표시된 업데이트를 확인합니다.

1. **설정**을 선택합니다.

설정을 확인하면 Amazon RDS가 Lambda 함수, RDS 프록시(프록시를 사용한 경우) 및 DB 클러스터 연결 프로세스를 시작합니다. 콘솔에 **연결 세부 정보** 대화 상자가 표시되며, 여기에 리소스 간 연결을 허용하는 보안 그룹 변경 사항이 나열됩니다.

## 연결된 컴퓨팅 리소스 보기
<a name="lambda-rds-connect-viewing"></a>

AWS Management Console을 사용하여 DB 클러스터에 연결된 Lambda 함수를 볼 수 있습니다. 표시되는 리소스에는 Amazon RDS가 자동으로 설정한 컴퓨팅 리소스 연결이 포함됩니다.

나열된 컴퓨팅 리소스에는 DB 클러스터에 수동으로 연결된 컴퓨팅 리소스가 포함되지 않습니다. 예를 들어 데이터베이스와 연결된 VPC 보안 그룹에 규칙을 추가하여 컴퓨팅 리소스가 DB 클러스터에 수동으로 액세스하도록 허용할 수 있습니다.

콘솔에 Lambda 함수를 나열하려면 다음 조건을 적용해야 합니다.
+ 컴퓨팅 리소스와 연결된 보안 그룹의 이름이 `lambda-rds-n` 또는 `lambda-rdsproxy-n`(`n`은 숫자를 나타냄) 패턴과 일치합니다.
+ 컴퓨팅 리소스와 연결된 보안 그룹에 포트 범위가 DB 클러스터 또는 프록시의 포트로 설정된 아웃바운드 규칙이 있습니다. 아웃바운드 규칙의 대상이 DB 클러스터 또는 관련 프록시와 연결된 보안 그룹으로 설정되어 있어야 합니다.
+ 구성에 프록시가 포함된 경우 데이터베이스와 연결된 프록시에 연결된 보안 그룹의 이름이 `rdsproxy-lambda-n`(`n`은 숫자를 나타냄) 패턴과 일치합니다.
+ 함수와 연결된 보안 그룹에 포트가 DB 클러스터 또는 관련 프록시가 사용하는 포트로 설정된 아웃바운드 규칙이 있습니다. 대상이 DB 클러스터 또는 관련 프록시와 연결된 보안 그룹으로 설정되어 있어야 합니다.

**DB 클러스터에 자동으로 연결된 컴퓨팅 리소스를 보는 방법**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.

1. 탐색 창에서 **데이터베이스**를 선택하고 DB 클러스터를 선택합니다.

1. **연결 및 보안** 탭의 **연결된 컴퓨팅 리소스**에서 컴퓨팅 리소스를 확인합니다.

# Amazon Aurora DB 클러스터 수정
<a name="Aurora.Modifying"></a>

백업 보관 기간 변경 또는 데이터베이스 포트 변경과 같은 작업을 수행하기 위해 DB 클러스터의 설정을 변경할 수 있습니다. DB 인스턴스 클래스 변경이나 성능 개선 도우미 사용 설정 같은 작업을 수행하기 위해 DB 클러스터에서 DB 인스턴스를 수정할 수 있습니다. 이번 주제에서는 Aurora DB 클러스터와 그 DB 인스턴스를 수정하는 과정을 안내하고 각각에 대한 설정에 대해서 설명하겠습니다.

프로덕션 DB 클러스터 또는 DB 인스턴스를 수정하기 전에 테스트 DB 클러스터 또는 DB 인스턴스에서 변경 사항을 테스트하면 각 변경 사항이 미칠 영향을 완전히 이해하는 데 도움이 됩니다. 이는 특히 데이터베이스 버전을 업그레이드할 때 중요합니다.

**Topics**
+ [콘솔, CLI, API를 사용하여 DB 클러스터 수정](#Aurora.Modifying.Cluster)
+ [DB 클러스터에서 DB 인스턴스 수정](#Aurora.Modifying.Instance)
+ [데이터베이스 마스터 사용자의 암호 변경](#Aurora.Modifying.Password)
+ [Amazon Aurora에 대한 설정](#Aurora.Modifying.Settings)
+ [Amazon Aurora DB 클러스터에 적용되지 않는 설정](#Aurora.Modifying.SettingsNotApplicableDBClusters)
+ [DB 인스턴스용 Amazon Aurora에 적용되지 않는 설정](#Aurora.Modifying.SettingsNotApplicable)

## 콘솔, CLI, API를 사용하여 DB 클러스터 수정
<a name="Aurora.Modifying.Cluster"></a><a name="modify_cluster"></a>

AWS Management Console, AWS CLI 또는 RDS API를 사용하여 DB 클러스터를 수정할 수 있습니다.

**참고**  
대부분의 수정 사항은 즉시 적용하거나 예정된 다음 유지 관리 기간에 적용할 수 있습니다. 삭제 방지 기능 활성화와 같은 일부 수정 사항은 적용 시기를 언제로 선택하든 상관없이 즉시 적용됩니다.  
AWS Management Console에서 마스터 암호를 변경하면 항상 즉시 적용됩니다. 그러나 AWS CLI 또는 RDS API를 사용하는 경우 이 변경 사항을 즉시 적용할지 아니면 예정된 다음 유지 관리 기간에 적용할지 선택할 수 있습니다.  
SSL 엔드포인트를 사용하고 있으며 DB 클러스터 식별자를 변경하는 경우, DB 클러스터를 중지하고 다시 시작하여 SSL 엔드포인트를 업데이트해야 합니다. 자세한 내용은 [Amazon Aurora DB 클러스터 중지 및 시작](aurora-cluster-stop-start.md) 단원을 참조하십시오.

### 콘솔
<a name="Aurora.Modifying.Cluster.Console"></a>

**DB 클러스터를 수정하려면**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.

1. 탐색 창에서 **Databases(데이터베이스)**를 선택한 다음 수정하려는 DB 클러스터를 선택합니다.

1. **수정**을 선택합니다. **Modify DB cluster(DB 클러스터 수정)** 페이지가 나타납니다.

1. 원하는 설정을 모두 변경합니다. 각 설정에 대한 자세한 내용은 [Amazon Aurora에 대한 설정](#Aurora.Modifying.Settings) 단원을 참조하십시오.
**참고**  
AWS Management Console에서는 현재 DB 인스턴스에 인스턴스 수준의 일부 변경 사항만 적용되지만 전체 DB 클러스터에는 다른 변경 사항이 적용됩니다. DB 인스턴스 또는 DB 클러스터에 설정 적용 여부에 대한 내용은 [Amazon Aurora에 대한 설정](#Aurora.Modifying.Settings)의 설정 범위를 참조하십시오. AWS Management Console에서 인스턴스 수준에서 전체 DB 클러스터를 수정하는 설정을 변경하려면 [DB 클러스터에서 DB 인스턴스 수정](#Aurora.Modifying.Instance) 단원의 지침을 따르십시오.

1. 원하는 대로 모두 변경되었으면 [**Continue**]를 선택하고 수정 사항 요약을 확인합니다.

1. 변경 사항을 즉시 적용하려면 **즉시 적용**을 선택합니다.

1. 확인 페이지에서 변경 내용을 검토합니다. 변경 내용이 올바른 경우 **클러스터 수정**을 선택하여 변경 내용을 저장합니다.

   그렇지 않으면 [**Back**]을 선택하여 변경 내용을 편집하거나 [**Cancel**]을 선택하여 변경 내용을 취소합니다.

### AWS CLI
<a name="Aurora.Modifying.Cluster.CLI"></a>

AWS CLI를 사용하여 DB 클러스터를 수정하려면 [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) 명령을 호출하십시오. DB 클러스터 식별자와 수정하려는 설정 값을 지정하십시오. 각 설정에 대한 자세한 내용은 [Amazon Aurora에 대한 설정](#Aurora.Modifying.Settings) 단원을 참조하십시오.

**참고**  
일부 설정은 DB 인스턴스에만 적용됩니다. 이러한 설정을 변경하려면 [DB 클러스터에서 DB 인스턴스 수정](#Aurora.Modifying.Instance)의 지침을 따르십시오.

**Example**  
다음 명령은 백업 보관 기간을 1주(7일)로 설정하여 `mydbcluster`를 수정합니다.  
대상 LinuxmacOS, 또는Unix:  

```
aws rds modify-db-cluster \
    --db-cluster-identifier mydbcluster \
    --backup-retention-period 7
```
Windows의 경우:  

```
aws rds modify-db-cluster ^
    --db-cluster-identifier mydbcluster ^
    --backup-retention-period 7
```

### RDS API
<a name="Aurora.Modifying.Cluster.API"></a>

Amazon RDS API를 사용하여 DB 클러스터를 수정하려면 [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) 작업을 호출하십시오. DB 클러스터 식별자와 수정하려는 설정 값을 지정하십시오. 각 파라미터에 대한 자세한 내용은 [Amazon Aurora에 대한 설정](#Aurora.Modifying.Settings) 단원을 참조하십시오.

**참고**  
일부 설정은 DB 인스턴스에만 적용됩니다. 이러한 설정을 변경하려면 [DB 클러스터에서 DB 인스턴스 수정](#Aurora.Modifying.Instance)의 지침을 따르십시오.

## DB 클러스터에서 DB 인스턴스 수정
<a name="Aurora.Modifying.Instance"></a><a name="modify_instance"></a>

AWS Management Console, AWS CLI 또는 RDS API를 사용하여 DB 클러스터에서 DB 인스턴스를 수정할 수 있습니다.

DB 인스턴스를 수정하는 경우 변경 사항을 즉시 적용할 수 있습니다. 변경 사항을 즉시 적용하려면 AWS Management Console에서 **즉시 적용(Apply Immediately)** 옵션을 선택하거나, AWS CLI 호출 시 `--apply-immediately` 파라미터를 사용하거나, Amazon RDS API 사용 시 `ApplyImmediately` 파라미터를 `true`로 설정합니다.

변경 사항을 즉시 적용하도록 선택하지 않으면 변경 사항이 다음 유지 관리 기간까지 연기됩니다. 다음 유지 관리 기간 동안 지연된 변경 사항이 모두 적용됩니다. 변경 사항을 즉시 적용하도록 선택하면 새 변경 사항과 이전에 지연된 변경 사항이 적용됩니다.

다음 유지 관리 기간에 보류 중인 수정 사항을 보려면 [describe-db-clusters](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/describe-db-clusters.html) AWS CLI 명령을 사용하고 `PendingModifiedValues` 필드를 확인합니다.

**중요**  
보류 중인 수정 작업으로 인해 가동 중지가 필요한 경우, **즉시 적용**을 선택하면 DB 인스턴스에서 예기치 못한 가동 중지가 발생할 수 있습니다. DB 클러스터의 다른 DB 인스턴스에서는 가동 중지가 발생하지 않습니다.  
지연한 수정 사항은 `describe-pending-maintenance-actions` CLI 명령의 출력에 나열되지 않습니다. 유지 관리 작업에는 다음 유지 관리 기간에 대해 예약하는 시스템 업그레이드만 포함됩니다.

### 콘솔
<a name="Aurora.Modifying.Instance.Console"></a>

**DB 클러스터에서 DB 인스턴스를 수정하려면**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.

1. 탐색 창에서 **데이터베이스**를 선택한 다음 변경하려는 DB 인스턴스를 선택합니다.

1. **작업**에서 **수정**을 선택합니다. **DB 인스턴스 수정** 페이지가 나타납니다.

1. 원하는 설정을 모두 변경합니다. 각 설정에 대한 자세한 내용은 [Amazon Aurora에 대한 설정](#Aurora.Modifying.Settings) 단원을 참조하십시오.
**참고**  
일부 설정은 전체 DB 클러스터에 적용되며, 클러스터 수준에서 변경이 필요합니다. 이러한 설정을 변경하려면 [콘솔, CLI, API를 사용하여 DB 클러스터 수정](#Aurora.Modifying.Cluster)의 지침을 따르십시오.  
 AWS Management Console에서는 현재 DB 인스턴스에 인스턴스 수준의 일부 변경 사항만 적용되지만 전체 DB 클러스터에는 다른 변경 사항이 적용됩니다. DB 인스턴스 또는 DB 클러스터에 설정 적용 여부에 대한 내용은 [Amazon Aurora에 대한 설정](#Aurora.Modifying.Settings)의 설정 범위를 참조하십시오.

1. 원하는 대로 모두 변경되었으면 [**Continue**]를 선택하고 수정 사항 요약을 확인합니다.

1. 변경 사항을 즉시 적용하려면 **즉시 적용**을 선택합니다.

1. 확인 페이지에서 변경 내용을 검토합니다. 변경 내용이 정확할 경우 **DB 인스턴스 수정**을 선택하여 변경 내용을 저장합니다.

   그렇지 않으면 [**Back**]을 선택하여 변경 내용을 편집하거나 [**Cancel**]을 선택하여 변경 내용을 취소합니다.

### AWS CLI
<a name="Aurora.Modifying.Instance.CLI"></a>

AWS CLI를 사용하여 DB 클러스터의 DB 인스턴스를 수정하려면 [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) 명령을 호출하십시오. DB 인스턴스 식별자와 수정하려는 설정 값을 지정하십시오. 각 파라미터에 대한 자세한 내용은 [Amazon Aurora에 대한 설정](#Aurora.Modifying.Settings) 단원을 참조하십시오.

**참고**  
일부 설정은 전체 DB 클러스터에 적용됩니다. 이러한 설정을 변경하려면 [콘솔, CLI, API를 사용하여 DB 클러스터 수정](#Aurora.Modifying.Cluster)의 지침을 따르십시오.

**Example**  
다음 코드는 DB 인스턴스 클래스를 `mydbinstance`로 설정하여 `db.r4.xlarge`를 수정합니다. 변경 사항은 `--no-apply-immediately`를 사용하여 다음 유지 관리 기간에 적용됩니다. 변경 사항을 바로 적용하려면 `--apply-immediately`를 사용합니다.  
대상 LinuxmacOS, 또는Unix:  

```
aws rds modify-db-instance \
    --db-instance-identifier mydbinstance \
    --db-instance-class db.r4.xlarge \
    --no-apply-immediately
```
Windows의 경우:  

```
aws rds modify-db-instance ^
    --db-instance-identifier mydbinstance ^
    --db-instance-class db.r4.xlarge ^
    --no-apply-immediately
```

### RDS API
<a name="Aurora.Modifying.Instance.API"></a>

Amazon RDS API를 사용하여 DB 인스턴스를 수정하려면 [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) 작업을 호출합니다. DB 인스턴스 식별자와 수정하려는 설정 값을 지정하십시오. 각 파라미터에 대한 자세한 내용은 [Amazon Aurora에 대한 설정](#Aurora.Modifying.Settings) 단원을 참조하십시오.

**참고**  
일부 설정은 전체 DB 클러스터에 적용됩니다. 이러한 설정을 변경하려면 [콘솔, CLI, API를 사용하여 DB 클러스터 수정](#Aurora.Modifying.Cluster)의 지침을 따르십시오.

## 데이터베이스 마스터 사용자의 암호 변경
<a name="Aurora.Modifying.Password"></a>

AWS Management Console 또는 AWS CLI를 사용하여 마스터 사용자의 암호를 변경할 수 있습니다.

### 콘솔
<a name="Aurora.Modifying.Password.CON"></a>

AWS Management Console을 사용하여 마스터 사용자 암호를 변경하려면 라이터 DB 인스턴스를 수정합니다.

**마스터 사용자의 암호를 변경하는 방법**

1. [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 AWS Management Console에 로그인한 후 Amazon RDS 콘솔을 엽니다.

1. 탐색 창에서 **데이터베이스**를 선택한 다음 변경하려는 DB 인스턴스를 선택합니다.

1. **작업**에서 **수정**을 선택합니다.

   **DB 인스턴스 수정** 페이지가 나타납니다.

1. **새 마스터 암호**를 입력합니다.

1. **마스터 암호 확인**에 동일한 새 암호를 입력합니다.  
![\[새 마스터 사용자 암호를 입력하고 확인합니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/aur_new_master_password.png)

1. **계속**해서 수정 사항을 요약한 내용을 확인합니다.
**참고**  
변경 사항이 바로 적용됩니다.

1. 확인 페이지에서 **DB 인스턴스 수정(Modify DB instance)**을 선택합니다.

### CLI
<a name="Aurora.Modifying.Password.CLI"></a>

AWS CLI를 사용하여 마스터 사용자 암호를 변경하려면 [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) 명령을 호출합니다. 다음 예제와 같이, DB 클러스터 식별자와 새 암호를 지정합니다.

암호 변경은 항상 즉시 적용되므로 `--apply-immediately|--no-apply-immediately`를 지정할 필요가 없습니다.

대상 LinuxmacOS, 또는Unix:

```
aws rds modify-db-cluster \
    --db-cluster-identifier mydbcluster \
    --master-user-password mynewpassword
```

Windows의 경우:

```
aws rds modify-db-cluster ^
    --db-cluster-identifier mydbcluster ^
    --master-user-password mynewpassword
```

## Amazon Aurora에 대한 설정
<a name="Aurora.Modifying.Settings"></a>

다음 표에는 수정이 가능한 설정, 설정 수정 방법, 설정 범위에 대한 세부 정보가 나와 있습니다. 이 범위를 통해 설정을 전체 DB 클러스터에 적용할지 또는 특정 DB 인스턴스에만 설정할 수 있는지 여부를 결정합니다.

**참고**  
Aurora Serverless v1 또는 Aurora Serverless v2 DB 클러스터를 수정하는 경우 추가 설정을 사용할 수 있습니다. 이러한 설정에 대한 내용은 [Aurora Serverless v1 DB 클러스터 수정](aurora-serverless.modifying.md) 및 [Aurora Serverless v2 DB 클러스터 관리](aurora-serverless-v2-administration.md) 섹션을 참조하세요.  
Aurora Serverless v1 및 Aurora Serverless v2에서는 제한 사항이 적용되어 일부 설정을 사용할 수 없습니다. 자세한 내용은 [Aurora Serverless v1의 제한 사항](aurora-serverless.md#aurora-serverless.limitations) 및 [Aurora Serverless v2 요구 사항 및 제한 사항](aurora-serverless-v2.requirements.md) 단원을 참조하세요.


****  

| 설정 및 설명 | 방법 | 범위 | 가동 중지 참고 사항 | 
| --- | --- | --- | --- | 
|  **자동 마이너 버전 업그레이드** 사용 가능하게 되면 DB 인스턴스에 기본 마이너 엔진 버전 업그레이드를 자동으로 받을지 여부. 업그레이드는 예약된 유지 관리 기간 중에만 설치됩니다. [Amazon Aurora PostgreSQL에 대한 데이터베이스 엔진 업데이트](AuroraPostgreSQL.Updates.md)의 엔진 업데이트에 대한 자세한 정보는 [Amazon Aurora MySQL에 대한 데이터베이스 엔진 업데이트Amazon Aurora MySQL 장기 지원(LTS) 및 베타 릴리스](AuroraMySQL.Updates.md) 단원을 참조하십시오. Aurora MySQL의 **마이너 버전 자동 업그레이드(Auto minor version upgrade)** 설정에 대한 자세한 내용은 [마이너 Aurora MySQL 버전 간 자동 업그레이드 활성화](AuroraMySQL.Updates.AMVU.md) 단원을 참조하세요.  |   이 설정은 기본적으로 활성화되어 있습니다. 각 새 클러스터에 대해 중요도, 예상 수명 및 각 업그레이드 후에 수행하는 확인 테스트 양에 따라 이 설정에 적합한 값을 선택합니다.  이 설정을 변경하는 경우 Aurora 클러스터의 모든 DB 인스턴스에 대해 이 수정 작업을 수행합니다. 클러스터의 DB 인스턴스에서 이 설정이 꺼져 있으면 클러스터가 자동으로 업그레이드되지 않습니다. AWS Management Console, [DB 클러스터에서 DB 인스턴스 수정](#Aurora.Modifying.Instance) 사용. AWS CLI를 사용하여 [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)를 실행하고 `--auto-minor-version-upgrade\|--no-auto-minor-version-upgrade` 옵션을 설정합니다. RDS API를 사용하여 [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)를 직접 호출하고 `AutoMinorVersionUpgrade` 파라미터를 설정합니다.  |  전체 DB 클러스터  |  이 변경 도중 인스턴스가 중단되지 않습니다. 이후 유지 관리 기간 동안 Aurora가 자동 업그레이드를 적용할 때는 중단이 발생합니다.  | 
|  **백업 보관 기간** 자동 백업을 보관할 일수. 최소값은 `1`입니다. 자세한 내용은 [백업](Aurora.Managing.Backups.md#Aurora.Managing.Backups.Backup) 섹션을 참조하세요.  |  AWS Management Console, [콘솔, CLI, API를 사용하여 DB 클러스터 수정](#Aurora.Modifying.Cluster) 사용. AWS CLI를 사용하여 [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)를 실행하고 `--backup-retention-period` 옵션을 설정합니다. RDS API를 사용하여 [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)를 직접 호출하고 `BackupRetentionPeriod` 파라미터를 설정합니다.  |  전체 DB 클러스터  |  이 변경 도중 인스턴스가 중단되지 않습니다.  | 
|  **백업 기간(시작 시간)** 데이터베이스의 자동 백업이 실행되는 기간. 백업 기간은 국제 표준시(UTC)의 시작 시간과 시간 단위의 지속 기간으로 구성됩니다. Aurora 백업은 연속 및 증분 백업이지만 백업 기간은 백업 유지 기간 내에 보관되는 일일 시스템 백업을 만드는 데 사용됩니다. 이것을 복사하여 유지 기간이 지난 뒤에도 보관할 수 있습니다. DB 클러스터에 대한 유지 관리 기간 및 백업 기간은 겹칠 수 없습니다. 자세한 내용은 [백업 기간](Aurora.Managing.Backups.md#Aurora.Managing.Backups.BackupWindow) 섹션을 참조하세요.  |  AWS Management Console, [콘솔, CLI, API를 사용하여 DB 클러스터 수정](#Aurora.Modifying.Cluster) 사용. AWS CLI를 사용하여 [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)를 실행하고 `--preferred-backup-window` 옵션을 설정합니다. RDS API를 사용하여 [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)를 직접 호출하고 `PreferredBackupWindow` 파라미터를 설정합니다.  |  전체 DB 클러스터  |  이 변경 도중 인스턴스가 중단되지 않습니다.  | 
|  **용량 설정** Aurora Serverless v1 DB 클러스터의 규모 조정 속성입니다. DB 클러스터의 조정 속성은 `serverless` DB 엔진 모드에서만 수정할 수 있습니다. Aurora Serverless v1에 대한 자세한 내용은 [Amazon Aurora Serverless v1 사용](aurora-serverless.md) 단원을 참조하십시오.  |  AWS Management Console, [콘솔, CLI, API를 사용하여 DB 클러스터 수정](#Aurora.Modifying.Cluster) 사용. AWS CLI를 사용하여 [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)를 실행하고 `--scaling-configuration` 옵션을 설정합니다. RDS API를 사용하여 [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)를 직접 호출하고 `ScalingConfiguration` 파라미터를 설정합니다.  |  전체 DB 클러스터  |  이 변경 도중 인스턴스가 중단되지 않습니다. 변경 사항이 즉시 적용됩니다. 이 설정은 즉시 적용 설정을 무시합니다.  | 
|  **인증 기관** DB 인스턴스에서 사용하는 서버 인증서의 CA(인증 기관)입니다.  |  AWS Management Console, [DB 클러스터에서 DB 인스턴스 수정](#Aurora.Modifying.Instance) 사용. AWS CLI를 사용하여 [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)를 실행하고 `--ca-certificate-identifier` 옵션을 설정합니다. RDS API를 사용하여 [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)를 직접 호출하고 `CACertificateIdentifier` 파라미터를 설정합니다.  |  지정된 DB 인스턴스만 해당  |  중단은 DB 엔진이 재시작 없는 교체를 지원하지 않는 경우에만 발생합니다. [describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI 명령을 사용하여 DB 엔진이 재시작 없는 교체를 지원하는지 여부를 확인할 수 있습니다.  | 
|  **클러스터 스토리지 구성** DB 클러스터의 스토리지 유형(**Aurora I/O-Optimized** 또는 **Aurora Standard**)입니다. 자세한 내용은 [Amazon Aurora DB 클러스터의 스토리지 구성](Aurora.Overview.StorageReliability.md#aurora-storage-type) 단원을 참조하십시오.  |  AWS Management Console, [콘솔, CLI, API를 사용하여 DB 클러스터 수정](#Aurora.Modifying.Cluster) 사용. AWS CLI를 사용하여 [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)를 실행하고 `--storage-type` 옵션을 설정합니다. RDS API를 사용하여 [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)를 직접 호출하고 `StorageType` 파라미터를 설정합니다.  | 전체 DB 클러스터 |  최적화된 읽기 인스턴스 클래스가 있는 Aurora PostgreSQL DB 클러스터의 스토리지 유형을 변경하면 중단이 발생합니다. 다른 인스턴스 클래스 유형이 있는 클러스터의 스토리지 유형을 변경할 때는 이 문제가 발생하지 않습니다. DB 인스턴스 클래스 유형에 대한 자세한 내용은 [DB 인스턴스 클래스 유형](Concepts.DBInstanceClass.Types.md) 섹션을 참조하세요.  | 
| 스냅샷으로 태그 복사 이 옵션을 선택하면 현재 DB 클러스터에 정의되어 있는 태그가 현재 DB 클러스터에서 생성된 DB 스냅샷으로 복사됩니다. 자세한 내용은 [Amazon Aurora 및Amazon RDS 리소스에 태그 지정](USER_Tagging.md) 섹션을 참조하세요. |  AWS Management Console, [콘솔, CLI, API를 사용하여 DB 클러스터 수정](#Aurora.Modifying.Cluster) 사용. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)를 실행하고 `--copy-tags-to-snapshot` 또는 `--no-copy-tags-to-snapshot` 옵션을 설정합니다. RDS API를 사용하여 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)를 호출하고 `CopyTagsToSnapshot` 파라미터를 설정합니다.  | 전체 DB 클러스터 |  이 변경 도중 인스턴스가 중단되지 않습니다.  | 
|  **데이터 API** Aurora Serverless v1 및 AWS Lambda를 포함한 웹 서비스 기반 애플리케이션을 사용하여 AWS AppSync에 액세스할 수 있습니다. 이 설정은 Aurora Serverless v1 DB 클러스터에만 적용됩니다. 자세한 내용은 [Amazon RDS Data API 사용](data-api.md) 섹션을 참조하세요.  |  AWS Management Console, [콘솔, CLI, API를 사용하여 DB 클러스터 수정](#Aurora.Modifying.Cluster) 사용. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)를 실행하고 `--enable-http-endpoint` 옵션을 설정합니다. RDS API를 사용하여 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)를 호출하고 `EnableHttpEndpoint` 파라미터를 설정합니다.  |  전체 DB 클러스터  |  이 변경 도중 인스턴스가 중단되지 않습니다.  | 
|  데이터베이스 인증 사용하고자 하는 데이터베이스 인증입니다.MySQL의 경우:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Modifying.html)PostgreSQL의 경우:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Modifying.html) |  AWS Management Console, [콘솔, CLI, API를 사용하여 DB 클러스터 수정](#Aurora.Modifying.Cluster) 사용. AWS CLI를 사용하여 [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)를 실행하고 다음 옵션을 설정합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Modifying.html) RDS API를 사용하여 [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)를 호출하고 다음 파라미터를 설정합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Modifying.html)  |  전체 DB 클러스터  |  이 변경 도중 인스턴스가 중단되지 않습니다.  | 
|  **데이터베이스 포트** DB 클러스터에 액세스하는 데 사용할 포트.  |  AWS Management Console, [콘솔, CLI, API를 사용하여 DB 클러스터 수정](#Aurora.Modifying.Cluster) 사용. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)를 실행하고 `--port` 옵션을 설정합니다. RDS API를 사용하여 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)를 호출하고 `Port` 파라미터를 설정합니다.  |  전체 DB 클러스터  |  이 변경 도중 인스턴스가 중단됩니다. DB 클러스터의 모든 DB 인스턴스는 즉시 재부팅됩니다.  | 
|  **DB 클러스터 식별자** DB 클러스터 식별자입니다. 이 값은 소문자 문자열로 저장됩니다. DB 클러스터 식별자를 변경하면 DB 클러스터 엔드포인트가 변경됩니다. DB 클러스터에 있는 DB 인스턴스의 엔드포인트는 변경되지 않습니다.  |  AWS Management Console, [콘솔, CLI, API를 사용하여 DB 클러스터 수정](#Aurora.Modifying.Cluster) 사용. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)를 실행하고 `--new-db-cluster-identifier` 옵션을 설정합니다. RDS API를 사용하여 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)를 호출하고 `NewDBClusterIdentifier` 파라미터를 설정합니다.  |  전체 DB 클러스터  |  이 변경 도중 인스턴스가 중단되지 않습니다.  | 
|  **DB 클러스터 파라미터 그룹** DB 클러스터와 연결할 DB 클러스터 파라미터 그룹. 자세한 내용은 [Amazon Aurora의 파라미터 그룹](USER_WorkingWithParamGroups.md) 섹션을 참조하세요.  |  AWS Management Console, [콘솔, CLI, API를 사용하여 DB 클러스터 수정](#Aurora.Modifying.Cluster) 사용. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)를 실행하고 `--db-cluster-parameter-group-name` 옵션을 설정합니다. RDS API를 사용하여 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)를 호출하고 `DBClusterParameterGroupName` 파라미터를 설정합니다.  |  전체 DB 클러스터  |  이 변경 도중 인스턴스가 중단되지 않습니다. 파라미터 그룹을 변경하는 경우 일부 파라미터에 대한 변경 내용은 재부팅 없이 DB 클러스터의 DB 인스턴스에 즉시 적용됩니다. 다른 파라미터에 대한 변경 내용은 DB 클러스터의 DB 인스턴스를 재부팅한 후에만 적용됩니다.  | 
|  **DB 인스턴스 클래스** 사용할 DB 인스턴스 클래스. 자세한 내용은 [Amazon AuroraDB 인스턴스 클래스](Concepts.DBInstanceClass.md) 섹션을 참조하세요.  |  AWS Management Console, [DB 클러스터에서 DB 인스턴스 수정](#Aurora.Modifying.Instance) 사용. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)를 실행하고 `--db-instance-class` 옵션을 설정합니다. RDS API를 사용하여 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)를 호출하고 `DBInstanceClass` 파라미터를 설정합니다.  |  지정된 DB 인스턴스만 해당  |  이 변경 도중 인스턴스가 중단됩니다.  | 
|  **DB 인스턴스 식별자** DB 인스턴스 식별자 이 값은 소문자 문자열로 저장됩니다.  |  AWS Management Console, [DB 클러스터에서 DB 인스턴스 수정](#Aurora.Modifying.Instance) 사용. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)를 실행하고 `--new-db-instance-identifier` 옵션을 설정합니다. RDS API를 사용하여 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)를 호출하고 `NewDBInstanceIdentifier` 파라미터를 설정합니다.  |  지정된 DB 인스턴스만 해당  |  이 변경 도중에는 가동 중지 시간이 발생합니다. RDS가 DB 인스턴스를 다시 시작하여 다음을 업데이트합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Modifying.html)  | 
|  **DB 파라미터 그룹** DB 인스턴스와 연결하려는 DB 파라미터 그룹. 자세한 내용은 [Amazon Aurora의 파라미터 그룹](USER_WorkingWithParamGroups.md) 섹션을 참조하세요.  |  AWS Management Console, [DB 클러스터에서 DB 인스턴스 수정](#Aurora.Modifying.Instance) 사용. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)를 실행하고 `--db-parameter-group-name` 옵션을 설정합니다. RDS API를 사용하여 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)를 호출하고 `DBParameterGroupName` 파라미터를 설정합니다.  |  지정된 DB 인스턴스만 해당  |  이 변경 도중 인스턴스가 중단되지 않습니다. 새 DB 파라미터 그룹을 DB 인스턴스와 연결하면 수정된 정적 파라미터 및 동적 파라미터는 DB 인스턴스가 재부팅된 후에만 적용됩니다. 그러나 DB 파라미터 그룹을 DB 인스턴스에 연결한 후 DB 파라미터 그룹에서 동적 파라미터를 수정하면 이러한 변경 사항이 재부팅 없이 즉시 적용됩니다. 자세한 내용은 [Amazon Aurora의 파라미터 그룹](USER_WorkingWithParamGroups.md) 및 [Amazon Aurora DB 클러스터 또는 Amazon Aurora DB 인스턴스 재부팅](USER_RebootCluster.md) 단원을 참조하세요.  | 
|  **삭제 방지** DB 클러스터가 삭제되지 않도록 방지하기 위한 **삭제 방지 활성화** 자세한 내용은 [Aurora 클러스터의 삭제 방지](USER_DeleteCluster.md#USER_DeletionProtection) 섹션을 참조하세요.  |  AWS Management Console, [콘솔, CLI, API를 사용하여 DB 클러스터 수정](#Aurora.Modifying.Cluster) 사용. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)를 실행하고 `--deletion-protection\|--no-deletion-protection` 옵션을 설정합니다. RDS API를 사용하여 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)를 호출하고 `DeletionProtection` 파라미터를 설정합니다.  | 전체 DB 클러스터 |  이 변경 도중 인스턴스가 중단되지 않습니다.  | 
|  **엔진 버전** 사용하려는 DB 엔진의 버전입니다. 프로덕션 DB 클러스터스를 업그레이드하려면 먼저 테스트 DB 클러스터에서 업그레이드 프로세스를 테스트하여 지속 시간을 확인하고 애플리케이션의 유효성을 확인하는 것이 좋습니다.  |  AWS Management Console, [콘솔, CLI, API를 사용하여 DB 클러스터 수정](#Aurora.Modifying.Cluster) 사용. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)를 실행하고 `--engine-version` 옵션을 설정합니다. RDS API를 사용하여 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)를 호출하고 `EngineVersion` 파라미터를 설정합니다.  |  전체 DB 클러스터  |  이 변경 도중 인스턴스가 중단됩니다.  | 
|  **확장 모니터링** DB 인스턴스가 실행되는 운영 체제에 대한 실시간 측정치 수집을 활성화하려면 [**Enable enhanced monitoring**]을 선택합니다. 자세한 내용은 [Enhanced Monitoring을 사용하여 OS 지표 모니터링](USER_Monitoring.OS.md) 섹션을 참조하세요.  |  AWS Management Console, [DB 클러스터에서 DB 인스턴스 수정](#Aurora.Modifying.Instance) 사용. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)를 실행하고 `--monitoring-role-arn` 및 `--monitoring-interval` 옵션을 설정합니다. RDS API를 사용하여 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)를 호출하고 `MonitoringRoleArn` 및 `MonitoringInterval` 파라미터를 설정합니다.  |  지정된 DB 인스턴스만 해당  |  이 변경 도중 인스턴스가 중단되지 않습니다.  | 
|  **로그 내보내기** Amazon CloudWatch Logs에 게시할 로그 유형을 선택합니다. 자세한 내용은 [Aurora MySQL 데이터베이스 로그 파일](USER_LogAccess.Concepts.MySQL.md) 섹션을 참조하세요.  |  AWS Management Console, [콘솔, CLI, API를 사용하여 DB 클러스터 수정](#Aurora.Modifying.Cluster) 사용. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)를 실행하고 `--cloudwatch-logs-export-configuration` 옵션을 설정합니다. RDS API를 사용하여 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)를 호출하고 `CloudwatchLogsExportConfiguration` 파라미터를 설정합니다.  |  전체 DB 클러스터  |  이 변경 도중 인스턴스가 중단되지 않습니다.  | 
|  **유지보수 윈도우** 시스템 유지 관리를 실행하는 기간. 시스템 유지 관리는 업그레이드를 포함합니다(해당할 경우). 유지 관리 기간은 국제 표준시(UTC)의 시작 시간과 시간 단위의 지속 기간으로 구성됩니다. 이 기간을 현재 시간으로 설정하려면 대기 중인 변경 사항이 모두 적용될 수 있도록 현재 시간과 기간 종료 시간 사이에 최소 30분 이상 필요합니다. 유지 관리 기간을 DB 클러스터 및 DB 클러스터의 각 DB 인스턴스에 대해 독자적으로 설정할 수 있습니다. 수정 범위가 전체 DB 클러스터이면 수정은 DB 클러스터 유지 관리 기간 중에 수행됩니다. 수정 범위가 전체 DB 인스턴스이면 수정은 이 DB 인스턴스의 유지 관리 기간 중에 수행됩니다. DB 클러스터에 대한 유지 관리 기간 및 백업 기간은 겹칠 수 없습니다. 자세한 내용은 [Amazon RDS 유지 관리 기간](USER_UpgradeDBInstance.Maintenance.md#Concepts.DBMaintenance) 섹션을 참조하세요.  |  AWS Management Console을 사용하여 DB 클러스터의 유지 관리 기간을 변경하려면 [콘솔, CLI, API를 사용하여 DB 클러스터 수정](#Aurora.Modifying.Cluster). AWS Management Console을 사용하여 DB 인스턴스의 유지 관리 기간을 변경하려면 [DB 클러스터에서 DB 인스턴스 수정](#Aurora.Modifying.Instance). AWS CLI를 사용하여 DB 클러스터의 유지 관리 기간을 변경하려면 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)를 실행하고 `--preferred-maintenance-window` 옵션을 설정합니다. AWS CLI를 사용하여 DB 인스턴스의 유지 관리 기간을 변경하려면 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)를 실행하고 `--preferred-maintenance-window` 옵션을 설정합니다. RDS API를 사용하여 DB 클러스터의 유지 관리 기간을 변경하려면 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)를 호출하고 `PreferredMaintenanceWindow` 파라미터를 설정합니다. RDS API를 사용하여 DB 인스턴스의 유지 관리 기간을 변경하려면 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)를 호출하고 `PreferredMaintenanceWindow` 파라미터를 설정합니다.  |  전체 DB 클러스터 또는 단일 DB 인스턴스  |  인스턴스가 중단될 수 있는 작업이 하나 이상 대기 중이고, 유지 관리 기간이 현재 시간을 포함하여 변경된 경우 대기 중인 작업들이 즉시 적용되고 인스턴스가 중단됩니다.  | 
|   **AWS Secrets Manager에서 마스터 자격 증명 관리** Secrets Manager에서 보안 암호의 마스터 사용자 암호를 관리하려면 **AWS Secrets Manager에서 마스터 자격 증명 관리**를 선택합니다. 원하는 경우 보안 암호를 보호하는 데 사용할 KMS 키를 선택합니다. 자신의 계정에서 KMS 키를 선택하거나 다른 계정의 키를 입력할 수 있습니다. 자세한 내용은 [Amazon Aurora 및 AWS Secrets Manager를 통한 암호 관리](rds-secrets-manager.md) 단원을 참조하십시오. Aurora에서 이미 DB 클러스터의 마스터 사용자 암호를 관리하고 있는 경우 **보안 암호 즉시 교체**를 선택하여 마스터 사용자 암호를 교체할 수 있습니다. 자세한 내용은 [Amazon Aurora 및 AWS Secrets Manager를 통한 암호 관리](rds-secrets-manager.md) 단원을 참조하십시오.  |  AWS Management Console, [DB 클러스터에서 DB 인스턴스 수정](#Aurora.Modifying.Instance) 사용. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)를 실행하고 `--manage-master-user-password \| --no-manage-master-user-password` 및 `--master-user-secret-kms-key-id` 옵션을 설정합니다. 마스터 사용자 암호를 즉시 교체하려면 `--rotate-master-user-password` 옵션을 설정합니다. RDS API를 사용하여 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)를 호출하고 `ManageMasterUserPassword` 및 `MasterUserSecretKmsKeyId` 파라미터를 설정합니다. 마스터 사용자 암호를 즉시 교체하려면 `RotateMasterUserPassword` 파라미터를 `true`로 설정합니다.  |  전체 DB 클러스터  |  이 변경 도중 인스턴스가 중단되지 않습니다.  | 
|  **네트워크 유형** DB 클러스터에서 지원하는 IP 주소 지정 프로토콜. 리소스가 IPv4 주소 지정 프로토콜을 통해서만 DB 클러스터와 통신할 수 있도록 지정하는 **IPv4**. 리소스가 IPv4, IPv6 또는 모두를 통해 DB 클러스터와 통신할 수 있도록 지정하는 **듀얼 스택 모드**. IPv6 주소 지정 프로토콜을 통해 DB 클러스터와 통신해야 하는 리소스가 있는 경우 이중 스택 모드를 사용합니다. 듀얼 스택 모드를 사용하려면 두 개의 가용 영역에 걸쳐 IPv4 및 IPv6 네트워크 프로토콜을 모두 지원하는 서브넷이 두 개 이상 있어야 합니다. 또한 IPv6 CIDR 블록을 지정한 DB 서브넷 그룹의 서브넷과 연결해야 합니다. 자세한 내용은 [Amazon Aurora IP 주소 지정](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.IP_addressing) 단원을 참조하십시오.  |  AWS Management Console, [콘솔, CLI, API를 사용하여 DB 클러스터 수정](#Aurora.Modifying.Cluster) 사용. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)를 실행하고 `--network-type` 옵션을 설정합니다. RDS API를 사용하여 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)를 호출하고 `NetworkType` 파라미터를 설정합니다.  |  전체 DB 클러스터  |  이 변경 도중 인스턴스가 중단되지 않습니다.  | 
|  **새 마스터 암호** 마스터 사용자의 암호. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Modifying.html)  |  AWS Management Console, [DB 클러스터에서 DB 인스턴스 수정](#Aurora.Modifying.Instance) 사용. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)를 실행하고 `--master-user-password` 옵션을 설정합니다. RDS API를 사용하여 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)를 호출하고 `MasterUserPassword` 파라미터를 설정합니다.  |  전체 DB 클러스터  |  이 변경 도중 인스턴스가 중단되지 않습니다.  | 
|  **성능 개선 도우미** 데이터베이스 성능을 분석하고 문제를 해결할 수 있도록 DB 인스턴스 로드를 모니터링하는 도구인 성능 개선 도우미 활성화 여부. 자세한 내용은 [성능 개선 도우미를 통한 Amazon Aurora 모니터링](USER_PerfInsights.md) 섹션을 참조하세요.  |  AWS Management Console, [DB 클러스터에서 DB 인스턴스 수정](#Aurora.Modifying.Instance) 사용. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)를 실행하고 `--enable-performance-insights\|--no-enable-performance-insights` 옵션을 설정합니다. RDS API를 사용하여 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)를 호출하고 `EnablePerformanceInsights` 파라미터를 설정합니다.  |  지정된 DB 인스턴스만 해당  |  이 변경 도중 인스턴스가 중단되지 않습니다.  | 
|  **성능 개선 도우미 AWS KMS key** 성능 개선 도우미 데이터의 암호화를 위한 AWS KMS key 식별자입니다. KMS 키 식별자는 KMS 키의 Amazon 리소스 이름(ARN), 키 식별자 또는 키 별칭입니다. 자세한 내용은 [Aurora의 성능 개선 도우미 설정 및 해제](USER_PerfInsights.Enabling.md) 단원을 참조하십시오.  |  AWS Management Console, [DB 클러스터에서 DB 인스턴스 수정](#Aurora.Modifying.Instance) 사용. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)를 실행하고 `--performance-insights-kms-key-id` 옵션을 설정합니다. RDS API를 사용하여 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)를 호출하고 `PerformanceInsightsKMSKeyId` 파라미터를 설정합니다.  |  지정된 DB 인스턴스만 해당  |  이 변경 도중 인스턴스가 중단되지 않습니다.  | 
|  **성능 개선 도우미 보관 기간** 성능 개선 도우미 데이터를 보관하는 시간(일). 프리 티어의 보존 설정은 **기본값(7일)**입니다. 성능 데이터를 더 오래 보존하려면 1\$124개월을 지정하십시오. 보존 기간에 대한 자세한 내용은 [성능 개선 도우미의 요금 및 데이터 보존](USER_PerfInsights.Overview.cost.md) 단원을 참조하십시오. 자세한 내용은 [Aurora의 성능 개선 도우미 설정 및 해제](USER_PerfInsights.Enabling.md) 단원을 참조하십시오.  |  AWS Management Console, [DB 클러스터에서 DB 인스턴스 수정](#Aurora.Modifying.Instance) 사용. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)를 실행하고 `--performance-insights-retention-period` 옵션을 설정합니다. RDS API를 사용하여 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)를 호출하고 `PerformanceInsightsRetentionPeriod` 파라미터를 설정합니다.  |  지정된 DB 인스턴스만 해당  |  이 변경 도중 인스턴스가 중단되지 않습니다.  | 
|  **프로모션 티어** 기존 기본 인스턴스에 장애가 발생한 후 Aurora 복제본을 기본 인스턴스로 승격할 순서를 지정하는 값입니다. 자세한 내용은 [Aurora DB 클러스터의 내결함성](Concepts.AuroraHighAvailability.md#Aurora.Managing.FaultTolerance) 단원을 참조하십시오.  |  AWS Management Console, [DB 클러스터에서 DB 인스턴스 수정](#Aurora.Modifying.Instance) 사용. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)를 실행하고 `--promotion-tier` 옵션을 설정합니다. RDS API를 사용하여 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)를 호출하고 `PromotionTier` 파라미터를 설정합니다.  |  지정된 DB 인스턴스만 해당  |  이 변경 도중 인스턴스가 중단되지 않습니다.  | 
|  **공개 액세스**(Public access) DB 인스턴스에 퍼블릭 IP 주소를 부여하려면(즉 VPC 외부에서 액세스할 수 있음) **공개적으로 액세스할 수 있음(Publicly accessible)**을 선택합니다. 공개적으로 액세스가 가능하려면 DB 인스턴스도 VPC의 퍼블릭 서브넷에 있어야 합니다. VPC 내부에서만 DB 인스턴스에 액세스할 수 있게 하려면 **공개적으로 액세스할 수 없음(Not publicly accessible)**을 선택합니다. 자세한 내용은 [VPC에 있는 DB 클러스터를 인터넷에서 숨기기](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.Hiding) 섹션을 참조하세요. Amazon VPC 외부에서 DB 인스턴스에 연결하려면 DB 인스턴스에 공개적으로 액세스할 수 있어야 하고, DB 인스턴스 보안 그룹의 인바운드 규칙을 사용하여 액세스 권한을 부여해야 하며, 기타 요구 사항을 충족해야 합니다. 자세한 내용은 [Amazon RDS DB 인스턴스에 연결할 수 없음](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting) 섹션을 참조하세요. DB 인스턴스에 공개적으로 액세스할 수 없는 경우 AWS Site-to-Site VPN 연결 또는 Direct Connect 연결을 사용하여 프라이빗 네트워크에서 액세스할 수도 있습니다. 자세한 내용은 [인터네트워크 트래픽 개인 정보](inter-network-traffic-privacy.md) 섹션을 참조하세요.  |  AWS Management Console, [DB 클러스터에서 DB 인스턴스 수정](#Aurora.Modifying.Instance) 사용. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)를 실행하고 `--publicly-accessible\|--no-publicly-accessible` 옵션을 설정합니다. RDS API를 사용하여 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)를 호출하고 `PubliclyAccessible` 파라미터를 설정합니다.  |  지정된 DB 인스턴스만 해당  |  이 변경 도중 인스턴스가 중단되지 않습니다.  | 
|  **Serverless v2 용량 설정** Aurora 용량 유닛(ACU)으로 측정한 Aurora Serverless v2 DB 클러스터의 데이터베이스 용량입니다. 자세한 내용은 [클러스터의 Aurora Serverless v2 용량 설정](aurora-serverless-v2-administration.md#aurora-serverless-v2-setting-acus) 단원을 참조하십시오.  |  AWS Management Console, [콘솔, CLI, API를 사용하여 DB 클러스터 수정](#Aurora.Modifying.Cluster) 사용. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)를 실행하고 `--serverless-v2-scaling-configuration` 옵션을 설정합니다. RDS API를 사용하여 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)를 호출하고 `ServerlessV2ScalingConfiguration` 파라미터를 설정합니다.  |  전체 DB 클러스터  |  이 변경 도중 인스턴스가 중단되지 않습니다. 변경 사항이 즉시 적용됩니다. 이 설정은 즉시 적용 설정을 무시합니다.  | 
|  **보안 그룹** DB 클러스터와 연결할 보안 그룹. 자세한 내용은 [보안 그룹을 통한 액세스 제어](Overview.RDSSecurityGroups.md) 섹션을 참조하세요.  |  AWS Management Console, [콘솔, CLI, API를 사용하여 DB 클러스터 수정](#Aurora.Modifying.Cluster) 사용. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)를 실행하고 `--vpc-security-group-ids` 옵션을 설정합니다. RDS API를 사용하여 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)를 호출하고 `VpcSecurityGroupIds` 파라미터를 설정합니다.  |  전체 DB 클러스터  |  이 변경 도중 인스턴스가 중단되지 않습니다.  | 
|  **대상 역추적 기간** DB 클러스터를 역추적 가능한 시간(초). 이 설정은 Aurora MySQL에서만 사용 가능하며 역추적을 활성화한 상태에서 DB 클러스터가 생성된 경우에만 사용 가능합니다.  |  AWS Management Console, [콘솔, CLI, API를 사용하여 DB 클러스터 수정](#Aurora.Modifying.Cluster) 사용. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)를 실행하고 `--backtrack-window` 옵션을 설정합니다. RDS API를 사용하여 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)를 호출하고 `BacktrackWindow` 파라미터를 설정합니다.  |  전체 DB 클러스터  |  이 변경 도중 인스턴스가 중단되지 않습니다.  | 

## Amazon Aurora DB 클러스터에 적용되지 않는 설정
<a name="Aurora.Modifying.SettingsNotApplicableDBClusters"></a>

다음과 같은 AWS CLI 명령 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) 및 RDS API 작업 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)의 설정은 Amazon Aurora DB 클러스터에 적용되지 않습니다.

**참고**  
Aurora DB 클러스터에 대한 이러한 설정을 수정하기 위해 AWS Management Console을 사용할 수 없습니다.


****  

| AWS CLI 설정 | RDS API 설정 | 
| --- | --- | 
|  `--allocated-storage`  |  `AllocatedStorage`  | 
|  `--auto-minor-version-upgrade \| --no-auto-minor-version-upgrade`  |  `AutoMinorVersionUpgrade`  | 
|  `--db-cluster-instance-class`  |  `DBClusterInstanceClass`  | 
|  `--enable-performance-insights \| --no-enable-performance-insights`  |  `EnablePerformanceInsights`  | 
|  `--iops`  |  `Iops`  | 
|  `--monitoring-interval`  |  `MonitoringInterval`  | 
|  `--monitoring-role-arn`  |  `MonitoringRoleArn`  | 
|  `--option-group-name`  |  `OptionGroupName`  | 
|  `--performance-insights-kms-key-id`  |  `PerformanceInsightsKMSKeyId`  | 
|  `--performance-insights-retention-period`  |  `PerformanceInsightsRetentionPeriod`  | 

## DB 인스턴스용 Amazon Aurora에 적용되지 않는 설정
<a name="Aurora.Modifying.SettingsNotApplicable"></a>

다음과 같은 AWS CLI 명령 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) 및 RDS API 작업 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)의 설정은 Amazon Aurora DB 인스턴스에 적용되지 않습니다.

**참고**  
Aurora DB 인스턴스에 대한 이러한 설정을 수정하기 위해 AWS Management Console을 사용할 수 없습니다.


****  

| AWS CLI 설정 | RDS API 설정 | 
| --- | --- | 
|  `--allocated-storage`  |  `AllocatedStorage`  | 
|  `--allow-major-version-upgrade\|--no-allow-major-version-upgrade`  |  `AllowMajorVersionUpgrade`  | 
|  `--copy-tags-to-snapshot\|--no-copy-tags-to-snapshot`  |  `CopyTagsToSnapshot`  | 
|  `--domain`  |  `Domain`  | 
|  `--db-security-groups`  |  `DBSecurityGroups`  | 
|  `--db-subnet-group-name`  |  `DBSubnetGroupName`  | 
|  `--domain-iam-role-name`  |  `DomainIAMRoleName`  | 
|  `--multi-az\|--no-multi-az`  |  `MultiAZ`  | 
|  `--iops`  |  `Iops`  | 
|  `--license-model`  |  `LicenseModel`  | 
|  `--network-type`  |  `NetworkType`  | 
|  `--option-group-name`  |  `OptionGroupName`  | 
|  `--processor-features`  |  `ProcessorFeatures`  | 
|  `--storage-type`  |  `StorageType`  | 
|  `--tde-credential-arn`  |  `TdeCredentialArn`  | 
|  `--tde-credential-password`  |  `TdeCredentialPassword`  | 
|  `--use-default-processor-features\|--no-use-default-processor-features`  |  `UseDefaultProcessorFeatures`  | 

# DB 클러스터에 Aurora 복제본 추가
<a name="aurora-replicas-adding"></a><a name="create_instance"></a>

복제를 사용하는 Aurora DB 클러스터에는 기본 DB 인스턴스 1개와 최대 15개의 Aurora 복제본이 있습니다. 기본 DB 인스턴스는 읽기 및 쓰기 작업을 지원하고, 클러스터 볼륨의 모든 데이터 수정 작업을 수행합니다. Aurora 복제본은 기본 DB 인스턴스와 동일한 스토리지 볼륨에 연결되지만 읽기 작업만 지원합니다. Aurora 복제본을 사용하여 기본 DB 인스턴스에서 읽기 워크로드를 오프로드합니다. 자세한 내용은 [Aurora 복제본](Aurora.Replication.md#Aurora.Replication.Replicas) 섹션을 참조하세요.

Amazon Aurora 복제본에는 다음과 같은 제약이 포함되어 있습니다.
+ Aurora Serverless v1 DB 클러스터용 Aurora 복제본은 생성할 수 없습니다. Aurora Serverless v1에는 모든 데이터베이스 읽기 및 쓰기 작업을 지원하기 위해 자동으로 확장 및 축소되는 단일 DB 인스턴스가 있습니다.

  그러나 Aurora Serverless v2 DB 클러스터에 리더 인스턴스를 추가할 수 있습니다. 자세한 내용은 [Aurora Serverless v2 리더 추가](aurora-serverless-v2-administration.md#aurora-serverless-v2-adding-reader) 섹션을 참조하세요.

DB 클러스터의 가용성을 높이려면 DB 클러스터의 여러 가용 영역에 걸쳐 Aurora DB 클러스터의 기본 인스턴스 및 Aurora 복제본을 분배하는 것이 좋습니다. 자세한 내용은 [리전 가용성](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability) 섹션을 참조하세요.

Aurora DB 클러스터에서 Aurora 복제본을 제거하려면 [Aurora DB 클러스터에서 DB 인스턴스 삭제](USER_DeleteCluster.md#USER_DeleteInstance) 의 다음 지침에 따라 Aurora 복제본을 삭제하십시오.

**참고**  
또한 Amazon Aurora은 RDS DB 인스턴스 등의 외부 데이터베이스 복제도 지원합니다. RDS DB 인스턴스는 Amazon Aurora와 같은 AWS 리전에 있어야 합니다. 자세한 내용은 [Amazon Aurora를 사용한 복제](Aurora.Replication.md) 섹션을 참조하세요.

AWS Management Console, AWS CLI 또는 RDS API를 사용하여 DB 클러스터에 Aurora 복제본을 추가할 수 있습니다.

## 콘솔
<a name="aurora-replicas-adding.Console"></a>

**DB 클러스터에 Aurora 복제본을 추가하려면**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.

1. 탐색 창에서 **데이터베이스**를 선택한 다음 새로운 DB 인스턴스를 추가할 DB 클러스터를 선택합니다.

1.  클러스터와 기본 인스턴스 모두 **사용 가능** 상태인지 확인합니다. DB 클러스터 또는 기본 인스턴스가 **생성 중** 같은 전환 상태인 경우에는 복제본을 추가할 수 없습니다.

    클러스터에 기본 인스턴스가 없는 경우 [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) AWS CLI 명령을 사용하여 인스턴스를 생성합니다. 이 상황은 CLI를 사용하여 DB 클러스터 스냅샷을 복구한 다음 AWS Management Console에서 클러스터를 보는 경우에 발생할 수 있습니다. 

1. **작업**에서 **Add reader(리더 추가)**를 선택합니다.

   **Add reader(리더 추가)** 페이지가 나타납니다.

1. **Add reader(리더 추가)** 페이지에서 Aurora 복제본에 대한 옵션을 지정합니다. 다음 표에서는 Aurora 복제본 설정을 보여 줍니다.    
<a name="aurora_replica_settings"></a>[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/aurora-replicas-adding.html)

1. **Add reader(리더 추가)**를 선택하여 Aurora 복제본을 생성합니다.

## AWS CLI
<a name="aurora-replicas-adding.CLI"></a>

DB 클러스터에 Aurora 복제본을 생성하려면 [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) AWS CLI 명령을 실행합니다. DB 클러스터의 이름을 `--db-cluster-identifier` 옵션으로 포함하십시오. 다음 예제와 같이 `--availability-zone` 파라미터를 사용하여 Aurora 복제본에 가용 영역을 선택적으로 지정할 수 있습니다.

예를 들어, 다음 명령을 사용하면 이름이 `sample-instance-us-west-2a`인 새 MySQL 5.7–호환 Aurora 복제본이 생성됩니다.

대상 LinuxmacOS, 또는Unix:

```
aws rds create-db-instance --db-instance-identifier sample-instance-us-west-2a \
    --db-cluster-identifier sample-cluster --engine aurora-mysql --db-instance-class db.r5.large \
    --availability-zone us-west-2a
```

Windows의 경우:

```
aws rds create-db-instance --db-instance-identifier sample-instance-us-west-2a ^
    --db-cluster-identifier sample-cluster --engine aurora-mysql --db-instance-class db.r5.large ^
    --availability-zone us-west-2a
```

다음 명령을 사용하면 이름이 `sample-instance-us-west-2a`인 새 MySQL 5.7 호환 Aurora 복제본이 생성됩니다.

대상 LinuxmacOS, 또는Unix:

```
aws rds create-db-instance --db-instance-identifier sample-instance-us-west-2a \
    --db-cluster-identifier sample-cluster --engine aurora-mysql --db-instance-class db.r5.large \
    --availability-zone us-west-2a
```

Windows의 경우:

```
aws rds create-db-instance --db-instance-identifier sample-instance-us-west-2a ^
    --db-cluster-identifier sample-cluster --engine aurora --db-instance-class db.r5.large ^
    --availability-zone us-west-2a
```

다음 명령을 사용하면 이름이 `sample-instance-us-west-2a`인 PostgreSQL 호환 Aurora 복제본이 생성됩니다.

대상 LinuxmacOS, 또는Unix:

```
aws rds create-db-instance --db-instance-identifier sample-instance-us-west-2a \
    --db-cluster-identifier sample-cluster --engine aurora-postgresql --db-instance-class db.r5.large \
    --availability-zone us-west-2a
```

Windows의 경우:

```
aws rds create-db-instance --db-instance-identifier sample-instance-us-west-2a ^
    --db-cluster-identifier sample-cluster --engine aurora-postgresql --db-instance-class db.r5.large ^
    --availability-zone us-west-2a
```

## RDS API
<a name="aurora-replicas-adding.API"></a>

DB 클러스터에 Aurora 복제본을 생성하려면 [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) 작업을 호출하십시오. DB 클러스터의 이름을 `DBClusterIdentifier` 파라미터로 포함하십시오. 선택에 따라 `AvailabilityZone` 파라미터를 사용하여 Aurora 복제본의 가용 영역을 지정할 수 있습니다.

Aurora 복제본을 사용한 Amazon Aurora Auto Scaling에 대한 자세한 내용은 다음 섹션을 참조하세요.

**Topics**
+ [Aurora 복제본을 사용하는 Amazon Aurora Auto Scaling](Aurora.Integrating.AutoScaling.md)
+ [Amazon Aurora DB 클러스터에 Auto Scaling 정책 추가](Aurora.Integrating.AutoScaling.Add.md)
+ [Amazon Aurora DB 클러스터의 Auto Scaling 정책 편집](Aurora.Integrating.AutoScaling.Edit.md)
+ [Amazon Aurora DB 클러스터에서 Auto Scaling 정책 삭제](Aurora.Integrating.AutoScaling.Delete.md)

# Aurora 복제본을 사용하는 Amazon Aurora Auto Scaling
<a name="Aurora.Integrating.AutoScaling"></a>

연결 및 워크로드 요구 사항을 충족하기 위해 Aurora Auto Scaling은 Aurora DB 클러스터에 대해 프로비저닝된 Aurora 복제본(리더 DB 인스턴스) 수를 동적으로 조정합니다. Aurora Auto Scaling은 Aurora MySQL 및 Aurora PostgreSQL에 모두 사용 가능합니다. Aurora Auto Scaling은 Aurora DB 클러스터를 활성화하여 연결 또는 워크로드의 갑작스러운 증가를 처리합니다. 연결 또는 워크로드가 감소하면 사용하지 않는 프로비저닝된 DB 인스턴스에 대해 요금을 지불하지 않도록 Aurora Auto Scaling이 불필요한 Aurora 복제본을 제거합니다.

고객은 조정 정책을 정의하고 Aurora DB 클러스터에 적용합니다. *조정 정책*은 Aurora Auto Scaling에서 관리할 수 있는 최소 및 최대 Aurora 복제본 수를 정의합니다. 정책을 기반으로 Amazon CloudWatch 지표와 대상 값을 사용하여 결정된 실제 워크로드에 따라 Aurora Auto Scaling이 Aurora 복제본 수를 늘리거나 줄여 조정합니다.

**참고**  
Aurora Auto Scaling은 라이터 DB 인스턴스의 워크로드에는 적용되지 않습니다. Aurora Auto Scaling은 리더 인스턴스의 워크로드만 처리합니다.

AWS Management Console을 사용하여 미리 정의된 지표를 기반으로 조정 정책을 적용할 수 있습니다. 또는 미리 정의된 지표나 사용자 지정 지표를 기반으로 AWS CLI 또는 Aurora Auto Scaling API를 사용하여 크기 조정 정책을 적용할 수도 있습니다.

**Topics**
+ [시작하기 전에](#Aurora.Integrating.AutoScaling.BYB)
+ [Aurora Auto Scaling 정책](#Aurora.Integrating.AutoScaling.Concepts)
+ [DB 인스턴스 ID 및 태그 지정](#Aurora.Integrating.AutoScaling.Concepts.Tagging)
+ [Aurora Auto Scaling 및 성능 개선 도우미](#aurora-auto-scaling-pi)

## 시작하기 전에
<a name="Aurora.Integrating.AutoScaling.BYB"></a>

Aurora Auto Scaling을 Aurora DB 클러스터에 사용하려면 먼저 기본(라이터) DB 인스턴스가 있는 Aurora DB 클러스터를 생성해야 합니다. Aurora DB 클러스터 생성에 대한 자세한 정보는 [Amazon Aurora DB 클러스터 생성](Aurora.CreateInstance.md) 섹션을 참조하세요.

DB 클러스터가 복제본이 사용 가능한 상태일 경우에만 Aurora Auto Scaling이 DB 클러스터의 크기를 조정합니다.

Aurora Auto Scaling이 새로운 Aurora 복제본을 추가할 때 새로운 Aurora 복제본은 기본 인스턴스에 사용되는 것과 동일한 DB 인스턴스 클래스입니다. DB 인스턴스 클래스에 대한 자세한 내용은 [Amazon AuroraDB 인스턴스 클래스](Concepts.DBInstanceClass.md) 섹션을 참조하십시오. 또한 새 Aurora 복제본을 위한 승격 티어는 우선 순위가 마지막인 기본값 15로 설정됩니다. 즉 장애 조치가 이루어지는 동안 수동으로 생성된 것과 같이 우선 순위가 더 높은 복제본이 먼저 승격됩니다. 자세한 내용은 [Aurora DB 클러스터의 내결함성](Concepts.AuroraHighAvailability.md#Aurora.Managing.FaultTolerance) 섹션을 참조하세요.

Aurora Auto Scaling은 자체에서 생성한 Aurora 복제본만 제거합니다.

Aurora Auto Scaling의 이점을 활용하려면 애플리케이션에서 새로운 Aurora 복제본과의 연결을 지원해야 합니다. 이렇게 하려면 Aurora 리더 엔드포인트를 사용하는 것이 좋습니다. AWS JDBC 드라이버와 같은 드라이버를 사용할 수 있습니다. 자세한 내용은 [Amazon Aurora DB 클러스터에 연결](Aurora.Connecting.md) 섹션을 참조하세요.

**참고**  
Aurora 글로벌 데이터베이스는 현재 세컨더리 데이터베이스 클러스터에 대해 Aurora Auto Scaling을 지원하지 않습니다.

## Aurora Auto Scaling 정책
<a name="Aurora.Integrating.AutoScaling.Concepts"></a>

Aurora Auto Scaling에서는 조정 정책을 사용하여 Aurora DB 클러스터의 Aurora 복제본 수를 조정합니다. Aurora Auto Scaling의 구성 요소는 다음과 같습니다.
+ 서비스 연결 역할
+ 대상 지표
+ 최소 및 최대 용량
+ 휴지 기간

**Topics**
+ [서비스 연결 역할](#Aurora.Integrating.AutoScaling.Concepts.SLR)
+ [대상 지표](#Aurora.Integrating.AutoScaling.Concepts.TargetMetric)
+ [최소 및 최대 용량](#Aurora.Integrating.AutoScaling.Concepts.Capacity)
+ [휴지 기간](#Aurora.Integrating.AutoScaling.Concepts.Cooldown)
+ [스케일 인 활동 활성화 또는 비활성화](#Aurora.Integrating.AutoScaling.Concepts.ScaleIn)
+ [Auto Scaling 정책 추가, 편집 또는 삭제](#Aurora.Integrating.AutoScaling.Concepts.AddEditDelete)

### 서비스 연결 역할
<a name="Aurora.Integrating.AutoScaling.Concepts.SLR"></a>

Aurora Auto Scaling은 `AWSServiceRoleForApplicationAutoScaling_RDSCluster` 서비스 연결 역할을 사용합니다. 자세한 정보는 *Application Auto Scaling 사용 설명서*의 [Application Auto Scaling 서비스 연결 역할](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html)을 참조하십시오.

### 대상 지표
<a name="Aurora.Integrating.AutoScaling.Concepts.TargetMetric"></a>

이 유형의 정책에서는 미리 정의된 지표나 사용자 지정 지표 및 지표의 대상 값이 대상 추적 조정 정책 구성에 지정됩니다. Aurora Auto Scaling은 조정 정책을 트리거하는 CloudWatch 경보를 생성 및 관리하고 지표와 대상 값을 기준으로 조정 조절을 계산합니다. 조정 정책은 필요에 따라 Aurora 복제본을 추가하거나 제거하여 지표를 지정한 대상 값으로 또는 대상 값에 가깝게 유지합니다. 대상 추적 조정 정책은 지표를 대상 값에 가깝게 유지하는 것 외에도 워크로드 변화로 인한 지표의 변동에 따라 조정되기도 합니다. 이 정책은 DB 클러스터의 사용 가능한 Aurora 복제본 수의 급격한 변동을 최소하기도 합니다.

미리 정의된 평균 CPU 사용률 지표가 사용되는 조정 정책을 예로 든다면, 그러한 정책이 CPU 사용률을 40%의 지정된 사용률(퍼센트)로 또는 그에 가깝게 유지할 수 있습니다.

**참고**  
 Aurora DB 클러스터마다 대상 지표에 대해 Auto Scaling 정책을 하나씩만 생성할 수 있습니다.

Aurora Auto Scaling을 구성하면 대상 지표 값이 클러스터에 있는 모든 리더 인스턴스의 평균으로 계산됩니다. 이 계산은 다음과 같이 이루어집니다.
+ Auto Scaling에서 관리되든 수동으로 추가되든 관계없이 Aurora 클러스터의 모든 리더 인스턴스를 포함합니다.
+ 사용자 지정 엔드포인트와 연결된 인스턴스를 포함합니다. 사용자 지정 엔드포인트는 대상 지표 계산에 영향을 주지 않습니다.
+ 클러스터의 라이터 인스턴스는 포함하지 않습니다.

이 지표는 다음 차원을 사용하여 CloudWatch에서 파생됩니다.
+ `DBClusterIdentifier`
+ `Role=READER`

예를 들어 다음 설정을 사용하는 Aurora MySQL 클러스터를 생각해 보세요.
+ **수동 인스턴스(Auto Scaling으로 제어되지 않음)**:
  + CPU 사용률이 50%인 라이터
  + CPU 사용률이 90%인 리더 1(사용자 지정 엔드포인트: `custom-reader-1`)
  + CPU 사용률이 90%인 리더 2(사용자 지정 엔드포인트: `custom-reader-2`)
+ **Auto Scaling 인스턴스**:
  + CPU 사용률이 10%인 리더 3(Auto Scaling을 사용하여 추가됨)

이 시나리오에서는 Auto Scaling 정책의 대상 지표가 다음과 같이 계산됩니다.

```
Target metric = (CPU utilization of reader 1 + reader 2 + reader 3) / total number of readers

Target metric = (90 + 90 + 10) / 3 = 63.33%
```

Auto Scaling 정책은 이 값을 사용하여 정의된 임계값에 따라 스케일 인할지 스케일 아웃할지를 평가합니다.

다음을 고려하세요.
+ 사용자 지정 엔드포인트는 트래픽이 특정 리더로 라우팅되는 방법을 결정하지만 지표 계산에서 리더를 제외하지는 않습니다.
+ 수동 인스턴스는 항상 대상 지표 계산에 포함됩니다.
+ 예기치 않은 규모 조정 동작을 방지하려면 Auto Scaling 구성이 클러스터의 모든 리더 인스턴스를 고려하는지 확인합니다.
+ 클러스터에 리더가 없는 경우 지표가 계산되지 않으며 Auto Scaling 정책 경보는 비활성 상태로 유지됩니다. Auto Scaling 정책이 효과적으로 작동하려면 항상 리더가 하나 이상 있어야 합니다.

### 최소 및 최대 용량
<a name="Aurora.Integrating.AutoScaling.Concepts.Capacity"></a>

Application Auto Scaling에서 관리할 최대 Aurora 복제본 수를 지정할 수 있습니다. 이 값은 0–15로 설정되어야 하며 최소 Aurora 복제본 수에 대해 지정된 값과 같거나 커야 합니다.

Application Auto Scaling에서 관리할 최소 Aurora 복제본 수를 지정할 수도 있습니다. 이 값은 0–15로 설정되어야 하며 최대 Aurora 복제본 수에 대해 지정된 값과 같거나 작아야 합니다.

Aurora Auto Scaling이 작동하려면 리더 DB 인스턴스가 하나 이상 있어야 합니다. DB 클러스터에 리더 인스턴스가 없고 최소 용량을 0으로 설정하면 Aurora Auto Scaling이 작동하지 않습니다.

**참고**  
Aurora DB 클러스터에 대해 최소 및 최대 용량이 설정됩니다. 지정된 값은 해당 Aurora DB 클러스터와 연관된 모든 정책에 적용됩니다.

### 휴지 기간
<a name="Aurora.Integrating.AutoScaling.Concepts.Cooldown"></a>

Aurora DB 클러스터의 축소 및 확장에 영향을 미치는 휴지 기간을 추가하여 대상 추적 조정 정책의 응답성을 조정할 수 있습니다. 휴지 기간은 기간이 만료될 때까지 후속 스케일 인 또는 스케일 아웃 요청을 차단합니다. 이 차단으로 인해 축소 요청에 대한 Aurora DB 클러스터의 Aurora 복제본 차단과 확장 요청에 대한 Aurora 복제본 생성 속도가 느려집니다.

다음과 같은 휴지 기간을 지정할 수 있습니다.
+ 축소 활동은 Aurora DB 클러스터에 있는 Aurora 복제본 수를 줄입니다. 스케일 인 휴지 기간은 스케일 인 활동이 완료되고 다른 스케일 인 활동이 시작되기 전의 시간을 초 단위로 지정합니다.
+ 확장 활동은 Aurora DB 클러스터에 있는 Aurora 복제본 수를 늘립니다. 스케일 아웃 휴지 기간은 스케일 아웃 활동이 완료되고 다른 스케일 아웃 활동이 시작되기 전의 시간을 초 단위로 지정합니다.
**참고**  
후속 스케일 아웃 요청이 첫 번째 요청보다 많은 Aurora Replica에 대한 요청인 경우 스케일 아웃 휴지 기간은 무시됩니다.

스케일 인 또는 스케일 아웃 휴지 기간을 지정하지 않은 경우 기본값은 각각 300초입니다.

### 스케일 인 활동 활성화 또는 비활성화
<a name="Aurora.Integrating.AutoScaling.Concepts.ScaleIn"></a>

정책의 스케일 인 활동을 활성화하거나 비활성화할 수 있습니다. 축소 활동을 활성화하면 조정 정책을 통해 Aurora 복제본을 삭제할 수 있습니다. 스케일 인 활동이 활성화되면 조정 정책의 스케일 인 휴지 기간이 스케일 인 활동에 적용됩니다. 축소 활동을 비활성화하면 스케일 정책을 통해 Aurora 복제본을 삭제할 수 없습니다.

**참고**  
조정 정책이 필요에 따라 Aurora 복제본을 생성할 수 있도록 확장 활동이 항상 활성화됩니다.

### Auto Scaling 정책 추가, 편집 또는 삭제
<a name="Aurora.Integrating.AutoScaling.Concepts.AddEditDelete"></a>

AWS Management Console, AWS CLI 또는 Application Auto Scaling API를 사용하여 Auto Scaling 정책을 추가, 편집 또는 삭제할 수 있습니다. Auto Scaling 정책을 추가, 편집 또는 삭제하는 방법에 대한 자세한 내용은 다음 섹션을 참조하세요.
+ [Amazon Aurora DB 클러스터에 Auto Scaling 정책 추가](Aurora.Integrating.AutoScaling.Add.md)
+ [Amazon Aurora DB 클러스터의 Auto Scaling 정책 편집](Aurora.Integrating.AutoScaling.Edit.md)
+ [Amazon Aurora DB 클러스터에서 Auto Scaling 정책 삭제](Aurora.Integrating.AutoScaling.Delete.md)

## DB 인스턴스 ID 및 태그 지정
<a name="Aurora.Integrating.AutoScaling.Concepts.Tagging"></a>

Aurora Auto Scaling으로 복제본이 추가되면 DB 인스턴스 ID에 `application-autoscaling-` 접두어가 붙습니다 (예: `application-autoscaling-61aabbcc-4e2f-4c65-b620-ab7421abc123`).

다음 태그는 DB 인스턴스에 자동으로 추가됩니다. DB 인스턴스 세부 정보 페이지의 **Tags** 탭에서 확인할 수 있습니다.


| Tag | 값 | 
| --- | --- | 
| application-autoscaling:resourceId | cluster:mynewcluster-cluster | 

Amazon RDS 리소스 태그에 관한 자세한 내용은 [Amazon Aurora 및Amazon RDS 리소스에 태그 지정](USER_Tagging.md) 섹션을 참조하세요.

## Aurora Auto Scaling 및 성능 개선 도우미
<a name="aurora-auto-scaling-pi"></a>

성능 개선 도우미를 사용하면 다른 Aurora 리더 DB 인스턴스와 마찬가지로 Aurora Auto Scaling에서 추가한 복제본을 모니터링할 수 있습니다.

성능 개선 도우미를 사용하여 Aurora DB 클러스터를 모니터링하는 방법에 대한 자세한 내용은 [성능 개선 도우미를 통한 Amazon Aurora 모니터링](USER_PerfInsights.md) 섹션을 참조하세요.

# Amazon Aurora DB 클러스터에 Auto Scaling 정책 추가
<a name="Aurora.Integrating.AutoScaling.Add"></a>

AWS Management Console, AWS CLI 또는 Application Auto Scaling API를 사용하여 크기 조정 정책을 추가할 수 있습니다.

**참고**  
CloudFormation을 사용하여 크기 조정 정책을 추가하는 예는 *AWS CloudFormation 사용 설명서*의 [Aurora DB 클러스터의 크기 조정 정책 선언](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-autoscaling.html#w2ab1c19c22c15c21c11)을 참조하세요.

## 콘솔
<a name="Aurora.Integrating.AutoScaling.AddConsole"></a>

AWS Management Console을 사용하여 크기 조정 정책을 Aurora DB 클러스터에 추가할 수 있습니다.

**Aurora DB 클러스터에 Auto Scaling 정책을 추가하려면**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.

1. 탐색 창에서 **데이터베이스**를 선택합니다.

1. 정책을 추가할 Aurora DB 클러스터를 선택하십시오.

1. **로그 및 이벤트** 탭을 선택합니다.

1. **Auto scaling policies(Auto Scaling 정책)** 섹션에서 **추가**를 선택합니다.

   [**Add Auto Scaling policy**] 대화 상자가 나타납니다.

1. **Policy Name(정책 이름)**에서 정책의 이름을 입력합니다.

1. 대상 지표로 다음 중 하나를 선택합니다.
   + 평균 CPU 사용률을 기반으로 정책을 생성하려면 **Aurora 복제본의 평균 CPU 사용률**.
   + Aurora 복제본에 대한 평균 연결 수를 기반으로 정책을 생성하려면 **Aurora 복제본의 평균 연결 수**.

1. 대상 값으로 다음 중 하나를 입력합니다.
   + 이전 단계에서 **Aurora 복제본의 평균 CPU 사용률**을 선택한 경우 Aurora 복제본에 유지하려는 CPU 사용률(퍼센트)을 입력하십시오.
   + 이전 단계에서 **Aurora 복제본의 평균 연결**을 선택한 경우 유지하려는 연결 수를 입력하십시오.

   Aurora 복제본이 추가되거나 제거되어 지정한 값에 가깝게 지표가 유지됩니다.

1. (선택 사항) **추가 구성**을 열어 스케일 인 또는 스케일 아웃 휴지 기간을 생성합니다.

1. **최소 용량**에 Aurora Auto Scaling 정책에 따라 유지해야 할 최소 Aurora 복제본 수를 입력하십시오.

1. **최대 용량**에 Aurora Auto Scaling 정책에 따라 유지해야 할 최대 Aurora 복제본 수를 입력하십시오.

1. [**Add policy**]를 선택합니다.

다음 대화 상자에서 평균 CPU 사용률 40%를 기반으로 Auto Scaling 정책을 생성합니다. 정책은 최소 5개의 Aurora 복제본과 최대 15개의 Aurora 복제본을 지정합니다.

![\[평균 CPU 사용률을 기반으로 Auto Scaling 정책 생성\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/aurora-autoscaling-cpu.png)


다음 대화 상자는 평균 연결 수 100을 기반으로 Auto Scaling 정책을 생성합니다. 정책은 최소 2개의 Aurora 복제본과 최대 8개의 Aurora 복제본을 지정합니다.

![\[평균 연결을 기반으로 Auto Scaling 정책 생성\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/aurora-autoscaling-connections.png)


## AWS CLI 또는 Application Auto Scaling API
<a name="Aurora.Integrating.AutoScaling.AddCode"></a>

미리 정의된 지표나 사용자 지정 지표를 기반으로 조정 정책을 적용할 수 있습니다. 이를 위해 AWS CLI 또는 Application Auto Scaling API를 사용할 수 있습니다. 첫 단계는 Application Auto Scaling 사용하여 Aurora DB 클러스터를 등록해야 합니다.

### Aurora DB 클러스터 등록
<a name="Aurora.Integrating.AutoScaling.AddCode.Register"></a>

Aurora DB 클러스터에 Aurora Auto Scaling을 사용하려면 먼저 Application Auto Scaling을 사용하여 Aurora DB 클러스터를 등록합니다. 그렇게 하려면 해당 클러스터에 적용할 크기 조정 차원 및 한계를 정의합니다. Application Auto Scaling은 Aurora 복제본 수를 나타내는 `rds:cluster:ReadReplicaCount` 크기 조정 가능한 차원을 따라 Aurora DB 클러스터를 동적으로 크기 조정합니다.

Aurora DB 클러스터를 등록하려면 AWS CLI 또는 Application Auto Scaling API를 사용할 수 있습니다.

#### AWS CLI
<a name="Aurora.Integrating.AutoScaling.AddCode.Register.CLI"></a>

Aurora DB 클러스터를 등록하려면 다음 파라미터와 함께 [https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) AWS CLI명령을 사용하세요.
+ `--service-namespace` 이 값을 로 설정하십시오.`rds`
+ `--resource-id` – Aurora DB 클러스터의 리소스 식별자. 이 파라미터의 경우 리소스 유형은 `cluster`이고 고유 식별자는 `cluster:myscalablecluster`와 같은 Aurora DB 클러스터의 이름입니다.
+ `--scalable-dimension` 이 값을 로 설정하십시오.`rds:cluster:ReadReplicaCount`
+ `--min-capacity` – Application Auto Scaling에서 관리하는 최소 리더 DB 인스턴스 수 `--min-capacity`, `--max-capacity` 및 클러스터의 DB 인스턴스 수 간의 관계에 대한 자세한 내용은 [최소 및 최대 용량](Aurora.Integrating.AutoScaling.md#Aurora.Integrating.AutoScaling.Concepts.Capacity) 단원을 참조하십시오.
+ `--max-capacity` – Application Auto Scaling에서 관리하는 최소 리더 DB 인스턴스 수 `--min-capacity`, `--max-capacity` 및 클러스터의 DB 인스턴스 수 간의 관계에 대한 자세한 내용은 [최소 및 최대 용량](Aurora.Integrating.AutoScaling.md#Aurora.Integrating.AutoScaling.Concepts.Capacity) 단원을 참조하십시오.

**Example**  
다음 예제에서는 이름이 `myscalablecluster`인 Aurora DB 클러스터를 등록합니다. 등록은 1개에서 8개까지 Aurora 복제본을 포함하도록 DB 클러스터 크기를 동적으로 조정해야 함을 나타냅니다.  
대상 LinuxmacOS, 또는Unix:  

```
aws application-autoscaling register-scalable-target \
    --service-namespace rds \
    --resource-id cluster:myscalablecluster \
    --scalable-dimension rds:cluster:ReadReplicaCount \
    --min-capacity 1 \
    --max-capacity 8 \
```
Windows의 경우:  

```
aws application-autoscaling register-scalable-target ^
    --service-namespace rds ^
    --resource-id cluster:myscalablecluster ^
    --scalable-dimension rds:cluster:ReadReplicaCount ^
    --min-capacity 1 ^
    --max-capacity 8 ^
```

#### Application Auto Scaling API
<a name="Aurora.Integrating.AutoScaling.AddCode.Register.API"></a>

Application Auto Scaling로 Aurora DB 클러스터를 등록하려면 다음 파라미터와 함께 [https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_RegisterScalableTarget.html](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_RegisterScalableTarget.html) Application Auto Scaling API 작업을 사용하십시오.
+ `ServiceNamespace` 이 값을 로 설정하십시오.`rds`
+ `ResourceID` – Aurora DB 클러스터의 리소스 식별자. 이 파라미터의 경우 리소스 유형은 `cluster`이고 고유 식별자는 `cluster:myscalablecluster`와 같은 Aurora DB 클러스터의 이름입니다.
+ `ScalableDimension` 이 값을 로 설정하십시오.`rds:cluster:ReadReplicaCount`
+ `MinCapacity` – Application Auto Scaling에서 관리하는 최소 리더 DB 인스턴스 수 `MinCapacity`, `MaxCapacity` 및 클러스터의 DB 인스턴스 수 간의 관계에 대한 자세한 내용은 [최소 및 최대 용량](Aurora.Integrating.AutoScaling.md#Aurora.Integrating.AutoScaling.Concepts.Capacity) 단원을 참조하십시오.
+ `MaxCapacity` – Application Auto Scaling에서 관리하는 최소 리더 DB 인스턴스 수 `MinCapacity`, `MaxCapacity` 및 클러스터의 DB 인스턴스 수 간의 관계에 대한 자세한 내용은 [최소 및 최대 용량](Aurora.Integrating.AutoScaling.md#Aurora.Integrating.AutoScaling.Concepts.Capacity) 단원을 참조하십시오.

**Example**  
다음 예제에서는 Application Auto Scaling API를 사용하여 이름이 `myscalablecluster`인 Aurora DB 클러스터를 등록합니다. 이 등록은 1개에서 8개까지 Aurora 복제본을 포함하도록 DB 클러스터 크기를 동적으로 조정해야 함을 나타냅니다.  

```
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.RegisterScalableTarget
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS

{
    "ServiceNamespace": "rds",
    "ResourceId": "cluster:myscalablecluster",
    "ScalableDimension": "rds:cluster:ReadReplicaCount",
    "MinCapacity": 1,
    "MaxCapacity": 8
}
```

### Aurora DB 클러스터에 대한 조정 정책 정의
<a name="Aurora.Integrating.AutoScaling.AddCode.DefineScalingPolicy"></a>

대상 추적 조정 정책 구성은 지표와 대상 값이 정의되어 있는 JSON 블록으로 나타냅니다. 텍스트 파일에 JSON 블록으로 조정 정책 구성을 저장할 수 있습니다. AWS CLI 또는 Application Auto Scaling API를 호출할 때 이 텍스트 파일을 사용합니다. 정책 구성 구문에 대한 자세한 정보는 Application Auto Scaling API 참조의 [https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html)을 참조하세요.**

 대상 추적 조정 정책 구성을 정의하기 위해 다음과 같은 옵션을 사용할 수 있습니다.

**Topics**
+ [미리 정의된 지표 사용](#Aurora.Integrating.AutoScaling.AddCode.DefineScalingPolicy.Predefined)
+ [사용자 지정 지표 사용](#Aurora.Integrating.AutoScaling.AddCode.DefineScalingPolicy.Custom)
+ [휴지 기간 사용](#Aurora.Integrating.AutoScaling.AddCode.DefineScalingPolicy.Cooldown)
+ [스케일 인 활동 비활성화](#Aurora.Integrating.AutoScaling.AddCode.DefineScalingPolicy.ScaleIn)

#### 미리 정의된 지표 사용
<a name="Aurora.Integrating.AutoScaling.AddCode.DefineScalingPolicy.Predefined"></a>

미리 정의된 지표를 사용하여 Aurora Auto Scaling에서 대상 추적과 동적 조정 둘 다에 원활하게 사용할 수 있는 대상 추적 조정 정책을 Aurora DB 클러스터에 대해 신속하게 정의할 수 있습니다.

현재 Aurora은 Aurora Auto Scaling에서 다음과 같이 미리 정의된 지표를 지원합니다.
+ **RDSReaderAverageCPUUtilization** – Aurora DB 클러스터에 있는 모든 Aurora 복제본에서 CloudWatch에 있는 `CPUUtilization` 지표의 평균 값.
+ **RDSReaderAverageDatabaseConnections** – Aurora DB 클러스터에 있는 모든 Aurora 복제본에서 CloudWatch에 있는 `DatabaseConnections` 지표의 평균 값.

`CPUUtilization` 및 `DatabaseConnections` 지표에 대한 자세한 정보는 [Amazon Aurora에 대한 Amazon CloudWatch 지표](Aurora.AuroraMonitoring.Metrics.md) 단원을 참조하십시오.

조정 정책에서 미리 정의된 지표를 사용하려면 조정 정책을 위한 대상 추적 구성을 생성합니다. 미리 정의된 지표의 `PredefinedMetricSpecification` 및 해당 지표의 대상 값에 대한 `TargetValue`를 이 구성에 포함해야 합니다.

**Example**  
다음 예제에서는 Aurora DB 클러스터의 대상 추적 조정을 위한 일반적인 정책 구성을 설명합니다. 이 구성에서 `RDSReaderAverageCPUUtilization` 미리 정의된 지표는 모든 Aurora 복제본에 대해 평균 CPU 사용률 40%를 기반으로 Aurora DB 클러스터를 조정합니다.  

```
{
    "TargetValue": 40.0,
    "PredefinedMetricSpecification":
    {
        "PredefinedMetricType": "RDSReaderAverageCPUUtilization"
    }
}
```

#### 사용자 지정 지표 사용
<a name="Aurora.Integrating.AutoScaling.AddCode.DefineScalingPolicy.Custom"></a>

사용자 지정 지표를 사용하여 사용자 지정 요구 사항에 맞는 대상 추적 조정 정책을 정의할 수 있습니다. 조정에 따라 변경되는 모든 Aurora 지표를 기반으로 사용자 지정 지표를 정의할 수 있습니다.

모든 Aurora 지표를 대상 추적에 사용할 수 있는 것은 아닙니다. 측정치는 유효한 사용량 수치로서 인스턴스의 사용량을 설명해야 합니다. Aurora DB 클러스터에 있는 Aurora 복제본 수에 따라 지표 값이 증가하거나 줄어들어야 합니다. 지표 데이터를 사용하여 Aurora 복제본 수를 비례적으로 확장 또는 축소하려면 이 비례적인 증가나 감소가 필요합니다.

**Example**  
다음 예제에서는 조정 정책의 대상 추적 구성을 설명합니다. 이 구성에서 사용자 지정 지표는 `my-db-cluster`라는 Aurora DB 클러스터의 모든 Aurora 복제본에 대해 평균 CPU 사용률 50%를 기반으로 Aurora DB 클러스터를 조정합니다.  

```
{
    "TargetValue": 50,
    "CustomizedMetricSpecification":
    {
        "MetricName": "CPUUtilization",
        "Namespace": "AWS/RDS",
        "Dimensions": [
            {"Name": "DBClusterIdentifier","Value": "my-db-cluster"},
            {"Name": "Role","Value": "READER"}
        ],
        "Statistic": "Average",
        "Unit": "Percent"
    }
}
```

#### 휴지 기간 사용
<a name="Aurora.Integrating.AutoScaling.AddCode.DefineScalingPolicy.Cooldown"></a>

`ScaleOutCooldown`에 초 단위로 값을 지정하여 Aurora DB 클러스터를 확장하기 위한 휴지 기간을 추가할 수 있습니다. 마찬가지로 `ScaleInCooldown`에 초 단위로 값을 추가하여 Aurora DB 클러스터를 축소하기 위한 휴지 기간을 추가할 수 있습니다. `ScaleInCooldown` 및 `ScaleOutCooldown`에 대한 자세한 정보는 *Application Auto Scaling API 참조*의 [https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html)을 참조하십시오.

**Example**  
다음 예제에서는 조정 정책의 대상 추적 구성을 설명합니다. 이 구성에서 `RDSReaderAverageCPUUtilization` 사전 정의 지표는 해당 Aurora DB 클러스터에 있는 모든 Aurora 복제본에 대해 평균 CPU 사용률 40%를 기반으로 Aurora DB 클러스터를 조정합니다. 구성에서는 스케일 인 휴지 기간 10분과 스케일 아웃 휴지 기간 5분을 제공합니다.  

```
{
    "TargetValue": 40.0,
    "PredefinedMetricSpecification":
    {
        "PredefinedMetricType": "RDSReaderAverageCPUUtilization"
    },
    "ScaleInCooldown": 600,
    "ScaleOutCooldown": 300
}
```

#### 스케일 인 활동 비활성화
<a name="Aurora.Integrating.AutoScaling.AddCode.DefineScalingPolicy.ScaleIn"></a>

축소 활동을 비활성화하여 대상 추적 조정 정책 구성에서 Aurora DB 클러스터를 축소하지 않도록 할 수 있습니다. 축소 활동을 비활성화하면 조정 정책에서 필요에 따라 Aurora 복제본을 생성할 수 있지만 삭제할 수는 없습니다.

`DisableScaleIn`에 부울 값을 지정하여 Aurora DB 클러스터에 대한 축소 활동을 활성화하거나 비활성화할 수 있습니다. `DisableScaleIn`에 대한 자세한 정보는 *Application Auto Scaling API 참조*의 [https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html)을 참조하십시오.

**Example**  
다음 예제에서는 조정 정책의 대상 추적 구성을 설명합니다. 이 구성에서 `RDSReaderAverageCPUUtilization` 미리 정의된 지표는 해당 Aurora DB 클러스터에 있는 모든 Aurora 복제본에 대해 평균 CPU 사용률 40%를 기반으로 Aurora DB 클러스터를 조정합니다. 구성에서는 조정 정책의 스케일 인 활동을 비활성화합니다.  

```
{
    "TargetValue": 40.0,
    "PredefinedMetricSpecification":
    {
        "PredefinedMetricType": "RDSReaderAverageCPUUtilization"
    },
    "DisableScaleIn": true
}
```

### Aurora DB 클러스터에 조정 정책 적용
<a name="Aurora.Integrating.AutoScaling.AddCode.ApplyScalingPolicy"></a>

Application Auto Scaling으로 Aurora DB 클러스터를 등록하고 조정 정책을 삭제한 후 등록된 Aurora DB 클러스터에 조정 정책을 적용합니다. 크기 조정 정책을 Aurora DB 클러스터에 적용하려면 AWS CLI 또는 Application Auto Scaling API를 사용할 수 있습니다.

#### AWS CLI
<a name="Aurora.Integrating.AutoScaling.AddCode.ApplyScalingPolicy.CLI"></a>

크기 조정 정책을 Aurora DB 클러스터에 적용하려면 [https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html)AWS CLI 명령을 다음 파라미터와 함께 사용합니다.
+ `--policy-name` – 조정 정책의 이름입니다.
+ `--policy-type` 이 값을 로 설정하십시오.`TargetTrackingScaling`
+ `--resource-id` – Aurora DB 클러스터의 리소스 식별자. 이 파라미터의 경우 리소스 유형은 `cluster`이고 고유 식별자는 `cluster:myscalablecluster`와 같은 Aurora DB 클러스터의 이름입니다.
+ `--service-namespace` 이 값을 로 설정하십시오.`rds`
+ `--scalable-dimension` 이 값을 로 설정하십시오.`rds:cluster:ReadReplicaCount`
+ `--target-tracking-scaling-policy-configuration` – Aurora DB 클러스터에 사용할 대상 추적 조정 정책 구성입니다.

**Example**  
다음 예제에서는 Application Auto Scaling를 사용하여 `myscalablepolicy`라는 대상 추적 조정 정책을 `myscalablecluster`라는 Aurora DB 클러스터에 적용합니다. 이를 위해 `config.json`이라는 파일에 저장된 정책 구성을 사용합니다.  
대상 LinuxmacOS, 또는Unix:  

```
aws application-autoscaling put-scaling-policy \
    --policy-name myscalablepolicy \
    --policy-type TargetTrackingScaling \
    --resource-id cluster:myscalablecluster \
    --service-namespace rds \
    --scalable-dimension rds:cluster:ReadReplicaCount \
    --target-tracking-scaling-policy-configuration file://config.json
```
Windows의 경우:  

```
aws application-autoscaling put-scaling-policy ^
    --policy-name myscalablepolicy ^
    --policy-type TargetTrackingScaling ^
    --resource-id cluster:myscalablecluster ^
    --service-namespace rds ^
    --scalable-dimension rds:cluster:ReadReplicaCount ^
    --target-tracking-scaling-policy-configuration file://config.json
```

#### Application Auto Scaling API
<a name="Aurora.Integrating.AutoScaling.AddCode.ApplyScalingPolicy.API"></a>

Application Auto Scaling API를 사용하여 Aurora DB 클러스터에 조정 정책을 적용하려면 다음 파라미터와 함께 [https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_PutScalingPolicy.html](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_PutScalingPolicy.html) Application Auto Scaling API 작업을 사용하십시오.
+ `PolicyName` – 조정 정책의 이름입니다.
+ `ServiceNamespace` 이 값을 로 설정하십시오.`rds`
+ `ResourceID` – Aurora DB 클러스터의 리소스 식별자. 이 파라미터의 경우 리소스 유형은 `cluster`이고 고유 식별자는 `cluster:myscalablecluster`와 같은 Aurora DB 클러스터의 이름입니다.
+ `ScalableDimension` 이 값을 로 설정하십시오.`rds:cluster:ReadReplicaCount`
+ `PolicyType` 이 값을 로 설정하십시오.`TargetTrackingScaling`
+ `TargetTrackingScalingPolicyConfiguration` – Aurora DB 클러스터에 사용할 대상 추적 조정 정책 구성입니다.

**Example**  
다음 예제에서는 Application Auto Scaling를 사용하여 `myscalablepolicy`라는 대상 추적 조정 정책을 `myscalablecluster`라는 Aurora DB 클러스터에 적용합니다. `RDSReaderAverageCPUUtilization` 사전 정의 지표를 기반으로 하는 정책 구성을 사용합니다.  

```
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.PutScalingPolicy
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS

{
    "PolicyName": "myscalablepolicy",
    "ServiceNamespace": "rds",
    "ResourceId": "cluster:myscalablecluster",
    "ScalableDimension": "rds:cluster:ReadReplicaCount",
    "PolicyType": "TargetTrackingScaling",
    "TargetTrackingScalingPolicyConfiguration": {
        "TargetValue": 40.0,
        "PredefinedMetricSpecification":
        {
            "PredefinedMetricType": "RDSReaderAverageCPUUtilization"
        }
    }
}
```

# Amazon Aurora DB 클러스터의 Auto Scaling 정책 편집
<a name="Aurora.Integrating.AutoScaling.Edit"></a>

AWS Management Console, AWS CLI 또는 Application Auto Scaling API를 사용하여 크기 조정 정책을 편집할 수 있습니다.

## 콘솔
<a name="Aurora.Integrating.AutoScaling.EditConsole"></a>

AWS Management Console을 사용하여 조정 정책을 편집할 수 있습니다.

**Aurora DB 클러스터의 Auto Scaling 정책을 편집하려면**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.

1. 탐색 창에서 **데이터베이스**를 선택합니다.

1. Auto Scaling 정책을 편집할 Aurora DB 클러스터를 선택합니다.

1. **로그 및 이벤트** 탭을 선택합니다.

1. **Auto scaling policies(Auto Scaling 정책)** 섹션에서 Auto Scaling 정책을 선택한 후 **편집**을 선택합니다.

1. 정책을 변경합니다.

1. **저장**을 선택합니다.

[**Edit Auto Scaling policy**] 대화 상자 샘플은 다음과 같습니다.

![\[평균 CPU 사용률을 기반으로 Auto Scaling 정책 편집\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/aurora-autoscaling-edit-cpu.png)


## AWS CLI 또는 Application Auto Scaling API
<a name="Aurora.Integrating.AutoScaling.EditCode"></a>

크기 조정 정책을 적용하는 것과 같은 방식으로 AWS CLI 또는 Application Auto Scaling API를 사용하여 크기 조정 정책을 편집할 수 있습니다.
+ AWS CLI를 사용할 때는 `--policy-name` 파라미터에서 편집할 정책의 이름을 지정하세요. 변경할 파라미터의 새로운 값을 지정합니다.
+ Application Auto Scaling API를 사용할 때는 `PolicyName` 파라미터에서 편집하려는 정책의 이름을 지정하세요. 변경할 파라미터의 새로운 값을 지정합니다.

자세한 내용은 [Aurora DB 클러스터에 조정 정책 적용](Aurora.Integrating.AutoScaling.Add.md#Aurora.Integrating.AutoScaling.AddCode.ApplyScalingPolicy) 단원을 참조하십시오.

# Amazon Aurora DB 클러스터에서 Auto Scaling 정책 삭제
<a name="Aurora.Integrating.AutoScaling.Delete"></a>

AWS Management Console, AWS CLI 또는 Application Auto Scaling API를 사용하여 크기 조정 정책을 삭제할 수 있습니다.

## 콘솔
<a name="Aurora.Integrating.AutoScaling.Delete.Console"></a>

AWS Management Console을 사용하여 조정 정책을 삭제할 수 있습니다.

**Aurora DB 클러스터의 Auto Scaling 정책을 삭제하려면**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.

1. 탐색 창에서 **데이터베이스**를 선택합니다.

1. Auto Scaling 정책을 삭제할 Aurora DB 클러스터를 선택합니다.

1. **로그 및 이벤트** 탭을 선택합니다.

1. **Auto scaling policies(Auto Scaling 정책)** 섹션에서 Auto Scaling 정책을 선택한 후 **삭제**를 선택합니다.

## AWS CLI
<a name="Aurora.Integrating.AutoScaling.Delete.CLI"></a>

Aurora DB 클러스터에서 크기 조정 정책을 삭제하려면 다음 파라미터와 함께 [https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/delete-scaling-policy.html](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/delete-scaling-policy.html) AWS CLI 명령을 사용하세요.
+ `--policy-name` – 조정 정책의 이름입니다.
+ `--resource-id` – Aurora DB 클러스터의 리소스 식별자. 이 파라미터의 경우 리소스 유형은 `cluster`이고 고유 식별자는 `cluster:myscalablecluster`와 같은 Aurora DB 클러스터의 이름입니다.
+ `--service-namespace` 이 값을 로 설정하십시오.`rds`
+ `--scalable-dimension` 이 값을 로 설정하십시오.`rds:cluster:ReadReplicaCount`

**Example**  
다음 예제에서는 `myscalablepolicy`라는 대상 추적 조정 정책을 `myscalablecluster`라는 Aurora DB 클러스터에서 삭제합니다.  
대상 LinuxmacOS, 또는Unix:  

```
aws application-autoscaling delete-scaling-policy \
    --policy-name myscalablepolicy \
    --resource-id cluster:myscalablecluster \
    --service-namespace rds \
    --scalable-dimension rds:cluster:ReadReplicaCount \
```
Windows의 경우:  

```
aws application-autoscaling delete-scaling-policy ^
    --policy-name myscalablepolicy ^
    --resource-id cluster:myscalablecluster ^
    --service-namespace rds ^
    --scalable-dimension rds:cluster:ReadReplicaCount ^
```

## Application Auto Scaling API
<a name="Aurora.Integrating.AutoScaling.Delete.API"></a>

Aurora DB 클러스터에서 조정 정책을 삭제하려면 다음 파라미터와 함께 [https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_DeleteScalingPolicy.html](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_DeleteScalingPolicy.html) Application Auto Scaling API 작업을 사용하십시오.
+ `PolicyName` – 조정 정책의 이름입니다.
+ `ServiceNamespace` 이 값을 로 설정하십시오.`rds`
+ `ResourceID` – Aurora DB 클러스터의 리소스 식별자. 이 파라미터의 경우 리소스 유형은 `cluster`이고 고유 식별자는 `cluster:myscalablecluster`와 같은 Aurora DB 클러스터의 이름입니다.
+ `ScalableDimension` 이 값을 로 설정하십시오.`rds:cluster:ReadReplicaCount`

**Example**  
다음 예제에서는 Application Auto Scaling API를 사용하여 `myscalablepolicy`라는 대상 추적 조정 정책을 `myscalablecluster`라는 Aurora DB 클러스터에서 삭제합니다.  

```
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.DeleteScalingPolicy
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS

{
    "PolicyName": "myscalablepolicy",
    "ServiceNamespace": "rds",
    "ResourceId": "cluster:myscalablecluster",
    "ScalableDimension": "rds:cluster:ReadReplicaCount"
}
```

# Aurora DB 클러스터의 성능 및 확장 관리
<a name="Aurora.Managing.Performance"></a>

다음 옵션을 사용해 Aurora DB 클러스터 및 DB 인스턴스의 성능 및 확장을 관리할 수 있습니다.

**Topics**
+ [스토리지 조정](#Aurora.Managing.Performance.StorageScaling)
+ [인스턴스 조정](#Aurora.Managing.Performance.InstanceScaling)
+ [읽기 확장](#Aurora.Managing.Performance.ReadScaling)
+ [연결 관리](#Aurora.Managing.MaxConnections)
+ [쿼리 실행 계획 관리](#Aurora.Managing.Optimizing)

## 스토리지 조정
<a name="Aurora.Managing.Performance.StorageScaling"></a>

Aurora 스토리지는 클러스터 볼륨에 저장된 데이터에 따라 자동 조정됩니다. 데이터가 증가하면 DB 엔진 버전에 따라 클러스터 볼륨 스토리지가 확장됩니다. 각 엔진 버전의 최대 Aurora 클러스터 볼륨 크기에 대한 자세한 내용은 [Amazon Aurora 크기 제한](CHAP_Limits.md#RDS_Limits.FileSize.Aurora) 섹션을 참조하세요. 클러스터 볼륨에 포함되는 데이터 종류를 알아보려면 [Amazon Aurora 스토리지](Aurora.Overview.StorageReliability.md) 단원을 참조하세요. 특정 버전의 최대 크기에 대한 자세한 내용은 [Amazon Aurora 크기 제한](CHAP_Limits.md#RDS_Limits.FileSize.Aurora) 섹션을 참조하세요.

스토리지 비용을 결정하기 위해 클러스터 볼륨 크기가 한 시간 단위로 평가됩니다. 요금에 대한 자세한 내용은 [Aurora 요금 페이지](https://aws.amazon.com/rds/aurora/pricing)를 참조하십시오.

Aurora 클러스터 볼륨의 크기는 수테비바이트까지 확장할 수 있지만 요금은 볼륨에서 사용한 공간에 대해서만 청구됩니다. 요금이 청구되는 스토리지 공간을 결정하는 메커니즘은 Aurora 클러스터 버전에 따라 다릅니다.
+ 클러스터 볼륨에서 Aurora 데이터가 제거되면 비슷한 양만큼 요금이 청구되는 전체 공간이 감소합니다. 이 동적 크기 조정 동작은 기본 테이블스페이스가 삭제되거나 공간이 더 적게 필요하도록 재구성할 때 발생합니다. 따라서 더 이상 필요하지 않은 테이블과 데이터베이스를 삭제하여 스토리지 비용을 줄일 수 있습니다. 동적 크기 조정은 특정 Aurora 버전에 적용됩니다. 다음은 데이터를 제거할 때 클러스터 볼륨의 크기가 동적으로 조정되는 Aurora 버전입니다.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Performance.html)
+ 위 목록에 있는 Aurora 버전보다 낮은 버전에서는 데이터를 제거할 때 복원된 공간을 클러스터 볼륨이 다시 사용할 수 있지만 볼륨 자체의 크기는 줄어들지 않습니다.

동적 크기 조정은 클러스터 볼륨 내의 테이블스페이스를 물리적으로 제거하거나 크기를 조정하는 작업에 적용됩니다. 따라서 `DROP TABLE`, `DROP DATABASE`, `TRUNCATE TABLE` 및 `ALTER TABLE ... DROP PARTITION`과 같은 SQL 문에 적용됩니다. `DELETE` 문을 사용하여 행을 삭제하는 경우에는 적용되지 않습니다. 테이블에서 많은 수의 행을 삭제하는 경우 이후에 Aurora MySQL `OPTIMIZE TABLE` 확장이나 Aurora PostgreSQL `pg_repack` 문을 실행해 테이블을 재구성하여 클러스터 볼륨의 크기를 동적으로 조정할 수 있습니다.

Aurora MySQL의 경우 다음 고려 사항이 적용됩니다.
+ 동적 크기 조정을 지원하는 DB 엔진 버전으로 DB 클러스터를 업그레이드한 후 해당 특정 AWS 리전에서 이 기능이 활성화되면 나중에 `DROP TABLE`과 같은 특정 SQL 문에 의해 해제되는 모든 공간을 회수할 수 있습니다.

  특정 AWS 리전에서 이 기능이 명시적으로 비활성화되어 있으면 동적 크기 조정을 지원하는 버전에서도 공간을 재사용할 수만 있고 회수할 수 없습니다.

  이 기능은 2020년 11월부터 2022년 3월까지 특정 DB 엔진 버전(1.23.0-1.23.4, 2.09.0-2.09.3 및 2.10.0)에서 활성화되었으며, 이후 버전에서는 기본적으로 활성화됩니다.
+ 테이블은 내부적으로 다양한 크기의 연속된 하나 이상의 조각으로 저장됩니다. 테이블 `TRUNCATE TABLE` 작업을 실행하는 동안 첫 번째 조각에 해당하는 공간은 재사용할 수 있고 회수할 수 없습니다. 다른 조각은 회수할 수 있습니다. `DROP TABLE` 작업 중에는 전체 테이블스페이스에 해당하는 공간을 회수할 수 있습니다.
+ `innodb_file_per_table` 파라미터는 테이블 스토리지가 구성되는 방식에 영향을 미칩니다. 테이블이 시스템 테이블스페이스의 일부인 경우 테이블을 삭제해도 시스템 테이블스페이스의 크기가 줄어들지 않습니다. 따라서 동적 크기 조정을 최대한 활용하려면 Aurora MySQL DB 클러스터에서 `innodb_file_per_table`을 1로 설정해야 합니다.
+ 버전 2.11 이상의 경우 InnoDB 임시 테이블스페이스가 삭제되고 재시작 시 다시 생성됩니다. 임시 테이블스페이스가 차지하는 공간이 시스템에 릴리스되고 클러스터 볼륨의 크기가 조정됩니다. 동적 크기 조정 기능을 최대한 활용하려면 DB 클러스터를 버전 2.11 이상으로 업그레이드하는 것이 좋습니다.

**참고**  
동적 크기 조정 기능은 테이블스페이스의 테이블이 삭제될 때 즉시 공간을 회수하는 것이 아니라 하루에 약 10TB의 속도로 공간을 점진적으로 확보합니다. 시스템 테이블스페이스는 절대 제거되지 않으므로 시스템 테이블스페이스의 공간은 회수되지 않습니다. 테이블스페이스에서 회수되지 않은 여유 공간은 작업에서 해당 테이블스페이스에 공간이 필요할 때 재사용됩니다. 동적 규모 조정 기능은 클러스터가 사용 가능한 상태일 때만 스토리지 공간을 회수할 수 있습니다.

CloudWatch에서 `VolumeBytesUsed` 지표를 모니터링하여 클러스터가 사용 중인 스토리지 공간의 양을 확인할 수 있습니다. 스토리지 요금 청구에 대한 자세한 정보는 [Aurora 데이터 스토리지 요금이 청구되는 방법](Aurora.Overview.StorageReliability.md#aurora-storage-data-billing) 섹션을 참조하세요.
+ AWS Management Console에서는 클러스터에 대한 세부 정보 페이지의 `Monitoring` 탭에서 차트로 이 그림을 볼 수 있습니다.
+ AWS CLI를 사용하는 경우 다음 Linux 예제와 유사한 명령을 실행하면 됩니다. 이때 시작 및 종료 시간과 클러스터 이름을 해당되는 고유한 값으로 대체합니다.

  ```
  aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \
    --start-time "$(date -d '6 hours ago')" --end-time "$(date -d 'now')" --period 60 \
    --namespace "AWS/RDS" \
    --statistics Average Maximum Minimum \
    --dimensions Name=DBClusterIdentifier,Value=my_cluster_identifier
  ```

   이 명령을 실행하면 다음과 비슷한 출력이 생성됩니다.

  ```
  {
      "Label": "VolumeBytesUsed",
      "Datapoints": [
          {
              "Timestamp": "2020-08-04T21:25:00+00:00",
              "Average": 182871982080.0,
              "Minimum": 182871982080.0,
              "Maximum": 182871982080.0,
              "Unit": "Bytes"
          }
      ]
  }
  ```

다음 예제에서는 Linux 시스템에서 AWS CLI 명령을 사용하여 시간 경과에 따른 Aurora 클러스터의 스토리지 사용량을 추적하는 방법을 보여줍니다. `--start-time` 및 `--end-time` 파라미터는 전체 시간 간격을 하루로 정의합니다. `--period` 파라미터는 한 시간 간격으로 측정값을 요청합니다. 지표가 연속적으로 수집되지 않고 일정 간격으로 수집되기 때문에 작은 `--period` 값을 선택하는 것은 적절하지 않습니다. 또한 해당 SQL 문이 완료된 후에도 Aurora 스토리지 작업이 백그라운드에서 일정 시간 동안 계속되는 경우가 있습니다.

첫 번째 예제는 출력을 기본 JSON 형식으로 반환합니다. 데이터 포인트는 타임스탬프를 기준으로 정렬되지 않고 임의의 순서로 반환됩니다. 이 JSON 데이터를 차트 도구로 가져와 정렬 및 시각화를 수행할 수 있습니다.

```
$ aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \
  --start-time "$(date -d '1 day ago')" --end-time "$(date -d 'now')" --period 3600
  --namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_cluster_id
{
    "Label": "VolumeBytesUsed",
    "Datapoints": [
        {
            "Timestamp": "2020-08-04T19:40:00+00:00",
            "Maximum": 182872522752.0,
            "Unit": "Bytes"
        },
        {
            "Timestamp": "2020-08-05T00:40:00+00:00",
            "Maximum": 198573719552.0,
            "Unit": "Bytes"
        },
        {
            "Timestamp": "2020-08-05T05:40:00+00:00",
            "Maximum": 206827454464.0,
            "Unit": "Bytes"
        },
        {
            "Timestamp": "2020-08-04T17:40:00+00:00",
            "Maximum": 182872522752.0,
            "Unit": "Bytes"
        },
... output omitted ...
```

이 예제는 이전 예제와 동일한 데이터를 반환합니다. `--output` 파라미터는 데이터를 압축 일반 텍스트 형식으로 나타냅니다. `aws cloudwatch ` 명령은 해당 출력을 `sort` 명령에 파이프합니다. `-k` 명령의 `sort` 파라미터는 UTC(협정 세계시) 형식의 타임스탬프인 세 번째 필드를 기준으로 출력을 정렬합니다.

```
$ aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \
  --start-time "$(date -d '1 day ago')" --end-time "$(date -d 'now')" --period 3600 \
  --namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_cluster_id \
  --output text | sort -k 3
VolumeBytesUsed
DATAPOINTS  182872522752.0  2020-08-04T17:41:00+00:00 Bytes
DATAPOINTS  182872522752.0  2020-08-04T18:41:00+00:00 Bytes
DATAPOINTS  182872522752.0  2020-08-04T19:41:00+00:00 Bytes
DATAPOINTS  182872522752.0  2020-08-04T20:41:00+00:00 Bytes
DATAPOINTS  187667791872.0  2020-08-04T21:41:00+00:00 Bytes
DATAPOINTS  190981029888.0  2020-08-04T22:41:00+00:00 Bytes
DATAPOINTS  195587244032.0  2020-08-04T23:41:00+00:00 Bytes
DATAPOINTS  201048915968.0  2020-08-05T00:41:00+00:00 Bytes
DATAPOINTS  205368492032.0  2020-08-05T01:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T02:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T03:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T04:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T05:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T06:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T07:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T08:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T09:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T10:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T11:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T12:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T13:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T14:41:00+00:00 Bytes
DATAPOINTS  206833664000.0  2020-08-05T15:41:00+00:00 Bytes
DATAPOINTS  206833664000.0  2020-08-05T16:41:00+00:00 Bytes
```

정렬된 출력에는 모니터링 기간의 시작 및 종료 시 사용된 스토리지 양이 표시됩니다. 또한 Aurora가 클러스터에 더 많은 스토리지를 할당한 기간 동안의 데이터 포인트도 찾을 수 있습니다. 다음 예제에서는 Linux 명령을 사용하여 시작 및 종료 `VolumeBytesUsed` 값을 기가바이트(GB)와 기비바이트(GiB) 형식으로 변경합니다. 기가바이트는 10의 제곱으로 측정된 단위를 나타내며 회전식 하드 드라이브의 스토리지를 논할 때 일반적으로 사용됩니다. 기비바이트는 2의 제곱으로 측정된 단위를 나타냅니다. Aurora 스토리지 측정 및 제한은 일반적으로 기비바이트와 테비바이트와 같은 2의 제곱 단위로 명시됩니다.

```
$ GiB=$((1024*1024*1024))
$ GB=$((1000*1000*1000))
$ echo "Start: $((182872522752/$GiB)) GiB, End: $((206833664000/$GiB)) GiB"
Start: 170 GiB, End: 192 GiB
$ echo "Start: $((182872522752/$GB)) GB, End: $((206833664000/$GB)) GB"
Start: 182 GB, End: 206 GB
```

`VolumeBytesUsed` 지표는 클러스터에서 요금이 발생하고 있는 스토리지 양을 알려줍니다. 따라서 가능하면 이 수치를 최소화하는 것이 좋습니다. 그러나 이 지표에는 Aurora가 클러스터에서 내부적으로 사용하여 요금을 부과하지 않는 일부 스토리지가 포함되어 있습니다. 클러스터가 스토리지 제한에 근접하여 공간이 부족해질 수 있는 경우 `AuroraVolumeBytesLeftTotal` 지표를 모니터링하고 이 수치를 최대화하는 것이 더 도움이 됩니다. 다음 예제에서는 `AuroraVolumeBytesLeftTotal` 대신 `VolumeBytesUsed`에 대해 이전 계산과 비슷한 계산을 실행합니다.

```
$ aws cloudwatch get-metric-statistics --metric-name "AuroraVolumeBytesLeftTotal" \
  --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 3600 \
  --namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_old_cluster_id \
  --output text | sort -k 3
AuroraVolumeBytesLeftTotal
DATAPOINTS      140530528288768.0       2023-02-23T19:25:00+00:00       Count
$ TiB=$((1024*1024*1024*1024))
$ TB=$((1000*1000*1000*1000))
$ echo "$((69797067915264 / $TB)) TB remaining for this cluster"
69 TB remaining for this cluster
$ echo "$((69797067915264 / $TiB)) TiB remaining for this cluster"
63 TiB remaining for this cluster
```

Aurora MySQL 버전 2.09 이상이나 Aurora PostgreSQL을 실행하는 클러스터의 경우 데이터가 추가되면 `VolumeBytesUsed`에서 보고되는 사용 가능한 크기가 증가하고 데이터가 제거되면 사용 가능한 크기가 감소합니다. 다음 예에서는 이 작업을 수행하는 방법을 보여줍니다. 이 보고서는 임시 데이터가 있는 테이블이 생성되고 삭제될 때 15분 간격으로 클러스터의 최대 및 최소 스토리지 크기를 표시합니다. 이 보고서에는 최소 값보다 최대 값이 먼저 나열됩니다. 따라서 15분 간격 내에 스토리지 사용량이 어떻게 변경되었는지 이해하려면 오른쪽에서 왼쪽으로 수치를 해석해야 합니다.

```
$ aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \
  --start-time "$(date -d '4 hours ago')" --end-time "$(date -d 'now')" --period 1800 \
  --namespace "AWS/RDS" --statistics Maximum Minimum --dimensions Name=DBClusterIdentifier,Value=my_new_cluster_id
  --output text | sort -k 4
VolumeBytesUsed
DATAPOINTS	14545305600.0	14545305600.0	2020-08-05T20:49:00+00:00	Bytes
DATAPOINTS	14545305600.0	14545305600.0	2020-08-05T21:19:00+00:00	Bytes
DATAPOINTS	22022176768.0 14545305600.0	2020-08-05T21:49:00+00:00	Bytes
DATAPOINTS	22022176768.0	22022176768.0	2020-08-05T22:19:00+00:00	Bytes
DATAPOINTS	22022176768.0	22022176768.0	2020-08-05T22:49:00+00:00	Bytes
DATAPOINTS	22022176768.0 15614263296.0	2020-08-05T23:19:00+00:00	Bytes
DATAPOINTS	15614263296.0	15614263296.0	2020-08-05T23:49:00+00:00	Bytes
DATAPOINTS	15614263296.0	15614263296.0	2020-08-06T00:19:00+00:00	Bytes
```

다음 예시에서는 Aurora MySQL 또는 Aurora PostgreSQL의 호환되는 버전을 실행하는 클러스터의 경우 `AuroraVolumeBytesLeftTotal`에서 보고하는 사용 가능한 크기에 256TiB 크기 제한이 어떻게 반영되는지 보여줍니다. 호환되는 버전에 대한 자세한 내용은 [Amazon Aurora 크기 제한](CHAP_Limits.md#RDS_Limits.FileSize.Aurora) 섹션을 참조하세요.

```
$ aws cloudwatch get-metric-statistics --region us-east-1 --metric-name "AuroraVolumeBytesLeftTotal" \
  --start-time "$(date -d '4 hours ago')" --end-time "$(date -d 'now')" --period 1800 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBClusterIdentifier,Value=pq-57 \
  --output text | sort -k 3
AuroraVolumeBytesLeftTotal
DATAPOINTS	140515818864640.0	2020-08-05T20:56:00+00:00	Count
DATAPOINTS	140515818864640.0	2020-08-05T21:26:00+00:00	Count
DATAPOINTS	140515818864640.0	2020-08-05T21:56:00+00:00	Count
DATAPOINTS	140514866757632.0	2020-08-05T22:26:00+00:00	Count
DATAPOINTS	140511020580864.0	2020-08-05T22:56:00+00:00	Count
DATAPOINTS	140503168843776.0	2020-08-05T23:26:00+00:00	Count
DATAPOINTS	140503168843776.0	2020-08-05T23:56:00+00:00	Count
DATAPOINTS	140515818864640.0	2020-08-06T00:26:00+00:00	Count
$ TiB=$((1024*1024*1024*1024))
$ TB=$((1000*1000*1000*1000))
$ echo "$((140515818864640 / $TB)) TB remaining for this cluster"
140 TB remaining for this cluster
$ echo "$((140515818864640 / $TiB)) TiB remaining for this cluster"
256 TiB remaining for this cluster
```

## 인스턴스 조정
<a name="Aurora.Managing.Performance.InstanceScaling"></a>

필요에 따라 DB 클러스터의 DB 인스턴스마다 DB 인스턴스 클래스를 수정하여 Aurora DB 클러스터의 크기를 조정할 수 있습니다. Aurora는 데이터베이스 엔진 호환성에 따라 Aurora에 최적화된 여러 DB 인스턴스 클래스를 지원합니다.


| 데이터베이스 엔진 | 인스턴스 조정 | 
| --- | --- | 
|  Amazon Aurora MySQL  |  [Aurora MySQL DB 인스턴스 조정](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.Performance.InstanceScaling)섹션을 참조하십시오.  | 
|  Amazon Aurora PostgreSQL  |  [Aurora PostgreSQL DB 인스턴스 조정](AuroraPostgreSQL.Managing.md#AuroraPostgreSQL.Managing.Performance.InstanceScaling)섹션을 참조하십시오.  | 

## 읽기 확장
<a name="Aurora.Managing.Performance.ReadScaling"></a>

DB 클러스터에서 Aurora 복제본을 최대 15개까지 생성하여 Aurora DB 클러스터에 대한 읽기 조정을 수행할 수 있습니다. 각 Aurora 복제본은 복제본 지연 시간—을 최소화하여 클러스터 볼륨에서 동일한 데이터를 반환합니다(일반적으로 이 지연 시간은 기본 인스턴스가 업데이트를 적용한 후 100밀리초 미만입니다). 읽기 트래픽이 증가하면 Aurora 복제본을 추가 생성하여 직접 연결함으로써 DB 클러스터의 읽기 부하를 분산시키는 것도 가능합니다. Aurora 복제본의 DB 인스턴스 클래스가 기본 인스턴스의 DB 인스턴스 클래스와 같을 필요는 없습니다.

DB 클러스터에 Aurora 복제본을 추가하는 방법에 대한 자세한 내용은 [DB 클러스터에 Aurora 복제본 추가](aurora-replicas-adding.md) 단원을 참조하십시오.

## 연결 관리
<a name="Aurora.Managing.MaxConnections"></a>

Aurora DB 인스턴스에 대해 허용되는 최대 연결 수는 DB 인스턴스의 인스턴스 수준 파라미터 그룹의 `max_connections` 파라미터로 결정됩니다. 파라미터 기본값은 DB 인스턴스에 사용되는 DB 인스턴스 클래스와 데이터베이스 엔진 호환성에 따라 달라집니다.


| 데이터베이스 엔진 | max\$1connections 기본값 | 
| --- | --- | 
|  Amazon Aurora MySQL  |  [Aurora MySQL DB 인스턴스에 대한 최대 연결](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.MaxConnections)섹션을 참조하십시오.  | 
|  Amazon Aurora PostgreSQL  |  [Aurora PostgreSQL DB 인스턴스에 대한 최대 연결](AuroraPostgreSQL.Managing.md#AuroraPostgreSQL.Managing.MaxConnections) 섹션을 참조하세요.  | 

**작은 정보**  
애플리케이션이 연결을 자주 열고 닫거나, 수명이 긴 연결을 많이 열어 두는 경우, Amazon RDS 프록시를 사용하는 것이 좋습니다. RDS 프록시는 데이터베이스 연결을 효율적으로 안전하게 공유하기 위해 연결 풀링을 사용하는 완전관리형 고가용성 데이터베이스 프록시입니다. RDS 프록시에 대한 자세한 내용은 [Aurora용 Amazon RDS Proxy](rds-proxy.md) 섹션을 참조하세요.

## 쿼리 실행 계획 관리
<a name="Aurora.Managing.Optimizing"></a>

Aurora PostgreSQL용 쿼리 계획 관리 기능을 사용하면 최적화 프로그램에서 실행할 계획을 제어할 수 있습니다. 자세한 내용은 [Aurora PostgreSQL용 쿼리 실행 계획 관리](AuroraPostgreSQL.Optimize.md) 섹션을 참조하세요.

# Aurora DB 클러스터에 대한 볼륨 복제
<a name="Aurora.Managing.Clone"></a><a name="cloning"></a>

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 복제 개요
<a name="Aurora.Clone.Overview"></a>

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 복제의 제한 사항
<a name="Aurora.Managing.Clone.Limitations"></a>

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 복제 작동 방식
<a name="Aurora.Managing.Clone.Protocol"></a>

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) 이해
<a name="Aurora.Managing.Clone.Protocol.Before"></a>

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 클러스터 볼륨과 복제본 모두가 변경될 경우 변경 사항을 캡처하고 저장하기 위해 점점 더 많은 스토리지가 필요합니다.

### 원본 클러스터 볼륨 삭제
<a name="Aurora.Managing.Clone.Deleting"></a>

 처음에 복제 볼륨은 복제가 생성된 원본 볼륨과 동일한 데이터 페이지를 공유합니다. 원본 볼륨이 존재하는 한 복제 볼륨은 복제본이 생성하거나 수정한 페이지의 소유자로만 간주됩니다. 따라서 복제 볼륨의 `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 복제 생성
<a name="Aurora.Managing.Clone.create"></a>

소스 Aurora DB 클러스터와 같은 AWS 계정에서 복제본을 생성합니다. 이를 위해 AWS Management Console 또는 AWS CLI 및 다음 절차를 사용할 수 있습니다.

다른 AWS 계정에서 복제본을 생성하거나 다른 AWS 계정과 복제본을 공유하도록 허용하려면 [AWS RAM과 Amazon Aurora에서 교차 계정 복제](Aurora.Managing.Clone.Cross-Account.md)의 절차를 사용합니다.

### 콘솔
<a name="Aurora.Managing.Clone.Console"></a>

다음 프로시저에서는 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
<a name="Aurora.Managing.Clone.CLI"></a>

 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)

#### 복제본 생성
<a name="Aurora.Managing.Clone.CLI.create-empty-clone"></a>

 `[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) 단원을 참조하세요.

#### 상태 확인 및 복제본 세부 정보 가져오기
<a name="Aurora.Managing.Clone.CLI.check-status-get-details"></a>

 다음 명령을 사용하여 새로 생성된 클론 클러스터의 상태를 확인할 수 있습니다.

```
$ 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 인스턴스 생성
<a name="Aurora.Managing.Clone.CLI.create-db-instance"></a>

 [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
```

#### 복제본에 사용할 파라미터
<a name="Aurora.Managing.Clone.CLI.parameter-summary"></a>

 다음 표에는 `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 간 복제
<a name="Aurora.Managing.Clone.Cross-VPC"></a>

 원본 클러스터와 복제본에 서로 다른 네트워크 액세스 제어를 적용하고 싶다고 가정해 보겠습니다. 예를 들어 복제를 사용하여 개발 및 테스트를 위해 다른 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)

## 시작하기 전 준비 사항
<a name="before-you-begin"></a>

 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)를 참조하세요.

## 네트워크 환경에 대한 정보 수집
<a name="gathering-information-about-the-network-environment"></a>

 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단계: 원본 클러스터의 가용 영역 확인
<a name="cross-vpc-cloning-check-original-azs"></a>

 복제본을 생성하기 전에 원본 클러스터가 스토리지에 사용하는 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 서브넷 그룹 확인
<a name="cross-vpc-cloning-check-original-subnet-group"></a>

 원본 클러스터와 동일한 수의 서브넷을 복제본에 사용하려면 원본 클러스터의 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단계: 원본 클러스터의 서브넷 확인
<a name="cross-vpc-cloning-check-original-subnets"></a>

 원본 클러스터의 서브넷에 대한 자세한 정보가 필요한 경우 다음과 유사한 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 인스턴스의 가용 영역 확인
<a name="cross-vpc-cloning-check-original-instance-azs"></a>

 이 절차를 사용하여 원본 클러스터의 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 확인
<a name="cross-vpc-cloning-check-vpcs"></a>

 원본과 다른 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와 연결되어 있는지 확인하세요.

## 복제본을 위한 네트워크 리소스 생성
<a name="creating-network-resources-for-the-clone"></a>

 네트워크 정보를 수집하는 동안 복제본에 추가 네트워크 리소스가 필요하다는 것을 발견한 경우, 복제본을 설정하기 전에 해당 리소스를 만들 수 있습니다. 예를 들어, 더 많은 서브넷, 특정 AZ와 연결된 서브넷 또는 새 DB 서브넷 그룹을 만들어야 할 수 있습니다.
+  [1단계: 복제본의 서브넷 생성](#cross-vpc-cloning-create-clone-subnets) 
+  [2단계: 복제본에 대한 DB 서브넷 그룹 생성](#cross-vpc-cloning-create-subnet-group) 

### 1단계: 복제본의 서브넷 생성
<a name="cross-vpc-cloning-create-clone-subnets"></a>

 복제본에 대한 새 서브넷을 만들어야 하는 경우 다음과 유사한 명령을 실행합니다. 다른 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 서브넷 그룹 생성
<a name="cross-vpc-cloning-create-subnet-group"></a>

 다른 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 복제본 생성
<a name="creating-an-aurora-clone-with-new-network-settings"></a>

 새 클러스터에서 사용할 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 서브넷 그룹 지정
<a name="cross-vpc-cloning-specify-clone-subnet-group"></a>

 복제본을 생성할 때 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단계: 복제본의 인스턴스에 대한 네트워크 설정 지정
<a name="cross-vpc-cloning-configure-clone-instance-network"></a>

 복제본에 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단계: 클라이언트 시스템에서 복제본으로 연결 설정
<a name="cross-vpc-cloning-connect-to-clone"></a>

 이미 클라이언트 시스템에서 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
```

## 퍼블릭 서브넷에서 프라이빗 서브넷으로 클러스터 이동
<a name="moving-a-cluster-from-public-subnets-to-private-ones"></a>

 복제본을 사용하여 퍼블릭 서브넷과 프라이빗 서브넷 간에 클러스터를 마이그레이션할 수 있습니다. 애플리케이션을 프로덕션에 배포하기 전에 애플리케이션에 보안 계층을 추가할 때 이 작업을 수행할 수 있습니다. 이 예제에서는 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 간 복제본 생성의 엔드 투 엔드 예제
<a name="end-to-end-example-of-creating-a-cross-vpc-clone"></a>

 원본과 다른 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에서 교차 계정 복제
<a name="Aurora.Managing.Clone.Cross-Account"></a>

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)

## 계정 간 복제 제한 사항
<a name="Aurora.Managing.Clone.CrossAccount.Limitations"></a>

 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 계정에서 클러스터를 복제하도록 허용
<a name="Aurora.Managing.Clone.CrossAccount.yours"></a>

 다른 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 계정에 클러스터를 복제할 수 있는 권한 부여
<a name="Aurora.Managing.Clone.CrossAccount.granting"></a>

 공유하고 있는 클러스터가 암호화되어 있으면 해당 클러스터의 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)를 참조하세요.

#### 콘솔
<a name="Aurora.Managing.Clone.CrossAccount.granting.console"></a>

**클러스터를 복제할 수 있는 권한을 부여하려면**

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
<a name="Aurora.Managing.Clone.CrossAccount.granting.cli"></a>

**클러스터를 복제할 수 있는 권한을 부여하려면**

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
<a name="Aurora.Managing.Clone.CrossAccount.granting.api"></a>

**클러스터를 복제할 수 있는 권한을 부여하려면**

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 키를 사용하는 클러스터 재생성
<a name="Aurora.Managing.Clone.CrossAccount.granting.defaultkey"></a>

공유하려는 암호화된 클러스터가 기본 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 계정과 공유하는지 확인
<a name="Aurora.Managing.Clone.CrossAccount.confirming"></a>

 다른 사용자에게 클러스터 공유 권한이 있는지 확인할 수 있습니다. 따라서 클러스터가 계정 간 최대 복제 수 제한에 접근하는지 파악하는 데 효과적입니다.

 AWS RAM 콘솔을 사용하여 리소스를 공유하는 절차는 *AWS RAM 사용 설명서*에서 [자신이 소유한 리소스 공유](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing.html)를 참조하세요.

#### AWS CLI
<a name="Aurora.Managing.Clone.CrossAccount.confirming.cli"></a>

**소유한 클러스터가 다른 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
<a name="Aurora.Managing.Clone.CrossAccount.confirming.api"></a>

**소유한 클러스터가 다른 AWS 계정과 공유되는지 확인하려면 다음을 수행하세요.**
+  AWS RAM API 작업 [ListPrincipals](https://docs.aws.amazon.com/ram/latest/APIReference/API_ListPrincipals.html)를 호출합니다. 자신의 계정 ID를 리소스 소유자로, 그리고 클러스터 ARN을 리소스 ARN으로 사용합니다.

## 다른 AWS 계정에서 소유하고 있는 클러스터 복제
<a name="Aurora.Managing.Clone.CrossAccount.theirs"></a>

 다른 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 계정에서 소유하고 있는 클러스터 복제 초대장 보기
<a name="Aurora.Managing.Clone.CrossAccount.viewing"></a>

 다른 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
<a name="Aurora.Managing.Clone.CrossAccount.viewing.cli"></a>

**다른 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
<a name="Aurora.Managing.Clone.CrossAccount.viewing.api"></a>

**다른 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 계정에서 소유하고 있는 클러스터에 대한 공유 초대장 승인
<a name="Aurora.Managing.Clone.CrossAccount.accepting"></a>

 다른 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
<a name="Aurora.Managing.Clone.CrossAccount.accepting.cli"></a>

**다른 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
<a name="Aurora.Managing.Clone.CrossAccount.accepting.api"></a>

**다른 사용자의 클러스터 공유 초대장을 승인하려면**

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 클러스터 복제
<a name="Aurora.Managing.Clone.CrossAccount.cloning"></a>

 위와 같이 DB 클러스터를 소유하고 있는 AWS 계정의 초대장을 승인하였다면 이제 클러스터를 복제할 수 있습니다.

#### 콘솔
<a name="Aurora.Managing.Clone.CrossAccount.cloning.console"></a>

**다른 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
<a name="Aurora.Managing.Clone.CrossAccount.cloning.cli"></a>

**다른 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
<a name="Aurora.Managing.Clone.CrossAccount.cloning.api"></a>

**다른 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 클러스터의 계정 간 복제본 여부 확인
<a name="Aurora.Managing.Clone.CrossAccount.checking"></a>

 `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
<a name="Aurora.Managing.Clone.CrossAccount.checking.cli"></a>

**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
<a name="Aurora.Managing.Clone.CrossAccount.checking.api"></a>

**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"
        }
    ]
  }
  ```

# Aurora를 다른 AWS 서비스와 통합
<a name="Aurora.Integrating"></a>

Aurora DB 클러스터를 확장하여 AWS 클라우드에서 추가 기능을 사용할 수 있도록 Amazon Aurora를 다른 AWS 서비스와 통합합니다.

**Topics**
+ [AWS 서비스를 Amazon Aurora MySQL과 통합](#Aurora.Integrating.AuroraMySQL)
+ [AWS 서비스를 Amazon Aurora PostgreSQL과 통합](#Aurora.Integrating.AuroraPostgreSQL)

## AWS 서비스를 Amazon Aurora MySQL과 통합
<a name="Aurora.Integrating.AuroraMySQL"></a>

Aurora MySQL DB 클러스터를 확장하여 AWS 클라우드에서 추가 기능을 사용할 수 있도록 Amazon Aurora MySQL이 다른 AWS 서비스와 통합되었습니다. Aurora MySQL DB 클러스터는 AWS 서비스를 사용하여 다음과 같은 작업을 수행할 수 있습니다.
+ AWS Lambda 또는 `lambda_sync` 네이티브 함수를 사용하여 동기적 또는 비동기적으로 `lambda_async` 함수를 호출하십시오. 또는 AWS Lambda 프로시저를 사용하여 비동기적으로 `mysql.lambda_async` 함수를 호출하십시오.
+ `LOAD DATA FROM S3` 또는 `LOAD XML FROM S3` 명령을 사용하여 Amazon S3 버킷에 저장된 텍스트 또는 XML 파일에서 DB 클러스터로 데이터를 로드하십시오.
+ `SELECT INTO OUTFILE S3` 명령을 사용하여 DB 클러스터의 데이터를 Amazon S3 버킷에 저장된 텍스트 파일에 저장하십시오.
+ Application Auto Scaling을 사용하여 Aurora 복제본을 자동으로 추가 또는 제거하십시오. 자세한 내용은 [Aurora 복제본을 사용하는 Amazon Aurora Auto Scaling](Aurora.Integrating.AutoScaling.md) 섹션을 참조하세요.

Aurora MySQL과 다른 AWS 서비스의 통합에 대한 자세한 내용은 [Amazon Aurora MySQL을 다른 AWS 서비스와 통합](AuroraMySQL.Integrating.md) 섹션을 참조하세요.

## AWS 서비스를 Amazon Aurora PostgreSQL과 통합
<a name="Aurora.Integrating.AuroraPostgreSQL"></a>

Aurora PostgreSQL DB 클러스터를 확장하여 AWS 클라우드에서 추가 기능을 사용할 수 있도록 Amazon Aurora PostgreSQL이 다른 AWS 서비스와 통합되었습니다. Aurora PostgreSQL DB 클러스터는 AWS 서비스를 사용하여 다음과 같은 작업을 수행할 수 있습니다.
+ Performance Insights에서 관계형 데이터베이스 워크로드를 빠르게 수집하여 살펴보고 성능을 평가합니다.
+ Aurora Auto Scaling을 사용하여 Aurora 복제본을 자동으로 추가 또는 제거합니다. 자세한 내용은 [Aurora 복제본을 사용하는 Amazon Aurora Auto Scaling](Aurora.Integrating.AutoScaling.md) 섹션을 참조하세요.

Aurora PostgreSQL과 다른 AWS 서비스의 통합에 대한 자세한 내용은 [Amazon Aurora PostgreSQL를 다른 AWS 서비스와 통합](AuroraPostgreSQL.Integrating.md) 섹션을 참조하세요.

# Amazon Aurora DB 클러스터 유지 관리
<a name="USER_UpgradeDBInstance.Maintenance"></a>

Amazon RDS는 Amazon RDS 리소스를 정기적으로 유지 관리합니다. 다음 주제에서는 이러한 유지 관리 작업과 이를 적용하는 방법을 설명합니다.

## DB 클러스터 유지 관리 업데이트 개요
<a name="USER_UpgradeDBInstance.Maintenance.Overview"></a>

유지 관리에는 주로 DB 클러스터의 다음 리소스에 대한 업데이트가 포함됩니다.
+ 기본 하드웨어
+ 기본 운영 체제(OS)
+ 데이터베이스 엔진 버전

운영 체제 업데이트는 보안상 가장 빈번하게 발생하며 가능한 한 빨리 수행하는 것이 좋습니다. 운영 체제 업데이트에 대한 자세한 내용은 [Aurora DB 클러스터의 운영 체제 업데이트](#Aurora_OS_updates) 섹션을 참조하세요.

**Topics**
+ [유지 관리 업데이트 중 오프라인 리소스](#USER_UpgradeDBInstance.Maintenance.Overview.offline)
+ [연기된 DB 인스턴스및 DB 클러스터 수정 사항](#USER_UpgradeDBInstance.Maintenance.Overview.Deferred)
+ [DescribePendingMaintenanceActions API의 최종 일관성](#USER_UpgradeDBInstance.Maintenance.Overview.eventual-consistency)

### 유지 관리 업데이트 중 오프라인 리소스
<a name="USER_UpgradeDBInstance.Maintenance.Overview.offline"></a>

일부 유지 관리 항목을 사용하려면 Amazon RDS에서 DB 클러스터를 잠시 동안 오프라인 상태로 전환해야 합니다. 리소스가 오프라인 상태에 있어야 하는 유지 관리 항목에는 필수 운영 체제 또는 데이터베이스 패칭이 포함됩니다. 이때 보안 및 인스턴스 안정성과 관련된 패치에 한해 필수 패치 작업으로 자동 예약됩니다. 이러한 패치 작업은 드물게 발생하며 일반적인 빈도는 몇 개월에 한 번입니다. 대부분 유지 관리 기간의 일부만 필요합니다.

### 연기된 DB 인스턴스및 DB 클러스터 수정 사항
<a name="USER_UpgradeDBInstance.Maintenance.Overview.Deferred"></a>

즉시 적용되지 않도록 연기된 DB 클러스터 및 인스턴스 수정 사항은 유지 관리 기간에 적용됩니다. 예를 들어 유지 관리 기간에 DB 인스턴스 클래스나 클러스터 또는 DB 파라미터 그룹을 변경하도록 선택할 수 있습니다. **대기 중인 재부팅** 설정을 사용하여 지정한 수정 사항은 **대기 중인 유지 관리** 목록에 표시되지 않습니다. DB 클러스터 수정에 대한 자세한 내용은 [Amazon Aurora DB 클러스터 수정](Aurora.Modifying.md) 섹션을 참조하세요.

다음 유지 관리 기간에 보류 중인 수정 사항을 보려면 [describe-db-clusters](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/describe-db-clusters.html) AWS CLI 명령을 사용하고 `PendingModifiedValues` 필드를 확인합니다.

### DescribePendingMaintenanceActions API의 최종 일관성
<a name="USER_UpgradeDBInstance.Maintenance.Overview.eventual-consistency"></a>

Amazon RDS `DescribePendingMaintenanceActions` API는 최종 일관성 모델을 따릅니다. 즉, `DescribePendingMaintenanceActions` 명령의 결과가 모든 후속 RDS 명령에 즉시 표시되지 않을 수 있습니다. 이전 API 명령을 사용한 즉시 `DescribePendingMaintenanceActions`를 사용할 때는 이 점을 염두에 두세요.

최종 일관성은 유지 관리 업데이트를 관리하는 방식에 영향을 미칠 수 있습니다. 예를 들어 `ApplyPendingMaintenanceActions` 명령을 실행하여 DB 클러스터의 데이터베이스 엔진 버전을 업데이트하면 `DescribePendingMaintenanceActions`가 결국에는 해당 버전을 볼 수 있게 됩니다. 이 시나리오에서 `DescribePendingMaintenanceActions`는 유지 관리 작업이 적용되었음에도 불구하고 적용되지 않았다고 표시할 수 있습니다.

최종 일관성을 관리하려면 다음을 수행할 수 있습니다.
+ 수정 명령을 실행하기 전에 DB 클러스터의 상태를 확인합니다. 이전 명령이 시스템에 전파될 시간이 충분하도록 지수 백오프 알고리즘을 사용하여 적절한 `DescribePendingMaintenanceActions` 명령을 실행합니다. 이 작업을 수행하려면 몇 초의 대기 시간부터 시작하여 대기 시간을 5분까지 점진적으로 늘려가며 `DescribePendingMaintenanceActions` 명령을 반복적으로 실행합니다.
+ `DescribePendingMaintenanceActions` 명령이 정확한 응답을 반환하더라도 후속 명령 사이에 대기 시간을 추가합니다. 몇 초의 대기 시간으로 시작하는 지수 백오프 알고리즘을 적용하고 대기 시간을 약 5분까지 점진적으로 늘립니다.

## 보류 중인 유지 관리 업데이트 보기
<a name="USER_UpgradeDBInstance.Maintenance.Viewing"></a>

RDS 콘솔, AWS CLI 또는 RDS API를 사용하여 DB 클러스터에 대해 유지 관리 업데이트를 사용할 수 있는지 확인합니다. 업데이트가 있는 경우에는 이 그림과 같이 Amazon RDS 콘솔에서 DB  클러스터의 **유지 관리** 열에 사용 가능 여부가 표시됩니다.

![\[유지 관리 작업을 사용할 수 있으며 다음 유지 관리 기간에 적용됩니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/offlinepatchavailable.png)


DB 클러스터에 대해 유지 관리 업데이트가 제공되지 않는 경우 그에 대한 열 값은 **없음**입니다.

DB 클러스터에 대해 유지 관리 업데이트가 제공되는 경우 다음과 같은 열 값이 가능합니다.
+ **필수** – 유지 관리 작업은 리소스에 적용되며 무기한 보류할 수 없습니다.
+ **사용 가능** – 유지 관리 작업을 사용할 수 있습니다. 그러나 리소스에 자동으로 적용되지 않고 수동으로 적용할 수 있습니다.
+ **다음 기간** – 유지 관리 작업은 다음 유지 관리 기간 중에 리소스에 적용됩니다.
+ **진행 중** – 유지 관리 작업이 리소스에 적용되고 있습니다.

업데이트가 있을 경우에는 다음 중 한 가지를 선택할 수 있습니다.
+ 유지 관리 값이 **다음 기간**인 경우 **작업**에서 **업그레이드 보류**를 선택하여 유지 관리 작업을 보류합니다. 이미 시작된 유지 관리 작업은 보류할 수 없습니다.
+ 유지 관리 작업을 즉시 적용합니다.
+ 다음 유지 관리 기간 중에 유지 관리 작업을 적용합니다.
+ 작업이 없습니다.

**AWS Management Console을 사용하여 작업을 수행하는 방법**

1. 세부 정보를 표시할 DB 인스턴스또는 클러스터를 선택합니다.

1. **유지 관리 및 백업**을 선택합니다. 보류 중인 유지 관리 작업이 나타납니다.

1. 수행할 작업을 선택한 다음 적용할 시기를 선택합니다.

![\[Aurora DB 인스턴스의 보류 중인 유지 관리 항목.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/pending_maintenance_aurora_instance.png)


유지 관리 기간에 따라 대기 중인 작업의 시작 시기가 결정되지만 이러한 작업의 전체 실행 시간이 줄어들지는 않습니다. 유지 관리 기간에 끝나기 전에 반드시 유지 관리 작업이 끝나도록 되어 있는 것은 아니고, 특정 종료 시각을 지나 계속 진행될 수 있습니다. 자세한 내용은 [Amazon RDS 유지 관리 기간](#Concepts.DBMaintenance) 섹션을 참조하세요.

[describe-pending-maintenance-actions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-pending-maintenance-actions.html) AWS CLI 명령을 실행하여 DB 클러스터에 유지 관리 업데이트를 사용할 수 있는지 확인할 수도 있습니다.

유지 관리 업데이트 적용에 대한 내용은 [DB 클러스터에 업데이트 적용](#USER_UpgradeDBInstance.OSUpgrades) 섹션을 참조하세요.

### Amazon Aurora에 대한 유지 관리 작업
<a name="maintenance-actions-aurora"></a>

Aurora DB 클러스터에는 다음과 같은 유지 관리 작업이 적용됩니다.
+ `os-upgrade` - 롤링 업그레이드를 사용하여 DB 클러스터에 있는 모든 DB 인스턴스의 운영 체제를 업데이트합니다. 자세한 내용은 [Aurora DB 클러스터의 운영 체제 업데이트](#Aurora_OS_updates) 섹션을 참조하세요.
+ `system-update` - Aurora PostgreSQL용 DB 엔진에 패치를 적용합니다.

Aurora DB 인스턴스에는 다음 유지 관리 작업이 적용됩니다.
+ `ca-certificate-rotation` - DB 인스턴스에 대한 Amazon RDS 인증 기관 인증서를 업데이트합니다.
+ `hardware-maintenance` - DB 인스턴스의 기본 하드웨어에 대한 유지 관리를 수행합니다.
+ `system-update` – DB 인스턴스의 운영 체제를 업데이트합니다.

## Aurora MySQL 유지 관리 업데이트 빈도 선택
<a name="Aurora.Maintenance.LTS"></a>

각 DB 클러스터에 대해 Aurora MySQL 업그레이드가 자주 발생하는지 또는 드물게 발생하는지 제어할 수 있습니다. 적합한 방법은 Aurora MySQL 사용량 및 Aurora에서 실행되는 애플리케이션의 우선순위에 따라 다릅니다. 업그레이드를 자주 수행하지 않아도 되는 Aurora MySQL 장기 안정성 (LTS) 릴리스에 대한 자세한 내용은 [Aurora MySQL LTS(장기 지원) 릴리스](AuroraMySQL.Update.SpecialVersions.md#AuroraMySQL.Updates.LTS) 섹션을 참조하세요.

 다음 조건이 일부 또는 모두 적용되는 경우 Aurora MySQL 클러스터를 드물게 업그레이드하도록 선택할 수 있습니다.
+  Aurora MySQL 데이터베이스 엔진을 업데이트할 때마다 애플리케이션의 테스트 주기가 오래 걸리는 경우 
+  동일한 Aurora MySQL 버전에서 많은 DB 클러스터 또는 많은 애플리케이션이 모두 실행 중일 때, 모든 DB 클러스터와 관련 애플리케이션을 동시에 업그레이드하고 싶은 경우 
+  Aurora MySQL과 RDS for MySQL을 모두 사용하는 경우 Aurora MySQL 클러스터 및 RDS MySQL DB 인스턴스를 동일한 수준의 MySQL과 호환되도록 유지하려는 경우 
+  Aurora MySQL 애플리케이션이 프로덕션 환경이거나 업무상 중요한 애플리케이션일 때, 중요 패치의 경우 드문 경우를 제외하고는 업그레이드에 대한 가동 중지를 감당할 수 없는 경우 
+  후속 Aurora MySQL 버전에서 해결되는 성능 문제나 기능 차이로 인해 Aurora MySQL 애플리케이션이 제한되지 않는 경우 

 위의 요소가 현재 상황에 적용되는 경우 Aurora MySQL DB 클러스터에 강제 적용되는 업그레이드 수를 제한할 수 있습니다. 해당 DB 클러스터를 생성하거나 업그레이드할 때 "LTS(장기 지원)" 버전으로 알려진 특정 Aurora MySQL 버전을 선택하면 됩니다. 이렇게 하면 해당 DB 클러스터의 업그레이드 주기, 테스트 주기 및 업그레이드 관련 중단 수가 최소화됩니다.

 다음 조건이 일부 또는 모두 적용되는 경우 Aurora MySQL 클러스터를 자주 업그레이드하도록 선택할 수 있습니다.
+  애플리케이션의 테스트 주기가 간단한 경우 
+  애플리케이션이 아직 개발 단계에 있는 경우 
+  데이터베이스 환경이 다양한 Aurora MySQL 버전, 또는 Aurora MySQL 및 RDS for MySQL 버전을 사용하는 경우 각 Aurora MySQL 클러스터에는 자체 업그레이드 주기가 있습니다.
+  Aurora MySQL 사용량을 늘리기 전에 특정 성능 또는 기능 개선을 대기하고 있는 경우 

 위의 요소가 현재 상황에 적용되는 경우 Aurora가 중요한 업그레이드를 더 자주 적용하도록 활성화할 수 있습니다. 그러기 위해서는 Aurora MySQL DB 클러스터를 LTS 버전보다 최신인 Aurora MySQL 버전으로 업그레이드해야 합니다. 이렇게 하면 최신 성능 향상, 버그 수정 및 기능을 보다 신속하게 사용할 수 있습니다.

## Amazon RDS 유지 관리 기간
<a name="Concepts.DBMaintenance"></a>

유지 관리 기간은 시스템 변경 내용이 적용되는 주 단위의 기간입니다. 모든 DB 클러스터에는 주간 유지 관리 기간이 있습니다. 유지 관리 기간은 수정 사항 및 소프트웨어 패치 적용 시점을 조절할 수 있는 기회입니다. 유지 관리 기간 조정에 대한 자세한 내용은 [기본 DB 클러스터 유지 관리 기간 조정](#AdjustingTheMaintenanceWindow.Aurora) 섹션을 참조하세요.

유지 관리가 적용되는 동안 RDS에서 사용자의 DB  클러스터에 있는 리소스 중 일부를 사용합니다. 이에 따라 성능에 미미한 영향이 있을 수 있습니다. DB 인스턴스의 경우 드물지만, 유지 관리 업데이트를 완료하려면 다중 AZ 장애 조치가 필요한 경우가 있을 수 있습니다.

유지 관리 이벤트가 특정 주에 예정되어 있는 경우 사용자가 지정하는 30분의 유지 관리 기간 중에 해당 이벤트가 시작됩니다. 또한 대부분의 유지 관리 이벤트가 30분의 유지 관리 기간 중에 완료됩니다. 단, 대규모 유지 관리 이벤트는 완료하는 데 30분이 넘게 걸릴 수 있습니다. DB 클러스터가 중지되면 유지 관리 기간이 일시 중지됩니다.

지역별로 8시간 블록 시간 중에서 30분 유지 관리 시간이 임의로 선택됩니다. DB 클러스터 생성 시 유지 관리 기간을 지정하지 않으면 RDS에서 임의로 선택한 요일에 30분 유지 관리 기간을 배정합니다.

다음 표에는 기본 유지 관리 기간을 할당하는 각 AWS 리전의 시간 블록이 나와 있습니다.


****  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html)

**Topics**
+ [기본 DB 클러스터 유지 관리 기간 조정](#AdjustingTheMaintenanceWindow.Aurora)

### 기본 DB 클러스터 유지 관리 기간 조정
<a name="AdjustingTheMaintenanceWindow.Aurora"></a>

Aurora DB 클러스터 유지 관리 기간은 사용률이 가장 낮은 시간에 할당되어야 하므로 수시로 수정되어야 할 수 있습니다. 적용 중인 업데이트에 중단이 필요한 경우 이 시간 동안 DB 클러스터를 사용할 수 없습니다. 필수 업데이트를 수행하는 데 필요한 최소 시간 동안 중단됩니다.

**참고**  
데이터베이스 엔진 업그레이드를 위해 Amazon Aurora는 개별 인스턴스가 아닌 DB 클러스터에 대한 기본 유지 관리 기간을 관리합니다.

#### 콘솔
<a name="AdjustingTheMaintenanceWindow.Aurora.CON"></a>

**기본 DB 클러스터 유지 관리 기간을 조정하려면**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.

1. 탐색 창에서 **데이터베이스**를 선택합니다.

1. 유지 관리 기간을 변경하려는 DB 클러스터를 선택합니다.

1. **수정**을 선택합니다.

1. **유지 관리** 섹션에서 유지 관리 기간을 업데이트합니다.

1. **계속**을 선택합니다.

   확인 페이지에서 변경 내용을 검토합니다.

1. 변경 사항을 유지 관리 기간에 즉시 적용하려면 **수정 예약(Scheduling of modifications)** 섹션에서 **즉시(Immediately)**를 선택합니다.

1. **클러스터 수정**을 선택하여 변경 사항을 저장합니다.

   그렇지 않으면 [**Back**]을 선택하여 변경 내용을 편집하거나 [**Cancel**]을 선택하여 변경 내용을 취소합니다.

#### AWS CLI
<a name="AdjustingTheMaintenanceWindow.Aurora.CLI"></a>

기본 DB 클러스터 유지 관리 기간을 조정하려면 AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) 명령을 다음 파라미터와 함께 사용합니다.
+ `--db-cluster-identifier`
+ `--preferred-maintenance-window`

**Example**  
다음은 유지 관리 기간을 화요일 4:00–4:30 AM UTC로 설정하는 코드 예제입니다.  
대상 LinuxmacOS, 또는Unix:  

```
aws rds modify-db-cluster \
--db-cluster-identifier my-cluster \
--preferred-maintenance-window Tue:04:00-Tue:04:30
```
Windows의 경우:  

```
aws rds modify-db-cluster ^
--db-cluster-identifier my-cluster ^
--preferred-maintenance-window Tue:04:00-Tue:04:30
```

#### RDS API
<a name="AdjustingTheMaintenanceWindow.Aurora.API"></a>

기본 DB 클러스터 유지 관리 기간을 조정하려면 Amazon RDS [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) API 작업을 다음 파라미터와 함께 사용합니다.
+ `DBClusterIdentifier`
+ `PreferredMaintenanceWindow`

## DB 클러스터에 업데이트 적용
<a name="USER_UpgradeDBInstance.OSUpgrades"></a>

Amazon RDS를 사용하여 유지 관리 작업을 적용하는 시기를 선택할 수 있습니다. AWS Management Console, AWS CLI 또는 RDS API를 사용하여 Amazon RDS에서 업데이트를 적용하는 시기를 결정할 수 있습니다.

### 콘솔
<a name="USER_UpgradeDBInstance.OSUpgrades.Console"></a>

**DB 클러스터​의 업데이트를 관리하려면**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.

1. 탐색 창에서 **데이터베이스**를 선택합니다.

1. 필수 업데이트가 포함된 DB 클러스터를 선택합니다.

1. **작업**에서 다음 중 하나를 선택합니다.
   + **지금 패치**
   + **다음 기간에 패치**
**참고**  
**다음 기간에 패치**를 선택한 후 나중에 업데이트를 연기하려면 **업그레이드 연기**를 선택합니다. 유지 관리 작업이 이미 시작된 경우에는 보류할 수 없습니다.  
유지 관리 작업을 취소하려면 DB 인스턴스를 수정하고 **마이너 버전 자동 업그레이드**를 비활성화합니다.

### AWS CLI
<a name="USER_UpgradeDBInstance.OSUpgrades.CLI"></a>

대기 중인 업데이트를 DB 클러스터에 적용하려면 [apply-pending-maintenance-action](https://docs.aws.amazon.com/cli/latest/reference/rds/apply-pending-maintenance-action.html) AWS CLI 명령을 사용합니다.

**Example**  
대상 LinuxmacOS, 또는Unix:  

```
aws rds apply-pending-maintenance-action \
    --resource-identifier arn:aws:rds:us-west-2:001234567890:db:mysql-db \
    --apply-action system-update \
    --opt-in-type immediate
```
Windows의 경우:  

```
aws rds apply-pending-maintenance-action ^
    --resource-identifier arn:aws:rds:us-west-2:001234567890:db:mysql-db ^
    --apply-action system-update ^
    --opt-in-type immediate
```

**참고**  
유지 관리 작업을 연기하려면 `undo-opt-in`에 `--opt-in-type`을 지정합니다. 유지 관리 작업이 이미 시작된 경우 `undo-opt-in`에 `--opt-in-type`을 지정할 수 없습니다.  
유지 관리 작업을 취소하려면 [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) AWS CLI 명령을 실행하고 `--no-auto-minor-version-upgrade`을 지정합니다.

하나 이상의 대기 중인 업데이트가 있는 리소스 목록을 반환하려면, [describe-pending-maintenance-actions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-pending-maintenance-actions.html) AWS CLI 명령을 사용합니다.

**Example**  
대상 LinuxmacOS, 또는Unix:  

```
aws rds describe-pending-maintenance-actions \
    --resource-identifier arn:aws:rds:us-west-2:001234567890:db:mysql-db
```
Windows의 경우:  

```
aws rds describe-pending-maintenance-actions ^
    --resource-identifier arn:aws:rds:us-west-2:001234567890:db:mysql-db
```

`describe-pending-maintenance-actions` AWS CLI 명령의 `--filters` 파라미터를 지정하여 DB 클러스터에 대한 리소스 목록을 반환할 수도 있습니다. `--filters` 명령의 형식은 `Name=filter-name,Value=resource-id,...`입니다.

필터의 `Name` 파라미터에 대해 허용되는 값은 다음과 같습니다.
+ `db-instance-id` – DB 인스턴스 식별자 또는 Amazon 리소스 이름(ARN) 목록을 허용합니다. 반환되는 목록에는 이러한 식별자 또는 ARN으로 식별된 DB 인스턴스에 대해 보류 중인 유지 관리 작업만 포함됩니다.
+ `db-cluster-id` – Amazon Aurora의 DB 클러스터 식별자 또는 ARN 목록을 허용합니다. 반환되는 목록에는 이러한 식별자 또는 ARN으로 식별된 DB 클러스터에 대해 보류 중인 유지 관리 작업만 포함됩니다.

예를 들어 다음 예에서는 `sample-cluster1` 및 `sample-cluster2` DB 클러스터에 대해 보류 중인 유지 관리 작업을 반환합니다.

**Example**  
대상 LinuxmacOS, 또는Unix:  

```
aws rds describe-pending-maintenance-actions \
	--filters Name=db-cluster-id,Values=sample-cluster1,sample-cluster2
```
Windows의 경우:  

```
aws rds describe-pending-maintenance-actions ^
	--filters Name=db-cluster-id,Values=sample-cluster1,sample-cluster2
```

### RDS API
<a name="USER_UpgradeDBInstance.OSUpgrades.API"></a>

업데이트를 DB 클러스터에 적용하려면 Amazon RDS API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ApplyPendingMaintenanceAction.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ApplyPendingMaintenanceAction.html) 작업을 직접적으로 호출합니다.

하나 이상의 대기 중인 업데이트가 있는 리소스 목록을 반환하려면 Amazon RDS API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribePendingMaintenanceActions.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribePendingMaintenanceActions.html) 작업을 호출합니다.

## Aurora DB 클러스터 마이너 버전 자동 업그레이드
<a name="Aurora.Maintenance.AMVU"></a>

**마이너 버전 자동 업그레이드** 설정은 Aurora가 DB 클러스터에 업그레이드를 자동으로 적용할지 여부를 지정합니다. 이러한 업그레이드에는 추가 기능과 버그 수정 사항이 들어 있는 패치가 포함된 새 마이너 버전이 포함됩니다.

마이너 버전 자동 업그레이드는 데이터베이스를 최신 데이터베이스 엔진 버전으로 주기적으로 업데이트합니다. 그러나 업그레이드에 항상 최신 데이터베이스 엔진 버전이 포함되는 것은 아닙니다. 특정 시간에 데이터베이스를 특정 버전으로 유지해야 하는 경우 필요한 일정에 따라 필요한 데이터베이스 버전으로 수동으로 업그레이드하는 것이 좋습니다. 중요한 보안 문제가 발생하거나 버전이 지원 종료에 도달하면 **마이너 버전 자동 업그레이드** 옵션을 활성화하지 않은 경우에도 Amazon Aurora에서 마이너 버전 업그레이드가 적용될 수 있습니다. 자세한 내용은 특정 데이터베이스 엔진에 대한 업그레이드 설명서를 참조하세요.

[Aurora MySQL DB 클러스터의 부 버전 또는 패치 수준 업그레이드](AuroraMySQL.Updates.Patching.md) 및 [마이너 버전 업그레이드 수행](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md) 섹션을 참조하세요.

**참고**  
Aurora Global Database는 자동 마이너 버전 업그레이드를 지원하지 않습니다.

이 설정은 기본적으로 켜져 있습니다. 각 새 DB 클러스터에 대해 이 설정에 적합한 값을 선택합니다. 중요도, 예상 수명 및 각 업그레이드 후에 수행하는 확인 테스트 양에 따라 값을 선택합니다.

**자동 마이너 버전 업그레이드** 설정을 켜거나 끄는 방법에 대한 지침은 다음을 참조하세요.
+ [Aurora DB 클러스터 마이너 버전 자동 업그레이드 사용 설정](#aurora-amvu-cluster)
+ [Aurora DB 클러스터의 개별 DB 인스턴스에 마이너 버전 자동 업그레이드 사용 설정](#aurora-amvu-instance)

**중요**  
신규 및 기존 DB 클러스터의 경우 이 설정을 클러스터의 DB 인스턴스에 개별적으로 적용하는 것이 아니라 DB 클러스터에 적용하는 것이 좋습니다. 클러스터에서 이 설정이 꺼져 있는 DB 인스턴스가 있으면 DB 클러스터가 자동으로 업그레이드되지 않습니다.

다음 테이블은 클러스터 및 인스턴스 수준에서 적용한 **자동 마이너 버전 업그레이드** 설정이 작동하는 방식을 보여줍니다.


| 작업 | 클러스터 설정 | 인스턴스 설정 | 클러스터가 자동으로 업그레이드되었나요? | 
| --- | --- | --- | --- | 
| DB 클러스터에서는 참으로 설정했습니다. | True | 모든 신규 및 기존 인스턴스에 대해 참 | 예 | 
| DB 클러스터에서는 거짓으로 설정했습니다. | False | 모든 신규 및 기존 인스턴스에 대해 거짓 | 아니요 | 
|  이전에 DB 클러스터에서 참으로 설정되었습니다. 하나 이상의 DB 인스턴스에서 거짓으로 설정했습니다.  | 거짓으로 변경 | 하나 이상의 인스턴스에 대해 거짓 | 아니요 | 
|  이전에 DB 클러스터에서 거짓으로 설정되었습니다. 모든 인스턴스가 아닌 하나 이상의 DB 인스턴스에서 참으로 설정했습니다.  | False | 모든 인스턴스가 아닌 하나 이상의 인스턴스에 대해 참 | 아니요 | 
|  이전에 DB 클러스터에서 거짓으로 설정되었습니다. 모든 DB 인스턴스에서 참으로 설정했습니다.  | 참으로 변경 | 모든 인스턴스에 대해 참 | 예 | 

자동 마이너 버전 업그레이드는 카테고리가 `maintenance`이며 ID가 `RDS-EVENT-0156`인 Amazon RDS DB 클러스터 이벤트를 통해 미리 전달됩니다. 자세한 내용은 [Amazon RDS 이벤트 카테고리 및 Aurora용 이벤트 메시지](USER_Events.Messages.md) 섹션을 참조하세요.

자동 업그레이드는 유지 관리 기간 중에 발생합니다. DB 클러스터에서 개별 DB 인스턴스의 유지 관리 기간이 클러스터 유지 관리 기간과 다른 경우 클러스터 유지 관리 기간이 우선합니다.

Aurora PostgreSQL의 엔진 업데이트에 대한 자세한 내용은 [Amazon Aurora PostgreSQL에 대한 데이터베이스 엔진 업데이트](AuroraPostgreSQL.Updates.md) 섹션을 참조하십시오.

Aurora MySQL의 **마이너 버전 자동 업그레이드(Auto minor version upgrade)** 설정에 대한 자세한 내용은 [마이너 Aurora MySQL 버전 간 자동 업그레이드 활성화](AuroraMySQL.Updates.AMVU.md) 섹션을 참조하세요. Aurora MySQL의 엔진 업데이트에 대한 자세한 내용은 [Amazon Aurora MySQL에 대한 데이터베이스 엔진 업데이트Amazon Aurora MySQL 장기 지원(LTS) 및 베타 릴리스](AuroraMySQL.Updates.md) 섹션을 참조하세요.

**Topics**

### Aurora DB 클러스터 마이너 버전 자동 업그레이드 사용 설정
<a name="aurora-amvu-cluster"></a>

[콘솔, CLI, API를 사용하여 DB 클러스터 수정](Aurora.Modifying.md#Aurora.Modifying.Cluster)의 일반 절차를 따르세요.

**콘솔**  
**DB 클러스터 수정** 페이지의 **유지 관리** 섹션에서 **마이너 버전 자동 업그레이드 사용** 확인란을 선택합니다.

**AWS CLI**  
[modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI 명령을 호출합니다. `--db-cluster-identifier` 옵션에 DB 클러스터 이름을 지정하고 `--auto-minor-version-upgrade` 옵션에 `true`를 지정합니다. 필요에 따라 DB 클러스터에 대해 이 설정을 즉시 사용 설정하는 `--apply-immediately` 옵션을 지정합니다.

**RDS API**  
[ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) API 작업을 호출하고, `DBClusterIdentifier` 파라미터에 DB 클러스터 이름을 지정하고 `AutoMinorVersionUpgrade` 파라미터에 `true`를 지정합니다. 필요에 따라 `ApplyImmediately` 파라미터를 `true`로 설정하여 DB 클러스터에 대해 이 설정을 즉시 사용 설정합니다.

### Aurora DB 클러스터의 개별 DB 인스턴스에 마이너 버전 자동 업그레이드 사용 설정
<a name="aurora-amvu-instance"></a>

[DB 클러스터에서 DB 인스턴스 수정](Aurora.Modifying.md#Aurora.Modifying.Instance)의 일반 절차를 따르세요.

**콘솔**  
**DB 인스턴스 수정** 페이지의 **유지 관리** 섹션에서 **마이너 버전 자동 업그레이드 사용** 확인란을 선택합니다.

**AWS CLI**  
[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) AWS CLI 명령을 호출합니다. `--db-instance-identifier` 옵션에 해당 DB 인스턴스 이름을 지정하고 `true` 옵션에 `--auto-minor-version-upgrade`를 지정합니다. 필요에 따라 DB 인스턴스에 대해 이 설정을 즉시 활성화하는 `--apply-immediately` 옵션을 지정합니다. 클러스터의 각 DB 인스턴스에 대해 별도의 `modify-db-instance` 명령을 실행합니다.

**RDS API**  
[ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) API 작업을 호출하고, `DBInstanceIdentifier` 파라미터에 DB 클러스터 이름을 지정하고 `AutoMinorVersionUpgrade` 파라미터에 `true`를 지정합니다. 필요에 따라 `ApplyImmediately` 파라미터를 `true`로 설정하여 DB 인스턴스에 대해 이 설정을 즉시 활성화합니다. 클러스터의 각 DB 인스턴스에 대해 별도의 `ModifyDBInstance` 작업을 호출합니다.

다음과 같은 CLI 명령을 사용하여 Aurora MySQL 클러스터의 모든 DB 인스턴스에 대한 `AutoMinorVersionUpgrade` 설정의 상태를 확인할 수 있습니다.

```
aws rds describe-db-instances \
  --query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'
```

이 명령을 실행하면 다음과 비슷한 출력이 생성됩니다.

```
[
  {
      "DBInstanceIdentifier": "db-writer-instance",
      "DBClusterIdentifier": "my-db-cluster-57",
      "AutoMinorVersionUpgrade": true
  },
  {
      "DBInstanceIdentifier": "db-reader-instance1",
      "DBClusterIdentifier": "my-db-cluster-57",
      "AutoMinorVersionUpgrade": false
  },
  {
      "DBInstanceIdentifier": "db-writer-instance2",
      "DBClusterIdentifier": "my-db-cluster-80",
      "AutoMinorVersionUpgrade": true
  },
... output omitted ...
```

이 예시에서는 클러스터의 DB 인스턴스 중 하나에 대해 **마이너 버전 자동 업그레이드 사용**이 꺼져 있으므로, DB 클러스터 `my-db-cluster-57`에 대한 마이너 버전 자동 업그레이드 사용도 꺼져 있습니다.

## Aurora DB 클러스터의 운영 체제 업데이트
<a name="Aurora_OS_updates"></a>

Aurora MySQL 및 Aurora PostgreSQL DB 클러스터의 DB 인스턴스에는 때때로 운영 체제 업데이트가 필요합니다. Amazon RDS는 운영 체제를 최신 버전으로 업그레이드하여 데이터베이스 성능과 고객의 전반적인 보안 태세를 개선합니다. 일반적으로 업데이트에는 10분 정도 걸립니다. 운영 체제 업데이트는 DB 인스턴스의 DB 엔진 버전이나 DB 인스턴스 클래스를 변경하지 않습니다.

운영 체제 업데이트는 두 가지 유형이 있으며, 대기 중인 유지 관리 작업에 대한 설명에 따라 구분됩니다.
+ **운영 체제 배포 업그레이드** - 지원되는 최신 메이저 버전의 Amazon Linux로 마이그레이션하는 데 사용됩니다. 설명은 `New Operating System upgrade is available`입니다.
+ **운영 체제 패치** - 다양한 보안 수정을 적용하며, 경우에 따라 데이터베이스 성능을 개선하는 데 사용됩니다. 설명은 `New Operating System patch is available`입니다.

운영 체제 업데이트는 선택 사항일 수도, 필수일 수도 있습니다.
+ **선택적 업데이트**는 언제든지 적용할 수 있습니다. 이러한 업데이트는 선택 사항이지만, 정기적으로 적용하여 RDS 플릿을 최신 상태로 유지하는 것이 좋습니다. RDS는 이러한 업데이트를 자동으로 *적용하지 않습니다*.

  새로운 선택적 운영 체제 시스템 패치가 제공될 때 알림을 받으려면 보안 패치 이벤트 범주에서 [RDS-EVENT-0230](USER_Events.Messages.md#RDS-EVENT-0230) 구독을 신청하면 됩니다. RDS 이벤트 구독에 대한 자세한 내용은 [Amazon RDS 이벤트 알림 구독](USER_Events.Subscribing.md) 섹션을 참조하십시오.
**참고**  
`RDS-EVENT-0230`은 운영 체제 배포 업그레이드에는 적용되지 않습니다.
+ **필수 업데이트**는 요구 사항이며 필수 업데이트 전에 알림이 전송됩니다. 알림에는 마감일이 포함될 수 있습니다. 이 마감일 이전에 업데이트 일정을 계획하세요. 지정된 마감일 이후 Amazon RDS는 할당된 유지 관리 기간 중 하나에 DB 인스턴스의 운영 체제를 최신 버전으로 자동 업그레이드합니다.

  운영 체제 배포 업그레이드는 필수입니다.

**참고**  
여러 규정 준수 의무를 충족하려면 모든 선택 및 필수 업데이트를 적용하여 최신 상태를 유지해야 할 수 있습니다. 유지 관리 기간 동안 RDS에서 제공하는 모든 업데이트를 정기적으로 적용하는 것이 좋습니다.

Aurora DB 클러스터의 경우 **클러스터 수준** 유지 관리 옵션을 사용하여 운영 체제(OS) 업데이트를 수행할 수 있습니다. 콘솔에서 DB 클러스터의 이름을 선택하거나에서 AWS CLI에서 `os-upgrade` 명령을 사용할 때 **유지 관리 및 백업** 탭에서 클러스터 수준 업데이트를 수행하는 옵션을 찾습니다. 이 방법은 한 번에 몇 개의 리더 DB 인스턴스에 업데이트를 자동으로 적용하는 롤링 업그레이드를 통해 읽기 가용성을 유지합니다. 여러 번의 장애 조치를 방지하고 불필요한 가동 중지 시간을 줄이기 위해 Aurora는 라이터 DB 인스턴스를 마지막으로 업그레이드합니다.

클러스터 수준 OS 업데이트는 클러스터에 대해 지정한 유지 관리 기간 동안 발생합니다. 이렇게 하면 전체 클러스터에 대해 업데이트가 조정됩니다.

이전 버전과의 호환성을 위해 Aurora는 **인스턴스 수준** 유지 관리 옵션도 유지합니다. 대신 클러스터 수준 업데이트를 사용하는 것이 좋습니다. 인스턴스 수준 업데이트를 사용해야 하는 경우 먼저 DB 클러스터의 리더 DB 인스턴스를 업데이트한 다음 라이터 DB 인스턴스를 업데이트합니다. 리더 인스턴스와 라이터 인스턴스를 동시에 업데이트하면 장애 조치 관련 가동 중지 시간이 발생할 가능성이 높아집니다. 콘솔에서 DB 인스턴스의 이름을 선택하거나에서 AWS CLI에서 `system-update` 명령을 사용할 때 **유지 관리 및 백업** 탭에서 인스턴스 수준 업데이트를 수행하는 옵션을 찾습니다.

인스턴스 수준 OS 업데이트는 각 인스턴스에 대해 지정한 유지 관리 기간 동안 발생합니다. 예를 들어 클러스터와 두 리더 인스턴스의 유지 관리 기간이 다른 경우, 클러스터 수준의 OS 업데이트가 클러스터 유지 관리 기간에 맞춰 조정됩니다.



AWS Management Console 또는 AWS CLI를 사용하여 운영 체제 업그레이드 유형에 대한 정보를 얻을 수 있습니다.

### 콘솔
<a name="Aurora_OS_updates.pending-maintenance.CON"></a>

**AWS Management Console을 사용하여 업데이트 정보를 얻는 방법**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.

1. 탐색 창에서 **데이터베이스(Databases)**를 선택한 다음 DB 인스턴스를 선택합니다.

1. **유지 관리 및 백업**을 선택합니다.

1. **대기 중인 유지 관리** 섹션에서 운영 체제 업데이트를 찾은 다음 **설명** 값을 확인합니다.

다음 이미지는 운영 체제 패치를 사용할 수 있는 라이터 DB 인스턴스가 있는 DB 클러스터를 보여줍니다.

![\[클러스터 수준 운영 체제 패치.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/os-upgrade-cluster-minor.png)


![\[인스턴스 수준 운영 체제 패치.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/os-upgrade-writer-minor.png)


다음 이미지는 라이터 DB 인스턴스와 리더 DB 인스턴스가 있는 DB 클러스터를 보여줍니다. 라이터 인스턴스에는 필수 운영 체제 업그레이드를 사용할 수 있습니다. 리더 인스턴스에는 사용 가능한 운영 체제 패치가 있습니다.

![\[클러스터 수준 운영 체제 배포 업그레이드.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/os-upgrade-cluster-major.png)


![\[라이터 인스턴스 운영 체제 배포 업그레이드.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/os-upgrade-writer-major.png)


![\[리더 인스턴스 운영 체제 패치.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/os-upgrade-reader-minor.png)


### AWS CLI
<a name="Aurora_OS_updates.pending-maintenance.CLI"></a>

AWS CLI에서 업데이트 정보를 가져오려면 [describe-pending-maintenance-actions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-pending-maintenance-actions.html) 명령을 사용합니다.

```
aws rds describe-pending-maintenance-actions
```

다음 출력은 DB 클러스터 및 DB 인스턴스의 운영 체제 배포 업그레이드를 보여줍니다.

```
{
  "PendingMaintenanceActions": [
    {
      "ResourceIdentifier": "arn:aws:rds:us-east-1:123456789012:cluster:t3",
      "PendingMaintenanceActionDetails": [
        {
          "Action": "os-upgrade",
          "Description": "New Operating System upgrade is available"
        }
      ]
    },
    {
      "ResourceIdentifier": "arn:aws:rds:us-east-1:123456789012:db:t3-instance1",
      "PendingMaintenanceActionDetails": [
        {
          "Action": "system-update",
          "Description": "New Operating System upgrade is available"
        }
      ]
    },
  ]
}
```

다음 출력은 DB 인스턴스의 운영 체제 패치를 보여 줍니다.

```
{
  "ResourceIdentifier": "arn:aws:rds:us-east-1:123456789012:db:mydb2",
  "PendingMaintenanceActionDetails": [
    {
      "Action": "system-update",
      "Description": "New Operating System patch is available"
    }
  ]
}
```

### 운영 체제 업데이트 가용성
<a name="Aurora_OS_updates.availability"></a>

운영 체제 업데이트는 DB 엔진 버전 및 DB 인스턴스 클래스에 따라 다릅니다. 따라서 DB 인스턴스는 서로 다른 시점에 업데이트를 받거나 이를 요구합니다. 엔진 버전 및 인스턴스 클래스에 따라 DB 인스턴스에 운영 체제 업데이트가 지원되는 경우 업데이트가 콘솔에 표시됩니다. [describe-pending-maintenance-actions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-pending-maintenance-actions.html) AWS CLI 명령을 실행하거나 [DescribePendingMaintenanceActions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribePendingMaintenanceActions.html) RDS API 작업을 직접 호출하여 확인할 수도 있습니다. 인스턴스에 대한 업데이트가 지원되는 경우 [DB 클러스터에 업데이트 적용](#USER_UpgradeDBInstance.OSUpgrades)의 지침에 따라 운영 체제를 업데이트할 수 있습니다.

# 자동 마이너 버전 AWS Organizations 업그레이드에 업그레이드 롤아웃 정책 사용
<a name="Aurora.Maintenance.AMVU.UpgradeRollout"></a>

Aurora는 AWS Organizations 업그레이드 롤아웃 정책을 지원하여 여러 데이터베이스 리소스 및 AWS 계정에서 자동 마이너 버전 업그레이드를 관리합니다. 이 정책은 다음을 통해 클러스터에 대한 제어된 업그레이드 전략을 구현하는 데 도움이 됩니다.

**업그레이드 롤아웃 정책 작동 방식**

새 마이너 엔진 버전이 자동 업그레이드 대상이 되면 정책은 정의된 순서에 따라 업그레이드 시퀀스를 제어합니다.
+ [first]로 표시된 리소스(일반적으로 개발 환경)는 유지 관리 기간 동안 업그레이드할 수 있습니다.
+ 지정된 베이크 소요 시간이 지나면 [second]로 표시된 리소스가 적격 상태가 됩니다.
+ 또 다른 지정된 베이크 소요 시간이 지나면 [last]로 표시된 리소스(일반적으로 프로덕션 환경)가 적격 상태가 됩니다.
+ AWS 상태 알림을 통해 업그레이드 진행 상황을 모니터링합니다.

다음을 통해 업그레이드 주문을 정의할 수 있습니다.
+ 계정 수준 정책 - 지정된 계정의 모든 적격 리소스에 적용됩니다.
+ 리소스 태그 - 태그를 기반으로 특정 리소스에 적용합니다.

**참고**  
업그레이드 정책으로 구성되지 않았거나 정책에서 제외된 리소스는 자동으로 [second]의 업그레이드 순서를 받습니다.

**필수 조건**
+ AWS 계정은 업그레이드 롤아웃 정책이 활성화된 Organizations의 조직에 속해야 합니다.
+ 클러스터에 대한 마이너 버전 자동 업그레이드 활성화
+ 업그레이드 롤아웃 정책에 태그가 반드시 필요한 것은 아닙니다. 다양한 환경(예: 개발, 테스트, QA, 프로덕션)에 대한 특정 업그레이드 주문을 정의하려는 경우 태그를 사용할 수 있습니다. 정책에 태그 설정을 포함하지 않는 경우 해당 정책의 모든 리소스는 기본 업그레이드 순서를 따릅니다. Aurora 리소스의 경우 인스턴스 수준에서 태그가 정의되어 있더라도 업그레이드 롤아웃 정책에는 클러스터 수준 태그만 사용됩니다.

**리소스에 태그 지정**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.

1. 탐색 창에서 **Databases**(데이터베이스)를 선택합니다.

1. 태그하려는 클러스터를 선택합니다.

1. **작업**을 선택한 다음 **태그 관리**를 선택합니다.

1. **태그 추가**를 선택합니다.

1. 태그 키(예: 'Environment')와 값(예: 'Development')을 입력합니다.

1. **태그 추가**를 선택한 다음 **저장**을 선택합니다.

다음과 같이 AWS CLI를 사용하여 태그를 추가할 수 있습니다.

```
aws rds add-tags-to-resource \
    --resource-name arn:aws:rds:region:account-number:cluster:cluster-name \
    --tags Key=Environment,Value=Development
```

## 업그레이드 순서 및 단계
<a name="Aurora.Maintenance.AMVU.UpgradeRollout.OrderPhases"></a>

업그레이드 롤아웃 정책은 세 가지 업그레이드 주문을 지원합니다.
+ [first] - 일반적으로 개발 또는 테스트 환경에 사용됩니다.
+ [second] - 일반적으로 QA 환경에 사용됩니다. 정책이 특별히 구성되지 않은 경우 리소스의 기본 순서
+ [last] - 일반적으로 프로덕션 환경용으로 예약됨

새 마이너 엔진 버전이 자동 업그레이드 대상이 되는 경우:
+ 업그레이드 주문이 [first]인 리소스는 구성된 유지 관리 기간 동안 업그레이드할 수 있습니다.
+ 지정된 베이크 소요 시간이 지나면 업그레이드 주문이 [second]인 리소스는 유지 관리 기간 동안 업그레이드할 수 있습니다.
+ 또 다른 지정된 베이크 소요 시간이 지나면 업그레이드 주문이 [last]인 리소스는 유지 관리 기간 동안 업그레이드를 받을 수 있습니다.
+ 자동 마이너 버전 업그레이드 캠페인은 업그레이드 주문 [first], [second], [last]가 포함된 모든 적격 리소스가 업그레이드된 후 또는 캠페인이 예정된 종료일에 도달하는 시점 중 먼저 도래하는 시점에 종료됩니다.

**참고**  
애플리케이션에 대한 잠재적 영향을 최소화하기 위해 각 클러스터의 구성된 유지 관리 기간 동안 모든 자동 마이너 버전 업그레이드가 수행됩니다.

## 관찰성
<a name="Aurora.Maintenance.AMVU.UpgradeRollout.Observability"></a>

### AWS 상태 및 모니터링
<a name="Aurora.Maintenance.AMVU.UpgradeRollout.Observability.Health"></a>

다음과 같은 AWS 상태 알림을 받게 됩니다.
+ 자동 마이너 버전 업그레이드 캠페인 시작 전
+ 업그레이드 진행 상황을 추적하고 모니터링하는 데 도움이 되는 각 단계 전환 간
+ AWS Health 콘솔에서 플릿 전체에서 업그레이드된 리소스 수를 보여 주는 진행 상황 업데이트

Amazon RDS 이벤트 알림:
+ 다음을 포함하여 자동 마이너 버전 업그레이드에 활성화된 리소스에 대한 알림:
  + 리소스가 업그레이드 순서([first], [second] 또는 [last])에 따라 업그레이드할 수 있게 되는 경우
  + 유지 관리 기간 중 예약된 업그레이드 타임라인
  + 개별 데이터베이스 업그레이드 시작 및 완료 상태
+ 자동 모니터링을 위해 Amazon EventBridge0을 통해 이러한 이벤트 구독

### 고려 사항
<a name="Aurora.Maintenance.AMVU.UpgradeRollout.Observability.Considerations"></a>

유의해야 할 몇 가지 고려 사항은 다음과 같습니다.
+ 이 정책은 활성 캠페인 중에 이루어진 정책 변경을 포함하여 향후 모든 자동 마이너 버전 업그레이드 캠페인에 적용됩니다.
+ 진행 중인 업그레이드 캠페인에 참여하는 경우 리소스는 현재 실행 중인 업그레이드 순서를 따르며 구성된 정책을 기다리지 않습니다.
+ 업그레이드 정책으로 구성되지 않았거나 정책에서 제외된 리소스는 자동으로 [second]의 업그레이드 순서를 받습니다.
+ 이 정책은 다음 단계로 진행하기 전에 업그레이드 단계 사이의 검증 기간을 제공합니다.
+ 정책 또는 리소스 태그를 변경하려면 새 업그레이드 순서가 적용되기 전에 전파하는 데 시간이 필요합니다.
+ 이 정책은 자동 마이너 버전 업그레이드가 활성화된 Aurora 리소스에만 적용됩니다.
+ 환경 내에서 문제가 감지되면 후속 환경에 대한 자동 마이너 버전 업그레이드를 끄거나 업그레이드가 다음 업그레이드 순서로 진행되기 전에 검증 기간을 사용하여 문제를 해결할 수 있습니다.

RDS 리소스 태그 지정에 대한 자세한 내용은 [Amazon Aurora 및Amazon RDS 리소스에 태그 지정](USER_Tagging.md) 섹션을 참조하세요. 업그레이드 롤아웃 정책 설정 및 사용에 대한 자세한 지침은 *AWS Organizations 사용 설명서*의 [AWS Organizations 시작하기](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started.html)를 참조하세요.

# Amazon Aurora DB 클러스터 또는 Amazon Aurora DB 인스턴스 재부팅
<a name="USER_RebootCluster"></a><a name="reboot"></a>

 일반적으로 유지 관리를 위해 DB 클러스터 또는 클러스터 내의 일부 인스턴스를 재부팅해야 할 수 있습니다. 예를 들어 파라미터 그룹 내의 파라미터를 수정하거나 다른 파라미터 그룹을 클러스터에 연결한다고 가정해 보겠습니다. 이러한 경우 변경 사항을 적용하려면 클러스터를 재부팅해야 합니다. 마찬가지로 클러스터 내에서 하나 이상의 리더 DB 인스턴스를 재부팅할 수 있습니다. 개별 인스턴스에 대한 재부팅 작업을 준비하면 전체 클러스터의 다운타임을 최소화할 수 있습니다.

 클러스터의 각 DB 인스턴스를 재부팅하는 데 필요한 시간은 재부팅 시 데이터베이스 활동에 따라 다릅니다. 또한 특정 DB 엔진의 복구 프로세스에 따라서도 다릅니다. 가능하다면 재부팅 프로세스를 시작하기 전에 특정 인스턴스의 데이터베이스 활동을 줄이세요. 이렇게 하면 데이터베이스를 다시 시작하는 데 필요한 시간을 줄일 수 있습니다.

 클러스터의 각 DB 인스턴스는 사용 가능한 상태인 경우에만 재부팅할 수 있습니다. DB 인스턴스를 사용할 수 없는 이유로는 여러 가지가 있습니다. 예를 들어 클러스터가 중지 상태에 있는 경우, 인스턴스에 수정을 적용 중인 경우 및 유지 관리 기간 작업(예: 버전 업그레이드)이 여기에 포함됩니다.

 DB 인스턴스를 재부팅하면 데이터베이스 엔진 프로세스가 다시 시작됩니다. DB 인스턴스를 재부팅하면 DB 인스턴스 상태가 *rebooting*으로 설정되면서 잠시 중단됩니다.

**참고**  
 DB 인스턴스에서 연결된 DB 파라미터 그룹에 대한 최신 변경 내용을 사용하고 있지 않은 경우 AWS Management Console에 DB 파라미터 그룹이 **재시작 보류중** 상태로 표시됩니다. **재시작 보류중** 파라미터 그룹 상태로 인해 다음번 유지 관리 기간 중에 자동 재부팅이 되지는 않습니다. 최신 파라미터 변경 내용을 이 DB 인스턴스에 적용하려면 해당 DB 인스턴스를 수동으로 재부팅해야 합니다. 파라미터 그룹에 대한 자세한 내용은 [Amazon Aurora의 파라미터 그룹](USER_WorkingWithParamGroups.md) 단원을 참조하십시오.

**Topics**
+ [Aurora 클러스터 내의 DB 인스턴스 재부팅](aurora-reboot-db-instance.md)
+ [읽기 가용성을 포함하여 Aurora 클러스터 재부팅](aurora-mysql-survivable-replicas.md)
+ [읽기 가용성을 포함하지 않고 Aurora 클러스터 재부팅](aurora-reboot-cluster.md)
+ [Aurora 클러스터 및 인스턴스의 가동 시간 확인](USER_Reboot.Uptime.md)
+ [Aurora 재부팅 작업의 예](USER_Reboot.Examples.md)

# Aurora 클러스터 내의 DB 인스턴스 재부팅
<a name="aurora-reboot-db-instance"></a>

 이 절차는 Aurora에서 재부팅을 수행할 때 가장 중요한 작업입니다. 대부분의 유지 관리 절차에는 하나 이상의 Aurora DB 인스턴스를 특정 순서로 재부팅하는 작업이 포함됩니다.

## 콘솔
<a name="USER_RebootInstance.Console"></a>

**DB 인스턴스를 재부팅하려면**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.

1.  탐색 창에서 **데이터베이스**를 선택한 다음 재부팅하려는 DB 인스턴스를 선택합니다.

1.  **작업**에서 **재부팅**을 선택합니다.

    [**Reboot DB Instance**] 페이지가 나타납니다.

1.  DB 인스턴스를 재부팅하려면 [**Reboot**]를 선택합니다.

    또는 [**취소(Cancel)**]를 선택합니다.

## AWS CLI
<a name="USER_RebootInstance.CLI"></a>

 AWS CLI를 사용하여 DB 인스턴스를 재부팅하려면 [https://docs.aws.amazon.com/cli/latest/reference/rds/reboot-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/reboot-db-instance.html) 명령을 호출하십시오.

**Example**  
대상 LinuxmacOS, 또는Unix:  

```
aws rds reboot-db-instance \
    --db-instance-identifier mydbinstance
```
Windows의 경우:  

```
aws rds reboot-db-instance ^
    --db-instance-identifier mydbinstance
```

## RDS API
<a name="USER_RebootInstance.API"></a>

 Amazon RDS API를 사용하여 DB 인스턴스를 재부팅하려면 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RebootDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RebootDBInstance.html) 작업을 호출하세요.

# 읽기 가용성을 포함하여 Aurora 클러스터 재부팅
<a name="aurora-mysql-survivable-replicas"></a><a name="survivable_replicas"></a>

읽기 가용성 기능을 사용하면 기본 또는 보조 DB 클러스터의 리더 인스턴스를 재부팅하지 않고도 Aurora 클러스터의 라이터 인스턴스를 재부팅할 수 있습니다. 이렇게 하면 라이터 인스턴스를 재부팅하는 동안 읽기 작업에 대한 클러스터의 고가용성을 유지하는 데 도움이 됩니다. 나중에 편리한 일정에 따라 리더 인스턴스를 재부팅할 수 있습니다. 예를 들어 프로덕션 클러스터에서는 프라이머리 인스턴스의 재부팅이 완료된 후에만 리더 인스턴스를 한 번에 하나씩 재부팅할 수 있습니다. 재부팅하는 각 DB 인스턴스에 대해 [Aurora 클러스터 내의 DB 인스턴스 재부팅](aurora-reboot-db-instance.md)의 절차를 따릅니다.

기본 DB 클러스터의 읽기 가용성 기능은 Aurora MySQL 버전 2.10 이상에서 사용할 수 있습니다. 보조 DB 클러스터의 읽기 가용성은 Aurora MySQL 버전 3.06 이상에서 사용할 수 있습니다.

이 함수는 다음 Aurora PostgreSQL 버전에서 기본적으로 사용할 수 있습니다.
+ 15.2 이상의 15 버전
+ 14.7 이상의 14 버전
+ 13.10 이상의 13 버전
+ 12.14 이상의 12 버전

Aurora PostgreSQL의 읽기 가용성 기능에 대한 자세한 내용은 [Aurora 복제본의 읽기 가용성 향상](AuroraPostgreSQL.Replication.md#AuroraPostgreSQL.Replication.Replicas.SRO) 섹션을 참조하세요.

이 기능이 출시되기 전에는 기본 인스턴스를 재부팅하면 각 리더 인스턴스가 동시에 재부팅되었습니다. Aurora 클러스터에서 이전 버전을 실행 중인 경우 [읽기 가용성을 포함하지 않고 Aurora 클러스터 재부팅](aurora-reboot-cluster.md)의 재부팅 절차를 대신 사용합니다.

**참고**  
Aurora MySQL 버전 3.06 미만의 Aurora 글로벌 데이터베이스의 경우 읽기 가용성이 포함된 Aurora DB 클러스터의 재부팅 동작에 대한 변경 사항이 다릅니다. Aurora 글로벌 데이터베이스의 프라이머리 클러스터에 대한 라이터 인스턴스를 재부팅하는 경우 프라이머리 클러스터의 리더 프로그램 인스턴스는 사용할 수 있는 상태로 유지됩니다. 그러나 세컨더리 클러스터의 DB 인스턴스는 동시에 재부팅됩니다.  
향상된 읽기 가용성 기능의 제한된 버전은 Aurora PostgreSQL 버전 12.16, 13.12, 14.9, 15.4 이상용 Aurora 글로벌 데이터베이스에서 지원됩니다.

클러스터 파라미터 그룹을 변경한 후에는 클러스터를 자주 재부팅하게 됩니다. 파라미터를 변경하려면 [Amazon Aurora의 파라미터 그룹](USER_WorkingWithParamGroups.md)의 절차를 따릅니다. 클러스터 파라미터에 변경 사항을 적용하기 위해 Aurora 클러스터에서 라이터 DB 인스턴스를 재부팅한다고 가정해 보겠습니다. 리더 DB 인스턴스의 일부 또는 전부에는 이전 파라미터 설정이 계속해서 사용될 수 있습니다. 그러나 다른 파라미터 설정이 클러스터의 데이터 무결성에 영향을 미치지는 않습니다. 데이터 파일 구성에 영향을 주는 클러스터 파라미터는 라이터 DB 인스턴스에만 사용됩니다.

예를 들어, Aurora MySQL 인스턴스에서 리더 인스턴스 전에 라이터 인스턴스의 `binlog_format` 및 `innodb_purge_threads`와 같은 클러스터 파라미터를 업데이트할 수 있습니다. 라이터 인스턴스만 바이너리 로그를 작성하고 실행 취소 레코드를 제거합니다. 쿼리에서 SQL 문 또는 쿼리 출력을 해석하는 방식을 변경하는 파라미터의 경우 리더 인스턴스를 즉시 재부팅해야 할 수 있습니다. 이렇게 해야 쿼리 중에 예기치 않은 애플리케이션 동작을 방지할 수 있습니다. 예를 들어 `lower_case_table_names` 파라미터를 변경하고 라이터 인스턴스를 재부팅한다고 가정합시다. 이 경우 리더 인스턴스가 모두 재부팅될 때까지 새로 생성한 테이블에 액세스하지 못할 수 있습니다.

모든 Aurora MySQL 클러스터 파라미터 목록은 [클러스터 수준 파라미터](AuroraMySQL.Reference.ParameterGroups.md#AuroraMySQL.Reference.Parameters.Cluster) 섹션을 참조하세요.

모든 Aurora PostgreSQL 클러스터 파라미터 목록은 [Aurora PostgreSQL 클러스터 수준 파라미터](AuroraPostgreSQL.Reference.ParameterGroups.md#AuroraPostgreSQL.Reference.Parameters.Cluster) 섹션을 참조하세요.

**작은 정보**  
클러스터에서 처리량이 높은 워크로드를 처리 중인 경우 Aurora MySQL은 라이터 인스턴스와 함께 일부 리더 인스턴스를 재부팅할 수 있습니다.  
재부팅 횟수의 감소는 장애 조치 작업 중에도 적용됩니다. Aurora MySQL은 장애 조치 중에 라이터 DB 인스턴스와 장애 조치 대상만 재시작합니다. 클러스터의 다른 리더 DB 인스턴스는 리더 엔드포인트에 대한 연결을 통해 쿼리를 처리하는 데 계속해서 사용할 수 있습니다. 따라서 클러스터에 리더 DB 인스턴스를 2개 이상 보유하여 장애 조치 중에 가용성을 개선할 수 있습니다.

# 읽기 가용성을 포함하지 않고 Aurora 클러스터 재부팅
<a name="aurora-reboot-cluster"></a>

 읽기 가용성 기능을 사용하지 않으면 클러스터의 라이터 DB 인스턴스를 재부팅하여 전체 Aurora DB 클러스터를 재부팅할 수 있습니다. 이 작업을 수행하려면 의 절차를 수행합니다[Aurora 클러스터 내의 DB 인스턴스 재부팅](aurora-reboot-db-instance.md) 

 라이터 DB 인스턴스를 재부팅하면 클러스터의 각 리더 DB 인스턴스에 대해서도 재부팅이 시작됩니다. 이 방식으로 클러스터 전체 파라미터 변경 사항이 모든 DB 인스턴스에 동시에 적용됩니다. 그러나 모든 DB 인스턴스를 재부팅하면 클러스터가 잠시 중단됩니다. 라이터 DB 인스턴스의 재부팅이 완료되고 사용할 수 있게 될 때까지 리더 DB 인스턴스를 사용할 수 없게 됩니다.

이 재부팅 동작은 Aurora MySQL 버전 2.09 이하에서 생성된 모든 DB 클러스터에 적용됩니다.

Aurora PostgreSQL의 경우 이 동작은 다음 버전에 적용됩니다.
+ 14.6 이하 14 버전
+ 13.9 이하 13 버전
+ 12.13 이하 12 버전
+ 모든 PostgreSQL 11 버전

 RDS 콘솔에서 라이터 DB 인스턴스의 값인 [**라이터(Writer)**]는 [**데이터베이스(Databases)**] 페이지의 [**역할(Role)**] 열에 표시됩니다. RDS CLI에서 `describe-db-clusters` 명령 출력에는 `DBClusterMembers` 섹션이 포함됩니다. 라이터 DB 인스턴스를 나타내는 `DBClusterMembers` 요소는 `true` 필드에 `IsClusterWriter` 값이 표시됩니다.

**중요**  
 읽기 가용성 기능을 사용하면 Aurora MySQL 및 Aurora PostgreSQL에서는 재부팅 동작이 다릅니다. 일반적으로 라이터 인스턴스를 재부팅하는 동안 리더 DB 인스턴스를 사용할 수 있습니다. 그런 다음 편리한 시간에 리더 인스턴스를 재부팅할 수 있습니다. 일부 리더 인스턴스를 항상 사용할 수 있도록 하려면 시간 간격을 두고 리더 인스턴스를 재부팅하면 됩니다. 자세한 내용은 [읽기 가용성을 포함하여 Aurora 클러스터 재부팅](aurora-mysql-survivable-replicas.md) 단원을 참조하십시오.

# Aurora 클러스터 및 인스턴스의 가동 시간 확인
<a name="USER_Reboot.Uptime"></a>

 Aurora 클러스터의 각 DB 인스턴스에 대한 마지막 재부팅 이후 경과 시간을 확인하고 모니터링할 수 있습니다. Amazon CloudWatch 지표 `EngineUptime`은 DB 인스턴스가 마지막으로 시작된 이후의 시간(초)을 보고합니다. 특정 시점에 이 지표를 검토하여 DB 인스턴스의 가동 시간을 확인할 수 있습니다. 이 지표를 시간대별로 모니터링하여 인스턴스가 재부팅되는 시기를 감지할 수도 있습니다.

 클러스터 수준에서 `EngineUptime` 지표를 검사할 수도 있습니다. `Minimum` 및 `Maximum` 차원은 클러스터의 모든 DB 인스턴스에 대한 최소 및 최대 가동 시간 값을 보고합니다. 클러스터의 리더 인스턴스가 재부팅되거나 다른 이유로 다시 시작된 최근 시간을 확인하려면 `Minimum` 차원을 사용하여 클러스터 수준 지표를 모니터링합니다. 클러스터에서 재부팅 없이 가장 오래 지속된 인스턴스를 확인하려면 `Maximum` 차원을 사용하여 클러스터 수준 지표를 모니터링합니다. 예를 들어 구성 변경 후 클러스터의 모든 DB 인스턴스가 재부팅되었는지 확인해야 할 수 있습니다.

**작은 정보**  
 장기 모니터링의 경우 클러스터 수준 대신 개별 인스턴스에 대한 `EngineUptime` 지표를 모니터링하는 것이 좋습니다. 클러스터에 새 DB 인스턴스가 추가되면 클러스터 수준 `EngineUptime` 지표가 0으로 설정됩니다. 이러한 클러스터 변경은 Auto Scaling에서 수행되는 것과 같은 유지 관리 및 확장 작업의 일부로 발생할 수 있습니다.

 다음 CLI 예제는 클러스터의 라이터 및 리더 인스턴스에 대한 `EngineUptime` 지표를 검사하는 방법을 보여줍니다. 이 예제에는 이름이 `tpch100g`인 클러스터가 사용됩니다. 이 클러스터에는 라이터 DB 인스턴스 `instance-1234`가 있습니다. 또한 2개의 리더 DB 인스턴스 `instance-7448`과 `instance-6305`가 있습니다.

 먼저 `reboot-db-instance` 명령은 리더 인스턴스 중 하나를 재부팅합니다. `wait` 명령은 인스턴스 재부팅이 완료될 때까지 대기합니다.

```
$ aws rds reboot-db-instance --db-instance-identifier instance-6305
{
    "DBInstance": {
        "DBInstanceIdentifier": "instance-6305",
        "DBInstanceStatus": "rebooting",
...
$ aws rds wait db-instance-available --db-instance-id instance-6305
```

 CloudWatch `get-metric-statistics` 명령은 지난 5분간의 `EngineUptime` 지표를 1분 간격으로 검사합니다. `instance-6305` 인스턴스의 가동 시간이 0으로 재설정되고 다시 계산되기 시작합니다. 이 Linux용 AWS CLI 예제에서는 `$()` 변수 대체를 사용하여 CLI 명령에 해당하는 타임스탬프를 삽입합니다. 또한 Linux `sort` 명령을 사용하여 지표가 수집된 시간별로 출력 순서를 지정합니다. 이 타임스탬프 값은 출력의 각 줄에서 세 번째 필드입니다.

```
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
  --period 60 --namespace "AWS/RDS" --statistics Maximum \
  --dimensions Name=DBInstanceIdentifier,Value=instance-6305 --output text \
  | sort -k 3
EngineUptime
DATAPOINTS	231.0	2021-03-16T18:19:00+00:00	Seconds
DATAPOINTS	291.0	2021-03-16T18:20:00+00:00	Seconds
DATAPOINTS	351.0	2021-03-16T18:21:00+00:00	Seconds
DATAPOINTS	411.0	2021-03-16T18:22:00+00:00	Seconds
DATAPOINTS	471.0	2021-03-16T18:23:00+00:00	Seconds
```

 클러스터의 인스턴스 중 하나가 재부팅되었으므로 클러스터의 최소 가동 시간이 0으로 재설정됩니다. 클러스터의 DB 인스턴스 중 하나 이상이 사용 가능한 상태로 남아 있기 때문에 클러스터의 최대 가동 시간은 재설정되지 않습니다.

```
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
  --period 60 --namespace "AWS/RDS" --statistics Minimum \
  --dimensions Name=DBClusterIdentifier,Value=tpch100g --output text \
  | sort -k 3
EngineUptime
DATAPOINTS	63099.0	2021-03-16T18:12:00+00:00	Seconds
DATAPOINTS	63159.0	2021-03-16T18:13:00+00:00	Seconds
DATAPOINTS	63219.0	2021-03-16T18:14:00+00:00	Seconds
DATAPOINTS	63279.0	2021-03-16T18:15:00+00:00	Seconds
DATAPOINTS	51.0	2021-03-16T18:16:00+00:00	Seconds

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
  --period 60 --namespace "AWS/RDS" --statistics Maximum \
  --dimensions Name=DBClusterIdentifier,Value=tpch100g --output text \
  | sort -k 3
EngineUptime
DATAPOINTS	63389.0	2021-03-16T18:16:00+00:00	Seconds
DATAPOINTS	63449.0	2021-03-16T18:17:00+00:00	Seconds
DATAPOINTS	63509.0	2021-03-16T18:18:00+00:00	Seconds
DATAPOINTS	63569.0	2021-03-16T18:19:00+00:00	Seconds
DATAPOINTS	63629.0	2021-03-16T18:20:00+00:00	Seconds
```

 그런 다음 다른 `reboot-db-instance` 명령에 의해 클러스터의 라이터 인스턴스가 재부팅됩니다. 다른 `wait` 명령은 라이터 인스턴스의 재부팅이 완료될 때까지 일시 중지됩니다.

```
$ aws rds reboot-db-instance --db-instance-identifier instance-1234
{
  "DBInstanceIdentifier": "instance-1234",
  "DBInstanceStatus": "rebooting",
...
$ aws rds wait db-instance-available --db-instance-id instance-1234
```

 이제 라이터 인스턴스의 `EngineUptime` 지표에서 인스턴스 `instance-1234`가 최근에 재부팅되었음을 알 수 있습니다. 리더 인스턴스 `instance-6305`도 라이터 인스턴스와 함께 자동으로 재부팅되었습니다. 이 클러스터는 Aurora MySQL 2.09를 실행 중이므로 라이터 인스턴스가 재부팅될 때 리더 인스턴스의 실행이 유지되지 않습니다.

```
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
  --period 60 --namespace "AWS/RDS" --statistics Maximum \
  --dimensions Name=DBInstanceIdentifier,Value=instance-1234 --output text \
  | sort -k 3
EngineUptime
DATAPOINTS	63749.0	2021-03-16T18:22:00+00:00	Seconds
DATAPOINTS	63809.0	2021-03-16T18:23:00+00:00	Seconds
DATAPOINTS	63869.0	2021-03-16T18:24:00+00:00	Seconds
DATAPOINTS	41.0	2021-03-16T18:25:00+00:00	Seconds
DATAPOINTS	101.0	2021-03-16T18:26:00+00:00	Seconds

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
  --period 60 --namespace "AWS/RDS" --statistics Maximum \
  --dimensions Name=DBInstanceIdentifier,Value=instance-6305 --output text \
  | sort -k 3
EngineUptime
DATAPOINTS	411.0	2021-03-16T18:22:00+00:00	Seconds
DATAPOINTS	471.0	2021-03-16T18:23:00+00:00	Seconds
DATAPOINTS	531.0	2021-03-16T18:24:00+00:00	Seconds
DATAPOINTS	49.0	2021-03-16T18:26:00+00:00	Seconds
```

# Aurora 재부팅 작업의 예
<a name="USER_Reboot.Examples"></a>

 다음 Aurora MySQL 예제에서는 Aurora DB 클러스터의 리더 및 라이터 DB 인스턴스에 대한 재부팅 작업의 여러 조합을 보여줍니다. 재부팅할 때마다 SQL 쿼리는 클러스터의 인스턴스에 대한 가동 시간을 보여줍니다.

**Topics**
+ [Aurora 클러스터의 라이터 및 리더 인스턴스 찾기](#USER_Reboot.Examples.IsClusterWriter)
+ [단일 리더 인스턴스 재부팅](#USER_Reboot.Examples.RebootReader)
+ [라이터 인스턴스 재부팅](#USER_Reboot.Examples.RebootWriter)
+ [라이터와 리더를 독립적으로 재부팅](#USER_Reboot.Examples.RebootAsynch)
+ [Aurora MySQL 버전 2.10 클러스터에 클러스터 파라미터 변경 사항 적용](#USER_Reboot.Examples.ParamChangeNewStyle)

## Aurora 클러스터의 라이터 및 리더 인스턴스 찾기
<a name="USER_Reboot.Examples.IsClusterWriter"></a>

 DB 인스턴스가 여러 개인 Aurora MySQL 클러스터에서는 어느 인스턴스가 라이터이고, 어느 인스턴스가 리더인지 파악하는 것이 중요합니다. 또한 라이터 인스턴스와 리더 인스턴스는 장애 조치 작업이 수행될 때 역할을 전환할 수 있습니다. 따라서 라이터 또는 리더 인스턴스가 필요한 작업을 수행하기 전에 다음과 같은 검사를 수행하는 것이 가장 좋습니다. 이 경우 `False`의 `IsClusterWriter` 값은 리더 인스턴스 `instance-6305` 및 `instance-7448`을 식별합니다. `True` 값은 라이터 인스턴스 `instance-1234`를 식별합니다.

```
$ aws rds describe-db-clusters --db-cluster-id tpch100g \
  --query "*[].['Cluster:',DBClusterIdentifier,DBClusterMembers[*].['Instance:',DBInstanceIdentifier,IsClusterWriter]]" \
  --output text
Cluster:     tpch100g
Instance:    instance-6305    False
Instance:    instance-7448    False
Instance:    instance-1234    True
```

 재부팅 예제를 시작하기 전에 라이터 인스턴스의 가동 시간은 약 1주일입니다. 이 예제의 SQL 쿼리는 가동 시간을 확인하는 MySQL 관련 방법을 보여줍니다. 데이터베이스 애플리케이션에서 이 기술을 사용할 수 있습니다. AWS CLI를 사용하고 두 Aurora 엔진에서 모두 작동하는 다른 기술은 [Aurora 클러스터 및 인스턴스의 가동 시간 확인](USER_Reboot.Uptime.md) 섹션을 참조하세요.

```
$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
    -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
    -> from performance_schema.global_status
    -> where variable_name='Uptime';
+----------------------------+---------+
| Last Startup               | Uptime  |
+----------------------------+---------+
| 2021-03-08 17:49:06.000000 | 174h 42m|
+----------------------------+---------+
```

## 단일 리더 인스턴스 재부팅
<a name="USER_Reboot.Examples.RebootReader"></a>

 이 예제에서는 리더 DB 인스턴스 중 하나를 재부팅합니다. 아마도 이 인스턴스는 거대한 쿼리 또는 많은 동시 연결로 인해 오버로드되었을 수 있습니다. 또는 네트워크 문제로 인해 라이터 인스턴스보다 뒤쳐졌을 수 있습니다. 재부팅 작업이 시작된 후 이 예제에서는 `wait` 명령을 사용하여 인스턴스를 사용할 수 있게 될 때까지 일시 중지합니다. 이 시점까지 인스턴스의 가동 시간은 몇 분입니다.

```
$ aws rds reboot-db-instance --db-instance-identifier instance-6305
{
    "DBInstance": {
        "DBInstanceIdentifier": "instance-6305",
        "DBInstanceStatus": "rebooting",
...
    }
}
$ aws rds wait db-instance-available --db-instance-id instance-6305
$ mysql -h instance-6305.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
    -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
    -> from performance_schema.global_status
    -> where variable_name='Uptime';
+----------------------------+---------+
| Last Startup               | Uptime  |
+----------------------------+---------+
| 2021-03-16 00:35:02.000000 | 00h 03m |
+----------------------------+---------+
```

 리더 인스턴스를 재부팅해도 라이터 인스턴스의 가동 시간은 영향을 받지 않았습니다. 여전히 가동 시간은 약 1주일입니다.

```
$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
    -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
    -> from performance_schema.global_status where variable_name='Uptime';
+----------------------------+----------+
| Last Startup               | Uptime   |
+----------------------------+----------+
| 2021-03-08 17:49:06.000000 | 174h 49m |
+----------------------------+----------+
```

## 라이터 인스턴스 재부팅
<a name="USER_Reboot.Examples.RebootWriter"></a>

 이 예제에서는 라이터 인스턴스를 재부팅합니다. 이 클러스터는 Aurora MySQL 버전 2.09를 실행 중입니다. Aurora MySQL 버전이 2.10보다 낮기 때문에 라이터 인스턴스를 재부팅하면 클러스터의 모든 리더 인스턴스도 재부팅됩니다.

 `wait` 명령에 의해 재부팅이 완료될 때까지 일시 중지됩니다. 이제 해당 인스턴스의 가동 시간이 0으로 재설정됩니다. 라이터 및 리더 DB 인스턴스에 대한 재부팅 작업에 소요되는 시간은 크게 다를 수 있습니다. 라이터 및 리더 DB 인스턴스는 역할에 따라 서로 다른 종류의 정리 작업을 수행합니다.

```
$ aws rds reboot-db-instance --db-instance-identifier instance-1234
{
    "DBInstance": {
        "DBInstanceIdentifier": "instance-1234",
        "DBInstanceStatus": "rebooting",
...
    }
}
$ aws rds wait db-instance-available --db-instance-id instance-1234
$ mysql -h instance-1234.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
    -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
    -> from performance_schema.global_status where variable_name='Uptime';
+----------------------------+---------+
| Last Startup               | Uptime  |
+----------------------------+---------+
| 2021-03-16 00:40:27.000000 | 00h 00m |
+----------------------------+---------+
```

 라이터 DB 인스턴스를 재부팅한 후 두 리더 DB 인스턴스의 가동 시간이 모두 재설정됩니다. 라이터 인스턴스가 재부팅되어 리더 인스턴스도 재부팅되었습니다. 이 동작은 Aurora PostgreSQL 클러스터 및 버전 2.10 이전의 Aurora MySQL 클러스터에 적용됩니다.

```
$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
    -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
    -> from performance_schema.global_status where variable_name='Uptime';
+----------------------------+---------+
| Last Startup               | Uptime  |
+----------------------------+---------+
| 2021-03-16 00:40:35.000000 | 00h 00m |
+----------------------------+---------+

$ mysql -h instance-6305.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
    -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
    -> from performance_schema.global_status where variable_name='Uptime';
+----------------------------+---------+
| Last Startup               | Uptime  |
+----------------------------+---------+
| 2021-03-16 00:40:33.000000 | 00h 01m |
+----------------------------+---------+
```

## 라이터와 리더를 독립적으로 재부팅
<a name="USER_Reboot.Examples.RebootAsynch"></a>

 다음 예제에서는 Aurora MySQL 버전 2.10을 실행하는 클러스터를 보여줍니다. 이 Aurora MySQL 버전 이상에서는 모든 리더 인스턴스에 대한 재부팅을 야기하지 않고 라이터 인스턴스를 재부팅할 수 있습니다. 이렇게 하면 라이터 인스턴스를 재부팅할 때 쿼리 집약적인 애플리케이션이 중단되지 않습니다. 나중에 리더 인스턴스를 재부팅할 수 있습니다. 쿼리 트래픽이 낮은 시간에 이러한 재부팅을 수행할 수 있습니다. 리더 인스턴스를 한 번에 하나씩 재부팅할 수도 있습니다. 이렇게 하면 애플리케이션의 쿼리 트래픽에 항상 하나 이상의 리더 인스턴스를 사용할 수 있습니다.

 다음 예제에서는 Aurora MySQL 버전 `cluster-2393`을 실행하는 `5.7.mysql_aurora.2.10.0`이라는 이름의 클러스터를 사용합니다. 이 클러스터에는 이름이 `instance-9404`인 라이터 인스턴스 1개와 이름이 `instance-6772`, `instance-2470` 및 `instance-5138`인 리더 인스턴스 3개가 있습니다.

```
$ aws rds describe-db-clusters --db-cluster-id cluster-2393 \
  --query "*[].['Cluster:',DBClusterIdentifier,DBClusterMembers[*].['Instance:',DBInstanceIdentifier,IsClusterWriter]]" \
  --output text
Cluster:        cluster-2393
Instance:       instance-5138        False
Instance:       instance-2470        False
Instance:       instance-6772        False
Instance:       instance-9404        True
```

 `uptime` 명령을 통해 각 데이터베이스 인스턴스의 `mysql` 값을 확인하면 각 인스턴스의 가동 시간이 거의 동일하다는 것을 알 수 있습니다. 예를 들어 `instance-5138`의 가동 시간은 다음과 같습니다.

```
mysql> SHOW GLOBAL STATUS LIKE 'uptime';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Uptime        | 3866  |
+---------------+-------+
```

 CloudWatch를 사용하면 실제로 인스턴스에 로그인하지 않고도 해당 가동 시간 정보를 얻을 수 있습니다. 이 방식으로 관리자는 데이터베이스를 모니터링할 수 있지만 테이블 데이터를 보거나 변경할 수는 없습니다. 이 예에서는 5분에 걸친 기간을 지정하고 1분 간격으로 가동 시간 값을 확인합니다. 가동 시간 값이 증가하면 해당 기간 동안 인스턴스가 다시 시작되지 않았음을 나타냅니다.

```
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-9404 \
  --output text | sort -k 3
EngineUptime
DATAPOINTS	4648.0	2021-03-17T23:42:00+00:00	Seconds
DATAPOINTS	4708.0	2021-03-17T23:43:00+00:00	Seconds
DATAPOINTS	4768.0	2021-03-17T23:44:00+00:00	Seconds
DATAPOINTS	4828.0	2021-03-17T23:45:00+00:00	Seconds
DATAPOINTS	4888.0	2021-03-17T23:46:00+00:00	Seconds

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-6772 \
  --output text | sort -k 3
EngineUptime
DATAPOINTS	4315.0	2021-03-17T23:42:00+00:00	Seconds
DATAPOINTS	4375.0	2021-03-17T23:43:00+00:00	Seconds
DATAPOINTS	4435.0	2021-03-17T23:44:00+00:00	Seconds
DATAPOINTS	4495.0	2021-03-17T23:45:00+00:00	Seconds
DATAPOINTS	4555.0	2021-03-17T23:46:00+00:00	Seconds
```

 이제 리더 인스턴스 중 하나인 `instance-5138`을 재부팅합니다. 재부팅 후 인스턴스를 다시 사용할 수 있을 때까지 기다립니다. 이제 5분 동안 가동 시간을 모니터링하면 해당 시간 동안 가동 시간이 0으로 재설정된 것을 알 수 있습니다. 가장 최근의 가동 시간 값은 재부팅이 완료되고 5초 후에 측정되었습니다.

```
$ aws rds reboot-db-instance --db-instance-identifier instance-5138
{
  "DBInstanceIdentifier": "instance-5138",
  "DBInstanceStatus": "rebooting"
}
$ aws rds wait db-instance-available --db-instance-id instance-5138

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-5138 \
  --output text | sort -k 3
EngineUptime
DATAPOINTS	4500.0	2021-03-17T23:46:00+00:00	Seconds
DATAPOINTS	4560.0	2021-03-17T23:47:00+00:00	Seconds
DATAPOINTS	4620.0	2021-03-17T23:48:00+00:00	Seconds
DATAPOINTS	4680.0	2021-03-17T23:49:00+00:00	Seconds
DATAPOINTS  5.0 2021-03-17T23:50:00+00:00 Seconds
```

 다음으로 라이터 인스턴스 `instance-9404`에 대해 재부팅을 수행합니다. 라이터 인스턴스와 리더 인스턴스 중 하나에 대한 가동 시간 값을 비교합니다. 이렇게 하면 라이터를 재부팅해도 리더가 재부팅되지 않았다는 것을 알 수 있습니다. Aurora MySQL 2.10 이전 버전에서는 모든 리더의 가동 시간 값이 라이터와 동시에 재설정됩니다.

```
$ aws rds reboot-db-instance --db-instance-identifier instance-9404
{
  "DBInstanceIdentifier": "instance-9404",
  "DBInstanceStatus": "rebooting"
}
$ aws rds wait db-instance-available --db-instance-id instance-9404

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-9404 \
  --output text | sort -k 3
EngineUptime
DATAPOINTS	371.0	2021-03-17T23:57:00+00:00	Seconds
DATAPOINTS	431.0	2021-03-17T23:58:00+00:00	Seconds
DATAPOINTS	491.0	2021-03-17T23:59:00+00:00	Seconds
DATAPOINTS	551.0	2021-03-18T00:00:00+00:00	Seconds
DATAPOINTS  37.0  2021-03-18T00:01:00+00:00 Seconds

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-6772 \
  --output text | sort -k 3
EngineUptime
DATAPOINTS	5215.0	2021-03-17T23:57:00+00:00	Seconds
DATAPOINTS	5275.0	2021-03-17T23:58:00+00:00	Seconds
DATAPOINTS	5335.0	2021-03-17T23:59:00+00:00	Seconds
DATAPOINTS	5395.0	2021-03-18T00:00:00+00:00	Seconds
DATAPOINTS	5455.0	2021-03-18T00:01:00+00:00	Seconds
```

 모든 리더 인스턴스에서 라이터 인스턴스와 동일한 구성 파라미터가 변경되도록 하려면 라이터 다음에 모든 리더 인스턴스를 재부팅합니다. 이 예제에서는 모든 리더를 재부팅한 다음 사용할 수 있을 때까지 기다린 후 계속합니다.

```
$ aws rds reboot-db-instance --db-instance-identifier instance-6772
{
  "DBInstanceIdentifier": "instance-6772",
  "DBInstanceStatus": "rebooting"
}

$ aws rds reboot-db-instance --db-instance-identifier instance-2470
{
  "DBInstanceIdentifier": "instance-2470",
  "DBInstanceStatus": "rebooting"
}

$ aws rds reboot-db-instance --db-instance-identifier instance-5138
{
  "DBInstanceIdentifier": "instance-5138",
  "DBInstanceStatus": "rebooting"
}

$ aws rds wait db-instance-available --db-instance-id instance-6772
$ aws rds wait db-instance-available --db-instance-id instance-2470
$ aws rds wait db-instance-available --db-instance-id instance-5138
```

 이제 라이터 DB 인스턴스의 가동 시간이 가장 높다는 것을 알 수 있습니다. 이 인스턴스의 가동 시간 값은 모니터링 기간 동안 꾸준히 증가했습니다. 리더 DB 인스턴스는 모두 리더 이후에 재부팅되었습니다. 모니터링 기간 내에서 각 리더가 재부팅되고 가동 시간이 0으로 재설정된 시점을 확인할 수 있습니다.

```
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-9404 \
  --output text | sort -k 3
EngineUptime
DATAPOINTS	457.0	2021-03-18T00:08:00+00:00	Seconds
DATAPOINTS	517.0	2021-03-18T00:09:00+00:00	Seconds
DATAPOINTS	577.0	2021-03-18T00:10:00+00:00	Seconds
DATAPOINTS	637.0	2021-03-18T00:11:00+00:00	Seconds
DATAPOINTS  697.0 2021-03-18T00:12:00+00:00 Seconds

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-2470 \
  --output text | sort -k 3
EngineUptime
DATAPOINTS	5819.0	2021-03-18T00:08:00+00:00	Seconds
DATAPOINTS  35.0  2021-03-18T00:09:00+00:00 Seconds
DATAPOINTS	95.0	2021-03-18T00:10:00+00:00	Seconds
DATAPOINTS	155.0	2021-03-18T00:11:00+00:00	Seconds
DATAPOINTS	215.0	2021-03-18T00:12:00+00:00	Seconds

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-5138 \
  --output text | sort -k 3
EngineUptime
DATAPOINTS	1085.0	2021-03-18T00:08:00+00:00	Seconds
DATAPOINTS	1145.0	2021-03-18T00:09:00+00:00	Seconds
DATAPOINTS	1205.0	2021-03-18T00:10:00+00:00	Seconds
DATAPOINTS  49.0  2021-03-18T00:11:00+00:00 Seconds
DATAPOINTS	109.0	2021-03-18T00:12:00+00:00	Seconds
```

## Aurora MySQL 버전 2.10 클러스터에 클러스터 파라미터 변경 사항 적용
<a name="USER_Reboot.Examples.ParamChangeNewStyle"></a>

 다음 예제는 Aurora MySQL 2.10 클러스터의 모든 DB 인스턴스에 파라미터 변경 사항을 적용하는 방법을 보여줍니다. 이 Aurora MySQL 버전에서는 라이터 인스턴스와 모든 리더 인스턴스를 독립적으로 재부팅합니다.

 이 예제에서는 MySQL 구성 파라미터 `lower_case_table_names`를 사용하여 설명합니다. 이 파라미터 설정이 라이터와 리더 DB 인스턴스 간에 다른 경우 쿼리에서 대문자 또는 대/소문자 혼합 이름으로 선언된 테이블에 액세스하지 못할 수 있습니다. 또는 2개의 테이블 이름이 대문자와 소문자의 측면에서만 다른 경우 쿼리가 잘못된 테이블에 액세스할 수 있습니다.

 이 예제에서는 각 인스턴스의 `IsClusterWriter` 속성을 검사하여 클러스터의 라이터 및 리더 인스턴스를 확인하는 방법을 보여줍니다. 클러스트 이름은 `cluster-2393`입니다. 이 클러스터에는 `instance-9404`라는 이름의 라이터 인스턴스가 있습니다. 클러스터의 리더 인스턴스 이름은 `instance-5138` 및 `instance-2470`입니다.

```
$ aws rds describe-db-clusters --db-cluster-id cluster-2393 \
  --query '*[].[DBClusterIdentifier,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' \
  --output text
cluster-2393
instance-5138        False
instance-2470        False
instance-9404        True
```

 `lower_case_table_names` 파라미터 변경의 효과를 보여주기 위해 2개의 DB 클러스터 파라미터 그룹을 설정했습니다. `lower-case-table-names-0` 파라미터 그룹에서는 이 파라미터가 0으로 설정되어 있습니다. `lower-case-table-names-1` 파라미터 그룹에서는 이 파라미터 그룹이 1로 설정되어 있습니다.

```
$ aws rds create-db-cluster-parameter-group --description 'lower-case-table-names-0' \
  --db-parameter-group-family aurora-mysql5.7 \
  --db-cluster-parameter-group-name lower-case-table-names-0
{
    "DBClusterParameterGroup": {
        "DBClusterParameterGroupName": "lower-case-table-names-0",
        "DBParameterGroupFamily": "aurora-mysql5.7",
        "Description": "lower-case-table-names-0"
    }
}

$ aws rds create-db-cluster-parameter-group --description 'lower-case-table-names-1' \
  --db-parameter-group-family aurora-mysql5.7 \
  --db-cluster-parameter-group-name lower-case-table-names-1
{
    "DBClusterParameterGroup": {
        "DBClusterParameterGroupName": "lower-case-table-names-1",
        "DBParameterGroupFamily": "aurora-mysql5.7",
        "Description": "lower-case-table-names-1"
    }
}

$ aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name lower-case-table-names-0 \
  --parameters ParameterName=lower_case_table_names,ParameterValue=0,ApplyMethod=pending-reboot
{
    "DBClusterParameterGroupName": "lower-case-table-names-0"
}

$ aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name lower-case-table-names-1 \
    --parameters ParameterName=lower_case_table_names,ParameterValue=1,ApplyMethod=pending-reboot
{
    "DBClusterParameterGroupName": "lower-case-table-names-1"
}
```

 `lower_case_table_names`의 기본값은 0입니다. 이 파라미터 설정에서 테이블 `foo`는 테이블 `FOO`와 구별됩니다. 이 예제에서는 파라미터가 여전히 기본 설정에 있는지 확인합니다. 그런 다음 이름에서 대문자와 소문자만 다른 테이블 3개를 생성합니다.

```
mysql> create database lctn;
Query OK, 1 row affected (0.07 sec)

mysql> use lctn;
Database changed
mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
|                        0 |
+--------------------------+

mysql> create table foo (s varchar(128));
mysql> insert into foo values ('Lowercase table name foo');

mysql> create table Foo (s varchar(128));
mysql> insert into Foo values ('Mixed-case table name Foo');

mysql> create table FOO (s varchar(128));
mysql> insert into FOO values ('Uppercase table name FOO');

mysql> select * from foo;
+--------------------------+
| s                        |
+--------------------------+
| Lowercase table name foo |
+--------------------------+

mysql> select * from Foo;
+---------------------------+
| s                         |
+---------------------------+
| Mixed-case table name Foo |
+---------------------------+

mysql> select * from FOO;
+--------------------------+
| s                        |
+--------------------------+
| Uppercase table name FOO |
+--------------------------+
```

 다음으로 DB 파라미터 그룹을 클러스터에 연결하여 `lower_case_table_names` 파라미터를 1로 설정합니다. 이 변경 사항은 각 DB 인스턴스를 재부팅한 후에만 적용됩니다.

```
$ aws rds modify-db-cluster --db-cluster-identifier cluster-2393 \
  --db-cluster-parameter-group-name lower-case-table-names-1
{
  "DBClusterIdentifier": "cluster-2393",
  "DBClusterParameterGroup": "lower-case-table-names-1",
  "Engine": "aurora-mysql",
  "EngineVersion": "5.7.mysql_aurora.2.10.0"
}
```

 첫 번째 재부팅은 라이터 DB 인스턴스에 대해 수행합니다. 그런 다음 인스턴스를 다시 사용할 수 있을 때까지 기다립니다. 이 시점에서 라이터 엔드포인트에 연결하고 라이터 인스턴스에 변경된 파라미터 값이 있는지 확인합니다. `SHOW TABLES` 명령을 사용하여 데이터베이스에 3개의 서로 다른 테이블이 포함되어 있음을 확인합니다. 그러나 `foo`, `Foo` 또는 `FOO` 테이블을 참조하는 쿼리는 이름이 모두 소문자인 `foo` 테이블에 액세스합니다.

```
# Rebooting the writer instance
$ aws rds reboot-db-instance --db-instance-identifier instance-9404
$ aws rds wait db-instance-available --db-instance-id instance-9404
```

 이제 클러스터 엔드포인트를 사용하는 쿼리를 통해 파라미터 변경의 영향을 볼 수 있습니다. 쿼리의 테이블 이름이 대문자인지, 소문자인지, 대/소문자 혼합인지 여부에 관계없이 SQL 문은 이름이 모두 소문자인 테이블에 액세스합니다.

```
mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
|                        1 |
+--------------------------+

mysql> use lctn;
mysql> show tables;
+----------------+
| Tables_in_lctn |
+----------------+
| FOO            |
| Foo            |
| foo            |
+----------------+

mysql> select * from foo;
+--------------------------+
| s                        |
+--------------------------+
| Lowercase table name foo |
+--------------------------+

mysql> select * from Foo;
+--------------------------+
| s                        |
+--------------------------+
| Lowercase table name foo |
+--------------------------+

mysql> select * from FOO;
+--------------------------+
| s                        |
+--------------------------+
| Lowercase table name foo |
+--------------------------+
```

 다음 예제는 이전 쿼리와 동일한 쿼리를 보여줍니다. 이 예에서 쿼리는 리더 엔드포인트를 사용하고 리더 DB 인스턴스 중 하나에서 실행됩니다. 이러한 인스턴스는 아직 재부팅되지 않았습니다. 따라서 `lower_case_table_names` 파라미터에 대한 원래 설정이 유지됩니다. 즉, 쿼리는 `foo`, `Foo` 및`FOO` 테이블 각각에 액세스할 수 있습니다.

```
mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
|                        0 |
+--------------------------+

mysql> use lctn;

mysql> select * from foo;
+--------------------------+
| s                        |
+--------------------------+
| Lowercase table name foo |
+--------------------------+

mysql> select * from Foo;
+---------------------------+
| s                         |
+---------------------------+
| Mixed-case table name Foo |
+---------------------------+

mysql> select * from FOO;
+--------------------------+
| s                        |
+--------------------------+
| Uppercase table name FOO |
+--------------------------+
```

 다음으로 리더 인스턴스 중 하나를 재부팅하고 다시 사용할 수 있을 때까지 기다립니다.

```
$ aws rds reboot-db-instance --db-instance-identifier instance-2470
{
  "DBInstanceIdentifier": "instance-2470",
  "DBInstanceStatus": "rebooting"
}
$ aws rds wait db-instance-available --db-instance-id instance-2470
```

 `instance-2470`에 대한 인스턴스 엔드포인트에 연결되어 있는 동안 쿼리는 새 파라미터가 적용되었음을 보여줍니다.

```
mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
|                        1 |
+--------------------------+
```

 이 시점에서 클러스터의 두 리더 인스턴스는 서로 다른 `lower_case_table_names` 설정으로 실행됩니다. 따라서 클러스터의 리더 엔드포인트에 대한 연결에서 이 설정에는 예측할 수 없는 값이 사용됩니다. 둘 다 일관된 설정을 갖도록 다른 리더 인스턴스를 즉시 재부팅하는 것이 중요합니다.

```
$ aws rds reboot-db-instance --db-instance-identifier instance-5138
{
  "DBInstanceIdentifier": "instance-5138",
  "DBInstanceStatus": "rebooting"
}
$ aws rds wait db-instance-available --db-instance-id instance-5138
```

 다음 예제에서는 모든 리더 인스턴스의 `lower_case_table_names` 파라미터 설정이 동일한지 확인합니다. 명령은 각 리더 인스턴스의 `lower_case_table_names` 설정 값을 확인합니다. 그런 다음 리더 엔드포인트를 사용하는 동일한 명령으로 리더 엔드포인트에 대한 각 연결에 리더 인스턴스 중 하나(어느 것인지는 예측할 수 없음)가 사용되고 있음을 보여줍니다.

```
# Check lower_case_table_names setting on each reader instance.

$ mysql -h instance-5138.a12345.us-east-1.rds.amazonaws.com \
  -u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names'
+--------------------------+--------------------------+
| @@aurora_server_id       | @@lower_case_table_names |
+--------------------------+--------------------------+
| instance-5138            |                        1 |
+--------------------------+--------------------------+

$ mysql -h instance-2470.a12345.us-east-1.rds.amazonaws.com \
  -u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names'
+--------------------------+--------------------------+
| @@aurora_server_id       | @@lower_case_table_names |
+--------------------------+--------------------------+
| instance-2470            |                        1 |
+--------------------------+--------------------------+

# Check lower_case_table_names setting on the reader endpoint of the cluster.

$ mysql -h cluster-2393.cluster-ro-a12345.us-east-1.rds.amazonaws.com \
  -u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names'
+--------------------------+--------------------------+
| @@aurora_server_id       | @@lower_case_table_names |
+--------------------------+--------------------------+
| instance-5138            |                        1 |
+--------------------------+--------------------------+

# Run query on writer instance

$ mysql -h cluster-2393.cluster-a12345.us-east-1.rds.amazonaws.com \
  -u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names'
+--------------------------+--------------------------+
| @@aurora_server_id       | @@lower_case_table_names |
+--------------------------+--------------------------+
| instance-9404            |                        1 |
+--------------------------+--------------------------+
```

 파라미터 변경이 모든 위치에 적용되면 `lower_case_table_names=1` 설정의 효과를 확인할 수 있습니다. 테이블이 `foo`든, `Foo`든, `FOO`든 쿼리는 이 이름을 `foo`로 변환하고 모든 경우 동일한 테이블에 액세스합니다.

```
mysql> use lctn;

mysql> select * from foo;
+--------------------------+
| s                        |
+--------------------------+
| Lowercase table name foo |
+--------------------------+

mysql> select * from Foo;
+--------------------------+
| s                        |
+--------------------------+
| Lowercase table name foo |
+--------------------------+

mysql> select * from FOO;
+--------------------------+
| s                        |
+--------------------------+
| Lowercase table name foo |
+--------------------------+
```

# Amazon Aurora DB 클러스터 장애 조치
<a name="aurora-failover"></a>

예를 들어, 프로비저닝된 라이터 DB 인스턴스를 Aurora Serverless v2 라이터 인스턴스로 교체하려는 경우 Aurora DB 클러스터 장애 조치를 수동으로 수행할 수 있습니다.

Aurora는 다음 두 방법 중 하나를 사용하여 새 기본 DB 인스턴스로 장애 조치합니다.
+ 기존 리더 DB 인스턴스를 새 기본 인스턴스로 승격
+ 새로운 기본 인스턴스 만들기

DB 클러스터에 하나 이상의 리더 인스턴스가 있는 경우, 리더는 장애 이벤트 중에 기본 인스턴스로 승격됩니다. DB 클러스터의 가용성을 높이려면 최소 하나 이상의 리더 인스턴스를 둘 이상의 서로 다른 가용 영역에서 생성하는 것이 좋습니다. 장애 조치 메커니즘에 대한 자세한 내용은 [Aurora DB 클러스터의 내결함성](Concepts.AuroraHighAvailability.md#Aurora.Managing.FaultTolerance) 섹션을 참조하세요.

AWS Management Console, AWS CLI 또는 RDS API를 사용하여 수동 장애 조치를 수행할 수 있습니다.

## 콘솔
<a name="aurora-failover.CON"></a>

**DB 클러스터를 장애 조치하려면**

1. [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 AWS Management Console에 로그인한 후 Amazon RDS 콘솔을 엽니다.

1. 탐색 창에서 **데이터베이스**를 선택한 다음 DB 클러스터에서 장애 조치할 DB 인스턴스를 선택합니다.

1. **작업(Actions)**으로 **장애 조치(Failover)**를 선택합니다.

   확인 페이지가 표시됩니다.

1. **Failover**(장애 조치)를 선택합니다.

   **데이터베이스** 페이지에는 DB 클러스터 상태가 **장애 조치 중**으로 표시됩니다. 장애 조치가 완료되면 상태가 **사용 가능**으로 복귀하고 새 기본 DB 인스턴스와 이전 기본 DB 인스턴스의 역할이 표시됩니다.

## AWS CLI
<a name="aurora-failover.CLI"></a>

AWS CLI를 사용하여 DB 클러스터를 장애 조치하려면 [failover-db-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/failover-db-cluster.html) 명령을 직접 호출합니다. 다음 파라미터를 지정합니다.
+ `--db-cluster-identifier` – 장애 조치하려는 DB 클러스터
+ `--target-db-instance-identifier` – 기본 DB 인스턴스로 승격시킬 DB 인스턴스의 이름

**Example**  
대상 LinuxmacOS, 또는Unix:  

```
aws rds failover-db-cluster \
    --db-cluster-identifier mydbcluster \
    --target-db-instance-identifier mydbcluster-instance-2
```
Windows의 경우:  

```
aws rds failover-db-cluster ^
    --db-cluster-identifier mydbcluster ^
    --target-db-instance-identifier mydbcluster-instance-2
```

## RDS API
<a name="aurora-failover.API"></a>

Amazon RDS API를 사용하여 DB 클러스터를 수정하려면 [FailoverDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverDBCluster.html) 작업을 직접 호출합니다. 다음 파라미터를 지정합니다.
+ DBClusterIdentifier
+ TargetDBInstanceIdentifier

# Aurora DB 클러스터 및 DB 인스턴스 삭제
<a name="USER_DeleteCluster"></a>

Aurora DB 클러스터가 더 이상 필요하지 않은 경우 삭제할 수 있습니다. 클러스터를 삭제하면 데이터가 포함된 클러스터 볼륨이 제거됩니다. 클러스터를 삭제하기 전에 데이터의 스냅샷을 저장할 수 있습니다. 나중에 스냅샷을 복원하여 동일한 데이터가 포함된 새 클러스터를 만들 수 있습니다.

클러스터 자체와 클러스터에 포함된 데이터를 보존하면서 클러스터에서 DB 인스턴스를 삭제할 수도 있습니다. DB 인스턴스를 삭제하면 클러스터가 사용량이 많지 않거나 여러 DB 인스턴스의 계산 용량이 필요하지 않은 경우 요금을 줄일 수 있습니다.

**Topics**
+ [Aurora DB 클러스터 삭제](#USER_DeleteCluster.DeleteCluster)
+ [Aurora 클러스터의 삭제 방지](#USER_DeletionProtection)
+ [중지된 Aurora 클러스터 삭제](#USER_Deletion_Stopped_Cluster)
+ [읽기 전용 복제본인 Aurora MySQL 클러스터 삭제](#USER_DeleteInstance.AuroraReplica)
+ [클러스터를 삭제할 때의 최종 스냅샷](#USER_Deletion_Final_Snapshot)
+ [Aurora DB 클러스터에서 DB 인스턴스 삭제](#USER_DeleteInstance)

## Aurora DB 클러스터 삭제
<a name="USER_DeleteCluster.DeleteCluster"></a>

Aurora 는 DB 클러스터를 삭제하는 단일 단계 방법을 제공하지 않습니다. 이 설계는 실수로 데이터가 손실되거나 애플리케이션을 오프라인으로 전환하지 않도록 하기 위한 것입니다. Aurora 애플리케이션은 일반적으로 미션 크리티컬하며 고가용성이 필요합니다. 따라서 Aurora 에서는 DB 인스턴스를 추가 및 제거하여 클러스터 용량을 쉽게 확장하거나 축소할 수 있습니다. 그러나 클러스터 자체를 제거하려면 별도로 삭제해야 할 것이 있습니다.

클러스터에서 모든 DB 인스턴스를 제거한 다음 클러스터 자체를 삭제하려면 다음 일반 절차를 따르십시오.

1. 클러스터의 모든 판독기 인스턴스를 삭제합니다. [Aurora DB 클러스터에서 DB 인스턴스 삭제](#USER_DeleteInstance)의 절차를 따릅니다.

   클러스터에 리더 인스턴스가 있는 경우 인스턴스 중 하나를 삭제하면 해당 클러스터의 컴퓨팅 용량만 줄어듭니다. 읽기 장치 인스턴스를 먼저 삭제하면 절차 전체에서 클러스터가 사용 가능한 상태로 유지되고 불필요한 장애 조치 (failover) 작업이 수행되지 않습니다.

1. 클러스터에서 작성기 인스턴스를 삭제합니다. 다시 한 번, [Aurora DB 클러스터에서 DB 인스턴스 삭제](#USER_DeleteInstance)의 절차를 따릅니다.

    DB 인스턴스를 삭제하면 모든 DB 인스턴스를 삭제한 후에도 클러스터 및 연결된 클러스터 볼륨이 유지됩니다.

1. DB 클러스터를 삭제합니다.
   + **AWS Management Console** – 클러스터를 선택한 다음 **작업** 메뉴에서 **삭제**를 선택합니다. 나중에 필요할 경우에 대비하여 다음 옵션을 선택하여 클러스터의 데이터를 보존할 수 있습니다.
     + 클러스터 볼륨의 최종 스냅샷을 생성합니다. 기본 설정은 최종 스냅샷을 생성하는 것입니다.
     + 자동 백업을 보존합니다. 기본 설정은 자동 백업을 보존하지 않는 것입니다.
**참고**  
Aurora Serverless v1 DB 클러스터의 자동 백업은 유지되지 않습니다.

     또한 Aurora에서는 클러스터를 삭제할지 확인해야 합니다.
   + **CLI와 API** – `delete-db-cluster` CLI 명령 또는 `DeleteDBCluster` API 작업을 호출합니다. 나중에 필요할 경우에 대비하여 다음 옵션을 선택하여 클러스터의 데이터를 보존할 수 있습니다.
     + 클러스터 볼륨의 최종 스냅샷을 생성합니다.
     + 자동 백업을 보존합니다.
**참고**  
Aurora Serverless v1 DB 클러스터의 자동 백업은 유지되지 않습니다.

**Topics**
+ [빈 Aurora 클러스터 생성](#USER_DeleteInstance.Empty)
+ [단일 DB 인스턴스로 Aurora 클러스터 삭제](#USER_DeleteInstance.SingleInstance)
+ [여러 DB 인스턴스가 있는 Aurora 클러스터 삭제](#USER_DeleteInstance.MultipleInstances)

### 빈 Aurora 클러스터 생성
<a name="USER_DeleteInstance.Empty"></a>

AWS Management Console, AWS CLI 또는 Amazon RDS API를 사용해 빈 DB 클러스터를 삭제할 수 있습니다.

**작은 정보**  
DB 인스턴스가 없는 클러스터를 유지하여 클러스터에 CPU 요금이 부과되지 않고 데이터를 보존할 수 있습니다. 클러스터에 대해 하나 이상의 새 DB 인스턴스를 만들어 클러스터를 다시 빠르게 사용할 수 있습니다. 그러나 AWS CLI 또는 RDS API를 사용해야만 새 DB 인스턴스를 추가할 수 있습니다. Amazon RDS 콘솔을 사용하여 새 DB 인스턴스를 추가할 수 없습니다. 연결된 DB 인스턴스가 없는 상태에서 클러스터에서 Aurora특정 관리 작업을 수행할 수 있습니다. 데이터에 액세스하거나 DB 인스턴스에 연결해야 하는 작업은 수행할 수 없습니다.

#### 콘솔
<a name="delete-db-cluster.CON"></a>

**DB 클러스터를 삭제하는 방법**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.

1. 탐색 창에서 **데이터베이스**를 선택한 다음 삭제하려는 DB 클러스터를 선택합니다.

1. **작업**에 대해 **삭제**를 선택합니다.

1. DB 클러스터의 최종 DB 스냅샷을 생성하려면 **최종 스냅샷 생성**을 선택합니다. 이것이 기본 설정입니다.

1. 최종 스냅샷을 생성하도록 선택한 경우 **최종 스냅샷 이름**을 입력합니다.

1. 자동 백업을 보관하려면 **자동 백업 보관**을 선택합니다. 이것은 기본 설정이 아닙니다.

1. 상자에 **delete me**를 입력합니다.

1. **삭제**를 선택합니다.

#### CLI
<a name="delete-db-cluster.CLI"></a>

AWS CLI를 사용하여 빈 Aurora DB 클러스터를 삭제하려면 [delete-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-cluster.html) 명령을 호출합니다.

빈 클러스터는 개발 및 테스트에만 `deleteme-zero-instances` 사용되었으며 중요한 데이터가 포함되어 있지 않다고 가정합니다. 이 경우 클러스터를 삭제할 때 클러스터 볼륨의 스냅샷을 보존할 필요가 없습니다. 다음 예시에서는 클러스터에 DB 인스턴스가 포함되어 있지 않은 것을 보여준 다음 최종 스냅샷을 만들거나 자동 백업을 보존하지 않고 빈 클러스터를 삭제합니다.

```
$ aws rds describe-db-clusters --db-cluster-identifier deleteme-zero-instances --output text \
  --query '*[].["Cluster:",DBClusterIdentifier,DBClusterMembers[*].["Instance:",DBInstanceIdentifier,IsClusterWriter]]
Cluster:        deleteme-zero-instances

$ aws rds delete-db-cluster --db-cluster-identifier deleteme-zero-instances \
  --skip-final-snapshot \
  --delete-automated-backups
{
  "DBClusterIdentifier": "deleteme-zero-instances",
  "Status": "available",
  "Engine": "aurora-mysql"
}
```

#### RDS API
<a name="delete-db-cluster.API"></a>

Amazon RDS API를 사용하여 빈 Aurora DB 클러스터를 삭제하려면 [DeleteDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBCluster.html) 작업을 호출합니다.

### 단일 DB 인스턴스로 Aurora 클러스터 삭제
<a name="USER_DeleteInstance.SingleInstance"></a>

DB 클러스터에 삭제 방지 기능이 활성화된 경우에도 최근 DB 인스턴스를 삭제할 수 있습니다. 이 경우 DB 클러스터 자체는 여전히 존재하고 데이터는 보존됩니다. 새로운 DB 인스턴스를 클러스터에 연결하여 데이터에 다시 액세스할 수 있습니다.

다음 예제에서는 클러스터에 연결된 DB 인스턴스가 있는 경우 `delete-db-cluster` 명령이 작동하지 않는 방법을 보여 줍니다. 이 클러스터에는 단일 작성기 DB 인스턴스가 있습니다. 클러스터의 DB 인스턴스를 검사할 때 각 인스턴스의 `IsClusterWriter` 속성을 확인합니다. 클러스터에는 0개 또는 1개의 작성기 DB 인스턴스가 있을 수 있습니다. 값은 작성기 DB 인스턴스를 `true` 나타냅니다. 값은 읽기 DB 인스턴스를 `false` 나타냅니다. 클러스터에는 0, 1 또는 여러 개의 읽기 DB 인스턴스가 있을 수 있습니다. 이 경우 `delete-db-instance` 명령을 사용하여 작성기 DB 인스턴스를 삭제합니다. DB 인스턴스가 `deleting` 상태로 전환되는 즉시 클러스터도 삭제할 수 있습니다. 또한 이 예시에서는 클러스터에 보존할 가치가 있는 데이터가 없다고 가정합니다. 따라서 클러스터 볼륨의 스냅샷을 만들거나 자동 백업을 보존하지 않습니다.

```
$ aws rds delete-db-cluster --db-cluster-identifier deleteme-writer-only --skip-final-snapshot
An error occurred (InvalidDBClusterStateFault) when calling the DeleteDBCluster operation:
  Cluster cannot be deleted, it still contains DB instances in non-deleting state.

$ aws rds describe-db-clusters --db-cluster-identifier deleteme-writer-only \
  --query '*[].[DBClusterIdentifier,Status,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]'
[
    [
        "deleteme-writer-only",
        "available",
        [
            [
                "instance-2130",
                true
            ]
        ]
    ]
]

$ aws rds delete-db-instance --db-instance-identifier instance-2130
{
  "DBInstanceIdentifier": "instance-2130",
  "DBInstanceStatus": "deleting",
  "Engine": "aurora-mysql"
}

$ aws rds delete-db-cluster --db-cluster-identifier deleteme-writer-only \
  --skip-final-snapshot \
  --delete-automated-backups
{
  "DBClusterIdentifier": "deleteme-writer-only",
  "Status": "available",
  "Engine": "aurora-mysql"
}
```

### 여러 DB 인스턴스가 있는 Aurora 클러스터 삭제
<a name="USER_DeleteInstance.MultipleInstances"></a>

클러스터에 DB 인스턴스가 여러 개 포함되어 있는 경우 일반적으로 하나의 작성기 인스턴스와 하나 이상의 읽기 전용 인스턴스가 있습니다. 리더 인스턴스는 작성기 인스턴스에 문제가 발생할 경우 인수하기 위해 대기 상태에 있어 고가용성을 지원합니다. 읽기 전용 인스턴스를 사용하여 쓰기 인스턴스에 오버헤드를 추가하지 않고도 읽기 집약적인 워크로드를 처리할 수 있도록 클러스터를 확장할 수도 있습니다.

읽기 장치 DB 인스턴스가 여러 개인 클러스터를 삭제하려면 먼저 읽기 장치 인스턴스를 삭제한 다음 작성기 인스턴스를 삭제합니다. 라이터 인스턴스를 삭제하면 클러스터와 해당 데이터가 그대로 유지됩니다. 클러스터는 별도의 작업을 통해 삭제합니다.
+ Aurora DB 인스턴스를 삭제하는 절차는 섹션을 참조하십시오 [Aurora DB 클러스터에서 DB 인스턴스 삭제](#USER_DeleteInstance).
+ Aurora 클러스터에서 작성기 DB 인스턴스를 삭제하는 절차는 섹션을 참조하십시오 [단일 DB 인스턴스로 Aurora 클러스터 삭제](#USER_DeleteInstance.SingleInstance).
+ 빈 Aurora 클러스터를 삭제하는 절차는 섹션을 참조하십시오 [빈 Aurora 클러스터 생성](#USER_DeleteInstance.Empty).

이 CLI 예제에서는 라이터 DB 인스턴스와 단일 리더 DB 인스턴스가 모두 포함된 클러스터를 삭제하는 방법을 보여 줍니다. `describe-db-clusters` 출력은 `instance-7384` 이 작성기 `instance-1039` 인스턴스이며 읽기 인스턴스임을 보여 줍니다. 읽기 장치 인스턴스가 있는 동안 작성기 인스턴스를 삭제하면 장애 조치 (failover) 작업이 발생하기 때문에 이 예제에서는 읽기 전용 인스턴스를 먼저 삭제합니다. 해당 인스턴스도 삭제하려는 경우 읽기 인스턴스를 작성자로 승격하는 것은 의미가 없습니다. 이 경우에도 이러한 `db.t2.small` 인스턴스가 개발 및 테스트에만 사용되는 것으로 간주하고 삭제 작업이 최종 스냅샷을 건너뛰고 자동 백업을 보존하지 않습니다.

```
$ aws rds delete-db-cluster --db-cluster-identifier deleteme-writer-and-reader --skip-final-snapshot

An error occurred (InvalidDBClusterStateFault) when calling the DeleteDBCluster operation:
  Cluster cannot be deleted, it still contains DB instances in non-deleting state.

$ aws rds describe-db-clusters --db-cluster-identifier deleteme-writer-and-reader --output text \
  --query '*[].["Cluster:",DBClusterIdentifier,DBClusterMembers[*].["Instance:",DBInstanceIdentifier,IsClusterWriter]]
Cluster:        deleteme-writer-and-reader
Instance:       instance-1039  False
Instance:       instance-7384   True

$ aws rds delete-db-instance --db-instance-identifier instance-1039
{
  "DBInstanceIdentifier": "instance-1039",
  "DBInstanceStatus": "deleting",
  "Engine": "aurora-mysql"
}

$ aws rds delete-db-instance --db-instance-identifier instance-7384
{
  "DBInstanceIdentifier": "instance-7384",
  "DBInstanceStatus": "deleting",
  "Engine": "aurora-mysql"
}

$ aws rds delete-db-cluster --db-cluster-identifier deleteme-writer-and-reader \
  --skip-final-snapshot \
  --delete-automated-backups
{
  "DBClusterIdentifier": "deleteme-writer-and-reader",
  "Status": "available",
  "Engine": "aurora-mysql"
}
```

다음 예에서는 작성기 DB 인스턴스와 여러 읽기 장치 DB 인스턴스가 포함된 DB 클러스터를 삭제하는 방법을 보여 줍니다. 이 작가와 리더 인스턴스의 보고서를 얻기 위해 `describe-db-clusters` 명령에서 간결한 출력을 사용합니다. 다시 말하지만, 작성기 DB 인스턴스를 삭제하기 전에 모든 판독기 DB 인스턴스를 삭제합니다. 독자 DB 인스턴스를 삭제하는 순서는 중요하지 않습니다.

DB 인스턴스가 여러 개 있는 이 클러스터에 보존할 가치가 있는 데이터가 포함되어 있다고 가정합니다. 따라서 이 예제의 `delete-db-cluster` 명령에는 생성할 스냅샷의 세부 정보를 지정하는 `--no-skip-final-snapshot` 및 `--final-db-snapshot-identifier` 매개 변수가 포함됩니다. 여기에는 자동 백업을 보존하기 위한 `--no-delete-automated-backups` 파라미터도 포함됩니다.

```
$ aws rds describe-db-clusters --db-cluster-identifier deleteme-multiple-readers --output text \
  --query '*[].["Cluster:",DBClusterIdentifier,DBClusterMembers[*].["Instance:",DBInstanceIdentifier,IsClusterWriter]]
Cluster:        deleteme-multiple-readers
Instance:       instance-1010   False
Instance:       instance-5410   False
Instance:       instance-9948   False
Instance:       instance-8451   True

$ aws rds delete-db-instance --db-instance-identifier instance-1010
{
  "DBInstanceIdentifier": "instance-1010",
  "DBInstanceStatus": "deleting",
  "Engine": "aurora-mysql"
}

$ aws rds delete-db-instance --db-instance-identifier instance-5410
{
  "DBInstanceIdentifier": "instance-5410",
  "DBInstanceStatus": "deleting",
  "Engine": "aurora-mysql"
}

$ aws rds delete-db-instance --db-instance-identifier instance-9948
{
  "DBInstanceIdentifier": "instance-9948",
  "DBInstanceStatus": "deleting",
  "Engine": "aurora-mysql"
}

$ aws rds delete-db-instance --db-instance-identifier instance-8451
{
  "DBInstanceIdentifier": "instance-8451",
  "DBInstanceStatus": "deleting",
  "Engine": "aurora-mysql"
}

$ aws rds delete-db-cluster --db-cluster-identifier deleteme-multiple-readers \
  --no-delete-automated-backups \
  --no-skip-final-snapshot \
  --final-db-snapshot-identifier deleteme-multiple-readers-final-snapshot
{
  "DBClusterIdentifier": "deleteme-multiple-readers",
  "Status": "available",
  "Engine": "aurora-mysql"
}
```

 다음 예에서는 요청된 스냅샷이 Aurora 생성되었는지 확인하는 방법을 보여 줍니다. 식별자를 지정하여 특정 스냅샷에 대한 세부 정보를 요청할 수 `deleteme-multiple-readers-final-snapshot`있습니다. 클러스터 식별자를 지정하여 삭제된 클러스터의 모든 스냅샷에 대한 보고서를 가져올 수도 `deleteme-multiple-readers`있습니다. 두 명령 모두 동일한 스냅 샷에 대한 정보를 반환합니다.

```
$ aws rds describe-db-cluster-snapshots \
  --db-cluster-snapshot-identifier deleteme-multiple-readers-final-snapshot
{
    "DBClusterSnapshots": [
        {
            "AvailabilityZones": [],
            "DBClusterSnapshotIdentifier": "deleteme-multiple-readers-final-snapshot",
            "DBClusterIdentifier": "deleteme-multiple-readers",
            "SnapshotCreateTime": "11T01:40:07.354000+00:00",
            "Engine": "aurora-mysql",
...

$ aws rds describe-db-cluster-snapshots --db-cluster-identifier deleteme-multiple-readers
{
    "DBClusterSnapshots": [
        {
            "AvailabilityZones": [],
            "DBClusterSnapshotIdentifier": "deleteme-multiple-readers-final-snapshot",
            "DBClusterIdentifier": "deleteme-multiple-readers",
            "SnapshotCreateTime": "11T01:40:07.354000+00:00",
            "Engine": "aurora-mysql",
...
```

## Aurora 클러스터의 삭제 방지
<a name="USER_DeletionProtection"></a>

삭제 보호가 설정된 클러스터는 삭제할 수 없습니다. 클러스터 내에서 DB 인스턴스를 삭제할 수 있지만 클러스터 자체는 삭제할 수 없습니다. 이렇게 하면 모든 데이터가 포함된 클러스터 볼륨이 실수로 삭제되지 않습니다. Aurora는 콘솔, AWS CLI 또는 RDS API를 사용하여 클러스터를 삭제하려고 할 때 DB 클러스터에 대해 삭제 방지를 적용합니다.

AWS Management Console을 사용하여 프로덕션 DB 클러스터를 생성할 때 기본적으로 삭제 방지가 활성화됩니다. 하지만 AWS CLI 또는 API를 사용하여 클러스터를 생성하는 경우 삭제 방지가 기본적으로 비활성화됩니다. 삭제 보호를 활성화 또는 비활성화해도 중단이 발생하지 않습니다. 클러스터를 삭제하려면 클러스터를 수정하고 삭제 방지 기능을 비활성화합니다. 삭제 방지 활성화 및 비활성화에 대한 자세한 내용은 [콘솔, CLI, API를 사용하여 DB 클러스터 수정](Aurora.Modifying.md#Aurora.Modifying.Cluster) 섹션을 참조하십시오.

**작은 정보**  
모든 DB 인스턴스가 삭제되더라도 클러스터에 새 DB 인스턴스를 만들어 데이터에 액세스할 수 있습니다.

## 중지된 Aurora 클러스터 삭제
<a name="USER_Deletion_Stopped_Cluster"></a>

클러스터가 `stopped` 상태인 경우 삭제할 수 없습니다. 이 경우 클러스터를 삭제하기 전에 클러스터를 시작하십시오. 자세한 내용은 [Aurora DB 클러스터 시작](aurora-cluster-stop-start.md#aurora-cluster-start) 섹션을 참조하세요.

## 읽기 전용 복제본인 Aurora MySQL 클러스터 삭제
<a name="USER_DeleteInstance.AuroraReplica"></a>

Aurora MySQL에서는 다음 조건에 해당할 경우 DB 클러스터에서 DB 인스턴스를 삭제할 수 없습니다.
+ DB 클러스터는 다른 Aurora DB 클러스터의 읽기 전용 복제본입니다.
+ DB 인스턴스는 DB 클러스터의 유일한 인스턴스입니다.

이 경우 DB 인스턴스를 삭제하려면 더 이상 읽기 전용 복제본이 되지 않도록 먼저 DB 클러스터를 승격합니다. 승격이 완료된 후 DB 클러스터에서 최종 DB 인스턴스를 삭제할 수 있습니다. 자세한 내용은 [여러 AWS 리전에 걸쳐 Amazon Aurora MySQL DB 클러스터 복제](AuroraMySQL.Replication.CrossRegion.md) 섹션을 참조하세요.

## 클러스터를 삭제할 때의 최종 스냅샷
<a name="USER_Deletion_Final_Snapshot"></a>

이 섹션에서는 Aurora 클러스터를 삭제할 때 최종 스냅샷을 생성할지 여부를 선택하는 방법을 보여 줍니다. 최종 스냅샷을 생성하도록 선택했지만 지정한 이름이 기존 스냅샷과 일치하는 경우 작업이 중지되고 오류가 발생합니다. 이 경우 스냅샷 세부 정보를 검토하여 현재 세부 정보를 나타내는지 또는 이전 스냅샷인지 확인합니다. 기존 스냅샷에 보존할 최신 데이터가 없는 경우 스냅샷 이름을 변경하고 다시 시도하거나 **최종 스냅샷** 파라미터에 다른 이름을 지정하세요.

## Aurora DB 클러스터에서 DB 인스턴스 삭제
<a name="USER_DeleteInstance"></a>

전체 클러스터를 삭제하는 프로세스의 일부로 Aurora DB 클러스터에서 DB 인스턴스를 삭제할 수 있습니다. 클러스터에 특정 수의 DB 인스턴스가 포함되어 있는 경우 클러스터를 삭제하려면 각 DB 인스턴스를 삭제해야 합니다. 클러스터를 실행 중인 상태로 둔 상태에서 클러스터에서 하나 이상의 판독기 인스턴스를 삭제할 수도 있습니다. 클러스터가 사용량이 아닌 경우 계산 용량 및 관련 요금을 줄이기 위해 이렇게 할 수 있습니다.

DB 인스턴스를 삭제하려면 인스턴스의 이름을 지정합니다.

AWS Management Console, AWS CLI 또는 RDS API를 사용하여 DB 인스턴스를 삭제할 수 있습니다.

**참고**  
Aurora 복제본이 삭제되면 인스턴스 엔드포인트가 즉시 제거되고 Aurora 복제본이 리더 엔드포인트에서 제거됩니다. 삭제되는 Aurora 복제본을 실행하는 문이 있는 경우 3분의 유예 기간이 있습니다. 기존 문은 유예 기간 동안 완료할 수 있습니다. 유예 기간이 종료되면 Aurora 복제본이 종료 및 삭제됩니다.

Aurora DB 클러스터의 경우 DB 인스턴스를 삭제해도 전체 클러스터가 삭제되지는 않습니다. 클러스터가 사용 중이 아닐 때 Aurora 클러스터에서 DB 인스턴스를 삭제하여 컴퓨팅 파워와 관련 요금을 줄일 수 있습니다. DB 인스턴스가 하나 또는 DB 인스턴스가 0인 Aurora 클러스터의 특수한 상황에 대한 자세한 내용은 [단일 DB 인스턴스로 Aurora 클러스터 삭제](#USER_DeleteInstance.SingleInstance) 및 섹션을 참조하십시오 [빈 Aurora 클러스터 생성](#USER_DeleteInstance.Empty).

**참고**  
삭제 방지가 활성화된 DB 클러스터는 삭제할 수 없습니다. 자세한 내용은 [Aurora 클러스터의 삭제 방지](#USER_DeletionProtection) 섹션을 참조하세요.  
DB 클러스터를 수정하여 삭제 방지를 비활성화할 수 있습니다. 자세한 내용은 [Amazon Aurora DB 클러스터 수정](Aurora.Modifying.md) 섹션을 참조하세요.

### 콘솔
<a name="USER_DeleteInstance.CON"></a>

**DB 클러스터에서 DB 인스턴스를 삭제하는 방법**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.

1. 탐색 창에서 **데이터베이스**를 선택한 후 삭제하려는 DB 인스턴스를 선택합니다.

1. [** Actions**]에 대해 [**Delete**]를 선택합니다.

1. 상자에 **delete me**를 입력합니다.

1. **삭제**를 선택합니다.

### AWS CLI
<a name="USER_DeleteInstance.CLI"></a>

AWS CLI를 사용하여 DB 인스턴스를 삭제하려면 [delete-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-instance.html) 명령을 호출하고 `--db-instance-identifier` 값을 지정합니다.

**Example**  
대상 LinuxmacOS, 또는Unix:  

```
aws rds delete-db-instance \
    --db-instance-identifier mydbinstance
```
Windows의 경우:  

```
aws rds delete-db-instance ^
    --db-instance-identifier mydbinstance
```

### RDS API
<a name="USER_DeleteInstance.API"></a>

Amazon RDS API를 사용하여 DB 인스턴스를 삭제하려면 [DeleteDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBInstance.html) 작업을 호출하고 `DBInstanceIdentifier` 파라미터를 지정합니다.

**참고**  
 DB 인스턴스의 상태가 `deleting`인 경우 CA 인증서 값이 RDS 콘솔이나 AWS CLI 명령 또는 RDS API 작업의 출력에 나타나지 않습니다. CA 인증서에 대한 자세한 내용은 [SSL/TLS를 사용하여 DB 클러스터에 대한 연결 암호화](UsingWithRDS.SSL.md) 섹션을 참조하십시오.

# Amazon Aurora 및Amazon RDS 리소스에 태그 지정
<a name="USER_Tagging"></a><a name="tagging"></a>

Amazon RDS 태그는 사용자가 정의하고 DB 인스턴스 또는 DB 스냅샷과 같은 Amazon RDS 리소스와 연결하는 이름-값 페어입니다. 이 이름을 키라고 합니다. 원하는 경우 키에 값을 입력할 수 있습니다.

AWS Management Console, AWS CLI 또는 Amazon RDS API를 사용하여 Amazon RDS 리소스에서 태그를 추가, 나열 및 삭제할 수 있습니다. CLI 또는 API를 사용할 때 사용할 RDS 리소스에 대한 Amazon 리소스 이름(ARN)을 제공해야 합니다. ARN 생성에 대한 자세한 내용은 [Amazon RDS의 ARN 구성](USER_Tagging.ARN.Constructing.md) 주제섹션을 참조하십시오.

태그를 사용하여 Aurora 및 Amazon RDS 리소스에 메타데이터를 추가할 수 있습니다. 태그를 사용하여 데이터베이스 인스턴스, 스냅샷, Aurora 클러스터 등에 대한 고유한 표기법을 추가할 수 있습니다. 이렇게 하면 Aurora 및 Amazon RDS 리소스를 문서화하는 데 도움이 될 수 있습니다. 자동화된 유지 관리 절차와 함께 태그를 사용할 수도 있습니다.

 특히 이러한 태그를 IAM 정책에 사용할 수 있습니다. 태그를 사용하여 Aurora 및 Amazon RDS 리소스에 대한 액세스를 관리하고 해당 리소스에 적용 가능한 작업을 제어할 수 있습니다. 또한 비슷하게 태그가 지정된 리소스에 대한 비용을 그룹화하여 이러한 태그로 비용을 추적할 수 있습니다.

다음 Aurora 및 Amazon RDS 리소스에 태그를 지정할 수 있습니다.
+ DB 인스턴스
+ DB 클러스터
+ Aurora 글로벌 클러스터
+ DB 클러스터 엔드포인트
+ 읽기 전용 복제본
+ DB 스냅샷
+ DB 클러스터 스냅샷
+ 예약 DB 인스턴스
+ 이벤트 구독
+ DB 옵션 그룹
+ DB 파라미터 그룹
+ DB 클러스터 파라미터 그룹
+ DB 서브넷 그룹
+ RDS 프록시
+ RDS Proxy 엔드포인트
+ 블루/그린 배포
+ 제로 ETL 통합
+ 자동 백업
+ 클러스터 자동 백업

**참고**  
DB 인스턴스에 태그를 지정하면 Aurora는 연결된 Performance Insights 리소스에 해당 태그를 자동으로 적용합니다. 현재는 AWS Management Console을 사용하여 RDS 프록시 및 RDS 프록시 엔드포인트에 태그를 지정할 수 없습니다.

**Topics**
+ [Amazon RDS 리소스 태그를 사용하는 이유는 무엇인가요?](#Tagging.Purpose)
+ [Amazon RDS 리소스 태그 작동 방식](#Overview.Tagging)
+ [Amazon RDS 리소스에 태그를 지정하는 모범 사례](#Tagging.best-practices)
+ [DB 클러스터 스냅샷에 태그 복사](#USER_Tagging.CopyTagsCluster)
+ [자동 백업 리소스에 태그 지정](#USER_Tagging.AutomatedBackups)
+ [Amazon RDS에서 태그 추가 및 삭제](#Tagging.HowTo)
+ [자습서: 태그를 사용하여 중지할 Aurora DB 클러스터 지정](Tagging.Aurora.Autostop.md)

## Amazon RDS 리소스 태그를 사용하는 이유는 무엇인가요?
<a name="Tagging.Purpose"></a>

태그를 사용하여 다음을 수행할 수 있습니다.
+ 애플리케이션, 프로젝트, 부서, 환경 등을 기준으로 RDS 리소스를 분류하세요. 예를 들어 태그 키를 사용하여 범주를 정의하고 태그 값은 이 범주의 항목으로 정의할 수 있습니다. `environment=prod` 태그를 생성할 수도 있습니다. 또는 `project`의 태그 키와 `Salix`의 태그 값을 정의하여 Amazon RDS 리소스가 Salix 프로젝트에 할당되었음을 나타낼 수 있습니다.
+ 리소스 관리 작업을 자동화하세요. 예를 들어, `environment=prod` 태그가 지정된 인스턴스에 대한 유지 보수 창을 `environment=test` 태그가 지정된 인스턴스에 대한 창과 다르게 만들 수 있습니다. `environment=prod` 태그가 지정된 인스턴스에 대한 자동 DB 스냅샷을 구성할 수도 있습니다.
+ IAM 정책 내에서 RDS 리소스에 대한 액세스를 제어하세요. 전역 `aws:ResourceTag/tag-key` 조건 키를 사용하면 됩니다. 예를 들어, 정책에서 `DBAdmin` 그룹의 사용자만 `environment=prod` 태그가 지정된 DB 인스턴스를 수정하도록 허용할 수 있습니다. IAM 정책으로 태그가 지정된 리소스에 대한 액세스를 관리하는 방법에 대한 자세한 내용은 **AWS ID 및 액세스 관리 사용 설명서에서 [Amazon Aurora의 자격 증명 및 액세스 관리](UsingWithRDS.IAM.md) 및 [AWS에 대한 액세스 제어](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html#access_tags_control-resources)를 참조하세요.
+ 태그를 기반으로 리소스를 모니터링하세요. 예를 들어, `environment=prod` 태그가 지정된 DB 인스턴스에 대한 Amazon CloudWatch 대시보드를 만들 수 있습니다.
+ 유사하게 태그가 지정된 리소스에 대한 비용을 그룹화하여 비용을 추적하세요. 예를 들어, Salix 프로젝트와 관련된 RDS 리소스에 `project=Salix` 태그를 지정하면 이 프로젝트에 대한 비용 보고서를 생성하고 비용을 할당할 수 있습니다. 자세한 내용은 [Amazon RDS에서 태그와 함께 AWS 결제가 작동하는 방식](#Tagging.Billing) 섹션을 참조하세요.

## Amazon RDS 리소스 태그 작동 방식
<a name="Overview.Tagging"></a>

AWS은(는) 태그에 의미론적 의미를 적용하지 않습니다. 태그는 엄격히 문자열로 해석됩니다.

**Topics**
+ [Amazon RDS의 태그 세트](#Overview.Tagging.Sets)
+ [Amazon RDS의 태그 구조](#Overview.Tagging.Structure)
+ [태그 지정이 가능한 Amazon RDS 리소스](#Overview.Tagging.Resources)
+ [Amazon RDS에서 태그와 함께 AWS 결제가 작동하는 방식](#Tagging.Billing)

### Amazon RDS의 태그 세트
<a name="Overview.Tagging.Sets"></a>

모든 Amazon RDS 리소스에는 태그 세트라는 컨테이너가 있습니다. 컨테이너에는 리소스에 할당된 모든 태그가 포함됩니다. 리소스에는 정확히 하나의 태그 세트가 있습니다.

태그 세트 하나에는 0\$150개의 태그가 포함됩니다. 기존 리소스 태그와 키가 동일한 태그를 RDS 리소스에 추가하면 새 값이 이전 값을 덮어씁니다.

### Amazon RDS의 태그 구조
<a name="Overview.Tagging.Structure"></a>

RDS 태그의 구조는 다음과 같습니다

**태그 키**  
키는 태그의 필수 이름입니다. 문자열 값은 1\$1128자의 유니코드 문자 길이여야 하며 앞에 `aws:` 또는 `rds:` 접두사를 붙일 수 없습니다. 문자열에는 유니코드 문자, 숫자, 공백, `_`, `.`, `:`, `/`, `=`, `+`, `-` 및 `@`의 세트만 포함할 수 있습니다. Java 정규식은 `"^([\\p{L}\\p{Z}\\p{N}_.:/=+\\-@]*)$"`입니다. 태그 키는 대/소문자를 구분합니다. 따라서 `project`와 `Project`는 구별됩니다.  
키는 태그 세트에 고유합니다. 예를 들어, 태그 세트에 `project=Trinity`와 `project=Xanadu`처럼 키는 같지만 값은 다른 키-페어가 있을 수 없습니다.

**태그 값**  
값은 태그의 선택적 문자열 값입니다. 문자열 값은 1\$1256자의 유니코드 문자여야 합니다. 문자열에는 유니코드 문자, 숫자, 공백, `_`, `.`, `:`, `/`, `=`, `+`, `-` 및 `@`의 세트만 포함할 수 있습니다. Java 정규식은 `"^([\\p{L}\\p{Z}\\p{N}_.:/=+\\-@]*)$"`입니다. 태그 값은 대소문자를 구분합니다. 따라서 `prod` 값과 `Prod`은 구별됩니다.  
태그 세트에서 값이 고유할 필요는 없으며 null일 수도 있습니다. 예를 들어 `project=Trinity` 및 `cost-center=Trinity`의 태그 세트에 키-값 페어가 있을 수 있습니다.

### 태그 지정이 가능한 Amazon RDS 리소스
<a name="Overview.Tagging.Resources"></a>

다음 Amazon RDS 리소스에 태그를 지정할 수 있습니다.
+ DB 인스턴스
+ DB 클러스터
+ DB 클러스터 엔드포인트
+ 읽기 전용 복제본
+ DB 스냅샷
+ DB 클러스터 스냅샷
+ 예약 DB 인스턴스
+ 이벤트 구독
+ DB 옵션 그룹
+ DB 파라미터 그룹
+ DB 클러스터 파라미터 그룹
+ DB 서브넷 그룹
+ RDS 프록시
+ RDS Proxy 엔드포인트
**참고**  
현재는 AWS Management Console을 사용하여 RDS 프록시 및 RDS 프록시 엔드포인트에 태그를 지정할 수 없습니다.
+ 블루/그린 배포
+ 제로 ETL 통합(미리 보기)
+ 자동 백업
+ 클러스터 자동 백업

### Amazon RDS에서 태그와 함께 AWS 결제가 작동하는 방식
<a name="Tagging.Billing"></a>

태그를 사용하여 비용 구조를 반영하도록 AWS 청구서를 구성합니다. 이렇게 하려면 가입하여 태그 키 값이 포함된 AWS 계정 청구서를 가져옵니다. 그런 다음 같은 태그 키 값을 가진 리소스에 따라 결제 정보를 구성하여 리소스 비용의 합을 볼 수 있습니다. 예를 들어, 특정 애플리케이션 이름으로 여러 리소스에 태그를 지정한 다음 결제 정보를 구성하여 여러 서비스에 걸친 해당 애플리케이션의 총 비용을 볼 수 있습니다. 자세한 내용은 *AWS Billing 사용 설명서*의 [비용 할당 태그 사용](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)을 참조하십시오.

#### 비용 할당 태그가 DB 클러스터 스냅샷에서 작동하는 방식
<a name="Tagging.Billing.Snapshots"></a>

DB 클러스터 스냅샷에 태그를 추가할 수 있습니다. 그러나 청구서에는 이러한 그룹화가 반영되지 않습니다. 비용 할당 태그를 DB 클러스터 스냅샷에 적용하려면 다음 조건을 충족해야 합니다.
+ 태그가 상위 DB 인스턴스에 연결되어 있어야 합니다.
+ 상위 DB 인스턴스가 DB 클러스터 스냅샷과 동일한 AWS 계정 계정에 존재해야 합니다.
+ 상위 DB 인스턴스가 DB 클러스터 스냅샷과 동일한 AWS 리전 계정에 존재해야 합니다.

DB 클러스터 스냅샷이 상위 DB 인스턴스와 동일한 리전에 존재하지 않거나 상위 DB 인스턴스가 삭제된 경우 분리된 것으로 간주됩니다. 분리된 DB 스냅샷은 비용 할당 태그를 지원하지 않습니다. 분리된 스냅샷에 대한 비용은 태그가 지정되지 않은 품목에 집계됩니다. 다음 조건을 충족하는 경우 크로스 계정 DB 클러스터 스냅샷은 분리된 것으로 간주되지 않습니다.
+ 상위 DB 인스턴스와 동일한 리전에 있어야 합니다.
+ 상위 DB 인스턴스는 소스 계정에서 소유합니다.
**참고**  
상위 DB 인스턴스가 다른 계정에서 소유하고 있는 경우, 대상 계정의 크로스 계정 스냅샷에는 비용 할당 태그가 적용되지 않습니다.

## Amazon RDS 리소스에 태그를 지정하는 모범 사례
<a name="Tagging.best-practices"></a>

태그를 사용할 때는 다음 모범 사례를 준수하는 것이 좋습니다.
+ 조직의 모든 팀이 따르는 태그 사용 규칙을 문서화하세요. 특히 이름을 설명적이면서도 일관성 있게 지어야 합니다. 예를 들어 일부 리소스에 `env:production`으로 태그를 지정하는 대신 `environment:prod` 형식으로 표준화하세요.
**중요**  
개인 식별 정보(PII)나 기타 기밀 정보 또는 민감한 정보를 태그에 저장하지 마세요.
+ 태그 지정을 자동화하여 일관성을 보장하세요. 예를 들어 다음과 같은 기술을 사용할 수 있습니다.
  + CloudFormation 템플릿에 태그를 포함하세요. 템플릿으로 리소스를 만들면 리소스에 자동으로 태그가 지정됩니다.
  + AWS Lambda 함수를 사용하여 태그를 정의하고 적용하세요.
  + RDS 리소스에 태그를 추가하는 단계가 포함된 SSM 문서를 생성하세요.
+ 필요한 경우에만 태그를 사용하세요. 단일 RDS 리소스에 대해 최대 50개의 태그를 추가할 수 있지만, 불필요한 태그의 증가와 복잡성을 피하는 것이 가장 좋습니다.
+ 태그의 관련성과 정확성을 정기적으로 검토하세요. 필요에 따라 오래된 태그를 제거하거나 수정하세요.
+ AWS Management Console의 AWS Tag Editor를 사용하여 태그를 생성해 보세요. Tag Editor를 사용하여 RDS 리소스를 포함하여 지원되는 여러 AWS 리소스에 동시에 태그를 추가할 수 있습니다. 자세한 내용은 **AWS 리소스 그룹 사용 설명서의 [Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html)를 참조하세요.

## DB 클러스터 스냅샷에 태그 복사
<a name="USER_Tagging.CopyTagsCluster"></a>

DB 클러스터를 생성하거나 복원할 때 DB 클러스터의 태그가 클러스터의 스냅샷에 복사되도록 지정할 수 있습니다. 태그를 복사하면 DB 스냅샷의 메타데이터가 원본 DB 클러스터의 메타데이터와 일치하게 됩니다. DB 스냅샷의 액세스 정책 또한 원본 DB 클러스터의 액세스 정책과 같아집니다. 태그는 기본적으로 복사되지 않습니다.

다음 작업 시 DB 스냅샷으로 태그를 복사하도록 지정할 수 있습니다.
+ DB 클러스터 생성
+ DB 클러스터 복원
+ 읽기 전용 복제본 생성
+ DB 클러스터 스냅샷 복사

**참고**  
경우에 따라 [create-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-snapshot.html) AWS CLI 명령의 `--tags` 파라미터 값을 포함할 수 있습니다. 또는 [CreateDBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBSnapshot.html) API 작업에 하나 이상의 태그를 제공할 수도 있습니다. 이러한 경우 RDS는 원본 DB 인스턴스에서 새 DB 스냅샷으로 태그를 복사하지 않습니다. 이 기능은 원본 DB 인스턴스에 `--copy-tags-to-snapshot`(`CopyTagsToSnapshot`) 옵션이 활성화되어 있어도 적용됩니다.  
이 방법을 사용할 경우 DB 스냅샷에서 DB 인스턴스의 복사본을 생성할 수 있습니다. 이 접근 방식을 사용하면 새 DB 인스턴스에 적용되지 않는 태그를 추가하는 것을 피할 수 있습니다. AWS CLI `create-db-snapshot` 명령(또는 `CreateDBSnapshot` RDS API 작업)을 사용하여 DB 스냅샷을 생성합니다. DB 스냅샷을 생성한 후 이 주제의 뒷부분에서 설명된 대로 태그를 추가할 수 있습니다.

## 자동 백업 리소스에 태그 지정
<a name="USER_Tagging.AutomatedBackups"></a>

자동 백업 리소스는 백업 보존 기간 값을 0에서 0보다 크게 설정할 때 생성됩니다. `--tag-specifications` 파라미터를 사용하여 생성 중에 인스턴스 또는 클러스터 자동 백업 리소스에 태그를 지정할 수 있습니다.

### 태그 지정 파라미터
<a name="USER_Tagging.AutomatedBackups.TagSpecifications"></a>

`--tag-specifications` 요청 파라미터(예: [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html), [restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html), [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) 등)를 지원하는 API는 생성 중에 자동 백업(리소스 유형: `auto-backup` 또는 `cluster-auto-backup`)에 태그를 지정할 수 있습니다.

#### 클러스터 자동 백업에 태그 지정
<a name="USER_Tagging.AutomatedBackups.TagSpecifications.Cluster"></a>

자동 백업이 활성화된 DB 클러스터를 생성할 때 `ResourceType=cluster-auto-backup`과 함께 `--tag-specifications`를 사용합니다.

**참고**  
자동 백업 태그는 소스 DB 인스턴스 태그, DB 클러스터 태그 또는 DB 스냅샷 태그와 독립적입니다.

## Amazon RDS에서 태그 추가 및 삭제
<a name="Tagging.HowTo"></a>

다음을 수행할 수 있습니다.
+ 리소스를 생성할 때 태그를 생성합니다(예: AWS CLI 명령 `create-db-instance`를 실행할 때).
+ `add-tags-to-resource` 명령을 사용하여 기존 리소스에 태그를 추가합니다.
+ `list-tags-for-resource` 명령을 사용하여 특정 리소스와 연결된 태그를 나열합니다.
+ `add-tags-to-resource` 명령을 사용하여 태그를 업데이트합니다.
+ `remove-tags-from-resource` 명령을 사용하여 리소스에서 태그를 제거합니다.

다음 절차에서는 DB 인스턴스 및 Aurora DB 클러스터와 관련된 리소스에 대해 일반적인 태그 지정 작업을 수행하는 방법을 설명합니다. 권한 부여 목적으로 태그가 캐시됩니다. 이러한 이유로 Amazon RDS 리소스에서 태그를 추가하거나 업데이트할 때 수정 사항을 사용할 수 있기까지 몇 분이 걸릴 수 있습니다.

### 콘솔
<a name="USER_Tagging.CON"></a>

Amazon RDS 리소스에 태그를 지정하는 프로세스는 모든 리소스에서 비슷합니다. 다음 절차에서는 Amazon RDS DB 인스턴스에 태그를 지정하는 방법을 보여줍니다.

**DB 인스턴스에 태그를 추가하려면**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.

1. 탐색 창에서 **데이터베이스**를 선택합니다.
**참고**  
DB 인스턴스 목록을 필터링하려면 **데이터베이스** 창의 **Filter databases(데이터베이스 필터링)**에 텍스트 문자열을 입력합니다. 해당 문자열을 포함하는 DB 인스턴스만 표시됩니다.

1. 세부 정보를 보기 위해 태그 지정하려는 DB 인스턴스의 이름을 선택합니다.

1. 세부 정보 섹션에서 아래에 있는 **태그** 섹션으로 스크롤합니다.

1. [**추가**]를 선택합니다. **태그 추가** 창이 나타납니다.  
![\[태그 추가 창\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/RDSConsoleTagging5.png)

1. **태그 키**와 **값**에 값을 입력합니다.

1. 다른 태그를 추가하려면 **다른 태그 추가**를 선택하고 **태그 키**와 **값**에 값을 입력합니다.

   이 단계를 필요한 만큼 반복합니다.

1. [**추가**]를 선택합니다.

**DB 인스턴스에서 태그를 삭제하려면**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.

1. 탐색 창에서 **데이터베이스**를 선택합니다.
**참고**  
DB 인스턴스 목록을 필터링하려면 **데이터베이스** 창의 **Filter databases(데이터베이스 필터링)** 상자에 텍스트 문자열을 입력합니다. 해당 문자열을 포함하는 DB 인스턴스만 표시됩니다.

1. 세부 정보를 표시할 DB 인스턴스의 이름을 선택합니다.

1. 세부 정보 섹션에서 아래에 있는 **태그** 섹션으로 스크롤합니다.

1. 삭제하려는 태그를 선택합니다.  
![\[태그 섹션\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/RDSConsoleTagging6.png)

1. **Delete(삭제)**를 선택한 다음 **Delete tags(삭제 태그)**창에서 **Delete(삭제)**를 선택합니다.

### AWS CLI
<a name="USER_Tagging.CLI"></a>

AWS CLI 사용을 통해 DB 인스턴스에 대한 태그를 추가, 나열 또는 제거할 수 있습니다.
+ Amazon RDS 리소스에 하나 이상의 태그를 추가하려면 AWS CLI 명령 [https://docs.aws.amazon.com/cli/latest/reference/rds/add-tags-to-resource.html](https://docs.aws.amazon.com/cli/latest/reference/rds/add-tags-to-resource.html)를 사용합니다.
+ Amazon RDS 리소스의 태그를 나열하려면 AWS CLI 명령 [https://docs.aws.amazon.com/cli/latest/reference/rds/list-tags-for-resource.html](https://docs.aws.amazon.com/cli/latest/reference/rds/list-tags-for-resource.html)를 사용합니다.
+ Amazon RDS 리소스에서 하나 이상의 태그를 삭제하려면 AWS CLI 명령 [https://docs.aws.amazon.com/cli/latest/reference/rds/remove-tags-from-resource.html](https://docs.aws.amazon.com/cli/latest/reference/rds/remove-tags-from-resource.html)를 사용합니다.

필수 ARN을 생성하는 방법에 대해 자세히 알아보려면 [Amazon RDS의 ARN 구성](USER_Tagging.ARN.Constructing.md) 섹션을 참조하십시오.

### RDS API
<a name="USER_Tagging.API"></a>

Amazon RDS API를 사용하여 DB 인스턴스에 대한 태그를 추가, 나열 또는 제거할 수 있습니다.
+ Amazon RDS 리소스에 태그를 추가하려면 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_AddTagsToResource.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_AddTagsToResource.html) 작업을 사용합니다.
+ Amazon RDS 리소스에 배정된 태그를 나열하려면 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ListTagsForResource.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ListTagsForResource.html)를 사용합니다.
+ Amazon RDS 리소스에서 태그를 제거하려면 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RemoveTagsFromResource.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RemoveTagsFromResource.html) 작업을 사용합니다.

필수 ARN을 생성하는 방법에 대해 자세히 알아보려면 [Amazon RDS의 ARN 구성](USER_Tagging.ARN.Constructing.md) 섹션을 참조하십시오.

Amazon RDS API를 사용한 XML 작업 시 다음 스키마를 사용하십시오.

```
 1. <Tagging>
 2.       <TagSet>
 3.           <Tag>
 4.               <Key>Project</Key>
 5.               <Value>Trinity</Value>
 6.           </Tag>
 7.           <Tag>
 8.               <Key>User</Key>
 9.               <Value>Jones</Value>
10.           </Tag>
11.       </TagSet>
12.   </Tagging>
```

다음 표에는 허용되는 XML 태그와 해당 특성의 목록이 나와 있습니다. `Key`와 `Value`은 대/소문자를 구분합니다. 예를 들어 `project=Trinity`와 `PROJECT=Trinity`는 서로 다른 태그입니다.


****  
<a name="user-tag-reference"></a>[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/USER_Tagging.html)

# 자습서: 태그를 사용하여 중지할 Aurora DB 클러스터 지정
<a name="Tagging.Aurora.Autostop"></a>

 개발 환경이나 테스트 환경에서 여러 Aurora DB 클러스터를 생성한다고 가정합니다. 며칠 동안 이러한 클러스터를 모두 유지해야 합니다. 어떤 클러스터는 밤새 테스트를 실행합니다. 또 다른 클러스터는 밤새 중단하고 다음 날 다시 시작할 수 있습니다. 다음 예제에서는 밤새 중단하기에 적합한 클러스터에 태그를 할당하는 방법을 보여줍니다. 그런 다음 이 예제에서는 스크립트가 해당 태그가 있는 클러스터를 감지한 후 해당 클러스터를 중지하는 방법을 보여줍니다. 이 예제에서 키-값 쌍의 값 부분은 중요하지 않습니다. `stoppable` 태그가 있다는 것은 클러스터에 이 사용자 정의 속성이 있음을 의미합니다.

**중지할 Aurora DB 클러스터를 지정하려면**

1. 중지 가능으로 지정하려는 클러스터의 ARN을 결정합니다.

   태그 지정을 위한 명령 및 API는 ARN과 함께 작동합니다. 이렇게 하면 AWS 리전, AWS 계정 및 동일한 짧은 이름을 가질 수 있는 다양한 유형의 리소스 간에 원활하게 작동할 수 있습니다. 클러스터에서 작동하는 CLI 명령에서 클러스터 ID 대신 ARN을 지정할 수 있습니다. 사용자 클러스터의 이름을 *dev-test-cluster*로 대체합니다. ARN 파라미터를 사용하는 후속 명령에서, 사용자 클러스터의 ARN을 대체합니다. ARN에는 사용자의 AWS 계정 ID와 클러스터가 위치한 AWS 리전의 이름이 포함되어 있습니다.

   ```
   $ aws rds describe-db-clusters --db-cluster-identifier dev-test-cluster \
     --query "*[].{DBClusterArn:DBClusterArn}" --output text
   arn:aws:rds:us-east-1:123456789:cluster:dev-test-cluster
   ```

1. `stoppable` 태그를 이 클러스터에 추가합니다.

   이 태그의 이름은 사용자가 선택합니다. 이 방법을 사용하면 모든 관련 정보를 이름에 인코딩하는 명명 규칙을 만드는 것을 피할 수 있습니다. 이러한 규칙 하에서는 DB 인스턴스 이름 또는 다른 리소스의 이름에 정보를 인코딩할 수 있습니다. 이 예제에서는 태그를 있거나 없는 속성으로 취급하기 때문에 `Value=` 파라미터의 `--tags` 일부를 생략합니다.

   ```
   $ aws rds add-tags-to-resource \
     --resource-name arn:aws:rds:us-east-1:123456789:cluster:dev-test-cluster \
     --tags Key=stoppable
   ```

1. 태그가 클러스터에 있는지 확인합니다.

   이러한 명령은 클러스터에 대한 태그 정보를 JSON 형식 및 탭으로 구분된 일반 텍스트로 검색합니다.

   ```
   $ aws rds list-tags-for-resource \
     --resource-name arn:aws:rds:us-east-1:123456789:cluster:dev-test-cluster 
   {
       "TagList": [
           {
               "Key": "stoppable",
               "Value": ""
   
           }
       ]
   }
   $ aws rds list-tags-for-resource \
     --resource-name arn:aws:rds:us-east-1:123456789:cluster:dev-test-cluster --output text
   TAGLIST stoppable
   ```

1. `stoppable`(으)로 지정된 모든 클러스터를 중지하려면 모든 클러스터 목록을 준비합니다. 목록을 반복하고 각 클러스터에 관련 속성으로 태그가 지정되어 있는지 확인합니다.

   이 Linux 예제에서는 셸 스크립팅을 사용하여 클러스터 ARN 목록을 임시 파일에 저장한 후 각 클러스터에 대해 CLI 명령을 수행합니다.

   ```
   $ aws rds describe-db-clusters --query "*[].[DBClusterArn]" --output text >/tmp/cluster_arns.lst
   $ for arn in $(cat /tmp/cluster_arns.lst)
   do
     match="$(aws rds list-tags-for-resource --resource-name $arn --output text | grep 'TAGLIST\tstoppable')"
     if [[ ! -z "$match" ]]
     then
         echo "Cluster $arn is tagged as stoppable. Stopping it now."
   # Note that you can specify the full ARN value as the parameter instead of the short ID 'dev-test-cluster'.
         aws rds stop-db-cluster --db-cluster-identifier $arn
     fi
   done
   
   Cluster arn:aws:rds:us-east-1:123456789:cluster:dev-test-cluster is tagged as stoppable. Stopping it now.
   {
       "DBCluster": {
           "AllocatedStorage": 1,
           "AvailabilityZones": [
               "us-east-1e",
               "us-east-1c",
               "us-east-1d"
           ],
           "BackupRetentionPeriod": 1,
           "DBClusterIdentifier": "dev-test-cluster",
           ...
   ```

 매일 일과가 끝날 때 이와 같은 스크립트를 실행하여 불필요한 클러스터가 중지되도록 할 수 있습니다. 매일 밤 이러한 검사를 수행하기 위해 `cron` 등의 유틸리티를 사용하여 작업을 예약할 수도 있습니다. 예를 들어, 일부 클러스터가 실수로 실행 중으로 남아 있지 않도록 하려면 검사를 예약하면 됩니다. 이때 검사할 클러스터 목록을 준비하는 명령을 세부 조정할 수 있습니다.

다음 명령은 클러스터 목록을 생성하지만 `available` 상태에 있는 클러스터만 생성합니다. 스크립트는 이미 중지된 클러스터를 무시할 수 있습니다. 이러한 클러스터는 `stopped` 또는 `stopping` 등 상태 값이 다르기 때문입니다.

```
$ aws rds describe-db-clusters \
  --query '*[].{DBClusterArn:DBClusterArn,Status:Status}|[?Status == `available`]|[].{DBClusterArn:DBClusterArn}' \
  --output text
arn:aws:rds:us-east-1:123456789:cluster:cluster-2447
arn:aws:rds:us-east-1:123456789:cluster:cluster-3395
arn:aws:rds:us-east-1:123456789:cluster:dev-test-cluster
arn:aws:rds:us-east-1:123456789:cluster:pg2-cluster
```

**작은 정보**  
태그를 할당하고 해당 태그가 있는 클러스터를 찾는 기능을 사용하여 다른 방법으로 비용을 줄일 수 있습니다. 개발 및 테스트에 사용되는 Aurora DB 클러스터를 예로 들어 보겠습니다. 여기서 일과가 끝날 때 일부 클러스터를 삭제하도록 지정하거나 해당 클러스터의 리더 DB 인스턴스만 삭제하도록 지정할 수도 있습니다. 또는 사용량이 낮을 것으로 예상되는 시기에 DB 인스턴스를 소규모 DB 인스턴스 클래스로 변경하도록 지정할 수 있습니다.

# Amazon RDS의 Amazon 리소스 이름(ARN)
<a name="USER_Tagging.ARN"></a>

Amazon Web Services에 생성되는 리소스는 각기 고유한 Amazon 리소스 이름(ARN)으로 식별됩니다. 특정 Amazon RDS 작업에서는 ARN을 지정하여 Amazon RDS 리소스를 고유한 이름으로 식별해야 합니다. 예를 들어, RDS DB 인스턴스 읽기 전용 복제본을 생성할 때 원본 DB 인스턴스에 대한 ARN을 제공해야 합니다.

ARN 구성 및 기존 ARN 가져오기에 대한 자세한 내용은 아래의 주제를 참조하세요.

**Topics**
+ [Amazon RDS의 ARN 구성](USER_Tagging.ARN.Constructing.md)
+ [Amazon RDS의 기존 ARN 가져오기](USER_Tagging.ARN.Getting.md)

# Amazon RDS의 ARN 구성
<a name="USER_Tagging.ARN.Constructing"></a>

Amazon Web Services에 생성되는 리소스는 각기 고유한 Amazon 리소스 이름(ARN)으로 식별됩니다. 다음 구문을 사용하여 Amazon RDS 리소스에 대한 ARN을 생성할 수 있습니다.

 `arn:aws:rds:<region>:<account number>:<resourcetype>:<name>` 

글로벌 클러스터 리소스의 경우 ARN에는 `arn:aws:rds::<account number>:global-cluster:<name>`의 AWS 리전이 포함되지 않습니다. 글로벌 클러스터의 ARN은 AWS Management Console에 표시되지 않습니다.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/USER_Tagging.ARN.Constructing.html)

다음 표에는 특정 Amazon RDS 리소스 유형에 대한 ARN 생성 시 사용해야 하는 형식이 나와 있습니다.


****  

| 리소스 유형 | ARN 형식 | 
| --- | --- | 
| DB 인스턴스  |  arn:aws:rds:*<region>*:*<account>*:db:*<name>* 예: <pre>arn:aws:rds:us-east-2:123456789012:db:my-mysql-instance-1</pre>  | 
| DB 클러스터 |  arn:aws:rds:*<region>*:*<account>*:cluster:*<name>* 예: <pre>arn:aws:rds:us-east-2:123456789012:cluster:my-aurora-cluster-1</pre>  | 
| 이벤트 구독  |  arn:aws:rds:*<region>*:*<account>*:es:*<name>* 예: <pre>arn:aws:rds:us-east-2:123456789012:es:my-subscription</pre>  | 
| DB 파라미터 그룹  |  arn:aws:rds:*<region>*:*<account>*:pg:*<name>* 예: <pre>arn:aws:rds:us-east-2:123456789012:pg:my-param-enable-logs</pre>  | 
| DB 클러스터 파라미터 그룹  |  arn:aws:rds:*<region>*:*<account>*:cluster-pg:*<name>* 예: <pre>arn:aws:rds:us-east-2:123456789012:cluster-pg:my-cluster-param-timezone</pre>  | 
| 예약 DB 인스턴스  |  arn:aws:rds:*<region>*:*<account>*:ri:*<name>* 예: <pre>arn:aws:rds:us-east-2:123456789012:ri:my-reserved-postgresql</pre>  | 
| DB 보안 그룹  |  arn:aws:rds:*<region>*:*<account>*:secgrp:*<name>* 예: <pre>arn:aws:rds:us-east-2:123456789012:secgrp:my-public</pre>  | 
| 자동화된 DB 스냅샷 |  arn:aws:rds:*<region>*:*<account>*:snapshot:rds:*<name>* 예: <pre>arn:aws:rds:us-east-2:123456789012:snapshot:rds:my-mysql-db-2019-07-22-07-23</pre>  | 
| 자동화된 DB 클러스터 스냅샷 |  arn:aws:rds:*<region>*:*<account>*:cluster-snapshot:rds:*<name>* 예: <pre>arn:aws:rds:us-east-2:123456789012:cluster-snapshot:rds:my-aurora-cluster-2019-07-22-16-16</pre>  | 
| 수동 DB 스냅샷 |  arn:aws:rds:*<region>*:*<account>*:snapshot:*<name>* 예: <pre>arn:aws:rds:us-east-2:123456789012:snapshot:my-mysql-db-snap</pre>  | 
| 수동 DB 클러스터 스냅샷 |  arn:aws:rds:*<region>*:*<account>*:cluster-snapshot:*<name>* 예: <pre>arn:aws:rds:us-east-2:123456789012:cluster-snapshot:my-aurora-cluster-snap</pre>  | 
| DB 서브넷 그룹 |  arn:aws:rds:*<region>*:*<account>*:subgrp:*<name>* 예제: <pre>arn:aws:rds:us-east-2:123456789012:subgrp:my-subnet-10</pre>  | 
| 글로벌 클러스터 |  arn:aws:rds::*<account>*:global-cluster:*<name>* 예제: <pre>arn:aws:rds::123456789012:global-cluster:my-aurora-global-cluster-1</pre>  | 

# Amazon RDS의 기존 ARN 가져오기
<a name="USER_Tagging.ARN.Getting"></a>

AWS Management Console, AWS Command Line Interface(AWS CLI) 또는 RDS API를 사용해 RDS 리소스에 대한 ARN을 가져올 수 있습니다.

## 콘솔
<a name="USER_Tagging.ARN.CON"></a>

AWS Management Console에서 ARN을 확인하려면 ARN을 보려는 리소스를 탐색하거나, 해당 리소스의 세부 정보를 확인합니다.

예를 들어, DB 클러스터 세부 정보의 **구성** 탭에서 DB 클러스터의 ARN을 가져올 수 있습니다.

![\[DB 클러스터 ARN.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/DB-cluster-arn.png)


## AWS CLI
<a name="USER_Tagging.ARN.CLI"></a>

AWS CLI에서 특정 RDS 리소스에 대한 ARN을 가져오려면 해당 리소스에 `describe` 명령을 사용합니다. 다음 표에서는 각 AWS CLI ARN 명령, 그리고 ARN을 가져오기 위해 명령과 함께 사용하는 ARN 속성을 보여 줍니다.


****  
<a name="cli-command-arn-property"></a>[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/USER_Tagging.ARN.Getting.html)

예를 들어, 다음 AWS CLI 명령은 DB 인스턴스에 대한 ARN을 가져옵니다.

**Example**  
대상 LinuxmacOS, 또는Unix:  

```
aws rds describe-db-instances \
--db-instance-identifier DBInstanceIdentifier \
--region us-west-2 \
--query "*[].{DBInstanceIdentifier:DBInstanceIdentifier,DBInstanceArn:DBInstanceArn}"
```
Windows의 경우:  

```
aws rds describe-db-instances ^
--db-instance-identifier DBInstanceIdentifier ^
--region us-west-2 ^
--query "*[].{DBInstanceIdentifier:DBInstanceIdentifier,DBInstanceArn:DBInstanceArn}"
```
이 명령의 출력은 다음과 같습니다.  

```
[
    {
        "DBInstanceArn": "arn:aws:rds:us-west-2:account_id:db:instance_id", 
        "DBInstanceIdentifier": "instance_id"
    }
]
```

## RDS API
<a name="USER_Tagging.ARN.API"></a>

특정 RDS 리소스에 대한 ARN을 확인하기 위해 다음과 같이 RDS API 작업을 호출하고 ARN 속성을 사용할 수 있습니다.


****  
<a name="rds-operation-arn-property"></a>[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/USER_Tagging.ARN.Getting.html)

# Amazon Aurora 업데이트
<a name="Aurora.Updates"></a>

Amazon Aurora는 정기적으로 업데이트를 릴리스합니다. 업데이트는 시스템 유지 관리 기간 중에 Amazon Aurora DB 클러스터에 적용됩니다. 업데이트가 적용되는 시기는 업데이트의 유형뿐 아니라 DB 클러스터에 대한 유지 관리 기간 설정 및 리전에 따라 다릅니다. 업데이트 후에는 데이터베이스를 다시 시작해야 하므로 다운타임이 20\$130초간 발생할 수 있습니다. 다운타임 후에 DB 클러스터(들)를 다시 사용할 수 있습니다. 에서 유지 관리 기간 설정을 확인하거나 변경할 수 있습니다..[AWS Management Console](https://console.aws.amazon.com/)

**참고**  
DB 인스턴스를 재부팅하는 시간은 충돌 복구 프로세스, 재부팅 시의 데이터베이스 활동 및 특정 DB 엔진의 동작에 따라 다릅니다. 따라서 재부팅 시간을 단축하려면 재부팅 프로세스에서 데이터베이스 작업을 최소화하는 것이 좋습니다. 데이터베이스 작업을 줄이면 중간 트랜잭션의 롤백 작업이 줄어듭니다.

Amazon Aurora 운영 체제 업데이트에 대한 자세한 내용은 [Aurora DB 클러스터의 운영 체제 업데이트](USER_UpgradeDBInstance.Maintenance.md#Aurora_OS_updates) 단원을 참조하십시오

일부 업데이트는 Aurora에서 지원하는 데이터베이스 엔진으로 국한됩니다. 데이터베이스 엔진 업데이트에 대한 자세한 내용은 다음 표를 참조하십시오.


| 데이터베이스 엔진 | 업데이트 | 
| --- | --- | 
|  Amazon Aurora MySQL  |  [Amazon Aurora MySQL에 대한 데이터베이스 엔진 업데이트Amazon Aurora MySQL 장기 지원(LTS) 및 베타 릴리스](AuroraMySQL.Updates.md)섹션을 참조하십시오.  | 
|  Amazon Aurora PostgreSQL  |  [Amazon Aurora PostgreSQL에 대한 데이터베이스 엔진 업데이트](AuroraPostgreSQL.Updates.md)섹션을 참조하십시오.  | 

## Amazon Aurora 버전 식별
<a name="Aurora.Updates.Versions"></a>

Amazon Aurora는 Aurora에 일반적이며 모든 Aurora DB 클러스터에서 사용할 수 있는 특정 기능을 포함합니다. Aurora는 Aurora가 지원하는 특정 데이터베이스 엔진에 특정한 다른 기능을 포함합니다. 이러한 기능들은 Aurora PostgreSQL 같이 해당 데이터베이스 엔진을 사용하는 Aurora DB 클러스터에만 제공됩니다.

Aurora DB 인스턴스는 Aurora 버전 번호와 Aurora 데이터베이스 엔진 버전 번호 등 두 가지 버전 번호를 제공합니다. Aurora 버전 번호에 사용되는 형식은 다음과 같습니다.

```
<major version>.<minor version>.<patch version>
```

특정 데이터베이스 엔진을 사용하여 Aurora DB 인스턴스에서 Aurora 버전 번호를 가져오려면 다음 쿼리 중 하나를 사용하십시오.


| 데이터베이스 엔진 | 쿼리 | 
| --- | --- | 
|  Amazon Aurora MySQL  |  <pre>SELECT AURORA_VERSION();</pre> <pre>SHOW @@aurora_version;</pre>  | 
|  Amazon Aurora PostgreSQL  |  <pre>SELECT AURORA_VERSION();</pre>  | 