はじめに
DynamoDBのキャパシティーモード（オンデマンド/プロビジョニング）、及びそれによる違いについて書こうと思います。
なおこの記事は、下記（私の個人ブログ）とほぼ同じ内容です。
https://makky12.hatenablog.com/entry/2025/01/20/120500
前提その1：「キャパシティーモード」って？
ざっくり言うと「DynamoDBの動作モード」となります。
DynamoDBには、下記2つのモードがあります。
- オンデマンド（デフォルト）
- プロビジョンド
キャパシティーモードにより大きく異なるのは、主に以下2つです。
- 高負荷時の動作（≒オートスケーリング）
- 課金体系
前提その2：「リクエストユニット」「キャパシティユニット」って？
オンデマンドとプロビジョンド、どちらのモードにせよ、DynamoDBの課金は「ユニット」で実施されます。
このユニットですが、オンデマンド・プロビジョンドで、それぞれ下記の名称となっています。
| モード | 名称 | 書き込み単位 | 読み込み単位 | 備考 |
|---|---|---|---|---|
| オンデマンド | 要求ユニット(RU) | WRU | RRU | RUのRはRequestのR |
| プロビジョンド | キャパシティユニット(CU) | WCU | RCU |
一見ややこしそうですが、RU/CU共に読み込み・書き込み時の1ユニットの定義はほぼ同じで、下表のようになっています。（詳細は各モードの説明で触れます）
※書き込み/読み込み容量が増えると、その分消費RU/CUも増えます。
書き込み時
1KBまでの書き込みに対して、下記のWRU/WCUを消費する。
| 書き込みモード | 消費WRU/WCU数 | 備考 |
|---|---|---|
| 標準書き込み | 1 | デフォルトはこれ |
| トランザクション書き込み | 2 |
読み込み時
4KBまでの読み込みに対して、下記のRRU/RCUを消費する。（なお料金計算時には、1未満の端数は1に切り上げられます）
| 読み込みモード | 消費RRU/RCU数 | 備考 |
|---|---|---|
| 結果整合性 | 0.5 | デフォルトはこれ。 |
| 強力な整合性 | 1 | |
| トランザクション | 2 |
オンデマンドモード
オンデマンドモードは、いわゆる「使った（＝読み書きした）分だけ料金を支払う」モードです。（サーバーレスっぽい動作）
以下の特徴があります。
細かい設定・管理が不要
「使った分だけ払う」モードなので、事前にあれこれ細かい設定が不要で「とりあえずDynamoDBを使ってみる」のに向いています。
リクエスト数の変化に強い
リクエスト数の急激な変化にもDynamoDB側で柔軟に対応してくれるので（Auto Scalling）、予想外のリクエストにも強いです。（もちろん限度はあります）
そのため、使用状況が予想できない場合にも有効です。
課金体系
- 読み込み・書き込みリクエストで消費したWRU/RRUに対して課金されます。
- 読み込み・書き込みリクエストで消費するWRU/RRUは「前提その2」の表の通りです。
※キャパシティモードと違い「1秒当たり」という条件はありません。（あくまでも実際に消費したWRU/RRUに対する課金）
プロビジョンドモード
プロビジョンドモードは、想定される消費WRU/RCUを事前に設定しておくモードです。
オンデマンドモードと違い、ある程度運用管理の手間が発生しますが、その分コストはオンデマンドより抑えられる傾向があります。(「で、どっちを使うべき？（ユースケース）」を参照)
なお厳密にいうと、下記項目を事前に設定する必要があります。（読み込み/書き込み共に）
- 最小＆最大キャパシティユニット
- 使用率
- プロビジョンされた最初のユニット 1
特徴としては、以下の通りです。
オンデマンドモードより安価になる傾向がある
単価がオンデマンドモードより安価なため、オンデマンドモードよりコストを抑えられる傾向があります。
中～大規模な使用に向いている
規模が大きくなればなるほど「単価がオンデマンドモードより安価」の影響が大きくなってきます。
そのため規模が大きいほどプロビジョンドモードの恩恵も大きいです。（プロビジョンドモードが使用可能ならば）
課金体系
- 「事前に設定したWCU/RCU」に対して課金が発生します。
- 実際に消費したWCU/RCUは関係ありません
- 「1秒あたり」のWCU/RCUで課金を計算します。
- オンデマンドモードと違い、時間の条件があります。
なお1秒あたりに消費するWCU/RCUは「前提その2」の表の通りです。
で、どっちを使うべき？（ユースケース）
一番気になる「どちらを使うべきなのか」ですが、個人的には下記ではないかと思います。
オンデマンドモードが良いケース
比較的小規模な場合
プロビジョンドモードの説明で述べた通り「規模が大きくなるほどプロビジョンドモードとオンデマンドモードの差は大きくなりがち」です。
逆にいうと、規模が小さい場合はそこまで差が発生しないので、運用管理コストを考えるとオンデマンドモードの方が良い場合が多いです。
利用状況が予測不可能な場合
プロビジョンドモードはあらかじめWCU/RCUを設定しておく必要があるので、利用状況が予測できないと使用しづらく、スロットリングの発生にもつながってしまいます。
オンデマンドモードはそのあたりをDynamoDB側が柔軟に対応してくれるので、利用状況が予測できない場合も扱いやすいです。
プロビジョンドモードが良いケース
中～大規模な場合
先述の通り、規模が大きくなればなるほどプロビジョンドモードとオンデマンドモードの差は大きくなりがちなので、中～大規模になる（=規模が大きくなる）場合、（利用状況が予測できるなら）プロビジョンドモードのほうが良いことが多いです。
利用状況が予測可能な場合
あらかじめ利用状況が予測できるなら、プロビジョンドモードの方が安価に済むケースが多いです。
ただし先程述べた通り、小規模だとそこまで差が発生しないので、運用管理コストを考えると中～大規模な場合にプロビジョンドモードを使用するのが良いかもしれません。
実際にプロダクトに導入する場合の使い方
実際にプロダクトで導入する場合は、
- まずはオンデマンドモードで導入し、しばらく様子を見る
- その後メトリクスで消費WCU/RCUを確認し、WCU/RCUの目星が付く＆切り替えた方が良い場合は、プロビジョンドモードに切り替える
というステップを踏むのが良いと思います。
ちなみに消費WCU/RCUは、下記メトリクスで確認できます。（このメトリクスはプロビジョンドモードにおいても「実際に消費したWCU/RCU数」を示します）
- ConsumedWriteCapacityUnits（書き込み）
- ConsumedReadCapacityUnits（読み込み）
またプロビジョンモードは運用管理の手間もある程度発生しますので、単にコストだけでなく、そういった手間も考慮してどちらにするか決めた方が良いと思います。
（参考）プロビジョンドモードとオンデマンドモードの損益分岐点
一般的に「プロビジョンドモード時の設定WCU/RCUに対して、実際のリクエスト数が29%程度の場合にオンデマンドモードとプロビジョンドモードの金額が一致する」ようです。
ざっくり言うと「実際のリクエスト数が、プロビジョンドモード時の設定WCU/RCUから算出したリクエスト数の29%以下ならオンデマンドモードの方が、それを超えるならプロビジョンドモードの方が安い」ということです。（詳細な計算方法は下記記事を参照）
ちなみに今までは約14.4%だったのですが、2024/11に料金改定でオンデマンドモード＆グローバルテーブルの料金が約半額になった結果、損益分岐点も約2倍になりました。
まとめ
以上、DynamoDBのキャパシティモードの違いでした。
私自身、プロビジョンドモードの仕様は何回扱ってもこんがらがってしまう部分があるので（特に設定や課金体系）、定期的に見直していきたいと思いました。
宣伝
2/1(土)に富山で開催される「BuriKaigi 2025」において「Amazon Aurora バージョンアップについて、改めて理解する ～ バージョンアップ手法と文字コードへの影響 ～」というセッションで登壇させて頂くことになりました。
内容としてはAmazon Aurora のバージョンアップ概要やバージョンアップしないことでの影響、またバージョンアップ時に気を付けることなどをお話しする予定です。
それでは、今回はこの辺で
-
テーブルまたはインデックスの開始時にプロビジョニングされる容量。オンデマンドからプロビジョニングされた容量モードに切り替えるとき、テーブルまたはインデックスのトラフィックを処理できるよう、十分に高い要領に設定する必要がある ↩