DynamoDB Global Tables
global table 是一張橫跨多個 AWS 區域複寫的單一 DynamoDB 表格，其中每個複本都可寫入。DynamoDB 會自動讓它們保持同步 — 你能在每個區域獲得低延遲的本地讀寫，再加上跨區域的災難復原，而不必自行執行複寫。
在稽核記錄的情境中，某位 EU 客戶要求他們的資料存放在 eu-west-1，而其餘部分則執行於 us-east-1。而身為一份對合規至關重要的記錄，它必須能在整個區域中斷時存活。一張 global table 用單一功能就同時回應了這兩項需求。
什麼是 DynamoDB Global Tables？
DynamoDB Global Tables 是一張橫跨多個 AWS 區域複寫的單一表格，其中每個複本都可讀取也可寫入。DynamoDB 會透過最終一致的非同步複寫自動讓它們保持同步，並以「最後寫入者勝出」解決衝突。你能在每個區域獲得低延遲的本地讀寫，再加上跨區域的災難復原，支撐 DynamoDB 99.999% 的可用性 SLA。
- 多區域、主動-主動。 每個複本都可完整讀寫；任一區域的寫入都會傳播到其他區域。
- 複寫是非同步且最終一致的跨區域同步 — 通常在一秒內，但並非即時。
- 衝突以「最後寫入者勝出」解決。 同一項目在兩個區域的並行寫入，會調解為最近的那一次。
- 它支撐 99.999% 的可用性 SLA — 多區域 global table 是 DynamoDB 可用性最高的設定。
問題：單一區域不夠用
單一區域的表格有兩項稽核記錄無法接受的限制。第一，資料落地位置：某位 EU 客戶的事件必須儲存在 EU，但你的應用程式執行於美國。第二，災難復原：若 us-east-1 中斷，單一區域的稽核記錄在這段期間就無法讀取也無法寫入 — 偏偏這正是你最需要這份事件紀錄的時候。
自行打造其中任一項 — 跨區域複寫、容錯移轉、衝突處理 — 都是一個龐大且容易出錯的工程。global table 讓它變成一個組態選項。
global table 如何運作
你為表格新增一個複本區域；DynamoDB 會在該處建立一份副本，並讓所有複本保持同步。根據 AWS DynamoDB 常見問答，global table 提供多區域複寫，可用性高達 99.999%，而每個區域的複本都服務本地讀寫。
有兩條一致性規則定義了它的行為：
- 跨區域複寫是非同步的。 在
us-east-1的寫入會先在本地確認，再傳播到eu-west-1— 通常在一秒內，但寫入後立刻在另一區域讀取，可能還看不到它。（強一致讀取仍可運作，但只在單一區域之內。） - 衝突以「最後寫入者勝出」處理。 若同一項目在兩個區域幾乎同時被寫入，DynamoDB 會保留時間戳記最晚的那次寫入，並捨棄另一次。
一個實作範例：兼作 DR 的 EU 複本
你把 eu-west-1 加為 audit-log 表格的複本。現在：
| write region | item | visible in | |
|---|---|---|---|
| us-east-1 | TENANT#acme | EVENT#…#a1 | both regions (~1s lag to EU) |
| eu-west-1 | TENANT#bmw | EVENT#…#e7 | both regions (~1s lag to US) |
EU 客戶的應用程式對本地的 eu-west-1 複本進行讀寫 — 低延遲且資料就地存放。同一份滿足資料落地需求的複寫，也兼作了災難復原：若 us-east-1 當機，eu-west-1 複本仍持有完整的記錄並服務流量；你就容錯移轉到它。
因為稽核記錄是僅附加且依租戶分割的，最後寫入者勝出在這裡基本上不成問題 — 某個租戶的事件是從單一區域寫入的，且事件鍵是唯一的，所以兩個區域很少會在同一項目上競爭。這不是運氣；正是因為如此，僅附加的記錄才是 global table 最乾淨的適用情境之一。相對地，一個可變的計數器，在跨區域並行寫入下就需要謹慎處理。
在 DynoTable 中實作
新增複本之後，你會想確認資料真的落到了新區域並與來源相符 — 確認 EU 複本確實持有 acme 的事件、屬性正確，且沒有延遲落後。
DynoTable 可用各自的憑證連接任何區域，所以你可以讓一個視窗指向 us-east-1、另一個指向 eu-west-1，並排比對同一租戶的項目以驗證複寫。
你可以在 DynamoDB 表達式建構器 中先建好你要對每個複本執行的各區域查詢的雛形。
陷阱與後續步驟
- 別跨區域讀取你自己剛寫入的內容。 複寫延遲意味著某區域的寫入可能要約一秒後才會在另一區域出現。別在美國寫入後立刻就期望從 EU 讀到它；強一致只限單一區域。
- 最後寫入者勝出會默默捨棄資料。 對於在兩個區域並行寫入的可變項目，輸的那次會被捨棄且不會報錯。僅附加或每項目單一寫入者的設計（如這份稽核記錄）能避開此問題；共用的可變狀態則需要一個能感知衝突的設計。
- 每個複本都有成本。 每個區域都儲存一份完整副本，並各自計收容量與儲存費 — 一個複本大約會讓成本翻倍。為真正的落地或 DR 需求新增區域，而不是預設就加。
- 備份是逐複本進行的。 一張復原後的 global table 會成為一張獨立的表格 — 請逐區域規劃復原。請見備份與時間點復原。
global table 防的是失去一個區域。最後一項維運考量是防止失去資料 — 一次失敗的部署或意外的刪除 — 這要靠備份與時間點復原。
下載 DynoTable 來連接多個區域，並驗證你的 global table 複本是否持有相同的資料。