DynamoDB 隨需對佈建容量
DynamoDB 用兩種方式為輸送量計費。隨需按請求收費——你用多少付多少，能縮減到零。佈建預留一個固定的讀寫速率，不管你用不用都要付費，但每單位的價格低得多。選錯是最容易多付錢的方式之一。
稽核日誌把這個選擇變得具體。稽核寫入是尖峰而不可預測的：整夜安靜，然後在某個客戶跑一次批次操作、或一場事件產生數千筆事件時，湧來一場洪流。那個流量形狀就是整個決策。
我該用 DynamoDB 隨需還是佈建容量？
隨需按請求收費、能縮減到零，使它成為尖峰、全新或不可預測流量的安全預設。佈建以低得多的每單位價格預留一個固定的讀寫速率，只有在持續、穩定的流量讓那份預留維持高利用率時才勝出。除非你的量已經過驗證且可預測，否則就選隨需。
- 隨需＝按請求付費、縮減到零。 沒有容量要規劃；每次讀寫你付較高的價，但只在流量發生時才付。
- 佈建＝預留一個穩定的速率、永遠都在付費。 如果那個速率的利用率高，每單位便宜得多；你要吞下閒置容量的成本。
- 尖峰或未知的流量呼喚隨需。 穩定、可預測、高量的流量呼喚佈建（可選擇搭配自動擴展）。
- 你可以切換模式，但這個限制是不對稱的：佈建轉隨需被限制在每 24 小時最多四次，而隨需轉佈建則不受限制——它不是一個按請求開關的切換鈕。
問題：為你用不到的容量付費
用佈建容量，你要承諾，比如說，每秒 1,000 個寫入單位。如果稽核日誌平均每秒 50 次寫入，但你為事件日的尖峰佈建，你就得全天候為 1,000 付費，卻只用掉其中的二十分之一。改為佈建平均值，事件日的洪流就會被節流——寫入遭到拒絕。
所以固定容量在尖峰流量上逼你做一個糟糕的取捨：持續多付，或者佈建不足、在最要緊的時候丟掉寫入。隨需的存在正是為了移除那個取捨。
這兩種模式如何運作
隨需為你實際消耗的讀取和寫入請求單位收費，沒有容量要設定——它能即時容納到你先前流量峰值兩倍的尖峰，並在閒置時縮減到零。超過短時間窗內那 2 倍的跳升，它在提升期間仍可能節流。你為那份彈性付出每請求的溢價。
佈建每秒預留一定數量的讀取容量單位（RCU）和寫入容量單位（WCU）。每單位的價格低得多，但無論用不用你都持續為那份預留付費。超過它，DynamoDB 就會節流，除非啟用了自動擴展在設定的界限內增長容量——不過自動擴展反應要花上幾分鐘，所以突然的尖峰在它追上之前仍可能節流。
交叉點在於利用率。粗略地說：如果你持續、可預測的流量讓佈建容量維持高利用率，佈建在價格上勝出；如果流量是尖峰、突發或未知的，隨需憑著不為閒置預留收費而勝出。
一個實作範例：稽核日誌的帳單
稽核日誌平均每秒寫入約 50 筆事件，但在事件期間爆發到數千筆，讀取流量則低得多（合規匯出、偶爾的調查）。每筆事件都很小——遠低於 1 KB。
在佈建上，你得為那場爆發預留（並全天候為它付費），否則就要冒著節流事件日洪流的風險——那正是最不該丟掉稽核寫入的時候。在隨需上，安靜的時段幾乎不花錢，而到近期峰值兩倍以內的一場爆發不用設定就能被吸收；你只為真正發生的寫入付費。
對這個工作負載來說，隨需是正確的預設。一般規則：任何新的或尖峰的表都從隨需開始，只在流量被證實穩定到足以讓一份預留維持利用率之後，才轉移到佈建。
把你自己的數字填進去——每秒讀取／寫入、項目大小、儲存量——看看這兩種模式在單一區域下並排的樣子：
想看套用免費方案後的完整多區域全貌，用 DynamoDB 定價計算器。
在 DynoTable 中操作
容量決策從真實的數字開始：項目有多大、有多少筆、寫入有多快。靠猜這些正是表最後佈建失當的原因。
要把一筆樣本事件轉成它實際消耗的 RCU／WCU，用項目大小計算器跑一次。然後把決策落到你的真實表上：DynoTable 會呈現它的中繼資料——項目數與大小——並讓你檢視具代表性的項目，好讓你準確地估量它們。
陷阱與後續步驟
- 切換模式受速率限制，而且是不對稱的。 佈建轉隨需被限制在每 24 小時四次切換；隨需轉佈建不受限制。把它當成一個經過斟酌的決定，而不是一個你隨手轉的旋鈕。
- 自動擴展不是即時的。 它反應要花上幾分鐘，所以佈建上一個急遽的尖峰在容量增長之前可能節流。對真正突發的流量，隨需能更好地應對尖峰——即時到你先前峰值的兩倍。如果你知道有個尖峰會超過那點（一場發表或促銷），就事先在表上設定暖輸送量，預先佈建爆發的餘裕空間。
- 熱分割區不論模式都會節流。 即使是隨需也有每分割區的限制——不均勻的索引鍵可能在表看起來還未滿載時就節流。見熱分割區。
- 有它們自己的容量。 每個索引都分開計費，若佈建不足還可能節流基礎表的寫入——見為什麼 GSI 會節流基礎表寫入。
容量模式設定你在單一區域裡運行這張表要付多少。接下來：用 DynamoDB 全域表把它跨區域複寫。
下載 DynoTable 在你決定容量模式之前，先讀出你的表的真實大小和項目數。