RDS vs Aurora vs DynamoDB: AWS 데이터베이스 선택 가이드
관계형은 RDS/Aurora, 비관계형은 DynamoDB. SAA-C03 시험에서 자주 출제되는 AWS 데이터베이스 서비스의 특징과 선택 기준을 정리합니다.
관련 시험 도메인
- Domain 2: Design Resilient Architectures
- Domain 3: Design High-Performing Architectures
핵심 요약 (BLUF)
SQL 데이터와 복잡한 쿼리가 필요하면 RDS/Aurora, 무한 확장과 밀리초 지연시간이 필요하면 DynamoDB를 선택하세요. Aurora는 RDS의 고성능 버전(MySQL 5배, PostgreSQL 3배 빠름)이고, DynamoDB는 완전 서버리스 NoSQL입니다.
시험 팁
시험 핵심: 관계형 + 복잡한 JOIN = RDS/Aurora, 키-값 + 무한 확장 + 밀리초 응답 = DynamoDB
세 가지 서비스 한눈에 비교
| 비교 항목 | RDS | Aurora | DynamoDB |
|---|---|---|---|
| 데이터 모델 | 관계형 (SQL) | 관계형 (SQL) | 비관계형 (NoSQL) |
| 지원 엔진 | MySQL, PostgreSQL, MariaDB, Oracle, SQL Server | MySQL, PostgreSQL | 키-값, 문서 |
| 최대 스토리지 | 64TiB | 128TiB (자동 확장) | 무제한 |
| 읽기 복제본 | 최대 5개 | 최대 15개 | 글로벌 테이블 |
| 자동 장애 조치 | Multi-AZ 필요 | 기본 제공 | 기본 제공 |
| 서버리스 옵션 | ❌ | ✅ Aurora Serverless | ✅ 완전 서버리스 |
| 관리 수준 | 관리형 | 관리형 | 완전 관리형 |
| 비용 모델 | 인스턴스 + 스토리지 | 인스턴스 + I/O | RCU/WCU 또는 온디맨드 |
Amazon RDS
RDS란?
RDS(Relational Database Service)는 관계형 데이터베이스를 쉽게 설정, 운영, 확장할 수 있는 관리형 서비스입니다. 하드웨어 프로비저닝, 데이터베이스 설정, 패치, 백업을 자동화합니다.
RDS 관리 범위:
AWS가 관리 │ 사용자가 관리
──────────────────┼──────────────────
하드웨어 │ 스키마 설계
OS 패치 │ 쿼리 최적화
DB 엔진 패치 │ 인덱스 관리
백업 │ 애플리케이션 코드
고가용성 (Multi-AZ) │ 파라미터 튜닝
RDS 지원 데이터베이스 엔진
| 엔진 | 특징 | 적합한 경우 |
|---|---|---|
| MySQL | 오픈소스, 가장 보편적 | 웹 애플리케이션, 범용 |
| PostgreSQL | 고급 기능, GIS 지원 | 복잡한 쿼리, 분석 |
| MariaDB | MySQL 포크, 커뮤니티 | MySQL 대안 필요 시 |
| Oracle | 엔터프라이즈 기능 | 기존 Oracle 워크로드 |
| SQL Server | Microsoft 생태계 | .NET 애플리케이션 |
RDS 적합한 사용 사례
- 전통적인 OLTP 워크로드: 트랜잭션 처리
- 기존 온프레미스 마이그레이션: 최소한의 코드 변경
- 복잡한 JOIN 쿼리: 관계형 데이터 모델
- Oracle/SQL Server 라이선스: 기존 라이선스 활용(BYOL)
Amazon Aurora
Aurora란?
Aurora는 클라우드 네이티브 관계형 데이터베이스로, MySQL과 PostgreSQL과 호환되면서 최대 5배(MySQL) 또는 3배(PostgreSQL) 더 빠른 성능을 제공합니다.
Aurora 아키텍처:
┌─────────────────────────────────────┐
│ Aurora 스토리지 클러스터 │
│ (3개 AZ에 6개 복사본 자동 분산) │
│ │
│ AZ-a │ AZ-b │ AZ-c │
│ ██ ██ │ ██ ██ │ ██ ██ │
└─────────────────────────────────────┘
↑ ↑
┌─────────────┐ ┌─────────────┐
│ Writer │ │ Reader │
│ (Primary) │ │ (Replica) │
└─────────────┘ └─────────────┘
↑ ↑
쓰기 읽기 (최대 15개)
Aurora vs RDS 비교
| 항목 | RDS | Aurora |
|---|---|---|
| 성능 | 기준선 | MySQL 5x, PostgreSQL 3x |
| 스토리지 | 수동 프로비저닝 (최대 64TiB) | 자동 확장 (최대 128TiB) |
| 복제본 | 최대 5개 | 최대 15개 |
| 복제 지연 | 초 단위 | 밀리초 단위 |
| 장애 조치 | 1-2분 | ~30초 |
| 백업 | S3로 백업 | 연속적, 증분식 |
| 비용 | 낮음 | 20~30% 높음 |
Aurora 고유 기능
1. Aurora Serverless v2
사용량에 따라 자동 확장:
- ACU(Aurora Capacity Unit) 단위로 과금
- 0.5~128 ACU 범위에서 자동 조절
- 개발/테스트 환경에 적합
2. Aurora Global Database
전 세계 1초 미만 복제:
- 1개 기본 리전 + 최대 5개 보조 리전
- 보조 리전에서 1초 미만 읽기
- RTO < 1분의 재해 복구
3. Aurora 클론
몇 초 만에 TB급 데이터베이스 복제:
- Copy-on-Write 방식
- 원본 데이터 영향 없음
- 테스트 환경 구축에 최적
Aurora 적합한 사용 사례
- 고성능 OLTP: MySQL/PostgreSQL 성능 한계 초과 시
- 읽기 집중 워크로드: 15개 읽기 복제본 활용
- 가변적 트래픽: Aurora Serverless로 비용 최적화
- 글로벌 애플리케이션: Global Database로 지연시간 감소
시험 팁
시험 포인트: "MySQL/PostgreSQL 호환 + 고성능 + 자동 확장 스토리지" 키워드가 나오면 Aurora 선택
Amazon DynamoDB
DynamoDB란?
DynamoDB는 완전 관리형 NoSQL 데이터베이스로, 어떤 규모에서든 한 자릿수 밀리초 성능을 제공합니다. 서버 프로비저닝, 패치, 확장을 완전히 자동화합니다.
DynamoDB 데이터 모델:
테이블: Users
┌─────────────────────────────────────────────────┐
│ Partition Key │ Sort Key │ Attributes │
├───────────────┼───────────┼─────────────────────┤
│ user_001 │ profile │ {name, email, ...} │
│ user_001 │ order#001 │ {items, total, ...} │
│ user_001 │ order#002 │ {items, total, ...} │
│ user_002 │ profile │ {name, email, ...} │
└─────────────────────────────────────────────────┘
↓
파티션 키로 데이터 분산 → 무한 수평 확장
DynamoDB 핵심 개념
| 개념 | 설명 |
|---|---|
| 테이블 | 데이터 컬렉션 (스키마리스) |
| 항목(Item) | 테이블의 각 레코드 |
| 속성(Attribute) | 항목의 데이터 필드 |
| 파티션 키 | 데이터 분산 기준 (필수) |
| 정렬 키 | 파티션 내 정렬 기준 (선택) |
| GSI/LSI | 보조 인덱스 (다른 쿼리 패턴 지원) |
DynamoDB 용량 모드
1. 프로비저닝된 용량
- RCU (Read Capacity Unit): 초당 읽기 단위
- WCU (Write Capacity Unit): 초당 쓰기 단위
- 예측 가능한 트래픽에 적합
- Auto Scaling 설정 가능
2. 온디맨드 용량
- 요청당 과금
- 용량 계획 불필요
- 예측 불가능한 트래픽에 적합
- 프로비저닝 대비 약 2.5배 비용
DynamoDB 고유 기능
1. DynamoDB Streams
테이블 변경 사항 실시간 캡처:
INSERT/UPDATE/DELETE → Stream → Lambda 트리거
- 실시간 이벤트 처리
- 데이터 복제/동기화
2. 글로벌 테이블
다중 리전 복제:
서울 ↔ 버지니아 ↔ 프랑크푸르트
- 자동 다중 마스터 복제
- 로컬 읽기/쓰기 (낮은 지연시간)
- 리전 장애 시 자동 장애 조치
3. DAX (DynamoDB Accelerator)
인메모리 캐시:
애플리케이션 → DAX → DynamoDB
- 마이크로초 응답 시간
- 읽기 집중 워크로드
- API 변경 없이 적용
DynamoDB 적합한 사용 사례
- 대규모 확장 필요: 초당 수백만 요청
- 낮은 지연시간 필수: 한 자릿수 밀리초
- 단순한 쿼리 패턴: 키 기반 조회
- 서버리스 아키텍처: Lambda와 통합
- 세션 관리: TTL로 자동 만료
- 게임 리더보드: 빠른 읽기/쓰기
시험 팁
시험 포인트: "무한 확장", "밀리초 지연시간", "서버리스", "키-값" 키워드가 나오면 DynamoDB 선택
선택 기준 가이드
데이터 모델 기준
데이터 유형 결정 트리:
데이터 간 관계가 복잡한가?
│
├── YES: JOIN/트랜잭션 필요 → 관계형 (RDS/Aurora)
│ │
│ ├── 표준 성능 충분 → RDS
│ └── 고성능/자동확장 → Aurora
│
└── NO: 단순 키-값 조회 → DynamoDB
워크로드 기준
| 워크로드 특성 | 추천 서비스 |
|---|---|
| 복잡한 SQL 쿼리 | RDS/Aurora |
| ACID 트랜잭션 | RDS/Aurora (DynamoDB도 제한적 지원) |
| 스키마 변경 잦음 | DynamoDB |
| 초당 수만 요청 이상 | DynamoDB |
| 예측 가능한 성능 | DynamoDB |
| 읽기 집중 (리포팅) | Aurora (15개 읽기 복제본) |
| 완전 서버리스 | DynamoDB / Aurora Serverless |
확장성 기준
확장 요구사항:
수직 확장 (Scale Up) │ 수평 확장 (Scale Out)
─────────────────────────┼─────────────────────────
RDS: 인스턴스 크기 변경 │ DynamoDB: 파티션 자동 추가
Aurora: 인스턴스 크기 변경 │ DynamoDB: 무제한
│
한계: 인스턴스 최대 크기 │ 한계: 없음
시나리오별 솔루션
시나리오 1: 전자상거래 플랫폼
요구사항: 상품, 주문, 고객 관리 + 복잡한 쿼리
데이터: 관계형 (상품-주문-고객 JOIN 필요)
선택: Aurora MySQL
이유: 복잡한 관계 + 높은 트랜잭션 처리량
시나리오 2: 실시간 게임 리더보드
요구사항: 수백만 사용자, 밀리초 응답
데이터: 단순 (user_id → score)
선택: DynamoDB
이유: 무한 확장 + 예측 가능한 지연시간
시나리오 3: 온프레미스 Oracle 마이그레이션
요구사항: 기존 Oracle PL/SQL 활용
데이터: 복잡한 스키마, 스토어드 프로시저
선택: RDS Oracle
이유: 최소 코드 변경, BYOL 지원
시나리오 4: IoT 센서 데이터
요구사항: 수천만 디바이스, 초당 백만 쓰기
데이터: 시계열 (device_id + timestamp)
선택: DynamoDB
이유: 대규모 쓰기 처리, 파티션 키로 분산
시나리오 5: 분석 대시보드
요구사항: 복잡한 집계 쿼리, 임시 분석
데이터: 구조화된 비즈니스 데이터
선택: Aurora PostgreSQL
이유: 고급 분석 함수, 15개 읽기 복제본
시나리오 6: 세션 관리
요구사항: 빠른 읽기/쓰기, 자동 만료
데이터: 세션 키-값
선택: DynamoDB + TTL
이유: 밀리초 응답, TTL로 자동 정리
비용 비교
월별 비용 예시 (서울 리전)
동일 워크로드 기준 (월 1억 읽기, 1천만 쓰기):
RDS db.r6g.large (Multi-AZ)
├── 인스턴스: ~$300
├── 스토리지 100GB: ~$12
└── 총계: ~$312/월
Aurora db.r6g.large
├── 인스턴스: ~$350
├── 스토리지 100GB: ~$10
├── I/O: 사용량에 따라 변동
└── 총계: ~$380/월
DynamoDB 온디맨드
├── 읽기: 1억 × $0.285/100만 = ~$29
├── 쓰기: 1천만 × $1.425/100만 = ~$14
├── 스토리지 100GB: ~$25
└── 총계: ~$68/월
시험 팁
비용 포인트: 단순 키-값 워크로드는 DynamoDB가 비용 효율적. 복잡한 SQL 쿼리가 필요하면 RDS/Aurora가 적합.
SAA-C03 시험 출제 포인트
- ✅ 데이터 모델: 관계형 = RDS/Aurora, NoSQL = DynamoDB
- ✅ Aurora 성능: MySQL 5배, PostgreSQL 3배, 15개 읽기 복제본
- ✅ DynamoDB 특성: 서버리스, 무한 확장, 밀리초 지연시간
- ✅ Aurora 스토리지: 자동 확장, 128TiB, 6개 복사본
- ✅ DynamoDB 글로벌 테이블: 다중 리전 다중 마스터
- ✅ 용량 모드: 프로비저닝 vs 온디맨드
시험 팁
시험 문제 예시: "회사는 전 세계 사용자에게 한 자릿수 밀리초 지연시간으로 프로필 데이터를 제공해야 합니다. 데이터는 단순 키-값 형태입니다. 가장 적합한 솔루션은?" → 정답: DynamoDB 글로벌 테이블 (무한 확장 + 밀리초 응답 + 다중 리전)
자주 묻는 질문 (FAQ)
Q: Aurora와 RDS 중 무조건 Aurora를 선택해야 하나요?
아니요. Aurora는 성능이 뛰어나지만 비용이 20-30% 높습니다. 소규모 워크로드, 개발/테스트 환경, Oracle/SQL Server가 필요한 경우 RDS가 더 적합합니다.
Q: DynamoDB에서 JOIN이 필요하면 어떻게 하나요?
애플리케이션 레벨에서 처리합니다. DynamoDB는 JOIN을 지원하지 않으므로, 데이터를 비정규화하거나 여러 쿼리 결과를 애플리케이션에서 조합해야 합니다. JOIN이 많이 필요하면 RDS/Aurora를 고려하세요.
Q: Aurora Serverless는 언제 사용하나요?
트래픽이 불규칙하거나 간헐적일 때 적합합니다. 개발/테스트 환경, 야간에 트래픽이 없는 워크로드, 예측 불가능한 트래픽에 비용 효율적입니다. 24/7 안정적 트래픽에는 프로비저닝된 인스턴스가 저렴합니다.
Q: DynamoDB의 프로비저닝 용량과 온디맨드 중 어떤 것을 선택하나요?
트래픽 예측 가능성에 따라 결정합니다. 트래픽 패턴을 알면 프로비저닝(Auto Scaling)이 저렴합니다. 예측 불가능하거나 새로운 워크로드는 온디맨드로 시작 후 패턴 파악 후 전환을 고려하세요.
Q: RDS에서 Aurora로 마이그레이션이 쉬운가요?
MySQL/PostgreSQL이면 비교적 쉽습니다. RDS 스냅샷에서 Aurora 클러스터를 직접 생성할 수 있습니다. 다운타임을 최소화하려면 Aurora Read Replica를 생성 후 승격하는 방법도 있습니다.
Q: DynamoDB와 Aurora를 함께 사용할 수 있나요?
네, 하이브리드 아키텍처가 가능합니다. 트랜잭션 데이터는 Aurora에, 세션/캐시/빠른 조회 데이터는 DynamoDB에 저장하는 패턴이 일반적입니다.