RDS와 관계형 데이터베이스

Amazon RDS — 무엇까지 AWS가 하는가

Amazon RDS는 관계형 데이터베이스 엔진을 대신 운영해 주는 서비스입니다. 직접 EC2에 데이터베이스를 설치하는 것과 비교하면, 운영체제와 엔진 설치 · 패치 · 백업 · 장애 조치 · 복제 설정이 AWS 쪽으로 넘어갑니다. 반대로 스키마 · 인덱스 · 쿼리 · 데이터베이스 사용자 · 네트워크 배치 · 암호화 선택은 여전히 우리 몫입니다.

시험에서 LEAST operational overhead라는 한정어가 붙으면 이 경계선이 그대로 정답의 근거가 됩니다. "EC2에 직접 데이터베이스를 설치하고 스크립트로 백업한다"는 선택지는 같은 결과를 내더라도 운영 부담이 더 크므로 소거 대상입니다.

지원 엔진

RDS API의 Engine 파라미터가 받는 값이 곧 지원 엔진 목록입니다. 엔진 계열은 크게 세 갈래입니다.

Aurora가 목록에 함께 있지만 동작 모델은 별개입니다. RDS API 문서는 읽기 전용 복제본 생성 작업(CreateDBInstanceReadReplica)에 대해 Aurora는 이 작업을 지원하지 않는다고 명시합니다. Aurora에서 읽기 용량을 늘리는 방법은 복제본을 따로 만드는 것이 아니라 클러스터에 DB 인스턴스를 추가하는 것입니다. 자세한 구조는 아래 Aurora 절에서 다룹니다.

책임 경계 — 어디까지가 AWS인가

Multi-AZ와 읽기 전용 복제본 SAA 빈출

Multi-AZ는 가용성, 읽기 전용 복제본은 읽기 확장입니다. 이 한 문장이 이 장에서 가장 많은 문항을 가릅니다. 요구가 둘 다면 둘 다 구성하는 선택지가 정답이고, 둘을 바꿔 놓은 선택지는 그 자리에서 소거합니다.

같은 결론을 도메인 2 해설에서 이미 요약해 두었습니다. 여기서는 그 표 아래로 한 층 더 내려가 왜 그렇게 되는지를 복제 방식에서부터 따라갑니다.

Multi-AZ 배포 — 동기 복제로 가용성을 산다

Multi-AZ DB 인스턴스 배포는 다른 가용 영역에 동기식(synchronous) 대기 복제본을 두고 유지합니다. RDS 사용 설명서는 프라이머리가 "가용 영역을 가로질러 대기 복제본으로 동기적으로 복제된다"고 서술합니다. 커밋은 대기 쪽 스토리지에 기록이 반영된 뒤에 완료되므로, 장애 조치가 일어나도 커밋된 트랜잭션이 유실되지 않습니다.

대가는 지연 시간입니다. 같은 문서가 "동기 복제 때문에 단일 가용 영역 배포보다 쓰기와 커밋 지연이 늘어날 수 있다"고 명시합니다. Multi-AZ는 쓰기 지연을 조금 내주고 가용성을 사는 거래입니다.

결정적인 제약은 이것입니다. RDS 사용 설명서는 Multi-AZ에 대해 "고가용성 옵션은 읽기 전용 시나리오를 위한 확장 솔루션이 아니며, 대기 복제본으로 읽기 트래픽을 처리할 수 없다"고 못 박습니다. 대기 인스턴스는 평소에 놀고 있는 것처럼 보이지만, 애플리케이션이 접근할 수 있는 엔드포인트가 없습니다.

읽기 전용 복제본 — 비동기 복제로 읽기를 늘린다

읽기 전용 복제본은 소스 인스턴스의 변경을 비동기(asynchronous)로 따라갑니다. 비동기이므로 소스의 쓰기 성능이 복제본 수에 크게 좌우되지 않지만, 대신 복제 지연(replica lag)이 존재합니다. 방금 쓴 값을 곧바로 복제본에서 읽으면 이전 값이 보일 수 있습니다.

복제본은 자기 엔드포인트를 갖습니다. 그래서 읽기 부하를 나누려면 애플리케이션이 읽기 쿼리를 그 엔드포인트로 보내도록 수정해야 합니다. 문제문에 without changing application code가 붙어 있으면 읽기 전용 복제본만으로는 요구를 만족시키지 못한다는 뜻이 됩니다.

복제본에는 몇 가지 조건이 따라붙습니다. RDS API 문서 기준으로 정리하면 다음과 같습니다.

• 소스 인스턴스는 자동 백업이 켜져 있어야 합니다. 보존 기간이 0이면 복제본을 만들 수 없습니다.
• 복제본은 백업이 꺼진 상태로 생성됩니다. 필요하면 따로 켭니다.
• 개수 상한은 엔진에 따라 다릅니다. 대부분의 엔진은 인스턴스당 15개이고, Oracle과 SQL Server는 5개, Db2는 3개입니다.
• 복제본을 독립 인스턴스로 승격(PromoteReadReplica)할 수 있지만, 이것은 자동으로 일어나지 않습니다. 사람이나 자동화가 호출해야 합니다.
• 복제본 자체를 Multi-AZ로 만들 수도 있습니다. 소스가 Multi-AZ인지와는 무관한 별개 설정입니다.

네 가지 축으로 가르기

# (1) 가용성 — 기존 인스턴스를 Multi-AZ 배포로 전환합니다.
#     엔드포인트는 그대로이고 애플리케이션은 손대지 않습니다.
aws rds modify-db-instance \
  --db-instance-identifier app-prod \
  --multi-az \
  --apply-immediately

# (2) 읽기 확장 — 별도의 읽기 엔드포인트를 갖는 복제본을 만듭니다.
#     소스는 자동 백업이 켜져 있어야 합니다.
aws rds create-db-instance-read-replica \
  --db-instance-identifier app-prod-reader-1 \
  --source-db-instance-identifier app-prod

# (3) 두 엔드포인트가 다르다는 것을 확인합니다.
aws rds describe-db-instances \
  --query 'DBInstances[].[DBInstanceIdentifier,MultiAZ,Endpoint.Address,ReadReplicaSourceDBInstanceIdentifier]' \
  --output table

장애 조치는 어떻게 일어나는가

Multi-AZ 장애 조치의 핵심 기제는 DNS 레코드 전환입니다. RDS 사용 설명서는 "장애 조치 메커니즘이 DB 인스턴스의 DNS 레코드를 대기 인스턴스를 가리키도록 자동으로 바꾼다"고 설명하며, 그 결과 기존 연결은 다시 맺어야 한다고 덧붙입니다. 엔드포인트 문자열이 바뀌지 않으므로 애플리케이션 설정은 그대로 두어도 됩니다.

소요 시간은 같은 문서 기준 대체로 60~120초이며, 큰 트랜잭션이나 긴 복구 과정이 있으면 더 걸릴 수 있습니다. 장애 조치를 유발하는 사유도 문서에 표로 정리되어 있습니다.

위 목록에서 읽어야 할 것은 유지 관리도 장애 조치의 사유라는 점입니다. Multi-AZ는 계획된 유지 관리 중의 중단 시간을 줄이는 장치이기도 합니다. 이 관계는 유지 관리 기간 절에서 다시 다룹니다.

Multi-AZ DB 클러스터 — 이름이 비슷한 별개 아키텍처

여기가 이 장에서 가장 조심할 지점입니다. Multi-AZ DB 인스턴스 배포와 Multi-AZ DB 클러스터 배포는 이름이 두 글자 차이지만 구조가 다릅니다. RDS 사용 설명서는 Multi-AZ DB 클러스터를 이렇게 정의합니다.

• 읽기 가능한 대기 인스턴스 2개를 두는 배포 모드입니다. 쓰기 인스턴스 1개와 읽기 인스턴스 2개가 같은 리전의 서로 다른 세 가용 영역에 놓입니다.
• 복제는 동기가 아니라 반동기(semisynchronous)입니다. 변경을 커밋하려면 읽기 인스턴스 중 최소 하나의 확인이 필요하며, 모든 복제본에서 완전히 실행·커밋될 것까지 요구하지는 않습니다.
• 읽기 인스턴스는 자동 장애 조치 대상이면서 동시에 읽기 트래픽을 처리합니다.
• Multi-AZ DB 인스턴스 배포보다 쓰기 지연이 낮은 편이라고 문서가 명시합니다.
• 클러스터를 만들려면 DBClusterInstanceClass · AllocatedStorage · Iops · StorageType을 함께 지정해야 하고, 프로비저닝된 IOPS 스토리지만 지원합니다.

그리고 RDS 사용 설명서는 별도의 경고 상자로 "Multi-AZ DB 클러스터는 Aurora DB 클러스터와 같은 것이 아니다"라고 적어 둡니다. 이름에 모두 "클러스터"가 들어가지만 세 가지는 전부 다른 것입니다.

Amazon Aurora — 스토리지를 컴퓨트에서 떼어 냈다

Aurora는 MySQL과 PostgreSQL 호환 엔진이지만, 스토리지 계층을 다시 설계한 것이 본질입니다. RDS에서는 인스턴스마다 자기 볼륨이 있고 복제란 곧 데이터를 한 번 더 쓰는 일이었지만, Aurora에서는 모든 인스턴스가 하나의 클러스터 볼륨을 함께 봅니다.

클러스터 볼륨 — 데이터가 인스턴스와 독립이다

Aurora 사용 설명서는 클러스터 볼륨을 "한 AWS 리전 안의 세 가용 영역에 걸쳐 데이터 사본을 두는 단일 가상 볼륨"이라고 정의합니다. 중요한 문장은 그다음입니다 — "복제의 양은 클러스터 안의 DB 인스턴스 개수와 무관하다." 인스턴스를 몇 개 두든 데이터의 내구성은 스토리지 계층이 알아서 확보합니다.

이 구조에서 따라오는 결과가 실무와 시험 양쪽에서 자주 나옵니다.

• 인스턴스를 빠르게 추가할 수 있습니다. 테이블 데이터를 새로 복사하지 않고 이미 존재하는 공유 볼륨에 연결하기만 하면 됩니다.
• 인스턴스를 제거해도 데이터는 남습니다. 클러스터 전체를 삭제해야 데이터가 지워집니다.
• 스토리지는 데이터가 늘어나면 자동으로 커집니다. 용량을 미리 프로비저닝하지 않습니다.

Aurora 복제본과 엔드포인트

클러스터에 두 번째 이후의 인스턴스를 만들면 그것이 Aurora 복제본(Aurora Replica) 또는 리더 인스턴스입니다. Aurora 사용 설명서는 복제본의 목적이 두 가지라고 명시합니다 — 읽기 확장과 가용성입니다. 라이터가 사용 불가 상태가 되면 Aurora가 리더 중 하나를 새 라이터로 자동 승격합니다.

여기가 RDS 읽기 전용 복제본과 갈리는 지점입니다. RDS 복제본은 자동 승격이 없고, Aurora 복제본은 장애 조치 대상입니다. Aurora에서는 "읽기 확장을 위한 인스턴스"와 "장애 조치 대상"이 같은 것입니다.

접속은 엔드포인트를 통해 이루어지고, 종류가 나뉩니다.

리더 엔드포인트가 있다는 사실이 판단을 바꿉니다. RDS 읽기 전용 복제본은 복제본마다 엔드포인트가 따로라서 복제본을 늘릴 때 애플리케이션 쪽 분산 로직이 필요하지만, Aurora는 리더 엔드포인트 하나만 바라보면 됩니다. "읽기 확장이 필요한데 운영 부담은 늘리기 싫다"는 요구가 Aurora로 수렴하는 이유입니다.

다만 클러스터에 복제본이 하나도 없으면 리더 엔드포인트는 프라이머리에 연결됩니다. 복제본을 만들지 않으면 읽기 확장도 장애 조치 대상도 없습니다.

Aurora 글로벌 데이터베이스 — 리전을 넘는다

Aurora 글로벌 데이터베이스는 쓰기를 받는 주 리전의 클러스터 하나와 읽기 전용 보조 리전 클러스터들로 구성됩니다. 복제는 애플리케이션이나 엔진이 아니라 Aurora 스토리지 하위 시스템의 전용 인프라가 수행합니다.

용도는 둘입니다. 전 세계 사용자에게 낮은 지연의 읽기를 제공하는 것과, 리전 전체 장애로부터 빠르게 복구하는 것입니다. 시험에서 "여러 대륙의 사용자가 읽기를 하고, 쓰기는 한 곳에서만 일어난다"는 문장이 나오면 이 기능이 후보에 들어옵니다.

보조 리전은 기본적으로 읽기 전용이지만, 쓰기 전달(write forwarding)을 켜면 보조 클러스터가 받은 쓰기를 주 클러스터로 넘기고 그 결과가 다시 복제되어 돌아옵니다. API 파라미터 이름은 EnableGlobalWriteForwarding입니다.

Aurora Serverless v2 — 용량을 자동으로 조절한다

Aurora Serverless v2는 온디맨드 자동 확장 구성입니다. 인스턴스 클래스를 고르는 대신 Aurora 용량 단위(Aurora Capacity Unit, ACU)의 최소값과 최대값을 정해 두면, 워크로드에 맞춰 그 범위 안에서 용량이 오르내립니다.

v2의 특징은 조절 단위가 작다는 점입니다. Aurora 사용 설명서는 프로비저닝된 클러스터에서 확장하려면 인스턴스를 통째로 추가해야 하는 반면 v2는 0.5 ACU 단위로 더하고 뺄 수 있다고 설명합니다. API의 MinCapacity·MaxCapacity도 0.5 단위 값을 받습니다.

고르는 기준은 부하의 예측 가능성입니다.

백업 — 자동 백업, 특정 시점 복구, 스냅샷

RDS의 백업은 두 갈래입니다. 자동 백업은 보존 기간 안에서 임의의 시점으로 되돌리기 위한 것이고, 수동 스냅샷은 특정 순간을 기한 없이 보관하기 위한 것입니다. 둘은 대체재가 아니라 역할이 다릅니다.

자동 백업과 특정 시점 복구

자동 백업은 매일 백업 기간에 스토리지 볼륨 스냅샷을 만들고, 여기에 트랜잭션 로그를 더해 특정 시점 복구(Point-In-Time Recovery, PITR)를 가능하게 합니다. RDS 사용 설명서는 트랜잭션 로그가 5분마다 Amazon S3로 업로드된다고 명시합니다. 복구 가능한 가장 최근 시각은 LatestRestorableTime으로 확인합니다.

Multi-AZ 배포에서는 백업이 대기 인스턴스 쪽에서 수행됩니다. RDS 사용 설명서는 MariaDB · MySQL · Oracle · PostgreSQL의 Multi-AZ 배포에서 프라이머리의 I/O가 백업 중에 중단되지 않는다고 서술합니다. SQL Server는 예외로, 단일 가용 영역이든 Multi-AZ든 프라이머리에서 백업을 받기 때문에 I/O가 잠시 멈춥니다. Multi-AZ는 가용성만이 아니라 백업 영향도 줄입니다.

수동 스냅샷 — 보존 기간과 무관하게 남는다

수동 스냅샷은 우리가 명시적으로 만드는 것이고, 데이터베이스를 삭제해도 남습니다. 자동 백업은 인스턴스를 지우면서 함께 사라지지만(보존 옵션을 고르지 않은 경우), 수동 스냅샷은 우리가 지우기 전까지 유지됩니다. 규정 준수 요구로 특정 시점의 데이터를 오래 보관해야 한다면 이쪽입니다.

스냅샷은 증분입니다. RDS 사용 설명서는 첫 스냅샷이 전체 데이터를 담고 이후 스냅샷은 마지막 스냅샷 이후 변경된 데이터만 저장한다고 설명합니다. 수동 스냅샷은 리전당 100개까지 보관할 수 있으며, 이 상한은 자동 백업에는 적용되지 않습니다.

복구에서 반드시 기억할 사실이 하나 있습니다. 스냅샷 복원도 PITR도 기존 인스턴스를 되돌리는 것이 아니라 새 DB 인스턴스를 만드는 작업입니다. 엔드포인트가 새로 생기므로 애플리케이션이 가리키는 주소를 바꾸거나 원래 인스턴스의 이름을 바꿔 자리를 넘겨주어야 합니다. 게다가 새 인스턴스는 기본 보안 그룹 · 기본 파라미터 그룹 · 단일 가용 영역으로 만들어지므로, 복원 후 설정을 다시 맞춰야 합니다.

스냅샷 복사와 공유

스냅샷은 다른 리전으로 복사할 수 있고 다른 계정과 공유할 수 있습니다. 두 동작의 규칙이 다릅니다.

# 수동 스냅샷을 만듭니다.
aws rds create-db-snapshot \
  --db-instance-identifier app-prod \
  --db-snapshot-identifier app-prod-2026-07-29

# 다른 리전으로 복사합니다. 복사는 대상 리전에서 호출하고,
# 암호화된 스냅샷이면 대상 리전의 KMS 키를 반드시 지정합니다.
aws rds copy-db-snapshot \
  --region us-west-2 \
  --source-db-snapshot-identifier arn:aws:rds:ap-northeast-2:123456789012:snapshot:app-prod-2026-07-29 \
  --target-db-snapshot-identifier app-prod-2026-07-29-dr \
  --kms-key-id arn:aws:kms:us-west-2:123456789012:key/EXAMPLE-KEY-ID

# 특정 계정에만 복원 권한을 줍니다. all 은 퍼블릭 공개이므로 쓰지 않습니다.
aws rds modify-db-snapshot-attribute \
  --db-snapshot-identifier app-prod-2026-07-29 \
  --attribute-name restore \
  --values-to-add 210987654321

RDS Proxy — 연결이 폭주할 때

관계형 데이터베이스는 연결 하나마다 메모리와 CPU를 씁니다. 그런데 AWS Lambda나 컨테이너 기반 애플리케이션은 순간적으로 수백 개의 실행 환경이 동시에 살아납니다. 각자 연결을 열면 데이터베이스가 연결 수 상한에 부딪히거나 연결 생성 비용만으로 무너집니다.

RDS Proxy는 데이터베이스 연결 풀을 만들어 두고 재사용합니다. RDS 사용 설명서가 정리하는 효과는 네 가지입니다.

시험에서 결정적인 문장은 이것입니다 — "대부분의 애플리케이션에서 코드 변경 없이 RDS Proxy를 활성화할 수 있다." without changing application code라는 한정어와 연결 고갈이 함께 나오면 RDS Proxy가 곧바로 유력 후보가 됩니다.

프록시는 VPC 안의 서브넷에 놓이고, 엔진 계열(MYSQL · POSTGRESQL · SQLSERVER)을 지정해 만듭니다. RequireTLS로 프록시 연결에 전송 중 암호화를 강제할 수도 있습니다.

암호화 — 생성 시점에 결정된다

RDS의 저장 시 암호화는 AWS KMS 키로 이루어지며, 켜 두면 기반 스토리지 · 자동 백업 · 읽기 전용 복제본 · 스냅샷이 모두 암호화됩니다. 복호화는 투명하게 처리되므로 클라이언트 애플리케이션을 고칠 필요가 없습니다.

가장 중요한 제약

RDS 사용 설명서는 암호화된 DB 인스턴스의 제약을 목록으로 정리해 두었고, 그 첫 줄이 시험이 노리는 지점입니다.

그렇다면 이미 운영 중인 평문 데이터베이스는 어떻게 암호화할까요. 같은 문서가 우회 경로를 함께 알려 줍니다 — 스냅샷을 만들고, 그 스냅샷의 암호화된 사본을 만든 뒤, 그 사본으로 복원합니다. 평문 스냅샷의 복사본에는 암호화를 걸 수 있기 때문입니다.

# 1) 평문 인스턴스의 스냅샷을 만듭니다.
aws rds create-db-snapshot \
  --db-instance-identifier app-prod \
  --db-snapshot-identifier app-prod-plaintext

# 2) 그 스냅샷을 "암호화된 사본"으로 복사합니다. 여기서 암호화가 들어갑니다.
aws rds copy-db-snapshot \
  --source-db-snapshot-identifier app-prod-plaintext \
  --target-db-snapshot-identifier app-prod-encrypted \
  --kms-key-id arn:aws:kms:ap-northeast-2:123456789012:key/EXAMPLE-KEY-ID

# 3) 암호화된 스냅샷에서 새 인스턴스를 만듭니다. 새 엔드포인트가 생기므로
#    전환 계획(이름 교체 또는 애플리케이션 설정 변경)이 필요합니다.
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier app-prod-enc \
  --db-snapshot-identifier app-prod-encrypted

전송 중 암호화는 별개 계층입니다. RDS 사용 설명서는 암호화 여부와 무관하게 소스와 읽기 전용 복제본 사이의 전송 데이터는 암호화되며, 리전을 넘어 복제할 때도 그렇다고 명시합니다. 클라이언트와 데이터베이스 사이의 TLS는 엔진 설정으로 강제하거나 RDS Proxy의 RequireTLS로 강제합니다. KMS 키의 종류와 키 정책은 16장 보안·암호화·거버넌스에서 다룹니다.

유지 관리 기간과 패치 책임

RDS는 운영체제와 데이터베이스 엔진 패치를 유지 관리 기간(maintenance window)에 수행합니다. 지정하지 않으면 AWS가 리전마다 정해진 8시간 블록 안에서 임의의 요일 · 임의의 30분 창을 골라 배정합니다. 형식은 ddd:hh24:mi-ddd:hh24:mi이고 협정 세계시(UTC) 기준이며 최소 30분이어야 합니다.

규칙이 하나 더 있습니다. 유지 관리 기간과 백업 기간은 겹칠 수 없습니다. 두 창을 같은 시간대로 잡으려 하면 API가 거부합니다.

흔한 오해

시험 포인트 정리

이 장의 주제는 복원력 있는 아키텍처 설계(26%)와 고성능 아키텍처 설계(24%)에 걸쳐 있습니다.

확인 문제

이 장의 핵심을 확인하는 10문항입니다. 키보드만으로 완주할 수 있습니다 — 숫자키 1~5로 선택지를 고르고 Enter로 제출합니다.

학습용 유형 연결형과 순서 배열 문항이 섞여 있을 수 있습니다. 두 유형은 암기 확인에 효율이 좋아서 기본개념 확인 문제에만 넣었으며, 실제 SAA-C03 시험에는 출제되지 않습니다.

이어서 볼 곳

• 11장 · NoSQL · 캐시 · 분석 DB 읽기 지연을 줄이는 다음 수단인 ElastiCache와 DAX, 그리고 관계형이 답이 아닐 때 고르는 DynamoDB를 다룹니다. 기본개념 · 바로 다음 장
• 복원력 있는 아키텍처 설계 (26%) 이 장의 Multi-AZ 판단이 도메인 전체에서 어떤 위치에 있는지, 과제 진술 2.1과 2.2의 언어로 다시 봅니다. 시험 대비 · 주 도메인
• 함정 사전 · 데이터베이스와 캐시 Multi-AZ와 읽기 전용 복제본을 포함해 헷갈리는 쌍을 표 하나로 모아 두었습니다. 시험 직전 복습용입니다. 시험 대비
• 한정어 키워드 사전 "가용성"과 "읽기 확장"이라는 한정어가 어떻게 정답을 가르는지, 다른 한정어들과 함께 정리했습니다. 시험 대비 · 최우선
• 6장 · EBS 기존 볼륨 암호화 "생성 시점에만 암호화할 수 있다"는 제약과 스냅샷 우회 경로가 EBS에서 똑같이 반복됩니다. 기본개념
• 7장 · 다중 가용 영역 배치 데이터 계층의 Multi-AZ는 애플리케이션 계층의 다중 가용 영역 설계와 짝을 이룰 때만 의미가 있습니다. 기본개념

공식 문서 출처

이 장의 개념 서술과 API 동작은 모두 아래 문서에서 확인했습니다.

• Amazon RDS 사용 설명서 — Multi-AZ DB 인스턴스 배포 — 동기 복제 대기 복제본, 대기 인스턴스로 읽기를 처리할 수 없다는 명시, 장애 조치가 DNS 레코드를 전환한다는 설명, 소요 시간 60~120초, 장애 조치 사유 표
• Amazon RDS 사용 설명서 — Multi-AZ DB 클러스터 배포 — 읽기 가능한 대기 2개, 3개 가용 영역, 반동기 복제, 프로비저닝된 IOPS 전용, Aurora DB 클러스터와 다르다는 경고
• Amazon RDS 사용 설명서 — 읽기 전용 복제본 사용 — 비동기 복제와 별도 읽기 엔드포인트
• Amazon RDS API 레퍼런스 — CreateDBInstanceReadReplica — 엔진별 복제본 개수 상한(대부분 15, Oracle·SQL Server 5, Db2 3), 소스에 자동 백업이 필요하다는 조건, Aurora가 이 작업을 지원하지 않는다는 서술
• Amazon RDS API 레퍼런스 — CreateDBInstance — 지원 엔진 목록, MultiAZ와 AvailabilityZone을 함께 쓸 수 없다는 제약, 보존 기간 0~35일, 마이너 버전 자동 업그레이드 기본값, 유지 관리 기간 형식
• Amazon RDS API 레퍼런스 — CreateDBCluster — Multi-AZ DB 클러스터의 필수 설정, 클러스터 보존 기간 1~35일, Aurora Serverless v2 확장 구성
• Amazon RDS API 레퍼런스 — FailoverDBCluster — Aurora는 복제본을 승격하고 Multi-AZ DB 클러스터는 읽기 가능한 대기를 승격한다는 구분
• Amazon RDS 사용 설명서 — 백업 작업 — 보존 기간 범위와 기본값, 스냅샷의 증분 성격, 리전당 수동 스냅샷 100개, 백업 기간이 유지 관리 기간과 겹칠 수 없다는 규칙, Multi-AZ에서 백업이 대기 쪽에서 수행된다는 서술
• Amazon RDS 사용 설명서 — 지정한 시간으로 DB 인스턴스 복원 — 트랜잭션 로그가 5분마다 Amazon S3로 업로드된다는 설명, 복원 결과가 새 인스턴스라는 점
• Amazon RDS API 레퍼런스 — CopyDBSnapshot — 복사를 호출한 리전이 대상 리전이 된다는 규칙
• Amazon RDS API 레퍼런스 — ModifyDBSnapshotAttribute — 수동 스냅샷만 공유할 수 있다는 점, restore 속성과 all 값의 의미, 암호화된 스냅샷은 계정 ID 지정만 가능하다는 제약
• Amazon RDS 사용 설명서 — Amazon RDS 리소스 암호화 — 생성 시점에만 암호화할 수 있다는 제약 목록, 스냅샷 사본을 통한 우회 경로, 복제본 전송 데이터가 암호화된다는 서술
• Amazon RDS 사용 설명서 — Amazon RDS Proxy 사용 — 연결 풀링과 과부하 완충, 대기 인스턴스로 자동 재연결하며 애플리케이션 연결을 유지한다는 설명, 대개 코드 변경이 필요 없다는 서술
• Amazon RDS API 레퍼런스 — CreateDBProxy — 엔진 계열 값, Secrets Manager 접근용 IAM 역할, RequireTLS
• Amazon Aurora 사용 설명서 — Aurora 스토리지와 안정성 — 클러스터 볼륨이 3개 가용 영역에 사본을 두며 복제량이 인스턴스 개수와 무관하다는 서술, 자동 확장
• Amazon Aurora 사용 설명서 — Aurora 복제 — Aurora 복제본이 읽기 확장과 가용성을 겸하며 라이터 실패 시 자동 승격된다는 설명
• Amazon Aurora 사용 설명서 — Aurora 연결 관리 — 클러스터 · 리더 · 사용자 지정 · 인스턴스 엔드포인트의 역할과 리더 엔드포인트의 부하 분산
• Amazon Aurora 사용 설명서 — Aurora 글로벌 데이터베이스 — 주 리전에서만 쓰기, 읽기 전용 보조 리전, 스토리지 하위 시스템의 전용 인프라를 통한 복제
• Amazon Aurora 사용 설명서 — Aurora Serverless v2 사용 — 온디맨드 자동 확장 구성, 0.5 ACU 단위 조절, 적합한 워크로드 유형