雲端中的災難復原選項
AWS 中可用的災難復原策略可以大致分為四種方法，從低成本、低複雜性的製作備份，到使用多個主動區域的較複雜策略。請務必定期測試災難復原策略，如此才能在有需要時有信心呼叫它。
圖 6 - 災難復原策略
對於架構良好
備份和還原
備份和還原很適合用來緩解資料遺失或損毀造成的傷害。運用此方法，還可以搭配將資料複寫到其他 AWS 區域來緩解區域災難造成的影響，或是針對只部署到單一可用區域的工作負載，減輕其缺乏備援的缺點。除了資料以外，您還必須在復原區域中重新部署基礎設施、組態和應用程式程式碼。若要讓基礎設施能夠快速重新部署而不發生錯誤，您應一律使用 AWS CloudFormation
圖 7 - 備份與還原架構
AWS 服務
您的工作負載資料需要定期執行或連續不斷的備份策略。執行備份的頻率將決定可實現的復原點 (這些復原點應符合 RPO 要求)。備份也應提供將其還原到製作時間點的方法。具有時間點復原功能的備份，可透過以下服務和資源取得：
對於 Amazon Simple Storage Service (Amazon S3)，您可以使用 Amazon S3 跨區域複寫 (CRR)
AWS Backup
AWS Backup 支援跨區域 (如災難復原區域) 複製備份。
如需 Amazon S3 資料的附加災難復原策略，您可啟用 S3 物件版本控制。物件版本控制會保留刪除或修改動作之前的原始版本，藉以避免 S3 中的資料遭受執行動作的影響。物件版本控制對於人為錯誤造成的災難，可以有效緩解。如果您使用 S3 複寫將資料備份到 DR 區域，則根據預設，在來源儲存貯體中刪除物件時，Amazon S3 只會在來源儲存貯體中新增刪除標記。此方法可保護 DR 區域中的資料，避免來源區域的惡意刪除。
除了資料以外，您也必須備份重新部署工作負載並滿足復原時間點目標 (RTO) 所需的組態和基礎設施。AWS CloudFormation
儲存在災難復原區域中作為備份的任何資料，都必須在容錯移轉時還原。AWS Backup 提供還原功能，但目前未啟用排程或自動還原。您可以使用 AWS SDK 呼叫適用於 AWS Backup 的 API，來實作自動還原到 DR 區域。您可以將此設定為定期重複的任務，或在備份完成時觸發還原。下圖顯示使用 Amazon Simple Notification Service (Amazon SNS)
圖 8 - 還原和測試備份
注意
備份策略必須包括測試備份。如需詳細資訊，請參閲測試災難復原一節。請參閲 AWS Well-Architected 實驗室：測試資料的備份與還原
指示燈
使用指示燈方法，您可以將資料從一個區域複寫到另一個區域，並佈建核心工作負載基礎設施的副本。支援資料複寫和備份所需的資源 (例如資料庫和物件儲存)，永遠處於開啟狀態。其他元素 (例如應用程式伺服器) 會載入應用程式程式碼和組態，但處於關閉狀態，僅在測試期間或呼叫災難復原容錯移轉時使用。與備份和還原方法不同，您的核心基礎設施永遠可用，且您永遠可透過切換和水平擴展應用程式伺服器，來選擇快速佈建最大規模的生產環境。
圖 9 - 指示燈架構
指示燈方法透過最大限度地減少作用中資源，來將災難復原的持續成本降至最低，並可簡化發生災難時的復原流程，因為核心基礎設施需求全部存在。此復原選項需要您變更部署方法。您需要變更每個區域的核心基礎設施，並將工作負載 (組態、程式碼) 變更同時部署到每個區域。透過自動化部署和使用 Infrastructure as Code (IaC) 跨多個帳戶和區域部署基礎設施 (將完整的基礎設施部署到主要區域，以及縮減規模/關閉部署到災難復原區域的基礎設施)，可以簡化此步驟。建議您在每個區域使用不同的帳户，以提供最高等級的資源和安全隔離 (如果憑證洩露也是災難復原計劃的一部分)。
使用此方法，您還必須抵禦資料災難。持續複寫資料可以防止某些災難類型，但可能無法防止資料損毀或銷毀，除非您的策略還包括儲存資料的版本控制或時間點復原的選項。您可以備份災難區域中的複寫資料，以在同一個區域中建立時間點備份。
AWS 服務
除了使用備份和還原一節中介紹的 AWS 服務建立時間點備份之外，也請考慮使用以下服務建立指示燈策略。
對於指示燈，持續複寫資料到 DR 區域中的即時資料庫和資料存放區，是降低 RPO 的最佳方法 (搭配先前提及的時間點備份)。AWS 使用以下服務和資源，提供持續、跨區域的非同步資料複寫：
運用持續複寫，您的資料版本在 DR 區域中幾乎立即可用。使用適用於 S3 物件的 S3 複寫時間控制 (S3 RTC) 以及 Amazon Aurora Global Database 的管理功能等服務功能，可以監控實際複寫時間。
當發生容錯移轉以從災難復原區域執行讀/寫工作負載時，您必須將 RDS 僅供讀取複本提升為主要執行個體。對於 Aurora 以外的資料庫執行個體，此程序需要幾分鐘時間才能完成，且過程中需要重新開機。對於使用 RDS 進行跨區域複寫 (CRR) 和容錯移轉，使用 Amazon Aurora Global Database 具有幾個優勢。Global Database 使用專用基礎設施，讓您的資料庫完全可用於為您的應用程式提供服務，並且可以複寫到次要區域，典型延遲不到一秒 (在 AWS 區域內甚至可低於 100 毫秒)。使用 Amazon Aurora Global Database，如果主要區域效能下降或中斷，即使發生完全區域中斷，您也可以在 1 分鐘內，將其中一個次要區域提升為擔任讀/寫責任。提升可以自動進行，不須重新開機。
您必須在 DR 區域中，部署具有較少或較小資源之核心工作負載基礎設施的縮減規模版本。使用 AWS CloudFormation，您可以定義基礎設施，並且跨 AWS 帳戶以及跨 AWS 區域一致地部署它。AWS CloudFormation 使用預先定義的虛擬參數來識別部署它的 AWS 帳戶和 AWS 區域。因此，您可以在 CloudFormation 範本中實施條件邏輯，以便在 DR 區域中僅部署縮減版本的基礎設施。對於 EC2 執行個體部署，Amazon Machine Image (AMI) 提供硬體組態和已安裝軟體等資訊。您可以實作 Image Builder 管道來建立所需的 AMI，並將這些 AMI 複製到主要區域和備份區域。這有助於確保這些黃金 AMI 擁有在發生災難事件時，足以在新區域重新部署或水平擴展工作負載所需的一切。Amazon EC2 執行個體以縮減組態進行部署 (執行個體數少於您的主要區域)。您可以使用休眠，將 EC2 執行個體置於停止狀態，如此就不用支付 EC2 費用，只需為使用的儲存空間付費。若要啟動 EC2 執行個體，您可以使用 AWS 命令行界面 (CLI)
對於主動/待命組態 (例如指示燈)，所有流量一開始會流向主要區域，如果主要區域不再可用，則切換到災難復原區域。使用 AWS 服務時，可以考慮兩個流量管理選項。第一個選項是使用 Amazon Route 53
第二個選項是使用 AWS Global Accelerator
CloudEndure Disaster Recovery
CloudEndure Disaster Recovery
圖 10 - CloudEndure Disaster Recovery 架構
暖待命
暖待命方法是為了確保在另一個區域中，有一個縮減規模但功能齊全的生產環境副本。此方法延伸指示燈概念並可縮短復原時間，因為您的工作負載在另一個區域處於永遠啟用狀態。此方法也可讓您更輕鬆地執行測試或實施連續測試，提高從災難復原的能力信心。
圖 11 - 暖待命架構
注意：指示燈和暖待命之間的差異有時可能很難理解。兩者都包括 DR 區域中的環境，其中包含主要區域資產的副本。差別之處在於，如果不先採取額外動作，則指示燈無法處理請求，而暖待命則可 (以降低容量的等級) 立即處理流量。指示燈方法需要您「開啟」伺服器、可能需部署額外的 (非核心) 基礎設施以及擴充規模，而暖待命只需要擴充規模 (一切項目都已部署並正在執行)。根據您的 RTO 和 RPO 需求，在這些選項之間進行選擇。
AWS 服務
備份和還原以及指示燈涵蓋的所有 AWS 服務也都用於暖待命，來進行資料備份、資料複寫、主動/待命流量路由，以及基礎設施部署 (包括 EC2 執行個體)。
AWS Auto Scaling
多站點主動/主動
您可以在多站點主動/主動或熱待命主動/被動策略中，於多個區域同時執行工作負載。多站點主動/主動為來自其部署之所有區域的流量提供服務，而熱待命僅為來自單個區域的流量提供服務，另一個區域則僅用於災難復原。使用多站點主動/主動方法，使用者可以存取部署工作負載之任何區域中的工作負載。這個方法是災難復原中最複雜、成本也最高的方法，但可以透過選擇正確的技術和正確實作，將復原時間縮短到接近零 (不過資料損毀仍需依賴備份，這通常會導致非零復原點)。熱待命使用主動/被動組態，使用者僅被導向至單一區域，DR 區域不接受流量。大部分客户發現，如果想在第二個區域建立完整的環境，比較適合使用主動/主動。或者，如果您不想同時使用兩個區域來處理使用者流量，則暖待命可提供更經濟實惠且操作上較簡單的方法。
圖 12 - 多站點主動/主動架構 (將一個使用中路徑變更為非使用中，即成為熱待命)
對於多站點主動/主動，因為工作負載在多個區域中執行，因此沒有容錯移轉。在這種情況下，災難復原測試的重點是工作負載如何對遺失區域作出反應：是否將流量從故障的區域路由離開？ 其他區域可以處理所有流量嗎？ 也需要測試資料災難。備份和復原仍是必需的，也應定期測試。還應注意的是，涉及資料損毀、刪除或混淆之資料災難的復原時間永遠大於零，而且復原點永遠位於發現災難之前的某個時刻。如果保持接近零的復原時間會提高多站點主動/主動 (或熱待命) 方法的複雜性和成本，則應更努力維護安全並防止人為錯誤，以減輕人為災難。
AWS 服務
此處也將備份和還原、指示燈和暖待命涵蓋的所有 AWS 服務用於時間點資料備份、資料複寫、主動/主動流量路由，以及基礎設施部署和擴展 (包括 EC2 執行個體)。
對於前面討論的主動/被動方案 (指示燈和暖待命)，Amazon Route 53 和 AWS Global Accelerator 都可用於將網路流量路由到主動區域。對於此處的主動/主動策略，這兩種服務都允許定義政策，以決定哪些使用者移至哪個主動區域端點。使用 AWS Global Accelerator，您可以設定設定流量調撥工具來控制導向每個應用程式端點的流量百分比。Amazon Route 53 支援這個百分比方法，也支援其他多個可用政策，包括地理位置鄰近性和延遲型政策。Global Accelerator 會自動利用廣泛的 AWS 邊緣伺服器網路，盡快將流量傳輸到 AWS 骨幹網路，進而降低請求延遲。
使用此策略來複寫資料，可實現接近零的 RPO。AWS 服務 (例如 Amazon Aurora Global Database) 使用專用基礎設施，讓資料庫充分為您的應用程式提供服務，而且複寫到一個次要區域通常延遲時間不到一秒。使用主動/被動策略時，只會對主要區域進行寫入動作。與主動/主動的區別在於，設計如何處理對每個主動區域的寫入。常見的做法是設計為從離使用者最近的區域提供讀取服務，稱為讀取本機。對於寫入，您有幾個選項：
-
寫入全域策略會將所有寫入路由到單一區域。如果該區域出現故障，則會提升另一個區域來接受寫入。Aurora Global Database 非常適合寫入全域，因為它支援跨區域的僅供讀取複本同步，您也可以在 1 分鐘內，將其中一個次要區域提升為擔任讀/寫責任。
-
寫入本機策略則會將寫入路由到最近的區域 (跟讀取一樣)。Amazon DynamoDB 全域資料表支援此類策略，允許從部署全域資料表的每個區域進行讀取和寫入。Amazon DynamoDB 全域資料表會在並行更新間使用最後寫入者獲勝核對機制。
-
寫入分割區策略會根據分割區索引鍵 (類似使用者 ID)，將寫入指派給特定區域，以避免寫入衝突。雙向設定
的 Amazon S3 複寫可用於這種情況，且目前支援在兩個區域之間進行複寫。實施此方法時，請務必在儲存貯體 A 和 B 上同時啟用複本修改同步，來複寫複寫物件上的複本中繼資料變更，例如物件存取控制清單 (ACL)、物件標籤或物件鎖定。您也可以設定是否在主動區域的儲存貯體之間複寫刪除標記。除了複寫之外，您的策略還必須包括時間點備份，以防止資料損毀或銷毀事件。
AWS CloudFormation 是一個強大的工具，可在多個 AWS 區域的 AWS 帳戶之間實施一致部署的基礎設施。AWS CloudFormation StackSets 讓您跨多個帳戶和區域使用單次操作建立、更新或刪除 CloudFormation 堆疊，藉以擴充此功能。雖然 AWS CloudFormation 使用 YAML 或 JSON 定義 Infrastructure as Code，但 AWS Cloud Development Kit (AWS CDK)
