DynamoDB
서버리스 NoSQL. 한 자릿수 밀리초 지연과 무제한 확장
이게 뭔가요? / What is this?
DynamoDB는 서버나 인스턴스가 아니라, 용량 계획이나 서버 사양 걱정 없이 데이터를 저장하고 꺼내 쓰는 완전 관리형 서버리스 데이터베이스입니다. 크기를 미리 정할 필요 없는 무한히 늘어나는 서랍장처럼, 데이터가 얼마나 쌓이든 AWS가 뒤에서 알아서 공간을 늘려주고 사용자는 항목을 넣고 빼는 것만 신경 쓰면 됩니다.
개요 / Overview
DynamoDB는 키-값·문서 데이터베이스로 용량 계획 없이 확장되고 관리 부담이 거의 없습니다. "수백만 사용자", "밀리초 응답", "스키마가 유연", "서버리스"가 함께 나오면 DynamoDB입니다. 반대로 복잡한 조인이나 트랜잭션 리포팅이 필요하면 RDS/Aurora로 갑니다.
동작 원리 / How it works
DynamoDB는 파티션 키의 해시로 데이터를 물리 파티션에 분산합니다. 이 구조 때문에 파티션 키를 알고 하는 조회는 항상 한 자릿수 밀리초이지만, 키를 모르고 전체를 훑는 Scan은 느리고 비쌉니다. 즉 DynamoDB 설계는 "어떤 질의를 할지 먼저 정하고 그에 맞춰 키를 정하는" 순서이며, 관계형처럼 나중에 임의 조건으로 조회하는 유연성은 없습니다.
보조 인덱스가 이 제약을 완화합니다. LSI는 같은 파티션 키에 다른 정렬 키를 주고, GSI는 완전히 다른 파티션 키로 별도 테이블을 자동 유지합니다. GSI는 비동기로 갱신되므로 최종 일관성만 보장합니다.
시험은 무엇을 보는가 / What the exam is testing
시험은 DynamoDB를 "서버리스이고 무한 확장하는 키-값 저장소"로 다루며, RDS와의 경계를 계속 시험합니다. 밀리초 응답·수백만 사용자·유연한 스키마·용량 계획 불필요가 나오면 DynamoDB, 복잡한 조인·집계 리포팅·트랜잭션 무결성이 나오면 관계형입니다. 용량 모드 선택(On-Demand vs Provisioned)이 비용 문항으로 자주 붙습니다.
시험 포인트 / Exam points
On-Demand는 트래픽이 예측 불가하거나 급증할 때 용량 계획 없이 씁니다. Provisioned는 꾸준한 부하에서 더 저렴하며 Auto Scaling과 함께 씁니다. "예측할 수 없는 스파이크"는 On-Demand가 정답입니다.
읽기가 지배적이고 마이크로초 지연이 필요하면 DynamoDB Accelerator(DAX)를 앞에 둡니다. 애플리케이션 코드 변경이 거의 없다는 점이 ElastiCache와의 차이입니다.
여러 리전에 다중 쓰기 가능한 복제 테이블을 만들어 전 세계 사용자에게 낮은 지연을 제공합니다. "다중 리전 액티브-액티브"의 정답입니다.
TTL 속성으로 만료된 항목을 무료로 자동 삭제합니다(세션 데이터에 유용). DynamoDB Streams는 변경 사항을 Lambda로 흘려보내 이벤트 기반 처리를 만듭니다.
PITR을 켜면 최근 35일 안의 임의 시점(초 단위)으로 새 테이블에 복구할 수 있습니다. 실수로 지운 데이터를 되돌리는 시나리오의 정답입니다. 다만 35일이 상한이므로 "7년 보관" 같은 장기 보존이 요구되면 PITR이 아니라 AWS Backup의 보존 정책을 씁니다. 복구는 항상 새 테이블로 이뤄지며 원본을 덮어쓰지 않습니다.
자주 틀리는 함정 / Common traps
Scan으로 조건 조회를 설계하는 선택지 — 테이블 전체를 읽어 비용과 지연이 폭증합니다. GSI를 만들어 Query로 바꾸는 것이 정답입니다.
꾸준한 부하에 On-Demand를 고르는 것 — 예측 가능한 상시 트래픽에서는 Provisioned + Auto Scaling이 훨씬 저렴합니다.
헷갈리는 것 구분하기 / Telling them apart
캐싱 대상이 DynamoDB뿐이면 DAX가 API 호환이라 코드 변경이 거의 없습니다. RDS나 여러 소스를 캐싱해야 하거나 캐시 자료구조를 직접 다뤄야 하면 ElastiCache입니다.
DynamoDB
Serverless NoSQL with single-digit millisecond latency and unbounded scale
이게 뭔가요? / What is this?
DynamoDB is not a server or an instance — it is a fully managed, serverless database with no capacity planning or server specs to worry about. Think of it as a drawer cabinet that expands infinitely without ever choosing its size in advance: no matter how much data piles up, AWS grows the space behind the scenes and the user just worries about putting items in and taking them out.
개요 / Overview
DynamoDB is a key-value and document store that scales without capacity planning and needs almost no administration. "Millions of users", "millisecond response", "flexible schema", and "serverless" point here; complex joins and reporting point back to RDS or Aurora.
동작 원리 / How it works
DynamoDB distributes items across physical partitions by hashing the partition key. That is why lookups that know the key are always single-digit milliseconds while a Scan, which reads everything, is slow and expensive. Design therefore runs in the order "decide the queries first, then choose keys" — there is no relational-style freedom to query arbitrarily later.
Secondary indexes soften this. An LSI adds a different sort key under the same partition key; a GSI maintains a separate table keyed differently. GSIs update asynchronously, so they are only eventually consistent.
시험은 무엇을 보는가 / What the exam is testing
The exam treats DynamoDB as the serverless, infinitely scalable key-value store and keeps probing its boundary with RDS. Millisecond response, millions of users, flexible schema, and no capacity planning → DynamoDB. Complex joins, aggregate reporting, and transactional integrity → relational. Capacity-mode choice frequently rides along as the cost question.
시험 포인트 / Exam points
On-Demand suits unpredictable or spiky traffic with no capacity planning. Provisioned is cheaper for steady load, paired with auto scaling. "Unpredictable spikes" → On-Demand.
For read-heavy workloads needing microsecond latency, put DAX in front. Unlike ElastiCache, it needs almost no application change.
Multi-Region, multi-active replicated tables give worldwide users low latency — the answer for "multi-Region active-active".
TTL attributes delete expired items automatically at no cost (useful for sessions). DynamoDB Streams pipe changes to Lambda for event-driven processing.
With PITR enabled you can restore to any second within the last 35 days, into a new table — the answer for undoing an accidental delete. But 35 days is the ceiling, so long retention such as "keep 7 years" calls for AWS Backup retention policies instead. A restore always creates a new table and never overwrites the original.
자주 틀리는 함정 / Common traps
Designing conditional lookups with Scan — it reads the whole table, exploding cost and latency. Creating a GSI and using Query is correct.
Choosing On-Demand for steady load — predictable continuous traffic is much cheaper on Provisioned with auto scaling.
헷갈리는 것 구분하기 / Telling them apart
If only DynamoDB needs caching, DAX is API-compatible and needs almost no code change. Caching RDS or multiple sources, or needing rich cache data structures, means ElastiCache.
AWS SAA Hub Pro는 독립 학습 자료이며 Amazon Web Services, Inc.의 공식 서비스가 아닙니다. 시험 정책과 서비스 사양은 AWS 공식 문서를 기준으로 확인하세요.