DynamoDB on-demand throughput exceeded

TL;DR — 是的，隨需表格仍會節流。三個原因：你設定了最大吞吐量（MaxReadRequestUnits/MaxWriteRequestUnits）並超過它；你在 30 分鐘內驅動了超過先前流量尖峰的兩倍；或你觸及了表格層級配額（每個表格預設 40,000 個讀取請求單位與 40,000 個寫入請求單位）。提高或移除最大值、逐步增加流量，並保持指數退避重試。

這是什麼意思

ThrottlingException: Rate of requests exceeds the allowed throughput.

隨需模式會擴充以容納流量，但不是瞬間的，也不是沒有上限的。新的隨需表格立即維持每秒最多 4,000 次寫入與 12,000 次讀取，而隨需立即容納最多你先前流量尖峰的兩倍。超過設定的最大值、在 30 分鐘內衝過那個加倍，或越過配額，全都浮現為節流 — ThrottlingException 是 HTTP 400 且可重試，而錯誤帶有 ThrottlingReason 欄位（例如 IndexWriteMaxOnDemandThroughputExceeded），指名被觸及的資源與限制。

為什麼會發生

設定的最大吞吐量 — 你設定了 MaxReadRequestUnits/MaxWriteRequestUnits 而需求越過它；DynamoDB 回傳 ThrottlingException（這是你選擇的成本控制上限，盡力套用）。
快於先前尖峰的 2 倍 — 隨需立即容納最多先前尖峰的兩倍，但若你在 30 分鐘內超過該尖峰的兩倍，就可能發生節流。
冷啟動衝刺 — 全新的表格（或建立後立即的大量載入）超過每秒 4,000 次寫入與 12,000 次讀取的初始基線。
表格層級配額 — 每個表格預設 40,000 個讀取請求單位與 40,000 個寫入請求單位的上限；帳戶層級的配額違反改以 RequestLimitExceeded 浮現。
熱 partition — 流量集中在一個 partition key 上，它有自己的每 partition 限制，與表格模式無關。

如何修正

提高設定的最大值 — 透過 UpdateTable 增加 MaxReadRequestUnits/MaxWriteRequestUnits，或將值設為 -1 以移除你的自訂上限（服務配額仍適用）。
在已知尖峰前預熱 — 使用 DynamoDB 的 warm throughput 設定，或將流量增長分散至少 30 分鐘，讓隨需的加倍保持領先需求，而非追趕階梯式變化。
保持指數退避重試 — SDK 預設會重試節流；對突發負載使用 adaptive retry 模式。
控制大量匯入的節奏，或使用 S3 匯入功能，而非猛打全新的表格。
分散鍵空間，讓沒有任何單一 partition key 變熱 — 熱 partition 即使在表格有餘裕時也會節流。
請求配額增加，若你確實需要在一個表格上超過 40,000 個讀取/寫入請求單位。

追查哪個鍵在吸走請求？在 DynoTable 桌面應用程式中瀏覽並篩選表格，在它限制你的吞吐量前找出熱 partition key。

常見問題

DynamoDB 隨需表格會被節流嗎？ 會。隨需表格在你超過設定的最大吞吐量、在 DynamoDB 完成擴充前驅動超過先前流量尖峰的兩倍、越過每個表格預設 40,000 個讀取與 40,000 個寫入請求單位的配額，或將流量集中在熱 partition key 時，會節流。

我要如何提高隨需吞吐量限制？ 透過 UpdateTable 增加 MaxReadRequestUnits/MaxWriteRequestUnits，或將值設為 -1 以移除你的自訂上限 — 帳戶配額仍適用。若你需要超過每個表格預設 40,000 個請求單位，請請求配額增加。

參考資料

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