DynamoDB 테이블을 만들 때 가장 먼저 고르는 것이 용량 모드입니다. 온디맨드는 요청한 만큼만 내고, 프로비저닝은 초당 처리량을 미리 정해 두고 그만큼 시간 단위로 냅니다. 어느 쪽이 싼지는 트래픽 모양에 따라 달라지는데, 계산해 보면 기준이 되는 숫자가 하나 나옵니다.
이 글에서는 두 모드의 요금 단위를 먼저 맞춰 보고, 같은 처리량을 한 달 동안 썼을 때의 비용을 비교해 손익분기 사용률을 구합니다. 요금은 미국 동부(버지니아 북부) 리전, Standard 테이블 클래스 기준입니다.

요금 단위 맞추기
| 항목 | 온디맨드 | 프로비저닝 |
|---|---|---|
| 쓰기 | 쓰기 요청 단위 100만 개당 0.625달러 | 쓰기 용량 단위(WCU) 시간당 0.00065달러 |
| 읽기 | 읽기 요청 단위 100만 개당 0.125달러 | 읽기 용량 단위(RCU) 시간당 0.00013달러 |
| 단위의 뜻 | 요청 1번(쓰기 1KB, 강한 일관성 읽기 4KB까지) | 초당 1번(쓰기 1KB, 강한 일관성 읽기 4KB까지) |
| 저장 | GB당 월 0.25달러(두 모드 같음) | |
프리 티어로 리전마다 25 WCU와 25 RCU, 저장 공간 25GB가 매달 제공됩니다. 항목 크기가 단위보다 크면 단위를 더 씁니다. 3KB 항목 하나를 쓰면 쓰기 단위 3개가 필요하고, 최종적 일관성 읽기는 강한 일관성 읽기의 절반 단위만 씁니다.
같은 처리량, 한 달 비용 비교
쓰기 1 WCU는 초당 1번 쓰기를 한 달(약 730시간, 2,628,000초) 내내 처리할 수 있는 용량입니다. 이 용량을 100% 쓴다고 가정하고 두 모드의 비용을 비교해 보겠습니다.
| 구분 | 계산 | 한 달 비용 |
|---|---|---|
| 프로비저닝 1 WCU | 0.00065달러 × 730시간 | 약 0.47달러 |
| 같은 양(약 263만 번)을 온디맨드로 | 2.628 × 0.625달러 | 약 1.64달러 |
| 손익분기 사용률 | 0.47 ÷ 1.64 | 약 29% |
읽기도 계산해 보면 1 RCU 한 달 약 0.095달러, 같은 양의 온디맨드 읽기 약 0.33달러로 손익분기점이 역시 약 29%입니다. 정리하면 프로비저닝한 용량의 평균 사용률이 29%보다 높으면 프로비저닝이, 낮으면 온디맨드가 저렴합니다.

트래픽 모양별 판단
평균 사용률이라는 말이 중요합니다. 프로비저닝은 가장 바쁜 시간을 감당할 만큼 잡아야 하므로, 낮과 밤의 차이가 크면 평균 사용률이 낮아집니다.
| 트래픽 모양 | 예 | 유리한 모드 |
|---|---|---|
| 하루 종일 고르게 많음 | 평균이 최대의 70~80%인 백엔드 | 프로비저닝(필요하면 자동 조정) |
| 낮에만 몰리고 밤엔 거의 없음 | 최대 대비 평균 20% 안팎 | 온디맨드 |
| 예측이 어려운 새 서비스 | 출시 직후, 이벤트성 트래픽 | 온디맨드로 시작 |
| 거의 쓰지 않는 테이블 | 설정값·관리용 테이블 | 온디맨드 또는 프리 티어 안의 프로비저닝 |
예를 들어 쓰기가 평소 초당 20번, 가장 바쁠 때 초당 100번인 서비스를 프로비저닝 100 WCU로 고정하면 한 달 약 47달러입니다. 한 달 평균이 초당 20번이라면 약 5,256만 번 쓰기이므로 온디맨드로는 약 33달러입니다. 평균 사용률이 20%로 손익분기점보다 낮기 때문입니다. 같은 서비스라도 자동 조정으로 용량을 트래픽에 맞게 오르내리게 하면 평균 사용률이 올라가 프로비저닝 쪽이 다시 유리해질 수 있습니다.
자동 조정을 켠 프로비저닝은 어디쯤일까
프로비저닝 모드에는 자동 조정 기능이 있어, 목표 사용률을 정해 두면 소비량에 맞춰 용량을 올리고 내립니다. 목표 사용률을 70%로 잡았다면 평균 사용률도 대략 그 근처에서 움직이므로, 손익분기점인 29%보다 한참 위에 머무르게 됩니다. 앞의 서비스(평소 초당 20번, 최대 초당 100번 쓰기)라면 용량이 트래픽을 따라 오르내리면서 평균 30 WCU 안팎으로 유지될 수 있고, 이 경우 한 달 약 14달러로 온디맨드(약 33달러)보다 저렴해집니다.
다만 자동 조정은 소비량을 보고 따라가는 방식이라, 몇 초 만에 몇 배로 튀는 트래픽에는 늦게 반응할 수 있습니다. 갑작스러운 급증이 잦은 서비스라면 최소 용량을 넉넉히 잡거나 온디맨드를 유지하는 편이 제한 위험을 줄입니다. 위 숫자는 이해를 돕기 위한 어림셈이므로, 실제 판단은 CloudWatch 지표로 계산한 값으로 하는 것이 좋습니다.
항목 크기가 바꾸는 계산
앞의 계산은 쓰기 1KB, 읽기 4KB 이하인 항목을 기준으로 했습니다. 항목이 크면 같은 요청이라도 단위를 여러 개 씁니다.
| 작업 | 항목 크기 | 소비 단위 |
|---|---|---|
| 쓰기 | 0.8KB | 쓰기 단위 1개 |
| 쓰기 | 3.5KB | 쓰기 단위 4개(1KB 단위로 올림) |
| 강한 일관성 읽기 | 6KB | 읽기 단위 2개(4KB 단위로 올림) |
| 최종적 일관성 읽기 | 6KB | 읽기 단위 1개(강한 일관성의 절반) |
3.5KB 항목을 한 달에 100만 번 쓰면 온디맨드 기준 쓰기 단위 400만 개, 약 2.50달러입니다. 같은 데이터를 자주 바뀌는 작은 속성과 거의 안 바뀌는 큰 속성으로 나눠 두 항목에 저장하면, 자주 쓰는 쪽은 1KB 안에 들어가 쓰기 비용이 4분의 1로 줄어듭니다. 용량 모드를 고민하기 전에 항목 크기부터 줄일 수 있는지 보는 것이 더 큰 절약이 되기도 합니다.
고르는 순서
- 새 테이블은 온디맨드로 시작해 실제 트래픽 모양을 2~4주 관찰합니다.
- CloudWatch에서 소비된 읽기·쓰기 용량의 평균과 최대를 확인합니다.
- 평균이 최대의 30%를 꾸준히 넘는다면 프로비저닝과 자동 조정을 계산해 봅니다.
- 바꾼 뒤에는 한두 달 요금과 제한(스로틀링) 여부를 함께 확인합니다.
헷갈리기 쉬운 부분
- 온디맨드도 무한정은 아닙니다 — 갑자기 이전 최대치보다 훨씬 많은 트래픽이 몰리면 짧게 제한될 수 있으므로, 대형 이벤트 전에는 미리 대비가 필요합니다.
- 항목 크기가 비용을 바꿉니다 — 항목을 작게 나누거나 자주 읽는 속성만 따로 두면 요청당 단위 수가 줄어 두 모드 모두 저렴해집니다.
- 저장 요금은 모드와 무관합니다 — 데이터가 많고 요청이 적은 테이블은 용량 모드보다 저장량 관리(만료 시간 설정 등)가 비용에 더 큰 영향을 줍니다.
용량 모드에서 자주 묻는 것
프리 티어 25 WCU·25 RCU는 온디맨드에도 적용되나요?
요금 페이지는 프리 티어의 25 WCU와 25 RCU를 Standard 테이블 클래스를 쓰는 테이블의 프로비저닝 용량 기준으로 설명합니다. 아주 작은 테이블이라면 프로비저닝으로 프리 티어 안에 두는 편이 비용이 들지 않는 선택이 될 수 있습니다.
강한 일관성 읽기가 꼭 필요한가요?
방금 쓴 값을 바로 읽어야 하는 경우가 아니라면 최종적 일관성 읽기로도 충분한 경우가 많습니다. 읽기 단위가 절반으로 줄어 두 모드 모두에서 읽기 비용이 내려갑니다.
모드를 정한 뒤 확인할 다섯 가지
29% 기준으로 모드를 골랐다면, 실제 운영에서 요금이 계산대로 나오게 하는 설정이 따로 있습니다. 놓치기 쉬운 순서대로 정리했습니다.
| 확인 | 기준 | 놓치면 |
| 항목 크기 | 읽기 4KB, 쓰기 1KB 단위로 올림 | 1.1KB 항목을 쓰면 2단위로 과금, 크기를 1KB 아래로 줄이면 절반 |
| 프로비저닝의 자동 조정 목표 | 사용률 70%, 최소·최대 용량 지정 | 최대를 크게 두면 트래픽 폭주 때 요금 상한이 없어짐 |
| 모드 전환 횟수 | 24시간에 한 번만 바꿀 수 있음 | 잘못 바꾸면 하루 동안 되돌릴 수 없음 |
| 핫 파티션 | 파티션 키가 고르게 분산되는지 | 프로비저닝 용량이 남아도 특정 키만 제한에 걸림 |
| 예약 용량 | 프로비저닝 모드에서 1년·3년 약정 | 사용률이 일정한데 약정 없이 두면 최대 50%대 할인을 놓침 |
첫 줄의 항목 크기는 모드와 무관하게 가장 큰 변수입니다. 같은 요청 수라도 항목이 두 배 크면 요금이 두 배이므로, 자주 읽는 큰 속성은 별도 항목이나 S3로 빼는 설계가 모드 선택보다 먼저입니다.
정리
온디맨드는 쓰기 100만 건당 0.625달러, 읽기 100만 건당 0.125달러이고, 프로비저닝은 WCU 시간당 0.00065달러, RCU 시간당 0.00013달러입니다. 같은 처리량을 100% 쓰면 프로비저닝이 약 3.5배 저렴하지만, 평균 사용률이 약 29%보다 낮으면 온디맨드가 저렴해집니다. 새 테이블은 온디맨드로 시작해 실제 사용률을 확인한 뒤 바꾸는 것이 가장 안전한 순서입니다.
함께 읽으면 좋은 글: 서버리스 AWS Lambda 개념 / 비용 할당 태그와 Cost Explorer
참고 자료: DynamoDB 온디맨드 요금, DynamoDB 프로비저닝 요금, DynamoDB 용량 모드
※ 본 글은 2026년 10월 기준 Amazon DynamoDB 요금 페이지(미국 동부 리전, Standard 테이블 클래스)를 참고해 작성했으며, 요금은 리전과 시기에 따라 달라질 수 있으니 최신 내용은 AWS 공식 문서에서 확인해 주세요.
'IT 클라우드 정보' 카테고리의 다른 글
| CloudFront 캐시가 안 맞는 이유, 캐시 키와 TTL로 이해하는 캐시 정책 고르는 법 (0) | 2026.10.18 |
|---|---|
| NAT 게이트웨이 요금이 많이 나온다면, S3 게이트웨이 엔드포인트부터 확인하세요 (0) | 2026.10.17 |
| 지운 S3 파일을 되살리는 버전 관리와 아무도 못 지우게 하는 객체 잠금 (0) | 2026.10.16 |
| 비밀번호와 설정값은 어디에 둘까, Secrets Manager와 Parameter Store 요금으로 비교하기 (0) | 2026.10.15 |
| IAM 사용자 대신 IAM Identity Center를 쓰는 이유, 여러 계정 로그인을 한 곳에서 (0) | 2026.10.14 |