寫入單一區域模式 (單一優先層級)

寫入一個區域寫入模式，如下圖所示，為主動-被動模式，並將所有資料表寫入操作路由至單一作用中區域。(DynamoDB 沒有單一作用中區域的概念；DynamoDB 外部的 layer 會管理此概念。) 寫入一個區域模式非常適合需要透過確保一次只能寫入一個區域的寫入操作流程來避免寫入衝突的 MREC 資料表。當您想要使用條件式表達式且因為某些原因而無法使用 MRSC，或需要執行交易時，此寫入模式會有所幫助。除非您知道您正在對最新資料採取行動，否則這些表達式是不可能的，因此它們需要將所有寫入請求傳送到具有最新資料的單一區域。

當您使用 MRSC 資料表時，為了方便起見，您可以選擇通常寫入一個區域。例如，這有助於將 DynamoDB 以外的基礎設施建置降至最低。寫入模式仍然會寫入任何區域，因為使用 MRSC，您可以隨時安全地寫入任何區域，而無須擔心衝突解決會導致 MREC 資料表選擇寫入一個區域。

最終一致讀取操作可以前往任何複本區域，以達到較低的延遲。高度一致的讀取操作必須移至單一主要區域。

有時需要變更作用中區域以回應區域故障，如稍後所討論。有些使用者會定期變更目前作用中的區域，例如實作follow-the-sun部署。這會將作用中區域放在活動最多的地理位置附近 （通常是白天，因此是名稱），這會導致最低的延遲讀取和寫入操作。它還具有每天呼叫區域變更程式碼的附帶優勢，並確保它在任何災難復原之前都經過良好的測試。

被動區域可能會保留 DynamoDB 周圍的縮減規模基礎設施，只有在它成為作用中區域時才會建立。本指南不涵蓋指示燈和暖待命設計。如需詳細資訊，您可以閱讀部落格文章 上的災難復原 (DR) 架構 AWS，第 III 部分：指示燈和暖待命。

當您將全域資料表用於低延遲、全域分佈的讀取操作時，使用寫入至一個區域模式可正常運作。例如，一家大型社交媒體公司，需要在全球每個區域提供相同的參考資料。它們不會經常更新資料，但當它們更新時，只會寫入一個區域，以避免任何潛在的寫入衝突。讀取操作一律可從任何 區域進行。

另一個範例是，考慮之前討論的實作每日現金回饋計算的金融服務公司。他們使用寫入任何區域模式來計算餘額，但寫入一個區域模式來追蹤付款。此工作需要 MRSC 資料表中不支援的交易，因此它更適合使用單獨的 MREC 資料表並寫入一個區域模式。