DynamoDB の On-Demand と Provisioned、どちらが安い?料金と運用負荷の判断基準を整理する
DynamoDB の料金で迷いやすいのが、On-Demand と Provisioned のどちらを選ぶべきか、という話です。
「On-Demand は高い」「Provisioned の方が正義」と雑に覚えると、現場で普通に外します。実際には、アクセスパターンが読めるか、急なスパイクにどこまで備えたいか、Auto Scaling を含む運用をどこまで持ち込みたいかで答えが変わります。
この記事では、DynamoDB の 2 つのキャパシティモードを 料金 と 運用負荷 の両面から整理します。試験対策向けの暗記ではなく、設計判断として腹落ちする形でまとめます。
まず結論
先に結論を書くと、基本の判断軸はかなりシンプルです。
- アクセス量が読みにくい、または急なスパイクが多い → On-Demand
- 安定したアクセスが続き、必要容量をある程度見積もれる → Provisioned
つまり、
- 予測不能な負荷に強く、容量設計を減らしたいなら On-Demand
- 安定運用で単価を詰めたいなら Provisioned
です。
ここで大事なのは、どちらが常に安いかではなく、どの前提で安くなるか を見ることです。
On-Demand は「見積もりを捨てて変動に強くする」選択
On-Demand モードでは、RCU / WCU を事前に細かく決めなくても、実際のリクエスト量に応じて課金されます。
この方式が強いのは、たとえば次のようなケースです。
- リリース直後でアクセスが読めない
- キャンペーンやバッチで急に負荷が跳ねる
- 社内ツールで月末だけ利用が集中する
- PoC や新機能で、まだ利用パターンが固まっていない
要するに、予測のために頭を使うより、変動をそのまま受け止めた方が安い 場面に向いています。
On-Demand の利点
- 初期設定が軽い
- 急なアクセス増に合わせやすい
- 容量不足の見積もりミスを避けやすい
- 小さく始めるサービスと相性がよい
On-Demand の注意点
- 安定して大量アクセスが続くなら割高になりやすい
- 「何も考えなくていい」ぶん、継続利用時の見直しが遅れやすい
たとえば、平日はほぼ idle で、たまに API が一気に叩かれるワークロードなら、Provisioned を細かく調整するより On-Demand の方が素直です。
Provisioned は「読める負荷を安く回す」選択
Provisioned モードでは、読み込みキャパシティと書き込みキャパシティをあらかじめ設定します。負荷が比較的安定しているなら、必要量に合わせて単価を詰めやすいのが強みです。
向いているのは、たとえば次のようなケースです。
- 1 日を通してアクセス量が大きくぶれない
- 既存システム移行で、必要スループットの実績がある
- 高トラフィックが長く続くことが確定している
- Auto Scaling を使って、ある程度の増減だけ吸収すればよい
Provisioned の利点
- 安定負荷ならコストを最適化しやすい
- 既存メトリクスを元に設計しやすい
- 長期運用のチューニング余地がある
Provisioned の注意点
- 見積もりを外すと、余剰コストかスロットリングのどちらかを踏みやすい
- キャパシティ設計と監視を持ち込む必要がある
Provisioned は安くできる反面、その安さは設計と運用の手間込み です。ここを無視して「単価だけ」で決めると、結局は人件費と障害対応で損します。
比較表で整理する
| 観点 | On-Demand | Provisioned |
|---|---|---|
| 課金の考え方 | 使ったリクエスト量ベース | 事前に確保した容量ベース |
| 向いている負荷 | 変動が大きい / 読めない | 安定して予測しやすい |
| 初期設計 | 軽い | やや重い |
| 運用負荷 | 低め | 監視・調整が必要 |
| コスト最適化 | 変動負荷に強い | 安定負荷で有利 |
この表だけでも、かなり切り分けやすくなります。
料金だけでなく「運用負荷」も見る
ここを見落とす人が多いです。
Provisioned が安く見えても、実際には次の運用がついてきます。
- 必要な RCU / WCU の見積もり
- CloudWatch メトリクスの監視
- スロットリング発生時の見直し
- Auto Scaling の下限・上限調整
一方で On-Demand は、料金のぶれを受け入れる代わりに、こうした設計作業をかなり減らせます。
たとえばスタートアップの初期機能や、社内向けの利用頻度が読みにくい API なら、少し単価が高く見えても On-Demand の方が総コストで安い ことは普通にあります。なぜなら、障害調査と設定調整に人の時間を溶かさないからです。
典型シナリオ別の選び方
シナリオ 1: 新規サービスの立ち上げ
利用者数がまだ読めず、SNS で拡散される可能性もある。
- 選びやすいのは On-Demand
- 理由は、初期段階で容量予測に工数を割くより、まず安全に受けられる方が大事だから
シナリオ 2: 社内基幹の安定ワークロード
毎日ほぼ同じ件数の読み書きがあり、季節変動も小さい。
- 選びやすいのは Provisioned
- 理由は、実績値をもとに必要容量を置けるので、長期ではコストを詰めやすいから
シナリオ 3: 昼だけ極端に増える API
日次でピークの傾向は読めるが、完全固定ではない。
- ここは Provisioned + Auto Scaling も候補
- ただし、変動幅が大きく読みにくいなら On-Demand の方が設計が素直
つまり、単純に 2 択ではなく、予測精度がどこまであるか が分かれ目です。
試験で迷った時の判断基準
AWS 認定試験では、次のような言い回しが出たらかなり絞れます。
-
アクセスパターンが予測できない
-
管理オーバーヘッドを減らしたい
-
急なトラフィックスパイクに対応したい
- → On-Demand
-
安定したトラフィック
-
コストを最適化したい
-
利用実績がある
- → Provisioned
この軸を持っていれば、「DynamoDB だからとりあえず On-Demand」みたいな雑な判断は避けられます。
まとめ
DynamoDB の On-Demand と Provisioned は、安い方を固定で選ぶ話ではありません。
- On-Demand は、読めない負荷に対して設計を軽くしやすい
- Provisioned は、読める負荷に対してコストを詰めやすい
判断するときは、料金表だけでなく、アクセス予測のしやすさ と 運用で背負う手間 を一緒に見てください。
そこまで含めて考えると、どちらを選ぶべきかはかなり素直に決まります。