RDS — 매니지드 DB, 백업, 파라미터 그룹

10장 S3가 객체 영역이었다면, 본 챕터는 관계형 DB 차례입니다. AWS의 관계형 DB 매니지드 서비스는 **RDS (Relational Database Service)**입니다. PostgreSQL / MySQL / MariaDB / Oracle / SQL Server / Aurora를 한 콘솔에서 띄우고 운영할 수 있습니다.

본 챕터에서는 RDS의 매니지드 모델에서 시작해 자동 백업과 PITR, Multi-AZ와 Read Replica, 파라미터 / 옵션 그룹, 업그레이드까지 차례로 정리합니다. RDS가 사는 Private 서브넷은 8장 EC2와 VPC 기초의 서브넷 설계 위에 놓이고, 비밀번호 관리는 20장 Secrets Manager와 Parameter Store, 백업과 복원의 큰 그림은 30장 재해 복구·백업으로 이어집니다.

EC2 위 DB vs RDS #

처음 클라우드를 만나면 다들 한 번씩 망설입니다. “EC2 한 대 띄워 PostgreSQL을 직접 깔까, RDS로 갈까?”

운영 시스템은 거의 RDS가 답입니다. EC2 위 DB는 익스텐션이 RDS에서 미지원이거나 OS 단 튜닝이 필요한 특수 경우에만 씁니다.

엔진 선택 #

RDS가 지원하는 엔진은 다음과 같습니다.

PostgreSQL  ── 새 프로젝트의 첫 후보. JSONB / 익스텐션 풍부
MySQL       ── 가장 흔한 선택. 호환성 중시
MariaDB     ── MySQL 포크. 거의 MySQL 과 동일
Oracle      ── 라이선스 비싼 엔터프라이즈
SQL Server  ── 마이크로소프트 생태계
Aurora      ── AWS 자체 엔진. PostgreSQL / MySQL 호환

Aurora의 특징 #

Aurora는 AWS가 만든 클라우드 네이티브 DB입니다. PostgreSQL / MySQL 와이어 호환이라 코드 변경 거의 없이 옮길 수 있습니다.

운영 규모와 가용성이 중요하면 Aurora, 비용과 단순성이 중요하면 RDS PostgreSQL입니다.

Aurora Serverless v2는 사용량 기반 자동 스케일 RDS입니다. 트래픽이 들쭉날쭉한 경우에 매력적이며, 콜드 스타트가 거의 없습니다(v1의 단점이 해결됐습니다).

RDS 인스턴스 띄우기 #

aws rds create-db-instance \
  --db-instance-identifier my-postgres \
  --db-instance-class db.t3.micro \
  --engine postgres \
  --engine-version 16.4 \
  --master-username postgres \
  --master-user-password "very-strong-password" \
  --allocated-storage 20 \
  --storage-type gp3 \
  --vpc-security-group-ids sg-0abc... \
  --db-subnet-group-name my-db-subnet-group \
  --backup-retention-period 7 \
  --multi-az \
  --no-publicly-accessible

자주 만지는 옵션은 다음과 같습니다.

DB Subnet Group #

RDS는 Multi-AZ 구성에 둘 서브넷을 미리 지정해야 합니다. 그것이 DB Subnet Group입니다. 보통 Private 서브넷 두 AZ 이상으로 둡니다.

aws rds create-db-subnet-group \
  --db-subnet-group-name my-db-subnet-group \
  --db-subnet-group-description "DB private subnets" \
  --subnet-ids subnet-0a1... subnet-0b2... subnet-0c3...

DB가 사는 곳은 Private 서브넷(8장 VPC)으로, 인터넷에 직접 노출하지 않습니다. 앱 서버 SG만 SG 단위로 들어오게 허용합니다.

자동 백업 — 매니지드의 핵심 가치 #

RDS의 진짜 가치는 백업입니다.

Automated Backup #

backup-retention-period가 0보다 크면 자동 백업이 켜집니다.

• 매일 한 번 전체 백업이 백업 윈도우 시간에 일어납니다.
• 트랜잭션 로그가 5분마다 저장됩니다.
• 보존 기간(1~35일) 동안 보관됩니다.
• DB 삭제 시 자동 백업도 같이 삭제됩니다(SkipFinalSnapshot=false로 막을 수 있습니다).

Point-in-Time Recovery (PITR) #

자동 백업이 켜진 RDS는 보존 기간 안의 임의 시점으로 복원할 수 있습니다. 트랜잭션 로그 5분 단위 정밀도입니다.

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier my-postgres \
  --target-db-instance-identifier my-postgres-restored \
  --restore-time 2026-05-24T08:30:00Z

복원은 새 인스턴스를 만드는 형태입니다. 원본은 그대로 둡니다. “오늘 새벽 3시 27분 직전 상태가 필요하다"가 가능합니다.

Manual Snapshot #

자동 백업과 별도로 사용자가 명시적으로 만드는 백업입니다. DB를 삭제해도 사라지지 않고, 보존 기한도 없습니다.

aws rds create-db-snapshot \
  --db-instance-identifier my-postgres \
  --db-snapshot-identifier my-postgres-2026-05-24-prerelease

운영에서 수동 스냅샷을 쓰는 경우는 다음과 같습니다.

• 메이저 업그레이드 직전.
• 큰 마이그레이션 직전.
• DB 삭제 시 final snapshot.
• 다른 리전 / 계정으로 복사(DR 구성).

Multi-AZ — 고가용성 #

--multi-az 옵션을 켜면 RDS가 Standby 인스턴스를 다른 AZ에 자동 복제합니다.

   ┌──────────────────────────────────┐
   │           VPC                    │
   │                                  │
   │    AZ a              AZ b        │
   │    ┌──────┐          ┌──────┐    │
   │    │ Pri  │ ◀══════▶ │Stand │    │
   │    │mary  │  복제(동기) │ by   │    │
   │    └──────┘          └──────┘    │
   │       ▲                          │
   │       │ DNS endpoint             │
   │       │ (자동 페일오버)              │
   └───────┼──────────────────────────┘
           │
       앱 서버

• 동기 복제 — Standby도 매 트랜잭션 commit까지 받아 둡니다.
• 장애 시 자동 페일오버 — 30초~2분 안에 Standby가 Primary가 되고 DNS endpoint가 그쪽을 가리킵니다.
• 읽기 분산 안 됨 — Standby는 읽기에도 쓰이지 않습니다(Aurora와 다른 점입니다).

Multi-AZ의 비용 #

이중화의 대가는 인스턴스 / 스토리지 비용의 2배입니다. 학습이나 사이드 프로젝트는 단일 AZ, 운영은 Multi-AZ입니다.

Multi-AZ Cluster (옵션) #

PostgreSQL / MySQL에 새로 나온 Multi-AZ DB Cluster는 standby가 읽기 가능하고, 페일오버 시간도 35초 이하입니다. 단, AZ 세 개를 사용합니다(인스턴스 세 개 비용).

Read Replica — 읽기 분산 #

Read Replica는 비동기 복제로 만들어지는 읽기 전용 사본입니다. 읽기 트래픽이 많은 곳에 부하를 분산합니다.

aws rds create-db-instance-read-replica \
  --db-instance-identifier my-postgres-read-1 \
  --source-db-instance-identifier my-postgres \
  --availability-zone ap-northeast-2c

특징은 다음과 같습니다.

• 비동기 복제 — 약간의 지연이 있습니다(보통 ms ~ 초).
• 다른 리전에도 가능 — 글로벌 읽기 분산 / DR에 씁니다.
• 최대 5 개 — Aurora는 15 개입니다.
• Promote로 별도 인스턴스로 분리할 수 있습니다.

Read Replica의 적합도 #

읽기 트래픽이 많지 않으면 Read Replica보다 Multi-AZ Cluster가 단순합니다.

파라미터 그룹과 옵션 그룹 #

DB 엔진의 설정(max_connections, shared_buffers 같은)을 RDS에서는 파라미터 그룹으로 관리합니다.

Parameter Group #

aws rds create-db-parameter-group \
  --db-parameter-group-name my-postgres-16-params \
  --db-parameter-group-family postgres16 \
  --description "Custom params for my workload"

aws rds modify-db-parameter-group \
  --db-parameter-group-name my-postgres-16-params \
  --parameters \
    "ParameterName=max_connections,ParameterValue=200,ApplyMethod=pending-reboot" \
    "ParameterName=log_statement,ParameterValue=ddl,ApplyMethod=immediate"

파라미터는 두 종류입니다.

• Static — DB 재부팅 후 적용됩니다(max_connections 등).
• Dynamic — 즉시 적용됩니다(log_statement 등).

자주 만지는 파라미터는 다음과 같습니다.

Option Group #

엔진별 추가 기능(예: SQL Server의 SSIS, Oracle의 OEM)을 켜는 역할입니다. PostgreSQL / MySQL은 거의 안 만집니다.

업그레이드 — 운영 흐름 #

RDS는 엔진 버전 업그레이드를 두 종류로 나눕니다.

Minor Upgrade — 안전 #

16.3 → 16.4 같은 마이너 업그레이드입니다. 보통 보안 패치와 작은 개선입니다. 자동 적용 옵션을 켜면 백업 윈도우에 자동으로 됩니다.

aws rds modify-db-instance \
  --db-instance-identifier my-postgres \
  --auto-minor-version-upgrade \
  --apply-immediately

다운타임은 30초 ~ 5분입니다. Multi-AZ 면 더 짧습니다(Standby 먼저 업그레이드 후 페일오버, 그 다음 옛 Primary).

Major Upgrade — 신중 #

PostgreSQL 16 → 17 같은 메이저 업그레이드입니다. 깨질 수 있습니다. 절차는 다음과 같습니다.

1. 수동 스냅샷을 만듭니다(롤백용).
2. 테스트 환경에서 같은 버전 마이그레이션을 시도합니다.
3. 가능하면 Read Replica를 먼저 업그레이드합니다.
4. 운영 시간 외 다운타임 윈도우를 잡습니다.
5. aws rds modify-db-instance --engine-version 17.0을 실행합니다.
6. 업그레이드를 모니터링합니다.
7. 문제가 생기면 스냅샷에서 새 인스턴스를 복원합니다.

메이저 업그레이드 전에 PostgreSQL의 deprecated SQL이나 MySQL의 strict mode 변경 같은 호환성 이슈를 먼저 점검합니다.

Blue/Green Deployment #

RDS의 Blue/Green Deployment는 메이저 업그레이드나 큰 변경의 다운타임을 줄이는 방식입니다. 복제본(green)을 만들고 cutover 시점에만 짧게 멈춥니다.

aws rds create-blue-green-deployment \
  --blue-green-deployment-name my-postgres-bg \
  --source arn:aws:rds:ap-northeast-2:123456789012:db:my-postgres \
  --target-engine-version 17.0

Performance Insights — 성능 모니터링 #

RDS의 성능 모니터링 도구입니다. 어떤 SQL이 시간을 가장 많이 잡는지 그래프로 봅니다.

시간축 ──▶
DB Load ▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮
        │ ── SELECT ... FROM users WHERE ...
        │ ── UPDATE products SET ...
        │ ── lock:relation

• 7일은 무료이고, 그 이상은 추가 비용입니다.
• 슬로우 쿼리 / 락 / 대기를 분석합니다.
• 애플리케이션의 N+1 쿼리 같은 패턴이 그래프로 보입니다.

RDS Proxy — 연결 풀 #

Lambda나 컨테이너에서 RDS로 연결할 때 매번 TCP / TLS 핸드셰이크가 비쌉니다. RDS Proxy가 연결 풀을 매니지드로 만들어 줍니다.

쓰는 경우는 다음과 같습니다.

• Lambda + RDS — 매 invocation 마다 새 연결이 생기는 것을 Proxy로 풀링합니다(18장 API Gateway와 Lambda).
• 컨테이너 자동 스케일 — 인스턴스가 늘어나며 connection이 폭증하는 것을 막습니다.
• failover 자동 회복.

비용은 vCPU 시간당입니다. 작은 워크로드에는 오버킬일 수 있습니다.

자주 만나는 함정 #

• 퍼블릭 RDS — publicly-accessible=true로 만들고 SG가 0.0.0.0/0 이면 며칠 안에 brute-force 공격이 옵니다. 운영은 항상 Private 서브넷과 앱 SG만 허용합니다.
• master-user-password를 git에 둠 — 스크립트나 Terraform에 평문 비밀번호를 두면 노출됩니다. Secrets Manager(20장)로 관리합니다.
• Multi-AZ 안 켜고 운영 — 비용 절감으로 Multi-AZ를 끄면 AZ 장애 시 DB가 1~2시간 다운됩니다. 운영은 켭니다.
• backup-retention 0 — 비용 절감으로 자동 백업을 끄면 PITR도 동시에 꺼집니다. 사고 시 복구가 불가능합니다. 최소 7일을 권장합니다.
• Final Snapshot 없이 삭제 — DB 삭제 시 --skip-final-snapshot으로 빨리 지우면 데이터가 영구 손실됩니다. terraform destroy 같은 자동화에는 final snapshot을 강제합니다.
• Storage Auto-Scaling 끔 — 디스크가 80% 차오른 새벽에 쓰기가 실패합니다. --max-allocated-storage 옵션으로 자동 확장을 켭니다.

aws rds modify-db-instance \
  --db-instance-identifier my-postgres \
  --max-allocated-storage 200

• Read Replica를 페일오버 용도로 오해 — Read Replica는 자동 페일오버가 안 됩니다. 수동 promote가 필요합니다. 자동 페일오버는 Multi-AZ입니다.
• Connection 누수 — 앱이 연결을 안 닫아 max_connections를 채우면 새 요청이 거부됩니다. PgBouncer / RDS Proxy 또는 앱 풀 설정을 점검합니다.

연습문제 #

1. §“EC2 위 DB vs RDS"의 표를 보지 않고, RDS를 골랐을 때 직접 안 해도 되는 운영 작업 세 가지를 적어 보세요. 그리고 반대로 EC2 위 DB가 필요한 특수 상황 한 가지를 메모해 두세요.
2. 자동 백업(PITR), 수동 스냅샷, Read Replica 세 가지를 백업 / DR 관점에서 비교해, “어젯밤 잘못 실행한 DELETE를 되돌려야 한다"와 “메이저 업그레이드 직전 안전장치가 필요하다” 두 상황에 각각 무엇을 쓸지 §“자동 백업"을 근거로 골라 보세요. 이 비교는 30장 재해 복구·백업에서 다시 확장됩니다.
3. 운영 RDS를 띄우는 create-db-instance 명령에서, §“자주 만나는 함정"의 여섯 항목을 막기 위해 어떤 플래그를 어떤 값으로 둬야 하는지 한 줄씩 연결해 보세요(예: publicly-accessible, backup-retention-period, multi-az).

한 줄 요약: RDS는 매니지드 관계형 DB로 운영 시스템은 거의 RDS가 답이고, Aurora는 분산 스토리지와 빠른 페일오버를 더한 AWS 자체 엔진이다. 자동 백업과 PITR가 5분 정밀도로 임의 시점을 복원하고 수동 스냅샷은 DB를 지워도 살아남는다. Multi-AZ는 동기 복제 + 자동 페일오버지만 standby는 읽기에 못 쓰고, Read Replica는 비동기 읽기 사본일 뿐 자동 페일오버가 아니다. 운영 기본은 Private 서브넷, publicly-accessible=false, 백업 7일 이상이다.

다음 챕터 #

DB 영역은 잡았습니다. 다음 12장 Route 53에서는 사용자가 우리 시스템을 만나는 첫 지점인 DNS로 넘어갑니다. 도메인 등록과 Hosted Zone, 레코드 종류와 Alias, 라우팅 정책(Failover / Latency / Geolocation)까지 도메인 운용을 정리합니다.