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 不讓你太快提升的限制）。你在一天開始時有 4 次調降可用，並每小時再賺 1 次，在任何時候最多 4 次可用 — 足夠在完整 24 小時內進行最多 27 次調降。用盡它，進一步的 UpdateTable 調降呼叫就會以 LimitExceededException 失敗（HTTP 400；developer guide 對此例外的通用訊息是 "Too many operations for a given subscriber."），直到預算補充。這是一個配額，因此在同一視窗內盲目重試無濟於事。

為什麼會發生

自動擴充抖動 — 突發的工作負載使 DynamoDB 自動擴充反覆調降容量，燒掉調降預算。
太頻繁調降容量的指令碼 — 許多小的調降而非一個較大的。
負載測試期間的手動調校 — 隨流量退去反覆調低容量。
每索引預算 — 表格與 GSI 的調降限制是解耦的，因此每個 GSI 有自己的額度；有數個索引的表格可能在其中之一觸及它。一個同時調降表格與 GSI 的 UpdateTable 請求，若任一者超過其目前限制，就會整個被拒絕。

如何修正

等待補充。 每小時有一次調降變得可用（任何時候最多 4 次可用）；每個 UTC 日開始新的 4 次調降預算。
做更少、更大的調降。 一步從 1000 → 200，而非五個 160 單位的步驟。
調校自動擴充 — 提高目標使用率並加上 scale-in cooldown，讓它停止如此積極地調降。
切換到隨需，若工作負載突發或不可預測：
```
aws dynamodb update-table --table-name <Table> \
  --billing-mode PAY_PER_REQUEST
```
隨需完全移除手動容量管理（及其調降配額）。

參考資料

最後驗證於 2026-07-13，對照上方連結的 AWS 官方文件。