DynamoDB 隨需與佈建容量
DynamoDB 以兩種方式計收輸送量費用。隨需按每次請求計費 — 你用多少付多少，可縮減至零。佈建則保留一個固定的讀寫速率，無論你用不用都要付費，但每單位的價格低得多。挑錯一邊，是最容易超付的方式之一。
稽核記錄讓這個選擇變得具體。稽核寫入是尖峰且難以預測的：深夜安靜無事，接著當某位客戶執行一次大量操作、或某起事件產生數千個事件時，就湧入一波洪流。這種流量形狀，就是整個決策的關鍵。
我應該使用 DynamoDB 隨需還是佈建容量？
隨需按請求計費，可縮減至零，是應對尖峰、新建或流量不可預測的資料表最安全的預設選擇。佈建則以低得多的每單位價格保留固定的讀寫速率，只有在持續穩定的流量能讓該保留維持高使用率時才划算。除非你的流量已有實績且可預測，否則請選隨需。
- 隨需＝按每次請求付費、可縮減至零。 沒有容量需要規劃；每次讀寫付的單價較高，但只在流量發生時才付。
- 佈建＝保留一個穩定速率、永遠都要付。 若速率使用率高，每單位便宜得多；你得吞下閒置容量的成本。
- 尖峰／未知流量 → 隨需。 穩定、可預測、高量的流量 → 佈建（可選搭配自動調整規模）。
- 你可以切換模式，但每 24 小時只能切換有限次數 — 它不是一個逐請求的開關。
問題：為你不用的容量付費
採用佈建容量時，你承諾比如說每秒 1,000 個寫入單位。如果稽核記錄平均每秒 50 次寫入，但你卻為事件爆發日的尖峰佈建，那你就得全天候為 1,000 付費，卻只用了其中的二十分之一。改為依平均佈建，那麼事件爆發日的洪流就會被節流 — 寫入遭到拒絕。
所以固定容量在尖峰流量上逼你做一個糟糕的取捨：要嘛持續超付，要嘛佈建不足而在最要緊的時候丟掉寫入。隨需的存在正是為了消除這個取捨。
兩種模式如何運作
隨需對你實際消耗的讀取與寫入請求單位計費，沒有容量需要設定 — 它能即時容納流量尖峰，並在閒置時縮減至零。你為這份彈性，付出每次請求較高的溢價。
佈建保留每秒固定數量的讀取容量單位（RCU）與寫入容量單位（WCU）。每單位的價格低得多，但無論用不用，你都要持續為這份保留付費。超出它，DynamoDB 就會節流，除非啟用自動調整規模以在設定的範圍內擴增容量 — 不過自動調整規模是以分鐘為單位反應的，所以一次突發的尖峰在它跟上之前仍可能被節流。
臨界點在於使用率。大致來說：若你持續、可預測的流量讓佈建容量維持高使用率，佈建在價格上勝出；若流量是尖峰、突發或未知的，隨需就靠著不為閒置保留收費而勝出。
一個實作範例：稽核記錄的帳單
稽核記錄平均每秒寫入約 50 個事件，但在事件期間會爆發到數千，而讀取流量則低得多（合規匯出、偶爾的調查）。每個事件都很小 — 遠低於 1 KB。
在佈建上，你得為爆發保留（並全天候付費），不然就得冒著節流事件爆發日洪流的風險 — 而那正是最不該丟掉稽核寫入的時刻。在隨需上，安靜時段幾乎不花錢，而爆發會被自動吸收；你只為確實發生的寫入付費。
對這個工作負載而言，隨需是正確的預設。一般法則是：任何新的或尖峰的表格都從隨需開始，只有在流量被證實穩定到足以讓保留維持高使用率時，才轉到佈建。
把你自己的數字 — 每秒讀寫數、項目大小、儲存量 — 填進去，看看兩種模式在單一區域下的並排比較：
若要套用免費方案的完整多區域樣貌，請使用 DynamoDB 定價計算機。
在 DynoTable 中實作
容量決策始於真實的數字：項目有多大、有多少個、寫入得多快。靠猜測這些，就是表格落得佈建錯誤的原因。
要把一個範例事件轉換成它實際消耗的 RCU/WCU，請透過 項目大小計算機 執行一遍。接著，把決策落地到你的真實表格： DynoTable 會呈現表格中繼資料 — 項目數量與大小 — 並讓你檢視具代表性的項目，以便準確估算它們的大小。
陷阱與後續步驟
- 切換模式有頻率限制。 你可以在隨需與佈建之間切換，但每 24 小時只能有限次數 — 把它當成一個慎重的決定，而不是一個可以隨意轉動的旋鈕。
- 自動調整規模不是即時的。 它以分鐘為單位反應，所以佈建上一次陡峭的尖峰，可能在容量擴增之前就被節流。對於真正突發的流量，隨需會直接吸收尖峰。
- 熱分割不論哪種模式都會節流。 即使是隨需也有每分割的上限 — 不均勻的鍵可能在表格看似容量充足時就遭節流。請見熱分割。
- GSI 有自己的容量。 每個 index 都分開計費，且若佈建不足，可能節流基礎表格的寫入 — 請見GSI 為何會節流基礎表格的寫入。
容量模式決定了你在單一區域中執行該表格要付多少。接下來：用 DynamoDB Global Tables 把它跨區域複寫。
下載 DynoTable 來讀取表格的真實大小與項目數量，再決定要採用哪種容量模式。