本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
雲端中的災難復原選項
在 AWS 中，您可以使用的災難復原策略可以大致分為四種方法，從低成本和低複雜性的備份，到使用多個作用中區域更複雜的策略。主動/被動策略使用主動網站 （例如 AWS 區域） 來託管工作負載並提供流量。被動網站 （例如不同的 AWS 區域） 用於復原。在觸發容錯移轉事件之前，被動網站不會主動提供流量。
定期評估和測試災難復原策略至關重要，以便您可以在需要時放心地叫用災難復原策略。使用 AWS Resilience Hub
圖 6 - 災難復原策略
對於基於結構完善
選擇策略時，以及實作策略的 AWS 資源時，請記住，在 AWS 中，我們通常會將服務劃分為資料平面和控制平面。資料平面負責提供即時服務，而控制平面則用於設定環境。為了達到最大的彈性，您應該僅使用資料平面操作做為容錯移轉操作的一部分。這是因為資料平面通常具有比控制平面更高的可用性設計目標。
備份和還原
備份和還原是緩解資料遺失或損毀的適當方法。此方法也可以透過將資料複寫至其他 AWS 區域來緩解區域災難，或減輕部署至單一可用區域的工作負載缺乏備援。除了資料之外，您還必須在復原區域中重新部署基礎設施、組態和應用程式程式碼。若要讓基礎設施快速重新部署而不發生錯誤，您應該一律使用基礎設施做為程式碼 (IaC)，使用 AWS CloudFormation
圖 7 - 備份和還原架構
AWS 服務
您的工作負載資料需要定期執行或連續執行的備份策略。您執行備份的頻率將決定可實現的復原點 （應符合您的 RPO)。備份也應該提供將其還原至取得時間點的方法。具有point-in-time復原的備份可透過下列服務和資源取得：
對於 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 開發套件來呼叫 APIs，實作自動還原至 DR 區域 AWS Backup。您可以將此設定為定期重複任務，或在每次備份完成時觸發還原。下圖顯示使用 Amazon Simple Notification Service (Amazon SNS)
圖 8 - 還原和測試備份
注意
備份策略必須包括測試備份。如需詳細資訊，請參閱測試災難復原一節。請參閱 AWS Well-Architected Lab：測試資料的備份和還原
指示燈
使用指示燈方法，您可以將資料從一個區域複寫到另一個區域，並佈建核心工作負載基礎設施的副本。支援資料複寫和備份所需的資源 (例如資料庫和物件儲存) 始終處於開啟狀態。其他元素，例如應用程式伺服器，會載入應用程式碼和組態，但會「關閉」，而且只會在測試期間或呼叫災難復原容錯移轉時使用。在雲端中，您可以在不需要資源時取消佈建，並在執行時佈建資源。「關閉」的最佳實務是不部署資源，然後視需要建立組態和部署資源的功能 (「開啟」)。與備份和還原方法不同，您的核心基礎設施一律可用，而且您隨時可以選擇透過開啟和擴展應用程式伺服器來快速佈建完整規模的生產環境。
圖 9 - 指示燈架構
指示燈方法透過將作用中資源降至最低，將災難復原的持續成本降至最低，並在災難發生時簡化復原，因為核心基礎設施要求都已就緒。此復原選項需要您變更部署方法。您需要對每個區域進行核心基礎設施變更，並同時將工作負載 （組態、程式碼） 變更部署到每個區域。您可以透過自動化部署並使用基礎設施做為程式碼 (IaC)，跨多個帳戶和區域部署基礎設施 （完整基礎設施部署至主要區域，以及縮減/關閉基礎設施部署至 DR 區域），來簡化此步驟。建議您在每個區域使用不同的帳戶，以提供最高層級的資源和安全隔離 （如果遭入侵的憑證也是您災難復原計劃的一部分）。
使用此方法，您還必須緩解資料災難。持續資料複寫可以保護您防範某些類型的災難，但它不能保護您防範資料損毀或破壞，除非您的策略也包括所存放資料的版本控制，或時間點復原的選項。您可以備份災難區域中的複寫資料，以在相同區域中建立point-in-time備份。
AWS 服務
除了使用備份和還原區段中涵蓋的 AWS 服務來建立point-in-time備份之外，也請針對您的指示燈策略考慮下列服務。
對於指示燈，連續資料複寫到 DR 區域中的即時資料庫和資料存放區是低 RPO 的最佳方法 （除了先前討論point-in-time備份之外使用時）。AWS 使用下列服務和資源，為資料提供持續、跨區域、非同步的資料複寫：
透過持續複寫，您 DR 區域中的資料版本幾乎可以立即使用。您可以使用 S3 物件的 S3 複寫時間控制 (S3 RTC) 等服務功能S3以及 Amazon Aurora 全域資料庫的管理功能來監控實際的複寫時間。
當容錯移轉從災難復原區域執行讀取/寫入工作負載時，您必須提升 RDS 僅供讀取複本，才能成為主要執行個體。對於 Aurora 以外的資料庫執行個體，程序需要幾分鐘的時間來完成，而重新啟動是程序的一部分。對於跨區域複寫 (CRR) 和 RDS 的容錯移轉，使用 Amazon Aurora 全域資料庫提供數種優點。全域資料庫使用專用基礎設施，讓您的資料庫完全可供您的應用程式使用，並且可以複寫到一般延遲低於一秒的次要區域 (AWS 區域內的延遲遠低於 100 毫秒）。使用 Amazon Aurora 全球資料庫，如果您的主要區域發生效能降低或中斷，即使區域完全中斷，您也可以提升其中一個次要區域在不到一分鐘內承擔讀取/寫入責任。您也可以設定 Aurora 來監控所有次要叢集的 RPO 延遲時間，以確保至少一個次要叢集保留在您的目標 RPO 時段內。
在 DR 區域中，必須部署資源較少或更小的核心工作負載基礎設施的縮減版本。使用 AWS CloudFormation，您可以定義您的基礎設施，並在 AWS 帳戶和 AWS 區域之間一致地部署。 AWS CloudFormation 使用預先定義的虛擬參數來識別 AWS 帳戶及其部署所在的 AWS 區域。因此，您可以在 CloudFormation 範本中實作條件邏輯，以在 DR 區域中僅部署縮減規模的基礎設施版本。對於 EC2 執行個體部署，Amazon Machine Image (AMI) 會提供硬體組態和安裝的軟體等資訊。您可以實作 Image Builder 管道，以建立您需要AMIs，並將其複製到主要和備份區域。這有助於確保這些黃金 AMIs 擁有在發生災難事件時，在新區域中重新部署或擴展工作負載所需的一切。Amazon EC2 執行個體會部署在縮減規模的組態中 （相較於主要區域，執行個體較少）。若要擴展基礎設施以支援生產流量，請參閱暖待命一節中的 Amazon EC2 Auto Scaling
對於主動/被動組態，例如指示燈，所有流量一開始都會進入主要區域，並在主要區域不再可用時切換到災難復原區域。此容錯移轉作業可以自動或手動啟動。應謹慎使用根據運作狀態檢查或警示自動啟動的容錯移轉。即使使用此處討論的最佳實務，復原時間和復原點也會大於零，並導致可用性和資料的某些損失。如果您在不需要 （錯誤警示） 時失敗，則會發生這些損失。因此通常使用手動啟動的容錯移轉。在此情況下，您仍應將容錯移轉的步驟自動化，讓手動啟動就像按下按鈕一樣簡易。
使用 AWS 服務時，有幾個流量管理選項需要考慮。
一種選擇是使用 Amazon Route 53
另一個選項是使用 AWS Global Accelerator
Amazon CloudFront
AWS 彈性災難復原
AWS Elastic Disaster Recovery
圖 10 - AWS 彈性災難復原架構
暖待命
暖待命方法包括確保在另一個區域中有規模縮減但功能完整的生產環境副本。這種方法擴充了指示燈概念並減少了復原時間，因為您的工作負載始終在另一個區域中開啟。此方法也可讓您更輕鬆地執行測試或實作持續測試，以增加您對從災難復原能力的信心。
圖 11 - 暖待命架構
注意：指示燈和暖待命之間的差異有時可能難以理解。兩者都包含 DR 區域中的環境，其中包含主要區域資產的副本。差別在於，如果沒有先採取其他動作，指示燈無法處理請求，而暖待命可以立即處理流量 （容量降低）。指示燈方法需要您「開啟」伺服器，可能部署其他 （非核心） 基礎設施並擴展，而暖待命只需要您擴展 （所有項目都已部署並執行）。使用您的 RTO 和 RPO 需求，協助您選擇這些方法。
AWS 服務
備份、還原和指示燈涵蓋的所有 AWS 服務也會在暖待命中使用，用於資料備份、資料複寫、主動/被動流量路由，以及部署基礎設施，包括 EC2 執行個體。
Amazon EC2 Auto Scaling
由於 Auto Scaling 是控制平面活動，因此對它採取相依性會降低整體復原策略的彈性。這是權衡。您可以選擇佈建足夠的容量，讓復原區域可以處理部署的完整生產負載。此靜態穩定組態稱為熱待命 （請參閱下一節）。或者，您可以選擇佈建較少的資源，而成本較低，但需依賴 Auto Scaling。某些 DR 實作會部署足夠的資源來處理初始流量、確保低 RTO，然後依賴 Auto Scaling 來提升後續流量。
多站點主動/主動
您可以在多個區域中同時執行工作負載，做為多站台作用中/作用中或熱待命作用中/被動策略的一部分。多站台作用中/作用中 （多站台作用中/作用中） 會為部署區域的所有流量提供服務，而熱待命只會提供單一區域的流量，而其他區域則只會用於災難復原。使用多站台主動/主動方法，使用者可以在部署工作負載的任何區域中存取工作負載。這種方法是災難復原最複雜且成本最高的方法，但對於具有正確技術選擇和實作的大多數災難，它可以將復原時間減少到接近零 （但資料損毀可能需要依賴備份，這通常會導致非零的復原點）。熱待命使用主動/被動組態，其中使用者只會導向單一區域，而且 DR 區域不會接收流量。大多數客戶發現，如果他們要在第二個區域中站立完整環境，則使用它是有意義的/有作用的。或者，如果您不想使用這兩個區域來處理使用者流量，則 Warm Standby 會提供更經濟且操作較不複雜的方法。
圖 12 - 多站台作用中/作用中架構 （將一個作用中路徑變更為非作用中以進行熱待命）
使用多站台作用中/作用中時，由於工作負載正在多個區域中執行，因此在此案例中沒有容錯移轉等問題。在此情況下，災難復原測試將著重於工作負載對區域遺失的反應：流量是否從失敗的區域路由而來？ 其他 區域 （多個） 是否可以處理所有流量？ 也需要測試資料災難。備份和復原仍然是必要的，應該定期測試。也應該注意，涉及資料損毀、刪除或混淆的資料災難的復原時間一律大於零，而且復原點一律會在發現災難之前的某個時間點。如果需要多站台主動/主動 （或熱待命） 方法的額外複雜性和成本，以維持接近零的復原時間，則應採取額外的努力來維護安全性並防止人為錯誤，以緩解人類災難。
AWS 服務
備份和還原、指示燈和暖待命涵蓋的所有 AWS 服務，也會在此用於point-in-time資料備份、資料複寫、主動/主動流量路由，以及部署和擴展基礎設施，包括 EC2 執行個體。
對於先前討論的主動/被動案例 （指示燈和暖待命），Amazon Route 53 和 AWS Global Accelerator 都可以用於將網路流量路由到作用中區域。對於此處的作用中/作用中策略，這兩種服務也啟用政策的定義，以決定哪些使用者要前往哪個作用中區域端點。 AWS Global Accelerator 使用 設定流量撥號，以控制導向每個應用程式端點的流量百分比。Amazon Route 53 支援此百分比方法，以及多個其他可用的政策，包括地理鄰近性和以延遲為基礎的政策。Global Accelerator 會自動利用 AWS 邊緣伺服器的廣泛網路，盡快將流量加入 AWS 網路骨幹，進而降低請求延遲。
使用此策略的非同步資料複寫可啟用近乎零的 RPO。Amazon Aurora 全域資料庫等 AWS 服務使用專用基礎設施，讓您的資料庫完全可供您的應用程式使用，並可複寫至最多五個次要區域，且一般延遲不到一秒。使用主動/被動策略時，寫入只會發生在主要區域。與作用中/作用中的差異在於設計如何處理與寫入每個作用中區域的資料一致性。通常設計使用者讀取，以便從最接近他們的區域提供，稱為本機讀取。透過寫入，您有幾個選項：
-
寫入全域策略會將所有寫入路由至單一區域。如果該區域發生故障，則另一個區域會提升為接受寫入。Aurora 全域資料庫非常適合寫入全域，因為它支援跨區域與僅供讀取複本同步處理，而且您可以在不到一分鐘內提升其中一個次要區域承擔讀取/寫入責任。Aurora 也支援寫入轉送，可讓 Aurora 全域資料庫中的次要叢集將執行寫入操作的 SQL 陳述式轉送至主要叢集。
-
寫入本機策略會將寫入路由至最接近的區域 （就像讀取）。Amazon DynamoDB 全域資料表可啟用此類策略，允許從部署全域資料表的每個區域讀取和寫入。Amazon DynamoDB 全域資料表使用最後一個寫入器，可贏得並行更新之間的對帳。
-
寫入分割策略會根據分割區金鑰 （例如使用者 ID) 將寫入指派給特定區域，以避免寫入衝突。Amazon S3 雙向設定的
複寫可用於此案例，目前支援兩個區域之間的複寫。實作此方法時，請務必在儲存貯體 A 和 B 上啟用複本修改同步，以在複寫物件上複寫複本中繼資料變更，例如物件存取控制清單 (ACLs)、物件標籤或物件鎖定。您也可以設定是否要在作用中區域中的儲存貯體之間複寫刪除標記。除了複寫之外，您的策略還必須包含point-in-time備份，以防止資料損毀或損毀事件。
AWS CloudFormation 是一種強大的工具，可在多個 AWS 區域中的 AWS 帳戶之間強制執行持續部署的基礎設施。AWS CloudFormation StackSets 可讓您透過單一操作，跨多個帳戶和區域建立、更新或刪除 CloudFormation 堆疊，藉此擴充此功能。雖然 AWS CloudFormation 使用 YAML 或 JSON 將基礎設施定義為程式碼，但 AWS Cloud Development Kit (AWS CDK)
