RDS — 매니지드 관계형 데이터베이스

관계형 DB 를 직접 운영하는 일은 백업·복구·HA·튜닝·버전 업그레이드 등 손이 많이 가는 자리입니다. RDS (Relational Database Service) 는 그 운영 책임의 상당 부분을 AWS 가 가져가는 매니지드 서비스입니다.

1. RDS 에 대한 이야기

시기	사건
2009	RDS GA (MySQL).
2011	Oracle · SQL Server.
2013	PostgreSQL.
2014	Aurora MySQL.
2017	Aurora PostgreSQL · Performance Insights.
2018	Aurora Serverless v1.
2020	RDS Proxy.
2022	Aurora Serverless v2.

지원 엔진:

• MySQL · MariaDB · PostgreSQL · Oracle · SQL Server — 표준 OSS · 상용 엔진의 매니지드 호스팅.
• Aurora — AWS 가 만든 클라우드 네이티브 엔진. MySQL · PostgreSQL 호환.

2. Multi-AZ vs Read Replica

항목	Multi-AZ	Read Replica
목적	가용성 (HA)	읽기 부하 분산
동기성	동기 복제	비동기 복제
접근	프라이머리만	별도 엔드포인트로 읽기
장애 시	자동 페일오버	수동 승격
추가 비용	약 2 배	추가 인스턴스

Multi-AZ 는 가용성, Read Replica 는 확장성을 다루는 다른 도구입니다. 둘은 함께 쓰일 수 있습니다.

3. Aurora 의 차이

Aurora 는 스토리지 계층을 분산해서 다시 설계한 엔진입니다.

• 스토리지가 6 카피로 3 AZ 에 분산. 4/6 쿼럼 쓰기, 3/6 쿼럼 읽기.
• 컴퓨트와 스토리지 분리. 스토리지는 자동으로 64 TB 까지 확장.
• 빠른 페일오버 (수 초 ~ 수십 초) · 빠른 Read Replica (15 까지).
• Aurora Serverless v2 는 ACU (Aurora Capacity Unit) 단위 자동 스케일링.

호환성 — Aurora MySQL 은 MySQL 5.7/8.0, Aurora PostgreSQL 은 14/15/16 호환. 일부 확장·기능에서 표준 엔진과 차이가 있습니다.

4. 백업 · 스냅샷 · PITR

• 자동 백업 — 매일 한 번 + 트랜잭션 로그 5 분 단위. 보존 1 ~ 35 일. 인스턴스 삭제 시 함께 삭제.
• 스냅샷 — 사용자가 명시적으로 만드는 일회성 백업. 영구 보관 (과금).
• PITR (Point-in-Time Recovery) — 보존 기간 안의 임의 시점으로 새 인스턴스 복원.

백업은 같은 리전. 다른 리전에 두려면 스냅샷 복사 또는 Aurora Global Database.

5. 파라미터 그룹 · 옵션 그룹

• 파라미터 그룹 — 엔진 설정값 (max_connections · work_mem · shared_buffers). 인스턴스에 부착.
• 옵션 그룹 — 옵션 기반 기능 (Oracle TDE · SQL Server 옵션) 활성화.

기본 그룹은 수정 불가. 변경하려면 새 그룹을 만들어 부착. 일부 파라미터는 재시작 필요 (static).

6. Performance Insights · Monitoring

• Performance Insights — DB 부하를 시각화. 어떤 쿼리 · 세션 · 기다림이 부하 원인인지. 7 일 무료 + 장기 보관 유료.
• Enhanced Monitoring — OS 레벨 메트릭 (CPU · 디스크 · 프로세스). 1 ~ 60 초 단위.
• CloudWatch — 표준 메트릭 (연결 수 · IOPS · CPU · 스토리지).

7. RDS Proxy

DB 앞에 두는 매니지드 connection pooler. Lambda · ECS 같은 짧은 수명 컴퓨트가 매번 DB 연결을 만들어 pool 을 고갈시키는 자리에 도움이 됩니다.

Lambda → RDS Proxy → RDS instance

failover 시 연결을 끊지 않고 유지하는 효과도 있습니다.

8. 자체 EC2 PostgreSQL 과의 트레이드오프

항목	자체 EC2	RDS
비용	인스턴스만	인스턴스 + 매니지드 프리미엄
운영 부담	사용자 책임	AWS 가 다수 자동화
자유도	모든 확장 · 튜닝	일부 확장 제한
페일오버	직접 구성	Multi-AZ 자동
슈퍼유저 권한	가능	제한 (rds_superuser 만)

작은 규모·개발·연구 자리에서는 자체 운영이 비용상 유리할 수 있습니다. 운영 부담이 늘어나면 RDS 또는 매니지드 대안 (Neon · Supabase · CrunchyBridge) 으로 옮기는 흐름.

9. 매니지드 대안

서비스	메모
Neon (2022)	Postgres 의 스토리지 · 컴퓨트 분리, 브랜칭. Serverless 지향.
Supabase	Postgres + Auth · Storage · Realtime 묶음.
CrunchyBridge	Postgres 전문 매니지드.
PlanetScale	MySQL 호환 Vitess 기반. 브랜칭 모델.
Cloud SQL (GCP)	GCP 의 대응.
Azure Database for PostgreSQL	Azure 대응.

10. 보안 기본값

• Public access 비활성 — VPC 안에서만 접근.
• Security Group — 5432 포트를 앱 서버 SG 에서만.
• 암호화 (KMS) — 저장 · 스냅샷 · 로그 암호화 기본.
• IAM 인증 — DB 비밀번호 대신 IAM 토큰으로 짧은 인증 (15 분 유효).
• Secrets Manager 회전 — Lambda 로 자동.

11. 업그레이드 흐름

마이너 버전은 자동 (설정 가능), 메이저 버전은 수동.

1. 스냅샷.
2. Read Replica 또는 별도 인스턴스에서 새 메이저 버전 시험.
3. 점검창에 본 인스턴스 업그레이드.

Aurora 는 blue/green deployment 옵션으로 흐름이 단순해진 자리가 있습니다.

12. 자주 걸리는 자리

slow query 의 시야 부족 — 기본 CloudWatch 메트릭으로는 부족. Performance Insights · pg_stat_statements 켜기.

연결 수 폭주 — max_connections 가 인스턴스 클래스에 따라 다릅니다. 짧은 수명 컴퓨트는 RDS Proxy · 외부 PgBouncer.

스토리지 자동 증가 — 한 번 늘어난 EBS 는 줄지 않습니다. 디스크 사용 패턴을 미리 추정.

Multi-AZ 페일오버 시 DNS TTL — 클라이언트가 옛 IP 를 캐시하면 잠시 통신이 끊깁니다. 짧은 TTL · 재연결 로직.

파라미터 변경의 재시작 — static 파라미터는 재시작 필요. 점검창과 맞춰서.

Aurora 와 표준 엔진의 차이 — 일부 확장 · 동작이 다릅니다. 호환을 가정하지 말고 실제 시험.

삭제 보호 누락 — 운영 인스턴스는 deletion_protection 켜기.

하고픈 말

RDS 의 매니지드 프리미엄은 백업 · HA · 패치를 자동화하는 대가입니다. 작은 규모는 자체 PostgreSQL 이 비용상 유리하지만, 운영 인력이 한정적이거나 가용성 요구가 높으면 RDS · Aurora · Neon 같은 매니지드가 자연스러운 다음 단계입니다.

Next

• cloudfront
• lambda

RDS 사용자 가이드 · Aurora 사용자 가이드 · RDS Proxy · Neon · Supabase · CrunchyBridge · pgBouncer 를 참고합니다.