DynamoDB throttled on a hot partition despite capacity
TL;DR — テーブルには全体として未使用の RCU/WCU が十分にありますが、それでもスロットリングされます。単一のパーティションキーがホット だからです。すべての物理パーティションは、テーブルがどれだけキャパシティを持っていても、毎秒最大 3,000 読み取りユニット と 1,000 書き込みユニット を提供するよう設計されています。1つのキーに積み上がったトラフィックが、その1つのパーティションを枯渇させます。リクエストをより多くの別個のパーティションキーに分散させる(書き込みシャーディング)ことで修正します。
意味
ProvisionedThroughputExceededException: You exceeded your maximum allowed
provisioned throughput for a table or for one or more global secondary indexes.
# ...yet CloudWatch shows consumed capacity well below provisioned.DynamoDB はテーブルを多数の 物理パーティション に分散し、テーブルのキャパシティはそれらの間で分割されます。個々のパーティションは、両方のキャパシティモードで、毎秒最大 3,000 読み取りユニットと 1,000 書き込みユニットを提供するよう設計されています。アクセスパターンが1つのパーティションキーにトラフィックを集中させると、そのキーのパーティションが独自の上限に達しスロットリングします。テーブル全体のメトリクスが未使用に見えてもです(エラーの ThrottlingReason フィールド、例: TableReadKeyRangeThroughputExceeded が、達した正確な制限を示します)。アダプティブキャパシティは助けになりますが、本当に不均衡なキーを救うことはできません。
発生する理由
- カーディナリティの低いパーティションキー — ステータスフラグ、ブール値、「現在の日付」、またはほとんどのトラフィックを受け取る単一のテナント。
- バイラル / セレブなアイテム — 1つの人気のあるパーティションキー(トレンドの商品、ホットなユーザー)が不釣り合いな負荷を集める。
- 「今日」キーの時系列 — すべての書き込みが同じ日付ベースのパーティションキーに着地する。
- 書き込みが最新のパーティションに集まる 順次または単調なキー。
- カーディナリティの低いパーティションキーを持つ GSI。ベーステーブルの書き込みをスロットリングします。
修正方法
- キーのカーディナリティを上げます。 リクエストが多くの値に分散するようパーティションキーを設計します — これが単一で最も効果的な修正です。
- ホットキーを書き込みシャーディングします。 サフィックスを付け(
USER#42#1…USER#42#N)、1つの論理エンティティが複数のパーティションにまたがるようにします。読み取りをシャード全体にファンアウトします。 - 時系列キーに ランダム性や計算されたサフィックスを追加し、「今日の」書き込みがすべて衝突しないようにします。
- ホットな読み取りをキャッシュ(DAX やアプリケーションキャッシュ)し、ホットパーティションから読み取り圧力を逃がします。
- 指数バックオフのリトライを維持します — このエラーはリトライ可能で、SDK はデフォルトでバックオフします。
- カーディナリティの低い GSI キーを修正します — スロットリングされた GSI はベーステーブルをスロットリングします。
再設計しながらキーの分布を検査したいですか?DynoTable デスクトップアプリ はパーティションキーでフィルタ・ソートできるため、再シャーディングする前に過負荷のキーが明白になります。
DynoTable でサイズを確認する
ホットなパーティションキーを見つけましょう — ⌘K でテーブルを開き、パーティションキーで並べ替え、隣のキーより極端に多くのアイテムを抱えているキーを探します。そのキーに絞り込み、再シャーディングの前に書き込みパターンを確認してください。
書き込みシャードの接尾辞はクエリビルダーでモデリングし、リトライで増えるトラフィックは料金計算ツールで見積もりましょう。プロファイルの切り替えは ⌘P です。AWS に接続するとインストールを参照してください。
出典
- Best practices for designing partition keys (2026-07-13 時点で検証)
- Troubleshooting throttling in Amazon DynamoDB (2026-07-13 時点で検証)
よくある質問
テーブルに余裕があるのに DynamoDB がスロットリングするのはなぜですか? 単一のパーティションキーがホットだからです。すべての物理パーティションには、テーブルレベルのキャパシティに関わらず毎秒約 3,000 読み取りユニットと 1,000 書き込みユニットの上限があるため、1つのキーに積み上がったトラフィックが、テーブル全体のメトリクスが未使用に見える一方でその1つのパーティションを枯渇させます。
DynamoDB のホットパーティションを修正するには? リクエストが多くの値に分散するようパーティションキーのカーディナリティを上げる、サフィックスでホットキーを書き込みシャーディングする、時系列キーに計算されたサフィックスを追加する、ホットな読み取りをキャッシュします。指数バックオフのリトライは短いスパイクを乗り切るのに役立ちますが、不均衡なキーを修正しません。
関連するエラー
- ProvisionedThroughputExceededException — 一般的なスロットリングエラーとキャパシティの修正。
- ThrottlingException — アカウント/コントロールプレーンのレート制限。
- 学習: ホットパーティション · パーティションキーの仕組み
参考資料
- Best practices for designing and using partition keys effectively in DynamoDB — Amazon DynamoDB Developer Guide
- Using write sharding to distribute workloads evenly in your DynamoDB table — Amazon DynamoDB Developer Guide
- Troubleshooting throttling in Amazon DynamoDB — Amazon DynamoDB Developer Guide
- Error handling with DynamoDB — Amazon DynamoDB Developer Guide
最終検証日 2026-07-13、上記にリンクした公式 AWS ドキュメントに照らして確認しました。