DynamoDB の On-Demand と Provisioned、料金だけで選ぶとだいたい外す話
DynamoDB を設計するとき、最初に迷いやすいのが On-Demand と Provisioned のどちらを選ぶべきか、という点です。
どちらも同じ DynamoDB のキャパシティモードですが、違いは単なる課金方式ではありません。実際には、アクセス予測のしやすさ、急なスパイクへの強さ、CloudWatch を使った運用管理の重さ まで含めて判断する必要があります。
この記事では、DynamoDB の 2 つのモードを、料金だけでなく運用の観点も含めて整理します。
先に結論
まず結論として、基本の考え方は次の通りです。
- アクセス量が読みにくい、または 急なスパイクがある → On-Demand
- 安定したアクセスが継続し、必要容量をある程度見積もれる → Provisioned
つまり、
- 予測不能な負荷に強く、管理を軽くしたいなら On-Demand
- 安定負荷を長く回し、料金を詰めたいなら Provisioned
です。
こ��で重要なのは、「どちらが絶対に安いか」ではなく、どの前提で有利になるか を見ることです。
On-Demand の特徴
On-Demand は、読み書きのリクエスト量に応じて課金されるモードです。RCU や WCU を細かく見積もる前提が薄いため、設計の初動を軽くできます。
向いているケース
- 新規サービスで利用者数がまだ読めない
- キャンペーンやイベントでスパイクが起こる
- 社内システムで利用頻度が月末や締め日に偏る
- PoC や検証用途で、まず動かしたい
利点
- 容量見積もりを最小限にできる
- 急なアクセス増に対応しやすい
- 初期リリース時の設定ミスを減らしやすい
注意点
- 高いトラフィックが安定して続くなら、Provisioned より割高になりやすい
- 便利なので、そのまま放置してコスト最適化の機会を逃しやすい
たとえば、API のヒット数が日によって大きく変わるなら、Provisioned を細かく追い込むより On-Demand の方が現実的です。
Provisioned の特徴
Provisioned は、必要な読み書き容量を事前に設定するモードです。負荷の傾向が見えているなら、コストをかなり詰めやすくなります。
向いているケース
- 日次・週次のトラフィックが安定している
- 既存システムの移行で必要量の実績がある
- 長期間にわたって高トラフィックが続く
- Auto Scaling で小さな増減だけ吸収すれば足りる
利点
- 安定ワークロードではコストを最適化しやすい
- 既存メトリクスをもとに設計しやすい
- 長期運用でチューニングしやすい
注意点
- 容量見積もりを外すと、余剰コストかスロットリングを招きやすい
- Auto Scaling や CloudWatch アラームを含めた運用設計が必要になる
Provisioned は安くできる可能性がありますが、その前提として読める負荷が必要です。ここが曖昧なら、単価だけ見て選ぶと失敗しやすくなります。
比較表で整理する
| 観点 | On-Demand | Provisioned |
|---|---|---|
| 課金の軸 | 実リクエスト量 | 事前確保した容量 |
| 向いている負荷 | 変動が大きい / 予測しづらい | 安定して予測しやすい |
| 設計の重さ | 軽い | やや重い |
| 運用管理 | 少なめ | 監視と調整が必要 |
| コスト面の強み | スパイク対応時に無駄が少ない | 安定高負荷で有利 |
この表を見れば、どちらを選ぶかはかなり素直に判断できます。
実務で見るべきポイント
実務では、料金表だけで決めると危険です。少なくとも次は確認したいところです。
- アクセス量は本当に読めるか
- ピーク時の増減幅はどれくらいか
- CloudWatch で継続的に見張る運用を許容できるか
- スロットリング時の影響は大きいか
たとえば、昼休みや夜間にだけ急増する API で、しかも伸び方が日によって違うなら、On-Demand の方が設計として自然です。逆に、社内向けバッチや安定した参照系のように、必要な throughput が見えているなら Provisioned が効きます。
試験で迷わないための軸
AWS 認定試験では、問題文の言い回しでかなり判別できます。
-
予測不能なアクセス
-
管理オーバーヘッドを下げたい
-
急なスパイクに耐えたい
- → On-Demand
-
安定したトラフィック
-
コスト最適化
-
利用実績がある
- → Provisioned
この切り分けができれば、DynamoDB 関連の設問はかなり安定します。
まとめ
DynamoDB の On-Demand と Provisioned は、どちらが上という話ではありません。
- On-Demand は、予測しづらい負荷に対して設計と運用を軽くしやすい
- Provisioned は、安定した負荷に対して料金を詰めやすい
判断材料としては、アクセス予測の精度 と 運用にかけられる手間 をセットで見るのがコツです。
その2つを押さえるだけで、料金の話がずっと実務寄りに見えるようになります。