對於許多開發者來說，身份驗證系統（Authentication）是應用程式最脆弱的單點故障點。如果負責管理使用者登入的服務失效，無論後端其他微服務運行得再完美，使用者依然無法進入系統。長期以來，Amazon Cognito 作為 AWS 的託管身份服務，在面對區域級故障（Regional Outage）時，缺乏原生的自動化備援機制，迫使工程團隊必須自行開發複雜的資料同步工具。
針對這個痛點，AWS 最近推出了 Amazon Cognito 的多區域複製（Multi-Region Replication）功能，讓使用者能將身份池（User Pool）的設定與使用者資料自動同步到另一個備用區域。
解決傳統同步的痛點
在沒有此功能之前，若要實現跨區域備援，工程師通常需要手動導出使用者資料，再將其導入到另一個區域的 User Pool 中。這種做法存在三大風險：首先是安全性，資料在導出與傳輸過程中容易暴露；其次是資料一致性，手動同步難以保證即時性；最後是使用者體驗，在切換區域時，使用者往往會被強制要求重新設定密碼或重新登入。
現在透過多區域複製，Cognito 會自動將主區域（Primary Region）的設定、憑證與使用者資料同步到次要區域（Secondary Region）。由於兩個區域都能識別彼此發出的 Access Token（存取令牌），因此在發生故障切換時，既有的使用者工作階段（Session）依然有效，能大幅降低服務中斷對終端用戶的影響。
運作機制與技術限制
這套機制採取的是主從式（Active-Passive）架構，而非主動主動（Active-Active）模式。這意味著次要區域在平時處於唯讀狀態。
在正常運作時，所有的新使用者註冊、密碼重設或個人資料更新都必須在主區域完成。只有在觸發故障切換（Failover）進入備援狀態後，次要區域才會接管相關操作。此外，開發者需要注意幾個關鍵的技術限制：
第一，多因素驗證（MFA）的限制。目前次要區域並不支援 TOTP（基於時間的一次性密碼）形式的 MFA。如果你的應用程式對安全性要求極高，必須在所有環境都強制執行 MFA，這將是一個重要的考量因素。
第二，故障切換的觸發方式。AWS 並未提供一鍵式的自動切換，開發者仍需依賴 DNS 驅動的切換機制，這通常需要搭配自定義域名（Custom Domain）以及自行設定的健康檢查（Health Checks）來達成。
第三，狀態同步的不完全性。例如帳號鎖定計數器（Lockout Counters）並不會在區域間同步，這意味著在主區域被鎖定的帳號，在切換到次要區域後可能會恢復可用狀態。
安全性與整合能力
為了滿足企業對合規性的嚴格要求，此功能支援客戶管理金鑰（Customer-managed keys），但前提是必須使用支援多區域的 AWS KMS 金鑰。
在整合能力方面，多區域複製支援絕大多數的驗證方式，包括透過 Google、Apple、Facebook 等社群平台的聯邦登入（Federated Sign-in），以及企業常用的 SAML 和 OpenID Connect (OIDC) 協議。
實務建議與成本考量
對於大多數追求高可用性（High Availability）的團隊來說，這項功能移除了大量自行維護同步腳本的複雜度，是一個非常務實的選擇。但請注意，此功能目前僅限於 Amazon Cognito 的次世代基礎設施（Next-generation infrastructure）上的 User Pool 使用。
在成本方面，這項功能是以每月活躍使用者（MAU）為單位額外計費，且針對機器對機器（M2M）的驗證會在標準令牌發行價格上額外增加 30% 的費用。
總結來說，Cognito 的多區域複製將身份驗證的韌性從手動維護提升到了託管服務等級，雖然在 MFA 支援與同步細節上仍有侷限，但已足以應對大多數商業應用程式的災難復原（Disaster Recovery）需求。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。