DynamoDB vs Amazon S3

DynamoDB와 Amazon S3는 서로 다른 문제를 해결하므로 "어느 쪽"이냐에 대한 솔직한 답은 대개 둘 다입니다. DynamoDB는 키로 조회하고 쿼리하고 업데이트하는 구조화된 기록을 위한 키-값 및 문서 데이터베이스입니다. Amazon S3는 파일과 블롭 — 이미지, 백업, 로그, 동영상 — 을 통째로 저장하고 검색하는 객체 스토리지입니다. 둘은 양자택일이 아니라 상호 보완적입니다.

DynamoDB와 S3 중 무엇을 써야 하나요?

키로 쿼리하고 필터링하고 업데이트하는 작고 구조화된 기록이 많고 한 자릿수 밀리초 지연 시간이 필요할 때 DynamoDB를 사용하세요. 파일이나 블롭 — 이미지, 백업, 내보내기 — 을 통째로 저장하고 제공하며 이름으로 검색할 때 Amazon S3를 사용하세요. 둘은 상호 보완적입니다: 매우 흔한 패턴은 객체를 S3에, 그 메타데이터를 DynamoDB에 저장하는 것입니다.

한눈에 보는 DynamoDB vs Amazon S3

특성	DynamoDB	Amazon S3
주요 용도	구조화된 기록을 위한 NoSQL 키-값 / 문서 데이터베이스	파일, 블롭, 비구조화 데이터를 위한 객체 스토리지
데이터 단위	항목(타입 지정 속성의 집합), 기본 키로 주소 지정	객체(바이트 + 메타데이터), 버킷 내 키로 주소 지정
단위당 최대 크기	항목당 400 KB(속성 이름 + 값)	객체당 5 TB(단일 PUT은 최대 5 GB; 그보다 큰 업로드는 멀티파트 사용)
쿼리 / 액세스	`GetItem`, `Query`, `Scan`, `BatchGetItem`, PartiQL, 보조 인덱스(GSI/LSI)	키로 `GET` / `PUT` / `DELETE`, 버킷 `LIST`; Amazon Athena를 통한 인플레이스 쿼리(기존 고객은 S3 Select)
지연 시간 프로파일	어떤 규모에서도 단일 항목에 대한 한 자릿수 밀리초 읽기/쓰기	내구성 있는 객체 처리량; 키-값 데이터베이스보다 요청당 지연 시간이 높음, 밀리초 단위 기록 조회는 아님
일관성	기본값은 최종적 일관성(읽기); 요청당 강력한 일관성(읽기) 가능	모든 객체와 모든 요청에 대한 강력한 read-after-write 일관성(2020년부터)
요금 모델	읽기/쓰기 용량(RCU/WCU — 온디맨드 또는 프로비저닝된) + GB-월당 데이터 스토리지	GB-월당 스토리지(스토리지 클래스별) + 요청 요금(PUT/GET/LIST) + 데이터 검색 / 전송
최적 워크로드	사용자 프로필, 세션, 장바구니, 이벤트/상태 기록, 메타데이터, 높은 처리량의 OLTP 방식 액세스	미디어, 백업, 데이터 레이크 파일, 정적 자산, 대용량 내보내기, 아카이빙

위 표의 모든 셀은 공식 AWS 문서에서 가져온 것입니다(이 파일 상단의 provenance 노트 참고).

DynamoDB를 사용해야 할 때

데이터가 키로 액세스하는 구조화된 기록일 때 DynamoDB를 선택하세요:

개별적으로 읽고 쓰고 업데이트하는 작은 항목(각각 400 KB 한도 미만)이 많은 경우.
예측 가능하고 지연 시간이 낮은 조회 — DynamoDB는 어떤 규모에서도 단일 항목에 대한 한 자릿수 밀리초 읽기와 쓰기를 목표로 합니다.
기본 키와 보조 인덱스로 표현할 수 있는 액세스 패턴: id로 가져오기, 파티션 쿼리, 파티션 내 필터.
세밀한 업데이트를 동반한 높은 쓰기 처리량(기록 전체를 다시 쓰지 않고 속성 하나만 변경).

항목 안에 5 MB 파일을 저장하려고 애쓰고 있다면, 그것은 DynamoDB의 경계에 도달했다는 신호입니다 — DynamoDB 항목 크기 한도를 참고하세요.

S3를 사용해야 할 때

데이터가 이름으로 검색하는 통째 파일이나 블롭일 때 Amazon S3를 선택하세요:

이미지, PDF, 동영상, 오디오, 기타 바이너리 자산.
백업, 데이터베이스 내보내기, 그리고 나중에 Amazon Athena 같은 도구로 쿼리하는 데이터 레이크 파일(Parquet, CSV, JSON).
대용량 객체 — S3는 객체를 각각 최대 5 TB까지 저장하며, 이는 어떤 단일 데이터베이스 기록보다 훨씬 큽니다.
정적 웹사이트 자산과 사용자에게 직접 제공되는 콘텐츠.

S3는 데이터베이스가 아닙니다: DynamoDB 항목을 쿼리하듯 임의 객체의 내용 을 풍부한 인덱스로 쿼리할 수 없습니다. 객체에 대한 인플레이스 SQL 방식 필터링은 Amazon Athena를 통해 가능합니다(S3 Select는 기존 고객에게는 계속 제공되지만 2024년에 신규 고객에게는 마감되었습니다).

함께 사용하기

두 서비스는 결합할 때 가장 강력합니다. DynamoDB 항목에 담기에 너무 큰 데이터에 대한 AWS 자체의 지침은 객체를 S3에 저장하고 DynamoDB에 포인터를 유지하는 것입니다:

큰 파일(이미지, 문서, 동영상)을 S3에 객체로 저장합니다.
그 메타데이터 — S3 객체 키, 콘텐츠 유형, 소유자, 태그, 타임스탬프 — 를 저렴하게 쿼리할 수 있는 DynamoDB에 항목으로 저장합니다.
DynamoDB에서 키로 기록을 조회한 다음, 저장된 식별자를 사용해 S3에서 객체를 가져옵니다.

AWS가 짚는 한 가지 유의점: DynamoDB와 S3에 걸친 트랜잭션은 없으므로, 애플리케이션이 부분 실패를 처리합니다(예를 들어 DynamoDB 쓰기가 실패하면 고아가 된 S3 객체를 정리).

DynamoDB로 작업하기

데이터의 구조화된 절반에 대해 DynamoDB를 선택했다면, DynoTable은 macOS, Windows, Linux 전반에서 테이블을 탐색하고 편집하고 쿼리하는 데스크톱 DynamoDB 클라이언트입니다. 표준 AWS 자격 증명 체인을 읽으므로 마이그레이션할 DynamoDB 관련 항목이 없습니다 — 리전과 테이블을 가리키면 데이터는 DynamoDB에 그대로 머무릅니다.

위의 메타데이터-인-DynamoDB 패턴을 뒷받침하는 GetItem, Query, Update 또는 조건 표현식을 직접 만들어야 할 때, 무료 DynamoDB Expression Builder가 요청을 AWS SDK, CLI, boto3 형태로 생성합니다. 무엇을 S3에 둘지 결정하기 전에 400 KB 한도 대비 항목 크기를 재려면, 항목 크기 계산기가 기록의 바이트 크기를 측정합니다.

FAQ

DynamoDB가 파일이나 이미지를 저장할 수 있나요?

한도 내에서 작은 것은 가능합니다. DynamoDB 항목은 바이너리 데이터를 담을 수 있지만, 항목 전체 — 모든 속성 이름과 값 — 는 400 KB 미만이어야 합니다. 그보다 큰 것에 대한 AWS의 문서화된 모범 사례는 파일을 Amazon S3에 객체로 저장하고 S3 객체 키(및 메타데이터)를 DynamoDB 항목에 유지하는 것입니다.

S3가 DynamoDB보다 저렴한가요?

요금 방식이 다르므로 획일적인 답이 아니라 워크로드에 따라 다릅니다. S3는 GB-월당 스토리지에 요청당 및 검색 요금을 더해 과금하며, 자주 액세스하지 않는 대량 바이트의 보관처로는 일반적으로 더 저렴합니다. DynamoDB는 읽기/쓰기 용량에 스토리지를 더해 과금하며, 작은 기록 다수에 대한 높은 처리량과 낮은 지연 시간의 액세스를 위해 만들어졌습니다. DynamoDB에 큰 블롭을 저장하는 것은 크기 제한이 있고 상대적으로 비쌉니다 — 그래서 S3 객체 + DynamoDB 메타데이터 분리가 표준 패턴인 것입니다.

JSON에는 DynamoDB와 S3 중 무엇이 좋나요?

JSON이 키로 쿼리하고 업데이트하는 구조화된 기록 — 사용자, 주문, 세션 — 이라면 DynamoDB가 적합하며, JSON을 타입 지정 속성으로 매핑하고 PartiQL을 지원합니다. JSON이 통째로 저장했다가 나중에 대량으로 스캔하는 문서나 데이터 레이크 파일(예를 들어 Amazon Athena로 쿼리)이라면 S3가 적합합니다. 흔한 하이브리드는 쿼리 가능한 필드를 DynamoDB에, 전체 JSON 페이로드를 S3에 객체로 유지합니다.