SAABlog
데이터베이스중급

RDS vs Aurora vs DynamoDB: AWS 데이터베이스 선택 가이드

관계형은 RDS/Aurora, 비관계형은 DynamoDB. SAA-C03 시험에서 자주 출제되는 AWS 데이터베이스 서비스의 특징과 선택 기준을 정리합니다.

PHILOLAMB-
RDSAuroraDynamoDB데이터베이스NoSQL

관련 시험 도메인

  • 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

세 가지 서비스 한눈에 비교

비교 항목RDSAuroraDynamoDB
데이터 모델관계형 (SQL)관계형 (SQL)비관계형 (NoSQL)
지원 엔진MySQL, PostgreSQL, MariaDB, Oracle, SQL ServerMySQL, PostgreSQL키-값, 문서
최대 스토리지64TiB128TiB (자동 확장)무제한
읽기 복제본최대 5개최대 15개글로벌 테이블
자동 장애 조치Multi-AZ 필요기본 제공기본 제공
서버리스 옵션✅ Aurora Serverless✅ 완전 서버리스
관리 수준관리형관리형완전 관리형
비용 모델인스턴스 + 스토리지인스턴스 + I/ORCU/WCU 또는 온디맨드

Amazon RDS

RDS란?

RDS(Relational Database Service)는 관계형 데이터베이스를 쉽게 설정, 운영, 확장할 수 있는 관리형 서비스입니다. 하드웨어 프로비저닝, 데이터베이스 설정, 패치, 백업을 자동화합니다.

RDS 관리 범위:

AWS가 관리         │ 사용자가 관리
──────────────────┼──────────────────
하드웨어           │ 스키마 설계
OS 패치           │ 쿼리 최적화
DB 엔진 패치       │ 인덱스 관리
백업              │ 애플리케이션 코드
고가용성 (Multi-AZ) │ 파라미터 튜닝

RDS 지원 데이터베이스 엔진

엔진특징적합한 경우
MySQL오픈소스, 가장 보편적웹 애플리케이션, 범용
PostgreSQL고급 기능, GIS 지원복잡한 쿼리, 분석
MariaDBMySQL 포크, 커뮤니티MySQL 대안 필요 시
Oracle엔터프라이즈 기능기존 Oracle 워크로드
SQL ServerMicrosoft 생태계.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 비교

항목RDSAurora
성능기준선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 시험 출제 포인트

  1. 데이터 모델: 관계형 = RDS/Aurora, NoSQL = DynamoDB
  2. Aurora 성능: MySQL 5배, PostgreSQL 3배, 15개 읽기 복제본
  3. DynamoDB 특성: 서버리스, 무한 확장, 밀리초 지연시간
  4. Aurora 스토리지: 자동 확장, 128TiB, 6개 복사본
  5. DynamoDB 글로벌 테이블: 다중 리전 다중 마스터
  6. 용량 모드: 프로비저닝 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에 저장하는 패턴이 일반적입니다.

관련 글

참고 자료