DynamoDB vs RDS: AWS 데이터베이스 선택 기준
AWS에서 데이터베이스를 고를 때 가장 자주 마주치는 갈림길은 DynamoDB와 RDS입니다. 결론을 먼저 적으면, 액세스 패턴이 몇 가지로 고정되는 대량·가변 트래픽 워크로드는 DynamoDB, 조인과 집계, 애드혹 쿼리가 필요한 업무 데이터는 RDS입니다. 어느 쪽이 좋은 데이터베이스인가의 문제가 아니라, 쿼리를 지금 아는가와 나중에 정하는가의 문제입니다. RDS 쪽 세부 선택(인스턴스 클래스, Aurora 여부)은 RDS 인스턴스 클래스와 Aurora vs RDS에서 다뤘습니다. 요금은 us-east-1 기준입니다.
한눈에 보는 비교 #
| 구분 | DynamoDB | RDS |
|---|---|---|
| 데이터 모델 | 키-밸류·문서 | 관계형 (MySQL, PostgreSQL 등) |
| 쿼리 | 키 기반 조회 + 보조 인덱스 | SQL (조인, 집계, 애드혹) |
| 스키마 | 유연 (항목별 속성 자유) | 고정 (테이블 정의) |
| 확장 | 자동 수평 확장, 사실상 무제한 | 인스턴스 크기 + 리드 레플리카 |
| 운영 | 서버리스 (인스턴스 없음) | 인스턴스 관리 (패치는 자동화) |
| 과금 | 요청 단위 + 저장 용량 | 인스턴스 시간 + 스토리지 |
| 유휴 비용 | 0에 수렴 (온디맨드) | 인스턴스가 떠 있는 한 발생 |
모델 차이: 쿼리를 언제 정하는가 #
DynamoDB는 액세스 패턴을 테이블 설계 시점에 고정하는 데이터베이스입니다. 파티션 키로 항목을 찾고, 정렬 키로 범위를 자르고, 그 밖의 조회는 보조 인덱스(GSI)를 미리 만들어 둬야 합니다. 그 대가로 얻는 것이 확장의 자유입니다. 트래픽이 10배가 되어도 지연이 한 자릿수 밀리초로 유지되고, 파티션이 자동으로 늘어나며, 인스턴스라는 개념 자체가 없어 운영에 손이 거의 들지 않습니다.
RDS는 쿼리를 나중에 정할 수 있는 데이터베이스입니다. 정규화된 테이블에 데이터를 넣어 두면 조인, 집계, 서브쿼리로 어떤 질문이든 던질 수 있습니다. 보고서, 관리 화면, “이번 달 카테고리별 매출” 같은 요구는 SQL이 아니면 풀기 어렵습니다. 대가는 확장의 상한입니다. 쓰기는 결국 인스턴스 한 대의 수직 확장에 기대고, 읽기 분산도 레플리카 관리라는 운영을 동반합니다.
이 차이가 실무 판단 기준이 됩니다. “어떤 쿼리가 들어올지 지금 다 말할 수 있는가?” 장바구니, 세션, 주문 처리, IoT 이벤트처럼 패턴이 고정된 워크로드는 DynamoDB에 잘 맞고, 질문이 계속 바뀌는 업무 데이터는 RDS가 맞습니다.
요금: 요청당 vs 시간당 #
DynamoDB 온디맨드는 요청 단위 과금입니다. 쓰기 100만 건당 약 $0.625, 읽기(강한 일관성 기준) 100만 건당 약 $0.125이고(2024년 11월 50% 인하 반영, 최종 일관성 읽기는 그 절반), 저장은 GB·월당 약 $0.25(첫 25GB 무료)입니다. 트래픽이 없으면 요금도 0에 수렴하고, 스파이크가 와도 요청 수만큼만 냅니다. 예측 가능한 상시 트래픽이라면 프로비저닝드 모드와 예약 용량으로 단가를 더 내릴 수 있습니다. 예약 체계는 RI vs Savings Plans에서 다룬 대로 SP가 아니라 DynamoDB 자체의 예약 용량입니다.
RDS는 인스턴스 시간당 과금입니다. db.t4g.micro가 월 약 $12, 프로덕션에서 흔한 db.m8g.large가 월 약 $123(단일 AZ)이고 스토리지가 더해집니다. 트래픽과 무관하게 나가는 고정비이므로, 사용률이 낮은 DB일수록 요청당 환산 단가가 나빠집니다.
교차점 계산은 단순합니다. 월 요청이 수백만 건대라면 DynamoDB 요금은 몇 달러라 비교 자체가 성립하지 않습니다. 월 수십억 건, 상시 고트래픽에 이르면 요청당 과금 총액이 인스턴스 고정비를 넘기 시작하고, 그때는 프로비저닝드 모드 전환이나 RDS와의 재비교가 필요해집니다.
DynamoDB의 함정: 청구서와 설계 양쪽에서 나옵니다 #
- GSI는 쓰기 비용의 배수입니다: GSI마다 항목 변경이 복제되므로, GSI 3개짜리 테이블의 쓰기 요금은 대략 4배가 됩니다. “혹시 몰라서” 만든 인덱스가 청구서 금액을 그만큼 키웁니다.
- 스캔은 반칙입니다: 테이블 전체 스캔은 읽은 용량 전부에 과금되고 느립니다. 스캔이 정기적으로 필요해졌다는 것은 액세스 패턴 설계가 깨졌다는 신호이고, RDS나 분석 스택으로 데이터를 내보낼 시점입니다.
- 핫 파티션: 특정 파티션 키에 트래픽이 몰리면 용량이 남아도 스로틀링이 걸립니다. 키 설계가 성능 설계 그 자체입니다.
- 트랜잭션은 2배: 트랜잭션 읽기·쓰기는 일반 요청의 2배 과금입니다. 트랜잭션이 광범위하게 필요한 도메인이라면 애초에 관계형이 맞는지부터 다시 봅니다.
- RDS 쪽 함정: 반대로 RDS를 서버리스 스택(Lambda 등)과 조합하면 커넥션 폭주 문제가 있어 RDS Proxy 같은 계층이 추가로 필요합니다. DynamoDB는 HTTP API라 이 문제가 없습니다.
선택 순서 #
- 쿼리를 지금 아는지부터 봅니다: 액세스 패턴을 열거할 수 있으면 DynamoDB 후보, “무슨 질문이 올지 모른다"면 RDS입니다.
- 조인·집계·애드혹 요구를 확인합니다: 보고서와 관리 화면이 DB에 직접 붙어야 하면 RDS로 확정입니다. DynamoDB에서 이를 흉내 내는 설계는 대부분 후회로 끝납니다.
- 트래픽 패턴을 봅니다: 유휴 시간이 길거나 스파이크가 큰 워크로드는 온디맨드 DynamoDB가 요금 구조상 유리합니다. 상시 균일 고트래픽은 프로비저닝드 모드 또는 RDS와 비교합니다.
- 쓰기 비용을 GSI 포함으로 검산합니다: 항목 크기 × 쓰기 수 × (1 + GSI 수)로 계산해야 실제 청구서에 가깝습니다.
- 병행을 검토합니다: 실서비스 경로(주문, 세션)는 DynamoDB, 분석·보고는 RDS나 웨어하우스로 나누고 스트림으로 잇는 구성으로 정리되는 경우가 많습니다. 하나로 다 풀 필요가 없습니다.
정리 #
- 액세스 패턴이 고정된 대량·가변 트래픽은 DynamoDB, 조인·집계·애드혹 쿼리는 RDS입니다. “쿼리를 지금 아는가"가 첫 질문입니다.
- 과금 구조가 다릅니다. DynamoDB 온디맨드는 요청당(쓰기 100만 건 약 $0.625)이라 유휴 비용이 0에 수렴하고, RDS는 인스턴스 시간당이라 사용률이 낮을수록 손해입니다.
- GSI는 쓰기 요금을 배수로 만들고, 스캔은 설계 실패의 신호입니다. DynamoDB 비용 검산은 GSI 포함이 기본입니다.
- 트랜잭션 중심, 질문이 바뀌는 업무 데이터를 DynamoDB에 욱여넣는 것이 가장 흔한 실패 패턴입니다. 반대 방향(고정 패턴을 RDS에)은 비용과 확장에서 손해를 봅니다.
- 실서비스 경로는 DynamoDB, 분석은 관계형이라는 병행 구성이 흔한 정답입니다. 예약 할인은 SP가 아니라 DynamoDB 예약 용량·RDS RI로 각각 겁니다.