DynamoDB 能自動調整規模嗎？
可以。DynamoDB 自動調整規模會透過 Application Auto Scaling，在你定義的上下限之內，把佈建的讀取與寫入容量調向一個目標使用率（可設定 20–90%，常見是 70%）。或者，隨需容量模式不需任何設定就會即時隨流量擴縮。兩者都能讓資料表在負載變化時保持回應，而不需要人工做容量規劃。
佈建容量的自動調整規模
你會為每張資料表（以及每個全域次要索引）建立一個擴縮政策，設定：
- 一個目標使用率（要瞄準佈建容量的百分之多少）、
- 最小與最大容量單位，以及
- 要擴縮讀取、寫入，還是兩者。
當消耗量越過目標時，CloudWatch 警示會觸發 Application Auto Scaling 調高或調低容量。
隨需模式
隨需容量完全免去規劃：DynamoDB 會自行把輸送量調整到符合你的流量 — 立即容納到你前一次流量高峰的兩倍 — 並依請求計費。當流量是突發式的或難以預測時，它很合適。
該選哪一個
當流量穩定且你很清楚它的樣子時，搭配自動調整規模的佈建模式通常比較便宜；隨需模式則比較單純，也更適合未知或突發的流量。
目標使用率在哪裡就不再划算
目標使用率是一個價格旋鈕，而它有一個底線 — 低於那個底線，自動調整規模就徹底輸給隨需模式。
在 us-east-1，一個寫入容量單位每小時 0.00065 美元，所以保留一個月要 0.4745 美元，換得 2,628,000 次寫入。那是每次寫入 0.00000018 美元，對上隨需模式的 0.000000625 美元，也就是當每一個保留單位都被用掉時，佈建容量便宜 3.46 倍。把它倒過來就得到損益兩平點：平均使用率低於 28.9% 時，佈建就不再划算。讀取算出來也是同樣的 28.9%，所以這是定價模型的性質，而不是某一組費率的偶然結果。
以每秒持續 1,000 次、每筆 1 KB 項目的寫入，用定價計算機估價：
| 容量設定 | 佈建 | 每月 |
|---|---|---|
| 90% 目標 | 1,112 WCU | $527.64 |
| 70% 目標 | 1,429 WCU | $678.06 |
| 50% 目標 | 2,000 WCU | $949.00 |
| 20% 目標 | 5,000 WCU | $2,372.50 |
| 隨需 | 無 | $1,642.50 |
教訓在最後兩列。20% 的目標是 AWS 接受的最低值，它保留了五倍於你流量的容量，而做同樣的事卻比按請求付費貴 44%。上面每一列都假設自動調整規模把容量精準釘在目標上，所以請把它們當成最好的情況：真實流量會四處遊走，而演算法總是慢半拍跟上，這會把實際達成的使用率拖到你所設定的值之下。
這個旋鈕買到了什麼
擴容與縮容是刻意不對稱的，而那份不對稱正是這些餘裕所買到的東西。AWS 記載擴容會在消耗容量連續兩分鐘超過目標之後觸發，縮容則要連續 15 個資料點低於目標。接著那次 UpdateTable 呼叫還要再花上幾分鐘，而在它進行的期間，超過舊上限的請求都會被節流。
調降次數也是配給制的。每個 UTC 日開始時你有四次，之後每小時再賺一次，手上最多不超過四次，因此每張資料表每天最多 27 次。全域次要索引有自己的一份額度。
所以高目標值省下的是實實在在的錢，花掉的則是那段時間所需的緩衝。隨需模式每次請求貴一些，但整個把這個取捨拿掉了。
深入了解
在隨需與佈建容量的比較中比較兩者，並用定價計算機估算成本。下載 DynoTable，就能在「Table stats」中讀取一張資料表的大小與項目數估計值。
參考資料
- Managing throughput capacity automatically with DynamoDB auto scaling — Amazon DynamoDB Developer Guide
- DynamoDB on-demand capacity mode — Amazon DynamoDB Developer Guide
- DynamoDB provisioned capacity mode — Amazon DynamoDB Developer Guide
- Quotas in Amazon DynamoDB — Amazon DynamoDB Developer Guide — 調降額度，已於 2026-07-28 重新查證。
最後驗證於 2026-07-13，對照上方連結的 AWS 官方文件。
損益兩平點於 2026-07-28 以我們自己的定價計算機計算，費率取自它從 AWS Price List API 同步而來的 us-east-1 費率。擴縮延遲與調降額度於同一天重新讀自上方連結的 AWS 文件。