Provisioned throughput decreases are limited within a given day
TL;DR — DynamoDB は、単一の UTC 日にテーブル（または GSI）のプロビジョンド読み取り/書き込みキャパシティを 下げられる 回数を制限します。割り当てを使い切ったため、UpdateTable が拒否されます。毎時の補充を待つ、下げを少数のより大きなステップにまとめる、またはテーブルを オンデマンド に切り替えて下げの管理を完全にやめてください。
意味
LimitExceededException: Subscriber limit exceeded: Provisioned throughput
decreases are limited within a given UTC day各テーブルは UTC 日を、少額のキャパシティ 下げ の予算とともに始めます（上げは必要に応じて何度でも行えますが、アカウントのクォータと、DynamoDB が急激に増やすのを許さないことに従います）。1日を 4 回の下げが利用可能な状態で始め、毎時 1 回追加され、いつでも最大 4 回まで利用可能です — フルの 24 時間日にわたって最大 27 回の下げに十分です。それを使い切ると、予算が補充されるまで、さらなる UpdateTable の下げ呼び出しは LimitExceededException（HTTP 400。開発者ガイドのこの例外の総合的なメッセージは "Too many operations for a given subscriber."）で失敗します。これは クォータ なので、同じウィンドウ内でやみくもに再試行しても役に立ちません。
発生する理由
- Auto Scaling のばたつき — スパイク的なワークロードが DynamoDB の Auto Scaling を繰り返しキャパシティを下げさせ、下げの予算を消費する。
- キャパシティを頻繁に下げすぎるスクリプト — 1つの大きな下げの代わりに多数の小さな下げ。
- 負荷テスト中の手動チューニング — トラフィックが引くたびにキャパシティを繰り返し下げる。
- インデックスごとの予算 — テーブルと GSI の下げの制限は分離されているため、各 GSI が独自の割り当てを持ちます。複数のインデックスを持つテーブルは、そのうちの1つで達することがあります。テーブルと GSI の両方を下げる単一の
UpdateTableリクエストは、いずれかが現在の制限を超えると全体が拒否されます。
修正方法
- 補充を待ちます。 1 回の下げが毎時利用可能になり（いつでも最大 4 回）、新鮮な 4 回の下げの予算が毎 UTC 日始まります。
- 少数の大きな下げを行います。 5 回の 160 ユニットのステップの代わりに、1 ステップで 1000 → 200 に下げます。
- Auto Scaling をチューニングします — ターゲット使用率を上げ、スケールインのクールダウンを追加して、それほど積極的に下げなくします。
- ワークロードがバースト的または予測不能なら オンデマンドに切り替えます:オンデマンドは手動のキャパシティ管理（とその下げのクォータ）を完全に取り除きます。
aws dynamodb update-table --table-name <Table> \ --billing-mode PAY_PER_REQUEST
関連するエラー
- ProvisionedThroughputExceededException — 読み取り/書き込みがプロビジョンドキャパシティを超えるときのランタイムスロットル。
- LimitExceededException — より広範なアカウント/テーブルのコントロールプレーンのクォータファミリー。
- 学習: オンデマンドとプロビジョンド
参考資料
- Quotas in Amazon DynamoDB — Amazon DynamoDB Developer Guide
- Error handling with DynamoDB — Amazon DynamoDB Developer Guide
- UpdateTable — Amazon DynamoDB API Reference
- DynamoDB on-demand capacity mode — Amazon DynamoDB Developer Guide
最終検証日 2026-07-13、上記にリンクした公式 AWS ドキュメントに照らして確認しました。