AWS 03-2 표가 아닌 DB와 캐시 — DynamoDB·ElastiCache·MemoryDB·DocumentDB·Keyspaces

관계형 DB 에서는 테이블부터 그립니다. 정규화하고, 조회는 나중에 SQL 로 짭니다. DynamoDB 는 이 순서를 뒤집습니다. 이 DB 가 답할 질문을 다 알기 전에는 스키마 설계를 시작하지 않습니다(NoSQL design for DynamoDB).

이 편의 다섯 서비스는 전부 표(관계형 테이블)가 아닌 모양으로 데이터를 둡니다. 키 하나로 값을 찾는 키-값 모양, JSON 같은 문서를 통째로 넣는 문서 모양, 메모리에 올려 두고 마이크로초 단위로 꺼내는 인메모리 모양이 섞여 있습니다. 이런 DB 를 묶어 NoSQL(Not only SQL)이라고 부릅니다.

다섯을 가르는 물음은 둘입니다. 잃어도 되는 데이터인가, 그리고 어떤 API 로 꺼내는가. 요금은 서울(ap-northeast-2) 2026-09-23 기준입니다.

지도

flowchart TD
    START["관계형이 아닌 저장소를 검토한다"] --> Q1{"잃어도 되는 복사본인가"}
    Q1 -- "된다. 원본은 다른 DB 에 있다" --> EC["ElastiCache<br/>관리형 캐시"]
    Q1 -- "안 된다. 이게 원본이다" --> Q2{"이미 쓰는 API 가 있나"}
    Q2 -- "MongoDB" --> DOC["DocumentDB<br/>MongoDB 호환 문서 DB"]
    Q2 -- "Cassandra 쿼리" --> KS["Keyspaces<br/>Cassandra 호환 서버리스"]
    Q2 -- "Redis 명령" --> Q3{"이미 ElastiCache 를 쓰나"}
    Q3 -- "그렇다" --> ECD["ElastiCache + 내구성<br/>새 클러스터로"]
    Q3 -- "아니다" --> MDB["MemoryDB<br/>내구성 있는 인메모리 DB"]
    Q2 -- "없다" --> Q4{"조회 패턴이 정해졌나"}
    Q4 -- "아니다. 조건이 자주 바뀐다" --> RDS["RDS·Aurora<br/>관계형 DB 편(03-1)"]
    Q4 -- "그렇다" --> DDB["DynamoDB<br/>서버리스 키-값·문서 DB"]

마지막 갈래가 이 편의 첫 질문입니다. 새 서비스라도 조회 조건을 미리 못 정한다면 DynamoDB 가 아니라 관계형 DB 가 맞습니다.

1. DynamoDB — 질문을 먼저 정하고 테이블을 짠다

RDS 는 인스턴스를 골라 띄우고, 표에 담고, SQL 로 찾습니다. DynamoDB 는 셋 다 다릅니다. 고를 인스턴스가 없어 요청한 횟수와 쌓아 둔 양을 세어 값을 매기고, 데이터는 표가 아닌 키-값·문서 모양으로 담아 키로 찾습니다.

키 두 개가 전부다

관계형 DB 는 행과 열로 된 표에 데이터를 담고, 아무 열로나 WHERE 를 걸어 찾습니다. DynamoDB 는 무엇에 담고, 무엇으로 찾을까요? 데이터는 아이템(item) 하나하나에 담깁니다. 관계형의 행에 해당하지만 아이템마다 담는 값이 달라도 되고, 모든 아이템이 반드시 지녀야 하는 것은 키 하나뿐입니다(Core components of Amazon DynamoDB).

찾는 쪽도 키가 전부입니다. 빨리 찾으려면 테이블을 만들 때 정한 키를 써야 하고, 그 키가 아이템을 어디에 어떤 순서로 둘지까지 정하기 때문입니다. 키는 두 값을 합쳐 씁니다. 파티션 키(partition key)가 아이템을 어디에 저장할지 정합니다. DynamoDB 는 데이터를 여러 파티션(나눠 둔 저장 영역)에 흩어 두는데, 파티션 키 값이 같은 아이템끼리 같은 파티션에 모입니다. 정렬 키(sort key)가 그렇게 모인 아이템을 어떤 순서로 붙여 둘지 정합니다. 두 값을 합쳐야 아이템 하나를 가려낼 수 있습니다.

사용자와 주문을 한 테이블에 넣어 보면 두 키가 하는 일이 보입니다. 파티션 키에는 사용자를, 정렬 키에는 아이템의 종류와 날짜를 넣습니다.

사용자 u2 를 하나 더 두면 두 키가 각각 무슨 일을 하는지 한눈에 보입니다. 파티션 키가 아이템을 어느 파티션에 둘지 가르고, 정렬 키가 그 안에서 순서를 매깁니다.

flowchart TD
    IT["아이템을 넣는다"]
    IT --> PK{"파티션 키를 본다"}
    PK --> P1
    PK --> P2

    subgraph P1["파티션 1 · 파티션 키 u1"]
        A1["정렬 키 PROFILE"]
        A2["정렬 키 ORDER 2026-09-01"]
        A3["정렬 키 ORDER 2026-09-20"]
        A1 --> A2 --> A3
    end

    subgraph P2["파티션 2 · 파티션 키 u2"]
        B1["정렬 키 PROFILE"]
        B2["정렬 키 ORDER 2026-09-14"]
        B1 --> B2
    end

파티션 1 안의 화살표가 정렬 키 순서입니다. u1 을 찾을 때 파티션 2 는 아예 열어 보지 않고, 파티션 1 안에서도 앞에서부터 이어 읽기만 하면 됩니다.

u1 의 아이템 셋은 같은 파티션에 정렬 키 순서로 나란히 놓이고, 주문은 정렬 키가 날짜로 이어지니 날짜순으로 붙습니다. 그래서 「u1 의 9월 주문」은 파티션 키 USER#u1 과 「정렬 키가 ORDER#2026-09 로 시작한다」는 조건 하나로 한 번에 나옵니다. 한곳에 붙어 있는 것을 앞에서부터 읽기만 하면 되기 때문입니다.

거꾸로 키가 아닌 값으로 찾으면 느립니다. 「금액이 10만 원 넘는 주문」은 어느 파티션에 있는지 모르니 테이블을 통째로 훑어야 하고, 그렇게 훑는 것을 Scan 이라 부릅니다. 테이블끼리 잇는 조인도 없습니다. 그래서 DynamoDB 에서는 테이블보다 접근 패턴, 곧 애플리케이션이 던질 조회를 먼저 적습니다. 적어 둔 조회마다 키 조건 하나로 끝나도록 키를 고르고, 함께 읽을 데이터는 위처럼 한 테이블에 모아 둡니다. 키를 고를 때 하나 더 봅니다. 파티션 키 값이 고르게 퍼져야 합니다. 요청이 한 값에 몰리면 그 파티션 하나만 막히는데, 이렇게 막힌 것을 핫 파티션이라 부릅니다.

다른 조건으로도 찾아야 하면

접근 패턴을 잘 적어 둬도 운영하다 보면 적어 두지 않은 조회가 생깁니다. 사용자 키로는 못 찾는 「결제 대기 중인 주문 전부」 같은 조회는 어떻게 할까요? 이때 보조 인덱스를 붙입니다. 주로 GSI(Global Secondary Index, 글로벌 보조 인덱스)를 씁니다. 같은 데이터를 다른 파티션 키·정렬 키로 한 벌 더 정리해 두는 것입니다. 주문 상태를 파티션 키로 삼는 GSI 를 두면 그 조회가 Scan 없이 나옵니다. GSI 는 언제든 만들 수 있고, 한 벌 더 두는 만큼 쓰고 쌓는 값을 따로 냅니다. 파티션 키는 그대로 두고 정렬 키만 바꾸는 LSI(로컬 보조 인덱스)도 있지만 테이블을 만들 때만 정할 수 있어서, 나중에 생긴 조회에는 GSI 를 씁니다(Local secondary indexes).

테이블에 켜 두면 알아서 도는 것도 몇 가지 있습니다. TTL 을 켜면 만료 시각이 지난 아이템을 쓰기 용량을 쓰지 않고 지워 줍니다. Streams 를 켜면 아이템이 바뀔 때마다 그 변경을 순서대로 남겨 Lambda 같은 후처리 코드에 넘깁니다. 글로벌 테이블로 만들면 여러 리전에 복제본을 둡니다(Using time to live (TTL) in DynamoDB · Change data capture for DynamoDB Streams). 아이템 하나는 400 KB 까지 담습니다.

돈은 두 방식으로 낸다, 경계는 사용률 29%

인스턴스가 없으면 돈은 무엇으로 셀까요? DynamoDB 는 읽고 쓴 요청을 세고, 그것을 어떻게 낼지 테이블마다 둘 중에서 고릅니다. 온디맨드로 두면 01-1편의 EC2 온디맨드처럼 약정 없이 처리한 요청만큼만 냅니다. AWS 도 대부분의 워크로드에 이쪽을 기본으로 권합니다(AWS 01-1 서버를 통째로 빌린다 — EC2·Lightsail·Beanstalk·CloudShell). 프로비저닝으로 두면 초당 읽고 쓸 용량을 미리 잡아 두고, 쓰든 안 쓰든 잡아 둔 만큼 시간으로 냅니다. 잡아 둔 용량은 자동 조정(auto scaling)이 목표 사용률에 맞춰 늘리고 줄입니다(DynamoDB throughput capacity).

어느 쪽으로 두든 요청은 같은 크기의 단위로 셉니다. 쓰기 1 단위로 1 KB 까지 한 번 씁니다. 읽기 1 단위로는 4 KB 까지 강하게 한 번 읽거나, 최종 일관성으로 두 번 읽습니다. DynamoDB 는 기본으로 최종 일관성으로 읽어서 방금 쓴 값이 잠시 안 보일 수 있고, 요청에 ConsistentRead 를 켜면 쓴 값이 바로 보이게 강한 일관성 으로 읽는 대신 단위를 두 배 씁니다(DynamoDB read consistency).

결론부터 말하면 사용률 약 29% 에서 갈립니다. 잡아 둔 용량을 평균 29% 넘게 쓰면 프로비저닝이 싸지고, 약 58% 넘게 쓰면 온디맨드의 절반 아래로 떨어집니다. 부하를 모르는 새 테이블은 온디맨드로 시작하고, 사용률이 꾸준히 높게 나오면 프로비저닝으로 바꿉니다. 29% 는 단가를 나누면 나옵니다. 서울에서 온디맨드로 내면 읽기 백만 단위에 $0.1355, 쓰기 백만 단위에 $0.68 을 냅니다. 프로비저닝으로 잡아 두면 읽기 1 단위를 한 시간 잡는 데 $0.00014098, 쓰기는 $0.0007049 를 냅니다. 저장은 어느 쪽이든 GB-월 $0.27075 를 냅니다(Amazon DynamoDB pricing). 읽기 1 단위를 한 시간 잡으면 강하게 3,600번 읽을 수 있으니 백만 번에 $0.0392 를 내는 셈이고, 온디맨드 $0.1355 의 약 29% 에 그칩니다. 쓰기도 같은 비율로 갈립니다(백만 번에 $0.1958 대 $0.68).

실제 부하로 확인해 봅니다. 초당 읽기 100번·쓰기 10번이 한 달 내내 고르게 들어오고, 아이템 하나는 1 KB 이며, 10 GB 를 쌓아 두고, 최종 일관성으로 읽는다고 칩니다.

한 달 = 730시간 × 3,600초 = 2,628,000초
  읽기 100 × 2,628,000 = 2억 6,280만 번
    1 KB 최종 일관성 읽기 2번이 1 단위 → 1억 3,140만 단위
  쓰기  10 × 2,628,000 = 2,628만 번 → 2,628만 단위

온디맨드 · 서울
  읽기  131.4 백만 × $0.1355      = $17.80
  쓰기  26.28 백만 × $0.68        = $17.87
  저장  10 GB × $0.27075          =  $2.71
  합계                            = $38.38

프로비저닝 · 서울 · 목표 사용률 70%
  읽기  72 단위 × $0.00014098 × 730 =  $7.41
  쓰기  15 단위 × $0.0007049  × 730 =  $7.72
  저장                              =  $2.71
  합계                              = $17.84

이 부하를 받으려면 읽기 50 단위(읽기 100 ÷ 2)와 쓰기 10 단위가 듭니다. 72 는 50 ÷ 0.7 을, 15 는 10 ÷ 0.7 을 올린 값입니다(Managing throughput capacity automatically with DynamoDB auto scaling). 양쪽 다 프리 티어·백업·Streams·GSI·전송량은 뺐습니다. 사용률 70% 는 58% 를 넘으니 프로비저닝이 절반 아래로 떨어집니다. 어느 쪽으로 낼지는 이렇게 숫자가 갈라 주지만, DynamoDB 를 쓸지 말지는 무엇으로 찾을지 정했느냐가 갈라 줍니다.

「이 조건으로도 찾게 해 주세요」라는 요청이 매주 나오면 관계형 DB 편(03-1)의 RDS·Aurora 로 옮깁니다.

2. ElastiCache — 날아가도 되는 복사본을 메모리에

ElastiCache 는 관리형 인메모리 캐시입니다. 원본 DB 앞에 두고, 자주 읽는 값을 마이크로초 단위로 돌려줍니다.

캐시에 든 값은 원본의 복사본입니다. 노드가 죽거나 메모리가 차서 값이 빠지면 원본에서 다시 읽어 채웁니다. 캐시가 비었을 때 원본으로 가는 길이 코드에 없으면, 캐시 장애가 곧 서비스 장애가 됩니다.

두 가지 형태로 씁니다. 서버리스는 캐시 이름만 정하면 용량을 알아서 늘리고, 저장 GB-시간과 ECPU(ElastiCache Processing Unit)로 과금합니다. 단순한 읽기·쓰기는 1 KB 당 1 ECPU 이고, CPU 시간을 더 쓰는 명령은 그만큼 더 셉니다. 노드 기반은 노드 타입·개수·가용 영역(AZ) 배치를 고르고 노드 × 시간으로 냅니다.

엔진은 셋입니다. Redis OSS(Open Source Software)는 오픈 소스 Redis 입니다. Valkey 는 리눅스 재단이 관리하는 오픈 소스 키-값 저장소로, Redis OSS 를 그대로 갈아 끼울 수 있게 만들었습니다. Memcached 는 문자열만 담는 단순한 캐시입니다.

Valkey 는 노드 기반이 20%, 서버리스가 33% 쌉니다. 서버리스의 최저 요금은 Valkey 가 월 $7.37(0.1 GB × $0.101 × 730), Redis OSS 가 월 $110.23(1 GB × $0.151 × 730)입니다(Amazon ElastiCache pricing). 벡터 검색·전문 검색·내구성 같은 새 기능도 Valkey 에만 붙습니다. Valkey·Redis OSS 는 해시·정렬 셋 같은 자료 구조, 복제와 자동 장애 조치, 발행/구독(Pub/Sub)을 주고, Memcached 는 복제가 없는 대신 멀티스레드로 돕니다(Comparing node-based Valkey, Memcached, and Redis OSS clusters).

DynamoDB 앞에 둘 캐시라면 DAX(DynamoDB Accelerator)가 먼저입니다. DynamoDB 와 API 가 호환되는 전용 캐시라 코드를 거의 안 고치고 붙습니다. 대신 최종 일관성 읽기만 캐시합니다(In-memory acceleration with DynamoDB Accelerator (DAX)).

2026-06 부터 붙은 내구성

2026-06-02 부터 ElastiCache 도 데이터를 잃지 않는 원본으로 쓸 수 있습니다. 쓰기를 여러 AZ 에 걸친 트랜잭션 로그(Multi-AZ transactional log)에 남겨 노드가 모두 죽어도 되살립니다. 동기 쓰기는 두 AZ 이상의 로그에 남긴 뒤 응답해 잃는 데이터가 없도록 설계됐고, 쓰기 지연이 한 자릿수 밀리초로 늘며 노드 요금에 18% 가 붙습니다. 비동기 쓰기는 응답한 뒤 로그에 남겨 마이크로초 쓰기를 유지하고 추가 요금이 없지만, 장애 때 최대 10초분을 잃을 수 있습니다(Durability in ElastiCache).

조건이 붙습니다(Limitations).

• 클러스터를 만들 때만 켤 수 있습니다. 기존 비내구성 클러스터에는 켤 수 없어 새로 만들어야 하고, 한 번 켜면 끌 수 없습니다.
• Valkey 9.0 이상의 노드 기반 클러스터에서만 됩니다. 서버리스는 안 됩니다.
• 노드는 R·M·C 계열 Graviton(R8g·R7g·R6g·M8g·M7g·M6g·C8gn·C7gn)만 됩니다. t4g 는 안 됩니다.
• 데이터를 여러 샤드(주 노드 하나와 그 복제본의 묶음)로 나누는 클러스터 모드를 켜고, 샤드마다 복제본을 하나 이상 다른 AZ 에 둬야 합니다.

내구성은 이만큼 조건이 붙는 추가 선택지이고, ElastiCache 의 기본 전제는 여전히 잃어도 되는 복사본입니다.

캐시에만 있고 원본이 없는 값이 생기기 시작하면 내구성 클러스터나 MemoryDB 로 옮깁니다. 둘 중 무엇을 고를지는 다음 절에서 값으로 가립니다.

3. MemoryDB — Redis 명령으로 쓰는 원본 DB

MemoryDB 는 Valkey·Redis OSS 와 호환되는 인메모리 DB 인데, 캐시가 아니라 내구성 있는 주 DB 로 쓰도록 만든 서비스입니다.

데이터가 전부 메모리에 있어 읽기는 마이크로초입니다. 쓰기는 여러 AZ 에 걸친 트랜잭션 로그에 남기므로 한 자릿수 밀리초이고, 그 대가로 장애 조치 때도 쓰기를 잃지 않습니다. 주 노드에서 읽으면 자기가 쓴 값이 보이고, 복제본 읽기는 최종 일관성입니다(What is MemoryDB · Amazon MemoryDB FAQs).

노드 요금은 서울 db.r7g.large 가 Valkey $0.2583, Redis OSS $0.369 입니다. 쓴 데이터 요금은 Valkey 가 월 10 TB 까지 $0, 넘으면 GB당 $0.04 이고 Redis OSS 는 GB당 $0.20 입니다(서울 가격 목록 APN2-DataWritten). 스냅샷 저장은 따로 붙습니다(Amazon MemoryDB pricing).

같은 메모리(13.07 GiB)의 r7g.large 로 ElastiCache 와 나란히 놓습니다. ElastiCache Valkey 노드는 시간당 $0.2096 입니다. 주 노드 1 + 복제본 1 로 한 달(730시간) 돌리면 이렇고, ElastiCache 내구성은 복제본이 있어야 켜지므로 조건이 같습니다.

r7g.large × 2대 · 서울 · 한 달 · 전송량·스냅샷 제외
  ElastiCache Valkey, 내구성 없음   $0.2096          × 730 × 2 = $306.02
  ElastiCache Valkey, 동기 쓰기     $0.2096 × 1.18   × 730 × 2 = $361.10
  MemoryDB Valkey                   $0.2583          × 730 × 2 = $377.12
  MemoryDB Redis OSS                $0.369           × 730 × 2 = $538.74

셈해 보면 ElastiCache 동기 내구성이 MemoryDB Valkey 보다 4% 남짓 쌉니다. 차이가 작아서 고르는 기준은 운영 형태입니다. 이미 ElastiCache 를 쓰고 있다면 기존 클러스터에는 켤 수 없어 새로 만들어야 하지만, 같은 서비스·같은 엔진이라 클라이언트와 운영 방식은 그대로입니다. ElastiCache 가 없는 상태에서 주 DB 를 새로 세운다면 그 용도로 만든 MemoryDB 가 맞습니다. Redis OSS 엔진을 고르면 노드 요금이 30% 오르고 쓴 데이터 요금도 붙습니다. 정리하면 MemoryDB 는 앞에 원본 DB 를 따로 두지 않을 때 고르는 서비스입니다.

다만 데이터가 수백 GB 를 넘어 메모리 비용이 부담되면 DynamoDB 로 옮깁니다.

4. DocumentDB — MongoDB 드라이버로 붙는 AWS 의 문서 DB

DocumentDB 는 MongoDB 와 호환되는 관리형 문서 DB 입니다. MongoDB 를 돌리는 것이 아니라, AWS 가 따로 만든 엔진이 MongoDB API 를 흉내 냅니다.

호환 대상은 MongoDB 4.0·5.0·8.0 이고, 기존 애플리케이션·드라이버·도구 대다수가 거의 고치지 않고 붙습니다. 다만 모든 MongoDB 기능을 지원하지는 않습니다(Amazon DocumentDB compatibility with MongoDB). 옮기기 전에 걸리기 쉬운 차이는 셋입니다(Functional differences: Amazon DocumentDB and MongoDB).

요금은 인스턴스를 띄워 둔 시간과 저장·I/O 로 나옵니다. 저장소는 세 AZ 에 걸쳐 복제되지만 한 벌 값만 냅니다(Amazon DocumentDB pricing).

켜 둔 동안 요금이 나가는 인스턴스형이고 MongoDB 와는 호환일 뿐 같지 않다는 점을 먼저 따져야 합니다.

쓰는 MongoDB 기능이 호환 목록에 없으면 DocumentDB 대신 EC2 위에 MongoDB 를 직접 운영합니다.

5. Keyspaces — Cassandra 코드를 서버 없이

Apache Cassandra 는 많은 양의 데이터를 다루도록 만든 오픈 소스 와이드 컬럼 DB 로, 행마다 열 구성이 다를 수 있는 넓은 표 모양으로 데이터를 둡니다. Keyspaces 는 이 Cassandra 와 호환되는 서버리스 DB 라서, 서버 설치·패치 없이 쓴 만큼 냅니다(What is Amazon Keyspaces).

Keyspaces 는 CQL(Cassandra Query Language) 3.11 API 와 호환되고 2.x 와도 하위 호환됩니다(Supported Cassandra APIs, operations, functions, and data types). 서울 단가는 DynamoDB 와 같아서 읽기 요청 단위 백만 개당 $0.1355, 쓰기 백만 개당 $0.68, 저장 GB-월 $0.27075 이고 프로비저닝 모드도 있습니다. TTL 로 지우는 삭제는 백만 건당 $0.2975 입니다. 단가가 DynamoDB 와 같으니 Keyspaces 를 고르는 이유는 Cassandra 코드가 이미 있다는 것 하나입니다.

그 이유가 사라져 Cassandra 호환이 더는 필요 없으면 단가가 같은 DynamoDB 로 옮깁니다.

이럴 땐 무엇

자주 붙는 서비스

이 편의 서비스는 Lambda(Streams 후처리·서버리스 API) · API Gateway(서버리스 API 입구) · RDS·Aurora(ElastiCache 뒤의 원본) · DAX · VPC(ElastiCache·MemoryDB·DocumentDB 가 뜨는 망) · DMS(Database Migration Service, MongoDB 에서 옮길 때)와 자주 붙습니다.

한 장 요약

DynamoDB 는 테이블보다 접근 패턴이 먼저이고, 조회 방식이 정해져 있으면 크기와 상관없이 맞습니다. 용량 모드는 평균 사용률 약 29% 를 경계로 갈립니다. 캐시는 Valkey 가 싸고, DynamoDB 앞이라면 DAX 입니다. 캐시가 원본이 되면 이미 ElastiCache 를 쓰는 쪽은 내구성 클러스터를, 새로 세우는 쪽은 MemoryDB 를 고릅니다. DocumentDB·Keyspaces 는 이미 MongoDB·Cassandra 코드가 있을 때의 선택입니다.

관련 항목

표가 아닌 DB 라는 같은 갈래

DynamoDB · ElastiCache · MemoryDB · DocumentDB · Keyspaces · NoSQL

DynamoDB 테이블을 이루는 부품

파티션 키 · 정렬 키 · 복합 기본 키 · 글로벌 보조 인덱스 · 로컬 보조 인덱스 · 파티션 · 해시 함수 · 핫 파티션

DynamoDB 가 데이터를 다루는 규칙

최종 일관성 · 강한 일관성 · 트랜잭션 · ACID · TTL · DynamoDB Streams · 변경 데이터 캡처 · 글로벌 테이블

DynamoDB 를 사는 요금 방식

온디맨드 용량 모드 · 프로비저닝 용량 모드 · 읽기 용량 단위 · 쓰기 용량 단위 · DynamoDB 자동 조정 · AWS 프리 티어

캐시와 인메모리 DB 가 호환하는 엔진

Redis · Valkey · Memcached · 캐시 · 캐시 무효화

ElastiCache 와 MemoryDB 의 구성 부품

ElastiCache 서버리스 · ECPU · 트랜잭션 로그 · 복제 · 샤딩 · 장애 조치 · 가용 영역 · 스냅샷

호환 대상인 오픈 소스 DB

MongoDB · Cassandra · CQL · 와이드 컬럼 저장소 · 문서 지향 데이터베이스

이 편의 DB 와 비교되는 관계형 쪽

관계형 데이터베이스 · 정규화 · 조인 · RDS · Aurora · 데이터 모델링

이 DB 들과 자주 엮이는 서비스

Lambda · API Gateway · DAX · VPC · DMS