AWS SAA-C03 스터디 노트 5편. 왜 AWS는 데이터베이스를 이렇게 많이 만들어 놨는지부터 풀어 가서 — RDS·Aurora 같은 관계형, ElastiCache 인메모리 캐시, DynamoDB NoSQL, DocumentDB·Neptune·Keyspaces·QLDB·Timestream·OpenSearch 같은 특수 목적 DB까지. 시나리오 키워드만 보고 정답 DB가 즉시 떠오르도록 비유와 함정 위주로 친절하게 풀어쓴 스터디 노트.
이 글은 AWS Certified Solutions Architect Associate(SAA-C03) 스터디 노트 시리즈의 다섯 번째 편입니다. 데이터베이스 단원은 처음 보면 좀 겁이 나는 영역이에요. 공부하다 보면 RDS·Aurora·DynamoDB·ElastiCache·DocumentDB·Neptune·Keyspaces·QLDB·Timestream·Redshift·OpenSearch — 이렇게 한 번에 열 개 넘는 서비스가 쏟아지거든요. "왜 이렇게 많이 만들어 놨지?" 싶고, 이름도 비슷비슷해서 한 번에 머리에 안 들어옵니다.
그런데 시험을 풀어 보면 이 단원이 의외로 점수 따기 쉬운 영역이에요. 왜냐하면 AWS 데이터베이스 문제는 거의 다 "이 시나리오에는 어떤 DB가 맞을까?" 형태거든요. 즉 시나리오의 키워드 몇 개만 보고 정답 DB가 떠오르면 — 그게 사실상 끝입니다. 복잡한 설정 디테일을 묻기보단, "MongoDB 마이그레이션이면?" "그래프 관계 탐색이면?" "마이크로초 지연이면?" 식으로 키워드 매칭을 묻는 문제가 대부분이에요.
이 글의 목표는 바로 그거예요. 시나리오 키워드만 보고 정답 DB가 0.5초 안에 떠오르도록 머리를 훈련하는 것. 그래서 이 글은 표가 많고, 비유로 하나하나 정리해 갑니다. RDS·Aurora·DynamoDB 셋이 시험 비중의 절반 이상이라, 한 번에 다 외우려 하지 말고 우선 이 셋의 차이부터 흐름을 잡고, 나머지 특수 목적 DB는 키워드 매칭으로 보강하는 게 빠릅니다.
왜 AWS는 데이터베이스를 이렇게 많이 만들어 놨을까요
먼저 큰 그림부터 잡고 갑니다. AWS의 데이터베이스 서비스가 이렇게 많은 이유는 단순해요 — 하나의 DB로 모든 워크로드를 처리하면 어느 하나도 잘 못 하기 때문입니다.
회사 비유로 풀어 봅시다. 회사 안에서도 도구를 용도별로 나눠 쓰잖아요. 직원 명부는 엑셀(행과 열이 정해진 정형 데이터), 사내 위키는 노션이나 컨플루언스(자유로운 문서), 채팅은 슬랙(실시간 짧은 메시지), 회계 장부는 이중 잠금된 ERP(불변·감사 가능). 이걸 엑셀 하나로 다 하라고 하면? — 가능은 한데 어느 것도 잘 못 합니다.
AWS도 똑같아요. 관계형이 잘하는 일(엑셀처럼 행과 열이 깔끔하고 SQL Join이 필요한 작업)은 RDS·Aurora가, NoSQL이 잘하는 일(자판기처럼 키 넣으면 값 나오는 단순 조회를 어마어마한 규모로)은 DynamoDB가, 그래프가 잘하는 일(친구의 친구의 친구 같은 관계 탐색)은 Neptune이 — 이렇게 목적 특화(Purpose-Built) DB로 쪼개 놨습니다.
그러니까 시험 시나리오에서 어떤 DB를 고를지 막막할 때는 — 데이터의 모양부터 봅니다. 엑셀처럼 행과 열이 깔끔한가, 아니면 자판기처럼 키-값으로 끝나는가, 친구 관계처럼 노드와 엣지로 그려야 하는가, 시간에 따른 측정값이 죽 늘어선가. 모양이 잡히면 카테고리가 좁혀지고, 카테고리가 좁혀지면 정답 DB가 한두 개로 줄어듭니다.
DB 카테고리 한눈에 — 키워드부터 잡기
| 카테고리 | AWS 서비스 | 키워드 |
|---|---|---|
| RDBMS (관계형) | RDS, Aurora | SQL, Join, 강한 스키마, OLTP |
| NoSQL (비관계형) | DynamoDB, DocumentDB, ElastiCache, Keyspaces | 유연한 스키마, Join 없음, 빠른 확장 |
| 데이터 웨어하우스 | Redshift, Athena, EMR | OLAP, BI, 대규모 분석 |
| 검색 (Search) | OpenSearch | 무료 텍스트 검색, 비구조 데이터 |
| 그래프 (Graph) | Neptune | 관계 탐색, 소셜·추천 |
| 원장 (Ledger) | QLDB | 불변 거래 장부, 변경 이력 증명 |
| 시계열 (Time Series) | Timestream | IoT, 시간 지표 |
| 객체 스토리지 | S3, Glacier | 대용량 객체, 백업·아카이빙 |
이 표가 사실 시험의 절반입니다. 시나리오에서 굵은 글씨 키워드 하나만 잡히면 카테고리가 정해지고, 그 안에서 답을 고르면 돼요.
RDS — 관리형 관계형 DB의 기본기
Amazon RDS(Relational Database Service) 부터 시작합니다. 이름 그대로 — 클라우드에서 관계형 DB를 쉽게 운영할 수 있게 해 주는 완전 관리형 서비스예요. 회사로 치면 — 우리가 직접 사옥에 서버 들이고 OS 깔고 DB 깔고 백업 돌리는 게 아니라, 외부 IT 파트너에게 통째로 맡긴 모델입니다. AWS가 OS 패치·백업·모니터링·장애 복구를 다 해 줘요. 엔진별 디테일이 더 궁금하면 RDS 공식 사용자 가이드를 한 번 훑어보면 좋습니다.
여기서 시험 함정이 하나 있어요. RDS는 SSH 접속이 안 됩니다. 관리형이라 기본 EC2에 직접 접근할 수 없어요. 회사 비유로 — IT 파트너가 관리하는 서버실에 우리가 마음대로 들어갈 수 없는 것과 같아요. "RDS에 SSH로 접속해서 OS 패치를…" 같은 보기가 나오면 무조건 오답입니다.
지원 엔진은 6+1 이렇게 외워두면 좋아요.
- PostgreSQL (포트 5432)
- MySQL (포트 3306)
- MariaDB (포트 3306)
- Oracle (포트 1521)
- Microsoft SQL Server (포트 1433)
- IBM DB2
- Amazon Aurora (MySQL 호환 3306, PostgreSQL 호환 5432)
포트 번호도 종종 출제됩니다. MySQL/MariaDB가 같은 3306이라는 점만 짚어두면 헷갈릴 일이 별로 없어요.
스토리지 Auto Scaling — 조건이 까다롭습니다
스토리지가 부족해지면 다운타임 없이 자동 확장됩니다. 단, 자동 확장이 발동되려면 세 조건이 모두 맞아야 해요.
- 사용 가능 여유 공간이 할당된 스토리지의 10% 미만
- 그 부족 상태가 5분 이상 지속
- 지난 스토리지 수정 이후 6시간 이상 경과
이 셋 중 하나라도 빠지면 자동 확장이 안 됩니다. 시험에 "스토리지가 99% 차 있는데 왜 확장이 안 됐는가?" 같은 시나리오가 나오면, 답은 거의 항상 "6시간 경과 조건을 못 채웠기 때문"이에요. 그리고 자동 확장을 쓰려면 최대 스토리지 임계값(Maximum Storage Threshold) 을 미리 설정해 둬야 합니다.
백업 — 자동과 수동, 두 종류
| 종류 | 보존 기간 | 용도 |
|---|---|---|
| 자동 백업 | 1~35일 (비활성화는 0으로 설정) | 매일 자동 + 트랜잭션 로그 매 5분마다 |
| 수동 스냅샷 | 영구(사용자가 삭제 전까지) | 장기 규정 준수, 35일 넘는 보존 |
여기서 두 가지 함정이 자주 나와요.
첫째, 복원하면 항상 새 DB 인스턴스가 생깁니다. 기존 DB를 그 자리에서 덮어쓸 수가 없어요. 그래서 복원 후엔 애플리케이션의 DB 엔드포인트를 새 인스턴스로 바꿔 줘야 합니다.
둘째, 간헐적으로만 쓰는 DB의 비용 절감 팁 — 수동 스냅샷을 만들고 원본 DB를 지워 버리는 거예요. 그러면 인스턴스 비용은 사라지고 스냅샷 스토리지 비용만 발생합니다. 나중에 필요하면 스냅샷에서 복원하면 끝. 시험에 "월에 몇 번만 쓰는 DB의 비용을 줄이려면?" 시나리오가 나오면 이게 정답이에요.
보안 — 암호화 함정 하나
저장 데이터 암호화는 AWS KMS로 처리하는데, DB 생성 시에만 활성화 가능합니다. 만든 후에는 못 바꿔요.
여기서 정말 자주 나오는 시험 함정이 있어요. 이미 만들어 둔 비암호화 DB를 암호화하려면 어떻게 해야 하느냐? — 정답은 "스냅샷을 만들고, 그 스냅샷을 암호화 옵션 켜서 새 인스턴스로 복원한다" 입니다. 직접 토글하는 메뉴는 없어요.
전송 중 암호화는 AWS TLS 루트 인증서로, IAM 데이터베이스 인증으로 비밀번호 없이 IAM 역할 기반 인증도 가능합니다. 감사 로그는 CloudWatch Logs로 내보내서 장기 보관해요.
RDS Custom과 RDS Proxy — 시험에 정말 자주 나옵니다
RDS의 두 변형 — Custom과 Proxy를 짚고 갑니다. 둘 다 시험 단골이에요.
RDS Custom — 관리자 접근이 필요한 특수 케이스
RDS Custom은 관리형의 이점을 그대로 가지면서 OS와 DB 환경에 관리자 접근 권한까지 주는 변형입니다. 회사 비유로 — IT 파트너에게 맡기되, 가끔은 우리가 서버실에 들어가서 직접 만져야 하는 특수한 경우에 쓰는 거예요.
여기서 시험 함정 — 지원 엔진은 Oracle과 SQL Server뿐입니다. MySQL/PostgreSQL/MariaDB는 안 돼요. "MySQL에 RDS Custom으로 OS 패치를…" 같은 보기는 무조건 오답.
SSH나 AWS Systems Manager(Session Manager)로 EC2 인스턴스에 직접 접근할 수 있고, 사용자 지정 작업 전엔 자동화 모드(Automation Mode) 비활성화 + 스냅샷 생성이 권장입니다.
RDS Proxy — Lambda + RDS의 단골 정답
RDS Proxy는 시험에 정말 자주 나옵니다. 한 줄로 풀면 — DB 앞에 두는 커넥션 풀링 프록시예요. 회사 비유로 — 빌딩 1층 안내데스크 같은 거예요. 방문자(Lambda)가 수천 명 몰려와도 안내데스크가 응대해서 실제 사무실(DB)로는 소수만 안내합니다.
핵심 기능 네 가지:
- 완전 관리형 서버리스, 트래픽에 따라 자동 확장, 고가용성(Multi-AZ)
- 커넥션 풀링 — DB에 대한 연결 수를 줄여 CPU·RAM 부하 ↓
- 장애 조치 시간 최대 66% 단축 — Primary → Standby 전환 시 앱이 인지 못 하게
- IAM 인증 강제 + AWS Secrets Manager 통합
- VPC 내부 전용 — 퍼블릭 인터넷 접근 불가
가장 자주 나오는 시나리오가 Lambda + RDS 커넥션 고갈 문제입니다. Lambda가 갑자기 동시에 수천 개 실행되면 — 각 실행마다 DB 커넥션을 따로 만들려고 해서 DB 커넥션 풀이 폭발해요. 이걸 RDS Proxy 끼우면 풀링으로 해결됩니다. 시험에 "Lambda가 RDS 연결 한도를 초과하는데 어떻게 해결?" 시나리오가 나오면 답은 무조건 RDS Proxy.
RDS Multi-AZ vs Read Replica — 데이터베이스 단원 최대 함정
이 둘이 시험에서 정말 헷갈려서 자주 출제됩니다. 둘 다 "DB를 여러 개 만든다"라는 점은 같은데, 목적이 완전히 달라요.
회사 비유로 풀면 — Multi-AZ는 보험이에요. 평소엔 안 쓰지만 본사에 불났을 때 자동으로 백업 사옥으로 옮겨가는 보험. 평상시엔 백업 사옥에 사람이 출입할 수 없습니다(쿼리 불가).
Read Replica는 분점이에요. 본점이 너무 바쁘니까 분점을 여러 개 열고, 손님(읽기 요청)을 분점으로 분산시키는 모델. 분점에서도 손님 응대(SELECT)가 가능합니다.
| 구분 | Multi-AZ | Read Replica |
|---|---|---|
| 목적 | 고가용성·DR | 읽기 성능 확장 |
| 복제 방식 | 동기식 (Synchronous) | 비동기식 (Asynchronous) |
| 대기 인스턴스 접근 | 접근 불가 (장애 조치 전용) | 읽기 전용으로 접근 가능 (SELECT만) |
| 장애 조치 | 자동, 단일 DNS 유지 | 자동 아님 (수동 승격 필요) |
| 앱 변경 | 불필요 (DNS 자동) | 엔드포인트 업데이트 필요 |
| 리전 | 동일 리전 다른 AZ | 동일/다른 AZ, 교차 리전 가능 |
| 비용 | 동일 리전 무료 | 교차 리전은 네트워크 비용 |
여기서 시험 함정이 줄줄이 있어요.
- Multi-AZ Standby는 쿼리 불가입니다. Active-Passive 구조라 평상시엔 응답 안 함. "Standby를 분석 쿼리에 사용하면…" 같은 보기는 오답.
- Multi-AZ 활성화는 다운타임 없이 클릭만으로 가능. 시험에 "Multi-AZ로 전환하려면 DB를 잠시 내려야 하는가?" → 아니요.
- 분석 쿼리가 프로덕션을 느리게 한다는 시나리오 → Read Replica로 분리가 정답.
- "코드 변경 없이 자동 DR" → Multi-AZ. DNS가 자동으로 따라가니까 앱은 모릅니다.
> 한 줄 암기 — Multi-AZ = 보험(쿼리 불가) / Read Replica = 분점(읽기 가능).
Aurora — AWS 독점 RDBMS, 6 복사본 아키텍처
Aurora는 AWS가 클라우드용으로 새로 만든 RDBMS예요. 그냥 RDS의 한 엔진이지만 — 내부 아키텍처가 완전히 다릅니다. MySQL과 PostgreSQL과 완벽 호환되면서 성능은 MySQL 대비 5배, PostgreSQL 대비 3배. 일반 RDS보다 약 20% 비싸지만 대규모에서는 오히려 비용 절감이 됩니다. 6 복사본 아키텍처의 디테일은 Aurora 사용자 가이드 쪽에 그림과 함께 정리돼 있어요.
스토리지 아키텍처 — 6 복사본의 의미
Aurora의 핵심 마법이 스토리지 아키텍처에 있어요. 이걸 한 번 이해하면 다른 게 다 풀려요.
- 3개 AZ에 걸쳐 총 6개 복사본 저장 (변경 불가)
- 쓰기는 6개 중 4개만 정상이면 가능 (AZ 1개 완전 장애에도 쓰기 OK)
- 읽기는 6개 중 3개만 정상이면 가능
- 자가 치유(Self-Healing) — P2P 복제로 손상 데이터 자동 복구
- 스토리지 자동 확장 — 10GB 시작 → 최대 128TB(일부 버전 256TB)
회사 비유로 풀면 — 중요한 계약서를 안전하게 보관하려고 3개 도시(AZ)에 각각 두 부씩, 총 6부를 보관하는 거예요. 한 도시가 통째로 무너져도 다른 4부가 살아 있으면 새 계약을 쓸 수 있고(쓰기), 3부만 살아 있어도 계약 내용을 확인할 수 있어요(읽기). 그리고 손상된 사본은 알아서 다른 사본을 보고 복구합니다.
숫자 4·3·6만 머리에 박아 두면 시험에서 함정에 안 빠져요.
읽기 복제본과 엔드포인트
- 최대 15개 읽기 복제본 (RDS는 최대 5개)
- 복제 지연 일반적으로 10ms 미만
- 마스터 장애 시 30초 이내 자동 장애 조치
엔드포인트는 셋으로 나뉘는데, 시험에 자주 나옵니다.
| 엔드포인트 | 용도 |
|---|---|
| Writer Endpoint (클러스터) | 항상 현재 마스터를 가리킴, 쓰기용 |
| Reader Endpoint | 모든 읽기 복제본에 연결 수준 로드 밸런싱, 읽기용 |
| Custom Endpoints | 특정 인스턴스 부분집합으로 별도 엔드포인트 (예: 무거운 OLAP 쿼리용 고성능 복제본 따로 묶기) |
> 시험 단골 — Reader Endpoint가 하는 로드 밸런싱은 연결(Connection) 수준이지 쿼리 수준이 아니라는 점만 기억해 두세요.
Aurora의 변형들 — Serverless·Multi-Master·Global·ML
Aurora는 기본형 외에 변형이 여럿입니다. 각각 어떤 시나리오에 맞는지 키워드로 잡으면 돼요.
Aurora Serverless는 ACU(Aurora Capacity Units) 단위로 자동 확장·축소, 초당 과금입니다. 키워드 — 예측 불가, 간헐적, 용량 계획 불필요. v2부터는 프로덕션에도 충분히 쓸 만해요. 비유하자면 — 평상시엔 직원 0명이다가 손님 오면 자동으로 충원되는 팝업 가게 같은 거.
Aurora Multi-Master는 여러 Writer 노드를 동시에 운영하는 구성. 쓰기 고가용성이 필요한 특수 케이스에서.
Aurora Global Database는 전 세계 규모 시나리오의 답입니다.
- 1개 기본 리전(읽기/쓰기) + 최대 10개 보조 리전(읽기 전용, 리전당 최대 16개 복제본)
- 복제 지연 평균 1초 미만
- 기본 리전 장애 시 보조 리전 승격 RTO 1분 미만
- 키워드 — 리전 간 DR, 글로벌 읽기 지연 최소화
Aurora Machine Learning은 SQL 쿼리에서 AWS ML 서비스를 직접 호출. 둘만 외워두면 됩니다.
- Amazon SageMaker — 사용자 지정 ML 모델 (추천·사기 탐지)
- Amazon Comprehend — 텍스트 감정 분석(Sentiment Analysis)
Aurora 특수 기능 셋 — Backtrack·Clone·Babelfish
| 기능 | 한 줄 설명 |
|---|---|
| Backtrack | 스냅샷 복원 없이 DB를 특정 과거 시점으로 즉시 되감기 |
| Database Cloning | Copy-on-Write 프로토콜, 스냅샷 복원보다 훨씬 빠름 (스테이징 환경 구성에 자주) |
| Babelfish | SQL Server T-SQL → Aurora PostgreSQL이 이해하도록 번역하는 계층, 마이그레이션 시 코드 최소 변경 |
여기서 시험 단골이 둘 — "SQL Server를 Aurora로 옮기되 코드 변경 최소화" → Babelfish, "스냅샷 복원보다 빠른 스테이징 환경 구성" → Database Cloning.
Aurora 백업 함정
Aurora 백업의 가장 큰 함정 — 자동 백업을 비활성화할 수 없습니다. RDS는 자동 백업을 끄려면 보존 기간을 0으로 설정하면 되는데, Aurora는 그게 안 돼요. 시험에 "Aurora 자동 백업을 끄려면…" 같은 보기는 무조건 오답.
S3에 있는 온프레미스 DB 백업을 Aurora로 복원하려면 — Percona XtraBackup 도구로 백업해서 S3에 올린 뒤 Aurora MySQL 클러스터로 복원합니다. 도구 이름이 시험에 그대로 나와요.
ElastiCache — 캐시는 자판기, 그런데 코드 바꿔야 합니다
ElastiCache는 관리형 인메모리(In-Memory) 캐시 서비스입니다. Redis와 Memcached 두 엔진을 지원하고, 밀리초 미만(Sub-millisecond) 의 지연 시간을 제공해요.
회사 비유로 풀면 — 자주 쓰는 서류를 매번 지하 보관함(DB)까지 가서 꺼내 오는 게 아니라, 책상 위 자판기 형 캐시에 자주 쓰는 사본을 두고 빠르게 꺼내는 거예요. 자판기에 없으면(Cache Miss) 그때만 지하로 내려갑니다.
여기서 정말 중요한 시험 함정 — ElastiCache 도입 시 애플리케이션 코드 수정이 필수입니다. 캐시를 먼저 조회하도록 로직을 바꿔야 해요. RDS Proxy처럼 앞단에 그냥 끼우는 게 아니라, 앱 자체가 "먼저 캐시 보고 없으면 DB" 흐름으로 코드를 짜야 합니다.
> "코드 변경 없이 성능 향상"이 시나리오에 나오면 ElastiCache는 무조건 오답. 이건 시험에 한 번씩 꼭 나오는 함정이에요.
주요 사용 사례 둘.
- DB 부하 감소 — 공통 쿼리 결과 캐싱으로 RDS 읽기 부하 절감
- 세션 저장소 — 애플리케이션 서버를 Stateless로 만들어 확장성 향상
Redis vs Memcached — 단골 비교표
| 구분 | ElastiCache for Redis | ElastiCache for Memcached |
|---|---|---|
| 고가용성 | Multi-AZ + 자동 장애 조치 | 없음 |
| 복제 | 읽기 전용 복제본 지원 | 없음 |
| 데이터 보존 | 백업·복원 지원, 데이터 내구성 | 재시작 시 데이터 유실 |
| 데이터 구조 | String, Hash, List, Set, Sorted Set | 단순 Key-Value |
| 인증 | Redis AUTH, IAM 인증, SSL/TLS | SASL 기반 인증 |
| 확장 방식 | 읽기 복제본 추가 | 다중 노드 샤딩(Sharding) |
| 특수 기능 | Pub/Sub, Transactions, 스크립팅 | 멀티 스레드 아키텍처 |
| 사용 사례 | 리더보드, 세션 저장, 복잡한 데이터 구조 | 단순 캐싱, 고속 멀티스레드 처리 |
키워드 매칭으로 외우면 됩니다.
- 고가용성·데이터 보존이 중요 → Redis (Memcached는 둘 다 없음)
- 리더보드(실시간 순위) → Redis의 Sorted Set
- 단순 고속 캐싱·멀티 스레드 → Memcached
- SASL 인증 → Memcached (Redis는 Redis AUTH)
클러스터 모드와 캐싱 전략
클러스터 모드는 두 가지:
- 비활성화 — 단일 샤드, 1개 Primary + 최대 5개 Read Replica
- 활성화 — 여러 샤드에 데이터 분산, 수평 확장
캐싱 전략 셋도 자주 나옵니다.
| 전략 | 설명 | 장단점 |
|---|---|---|
| Lazy Loading (지연 로딩) | 캐시 조회 → Cache Miss 시 DB 조회 후 캐시에 저장 | 요청된 데이터만 캐시 / Stale 가능 |
| Write Through | DB에 쓸 때마다 캐시도 함께 업데이트 | 항상 최신 / 쓰기 지연 ↑, 캐시 공간 낭비 |
| Session Store | 사용자 세션 데이터를 ElastiCache에 + TTL로 만료 관리 | Stateless 앱 / 앱 코드 수정 필요 |
Redis AUTH는 전송 중 암호화가 활성화돼 있어야만 사용 가능하다는 점도 꽤 자주 나오는 디테일입니다.
DynamoDB — 자판기 모델의 끝판왕
DynamoDB는 AWS의 완전 관리형 서버리스 NoSQL 데이터베이스입니다. 기본 밀리초 지연, 여러 AZ 자동 복제, IAM 통합 인증.
비유로 풀면 — Aurora가 "잘 정리된 도서관"이라면, DynamoDB는 거대한 자판기 단지예요. 아주 많은 사람이 동시에 와서 키 넣고 값 받아가는 시나리오에 최적화돼 있습니다. 대신 자판기끼리 데이터를 합쳐 보거나(Join) 복잡한 검색은 잘 못 해요.
키 구조 — Partition Key와 Sort Key
DynamoDB의 키 구조는 두 부분.
- Partition Key — 테이블의 기본 키, 데이터 분산의 기준
- Sort Key — 선택적, Partition Key와 합쳐 복합 기본 키 구성
같은 Partition Key + 다른 Sort Key 조합으로 여러 항목을 저장할 수 있어요. 예를 들어 userId(파티션) + timestamp(정렬)로 한 사용자의 시간순 활동을 정렬해서 저장하는 식.
용량 모드 — 시험 단골
| 모드 | 특징 | 사용 사례 |
|---|---|---|
| Provisioned (프로비저닝) | RCU/WCU 미리 설정, Auto Scaling 결합 | 예측 가능, 서서히 변동 |
| On-Demand (온디맨드) | 자동 확장·축소, 사전 설정 X | 예측 불가, 급격한 트래픽 급증 |
RCU/WCU 계산 기준도 외워두면 좋아요.
- RCU(Read Capacity Unit) — 강한 일관성 = 4KB 1회 읽기 / 최종 일관성 = RCU 절반 소비
- WCU(Write Capacity Unit) — 1KB 1회 쓰기
> 키워드 — "예측 불가·급격한 스파이크" → On-Demand, "예측 가능·안정적" → Provisioned.
DynamoDB의 위성 기능들 — DAX·Streams·Global Tables·TTL
DynamoDB는 본체만으로도 강력한데, 주변 기능들이 시험에 정말 자주 나옵니다.
DAX — 마이크로초의 절대 키워드
DAX(DynamoDB Accelerator) 는 DynamoDB와 완전 호환되는 인메모리 읽기 캐시예요. 밀리초(ms) → 마이크로초(μs) 수준으로 단축됩니다.
여기서 시험 황금 룰 하나 — "마이크로초"라는 단어가 보이면 답은 무조건 DAX입니다. DynamoDB 자체로는 밀리초까지가 한계라서, "더 빠른 응답이 필요" + "DynamoDB" 조합이면 정답이 DAX로 바로 떨어져요. 그리고 DAX는 애플리케이션 코드 변경 없이도 투명하게 통합되는 게 ElastiCache와 다른 점.
Streams — 변경 이벤트를 Lambda로
DynamoDB Streams는 테이블의 데이터 변경(생성·수정·삭제)을 스트림으로 캡처해서, Lambda 함수를 트리거할 수 있어요.
전형적인 패턴 — "주문 테이블에 새 주문 INSERT → Streams가 캡처 → Lambda 실행 → 확인 이메일 발송." 이벤트 기반 처리에 정말 자주 씁니다. Kinesis Data Streams 통합으로 최대 1년 장기 보관도 가능하고요.
Global Tables — Active-Active 멀티 리전
Global Tables는 여러 리전에 걸친 Active-Active 복제입니다. 전 세계 어디서든 짧은 지연으로 읽기와 쓰기 모두 가능해요. Aurora Global Database가 보조 리전은 읽기 전용인 것과 다른 점이에요.
> 시험 키워드 — "Active-Active 멀티 리전 NoSQL" → DynamoDB Global Tables.
TTL — 자동 만료
TTL(Time To Live) 은 특정 시간이 지나면 항목을 자동으로 만료(삭제)시키는 기능. 세션 데이터처럼 일정 시간 후엔 필요 없는 데이터에 정말 비용 효율적입니다.
백업과 S3 통합
DynamoDB 백업은 둘.
- PITR(Point-in-Time Recovery) — 최대 35일 이내 어느 초 단위 시점으로든 복원
- 온디맨드 백업 — 장기 보관용
복원 결과는 RDS와 마찬가지로 항상 새 테이블이 생깁니다.
S3 통합도 자주 나오는데, 핵심은 RCU/WCU 소비 없이 처리된다는 점이에요.
- Export to S3 — PITR 활성화 시 RCU 소비 없이 데이터를 S3로 내보내기
- Import from S3 — WCU 소비 없이 새 테이블로 데이터 가져오기
"DynamoDB 데이터를 S3에 내보내는데 운영 영향 없이…" 시나리오의 답이 이쪽입니다.
특수 목적 DB — 키워드 매칭이 전부
이 영역은 시나리오 키워드 ↔ 정답 DB의 1:1 매칭만 외워두면 시험에서 무조건 점수예요. 비유 같은 거 안 들어가요. 키워드만 잡으세요.
| 서비스 | 시나리오 키워드 | 핵심 한 줄 |
|---|---|---|
| DocumentDB | MongoDB | Aurora 아키텍처, 3 AZ 복제, 10GB 자동 확장, 초당 수백만 요청 |
| Neptune | 그래프, 관계 탐색, 소셜·추천 | 3 AZ 복제, 최대 15개 읽기 복제본, Neptune Streams로 변경 캡처 |
| Keyspaces | Apache Cassandra, CQL | 서버리스, Multi-AZ 3중 복제, On-Demand/Provisioned, PITR 35일 |
| QLDB | 불변 거래 장부, 변경 이력 증명 | 절대 삭제·수정 불가, 암호화학적 불변성 증명 |
| Timestream | 시계열, IoT 센서, 시간 지표 | 메모리/저렴한 스토리지 자동 계층화, SQL, 하루 수조 건 |
| OpenSearch | 무료 텍스트 검색, 로그 분석 | 비구조 데이터 검색, ELK 스택 |
조금 더 풀어 보면 —
- DocumentDB는 한마디로 AWS판 MongoDB. 시나리오에 MongoDB가 보이면 무조건 이쪽.
- Neptune은 친구의 친구의 친구 같은 관계 탐색에 특화. 소셜 네트워크·추천 엔진·사기 감지·지식 그래프가 키워드.
- Keyspaces는 Cassandra/CQL을 그대로 쓰면서 관리는 AWS에 맡기고 싶을 때. 기존 CQL 코드를 안 바꿔도 됩니다.
- QLDB는 금융 거래 기록처럼 한 번 쓰면 절대 못 바꾸는 장부. "불변", "암호화 증명"이 보이면 이쪽.
- Timestream은 IoT 센서 데이터처럼 시간순으로 쌓이는 측정값. 자동으로 최근 데이터는 메모리, 과거 데이터는 저렴한 스토리지로 옮겨서 비용 최적화.
- OpenSearch는 로그 검색·자유 텍스트 검색의 답. ELK 스택을 AWS에서 매니지드로.
SQL vs NoSQL 선택 기준
마지막으로 시험에서 가끔 나오는 큰 그림 — 언제 SQL이고 언제 NoSQL인지의 기준입니다.
| 기준 | SQL (RDS/Aurora) | NoSQL (DynamoDB) |
|---|---|---|
| 데이터 구조 | 강한 스키마, 정형 | 유연한 스키마, 반정형 |
| 쿼리 복잡성 | 복잡한 Join, 집계 | 단순 Key-Value, Document |
| 트랜잭션 | ACID 필수 | 일부 지원 (제한적) |
| 확장성 | 수직 확장(Scale-Up) | 수평 확장(Scale-Out) |
| 일관성 | 강한 일관성 | 최종 일관성 (기본) |
| 데이터 크기 | GB~TB | TB~PB까지 무한 확장 |
시험에서 "강한 스키마와 복잡 Join이 필요하면?" → SQL, "유연한 스키마와 무한 수평 확장이 필요하면?" → NoSQL. 이 두 줄로 거의 끝나요.
RDS vs Aurora vs DynamoDB — 한 표로 비교
| 구분 | RDS | Aurora | DynamoDB |
|---|---|---|---|
| 타입 | 관계형 | 관계형 | NoSQL |
| 엔진 | MySQL, PostgreSQL, Oracle, SQL Server, MariaDB, DB2 | MySQL, PostgreSQL 호환 | 독자적 |
| 스토리지 | EBS, Auto Scaling | 자동 확장 (10GB~128TB) | 서버리스, 무제한 |
| 복제본 | 최대 5개 Read Replica | 최대 15개 Read Replica | Global Tables (Active-Active) |
| 장애 조치 | 수동 또는 Multi-AZ | 자동 (30초 이내) | 자동 (Multi-AZ 기본) |
| SQL | 완전 지원 | 완전 지원 | 미지원 |
| 관리 수준 | 관리형 (OS 접근 X) | 관리형 (OS 접근 X) | 완전 서버리스 |
| 사용 사례 | OLTP, 기존 RDBMS 마이그레이션 | 고성능 RDBMS, 글로벌 서비스 | 서버리스 앱, 게임, IoT |
시나리오 매칭 — 시험 직전 한 번 더
이 표가 사실상 데이터베이스 단원의 정답지예요. 시험 직전에 이 표만 한 번 더 보면 됩니다.
| 시나리오 키워드 | 정답 |
|---|---|
| Lambda + RDS 커넥션 초과 | RDS Proxy |
| Failover 시간 단축 + IAM 인증 강제 | RDS Proxy |
| 분석 쿼리로 프로덕션 DB 느려짐 | Read Replica |
| 코드 변경 없이 자동 DR | Multi-AZ |
| 마이크로초 지연 | DAX |
| MongoDB 마이그레이션 | DocumentDB |
| Cassandra·CQL 유지 마이그레이션 | Keyspaces |
| 불변 금융 거래 기록 | QLDB |
| IoT 센서, 시계열 | Timestream |
| 소셜 네트워크 관계, 그래프 | Neptune |
| 리더보드 (실시간 순위) | Redis Sorted Set |
| 예측 불가 DB 트래픽 | Aurora Serverless 또는 DynamoDB On-Demand |
| SQL Server → Aurora, 코드 최소 변경 | Aurora Babelfish |
| 글로벌 읽기 지연 + 리전 장애 복구 | Aurora Global Database |
| Active-Active 멀티 리전 NoSQL | DynamoDB Global Tables |
| 데이터 변경 시 Lambda 트리거 | DynamoDB Streams |
| Aurora 감정 분석 | Aurora ML + Comprehend |
| Aurora 커스텀 ML 모델 | Aurora ML + SageMaker |
| 스냅샷 복원보다 빠른 스테이징 환경 | Aurora Database Cloning |
| S3 내보내기에 RCU 영향 없이 | DynamoDB Export to S3 + PITR |
시험 직전 한 번 더 — 자주 헷갈리는 함정 모음
여기까지가 데이터베이스 영역의 핵심입니다. 시험 직전에 다시 펼쳐 볼 압축 노트를 박아 둘게요.
- RDS는 SSH 접속 불가 (관리형) — "OS 직접 패치" 보기는 오답
- 자동 백업 보존 1~35일, 수동 스냅샷은 영구
- 복원 결과는 항상 새 인스턴스/새 테이블 — 덮어쓰기 불가
- 암호화 활성화는 DB 생성 시에만 — 기존 DB는 스냅샷 → 암호화 복원
- Storage Auto Scaling — 10% 미만 + 5분 + 6시간 셋 다 충족
- RDS Custom = Oracle / SQL Server 전용 (MySQL/PostgreSQL 안 됨)
- RDS Proxy = VPC 내부 전용, 퍼블릭 X
- Lambda + RDS 커넥션 고갈 = RDS Proxy가 정답
- Multi-AZ = 동기 복제 + 단일 DNS + Standby 쿼리 불가
- Read Replica = 비동기 복제 + 엔드포인트 변경 + SELECT 가능
- Multi-AZ 활성화는 다운타임 없이 클릭만으로 가능
- Aurora 스토리지 — 3 AZ × 6 복사본, 쓰기 4/6, 읽기 3/6
- Aurora Read Replica 최대 15개, 자동 장애 조치 30초 이내
- Aurora 자동 백업 비활성화 불가 (RDS와 차이)
- Aurora Serverless 키워드 = 예측 불가 / 간헐적 / 용량 계획 X
- Aurora Global DB — 복제 < 1초, RTO < 1분
- Aurora Babelfish — SQL Server T-SQL → Aurora PostgreSQL
- Aurora Clone — Copy-on-Write, 스냅샷보다 빠름
- S3 → Aurora 복원 = Percona XtraBackup
- ElastiCache 도입 시 앱 코드 수정 필수 — "코드 변경 없이"는 오답
- Memcached — HA 없음, 데이터 영속성 없음, SASL 인증
- Redis — Multi-AZ + Auto-Failover, Sorted Set 리더보드
- Redis AUTH는 전송 중 암호화 활성화 시에만 사용 가능
- DynamoDB — 마이크로초 = DAX, 예측 불가 = On-Demand
- DynamoDB PITR 최대 35일, 복원은 새 테이블
- DynamoDB Streams → Lambda 트리거
- DynamoDB Global Tables = Active-Active 멀티 리전
- DynamoDB Export to S3 → PITR 활성화 시 RCU 소비 X
- DocumentDB = MongoDB / Neptune = 그래프 / Keyspaces = Cassandra·CQL
- QLDB = 불변 원장 / Timestream = 시계열·IoT / OpenSearch = 검색·로그
이만큼만 머리에 들어와 있으면 데이터베이스 단원 시나리오 문제는 거의 다 풀려요. 서비스 이름이 많아서 처음엔 헷갈리지만, 카테고리 → 시나리오 키워드 → 정답 DB 흐름만 잡고 가면 의외로 점수 따기 쉬운 영역입니다.
다음 글(6편)에서는 VPC·Route 53·CloudFront·Global Accelerator 같은 네트워킹·DNS 영역을 정리해요. SAA에서 데이터베이스만큼이나 헷갈리는 영역이지만, 한 번 잡아두면 시험 후반부 시나리오 문제가 정말 빠르게 풀립니다.
시리즈 다른 편
같은 시리즈의 다른 글들도 같은 친절 톤으로 묶어 정리되어 있어요.