# 災難復原 (DR) 計畫
備妥備份和冗餘工作負載元件是 DR 策略的開始。[RTO 和 RPO](disaster-recovery-dr-objectives.md) 是您還原工作負載的目標。根據業務需求設定這些目標。實作策略以滿足這些目標，考量工作負載資源和資料的位置和功能。發生中斷的可能性和復原成本也是重要因素，可反映為工作負載提供災難復原的商業價值。
可用性和災難復原都依賴相同的最佳實務，例如監控故障、部署至多個位置以及自動容錯移轉。然而，可用性著重於工作負載的元件，而災難復原則著重於整個工作負載的離散副本。災難復原的目標與可用性不同，著重於災難後復原的時間。
**Topics**
+ [REL13-BP01 定義停機和資料遺失的復原目標](rel_planning_for_recovery_objective_defined_recovery.md)
+ [REL13-BP02 使用定義的復原策略來滿足復原目標](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 測試災難復原實作以驗證實作](rel_planning_for_recovery_dr_tested.md)
+ [REL13-BP04 管理 DR 站點或區域的組態偏移](rel_planning_for_recovery_config_drift.md)
+ [REL13-BP05 自動化回復](rel_planning_for_recovery_auto_recovery.md)
# REL13-BP01 定義停機和資料遺失的復原目標
故障可能會以多種形式影響您的業務。首先，故障可能會導致服務中斷 (停機時間)。其次，故障可能會導致資料遺失、不一致或過時。為了引導您回應故障並從故障中復原，請為每個工作負載定義復原時間點目標 (RTO) 和復原點目標 (RPO)。*復原時間點目標 (RTO)* 是服務中斷與服務還原之間的可接受延遲上限。*復原點目標 (RPO)* 是從上次資料復原點之後起算，可接受的最長時間。
**預期成果：**每個工作負載都根據技術考量和業務影響指定了 RTO 和 RPO。
**常見的反模式：**
+ 您尚未指定復原目標。
+ 您選取任意復原目標。
+ 您選取的復原目標過於寬鬆且不符合業務目標。
+ 您尚未評估停機時間和資料遺失的影響。
+ 您選取的復原目標不切實際，例如零復原時間或零資料損失，這對於您的工作負載組態而言可能無法實現。
+ 您選取的復原目標比實際業務目標更嚴格。這會強制進行比工作負載所需更昂貴和更複雜的復原實作。
+ 您選取的復原目標與相依的工作負載不相容。
+ 您未將法規和合規要求納入考量。
**建立此最佳實務的優勢：**設定工作負載的 RTO 和 RPO 之後，您就可以根據業務需求訂定清楚且可衡量的復原目標。設定這些目標之後，您就可以制定專為實現這些目標所打造的災難復原 (DR) 計畫。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
建構對照表或工作表，以協助引導您的災難復原規劃。在對照表中，根據個別的業務影響 (例如嚴重、高、中和低) 以及要做為個別目標的相關聯 RTO 和 RPO，建立不同的工作負載類別或分級。下列對照表為您提供可遵循的範例 (請注意，您的 RTO 和 RPO 值可能不同)：
![\[顯示災難復原矩陣的圖表\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/images/disaster-recovery-matrix.png)
針對每個工作負載，調查並了解停機時間和資料遺失對業務造成的影響。影響通常會隨著停機時間和資料遺失而增強，但影響的程度會根據工作負載類型而有所不同。例如，長達一小時的停機時間可能會產生低程度的影響，但隨後影響可能會迅速增強。影響可能有多種形式，包括財務影響 (例如收益損失)、聲譽影響 (包括失去客戶信任)、營運影響 (例如發不出薪資或生產力降低)，以及法規風險。完成後，將工作負載指派至適當的分級。
當您分析故障的影響時，請考慮下列問題：
1. 在對業務造成無法接受的影響之前，可以容忍的最長工作負載停機時間是多久？
1. 工作負載中斷會對業務產生多大程度的影響以及何種影響？ 請考慮各種影響，包括財務、聲譽、營運和法規。
1. 在對業務造成無法接受的影響之前，可以容忍的遺失或無法復原的最大資料量是多少？
1. 是否可從其他來源重新建立遺失的資料 (也稱為*衍生*資料)？ 如果可以，請同時考量用來重新建立工作負載資料的所有來源資料的 RPO。
1. 此工作負載所依賴的工作負載 (下游) 的復原目標和可用性期望為何？ 工作負載的目標必須在其下游相依的工作負載具有復原能力的情況下才能達成。請考慮可能改善此工作負載復原能力的下游相依性因應措施或緩解措施。
1. 依賴此工作負載的工作負載 (上游) 的復原目標和可用性期望為何？ 上游工作負載目標可能要求此工作負載具有比首次出現更嚴格的復原能力。
1. 是否取決於事件類型而有不同的復原目標？ 例如，根據事件影響的是可用區域或整個區域而定，您可能有不同的 RTO 和 RPO。
1. 您的復原目標是否在一年中的某些事件或某段時間改變？ 例如，您可能在節日購物季節、體育賽事、特別促銷和新產品推出時，採用不同的 RTO 和 RPO。
1. 復原目標如何與您可能擁有的任何業務範圍和組織災難復原策略保持一致？
1. 是否需要考慮任何法律或合約後果？ 例如，您是否在合約方面有義務要提供具有特定 RTO 或 RPO 的服務？ 若未履行義務，可能會受到哪些懲罰？
1. 是否需要維護資料完整性以符合法規或合規要求？
下列工作表可協助您評估每個工作負載。您可以修改此工作表以滿足您的特定需求，例如新增其他問題。
![\[工作表\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/images/worksheet.png)
### 實作步驟
1. 確定負責每個工作負載的業務利害關係人和技術團隊，並與他們互動。
1. 在組織中建立工作負載影響的關鍵性類別或分級。範例類別包括：嚴重、高、中和低。為每個類別選擇合乎您業務目標和需求的 RTO 和 RPO。
1. 將您在上一個步驟中建立的其中一個影響類別指派給每個工作負載。若要決定工作負載對應至類別的方式，請考慮工作負載對業務的重要性，以及中斷或資料遺失的影響，並利用上述問題來引導您。這樣就能找到每個工作負載的 RTO 和 RPO。
1. 考慮上一個步驟中為每個工作負載確定的 RTO 和 RPO。讓工作負載的業務和技術團隊參與，以判斷是否應調整目標。例如，業務利害關係人可判斷是否需要更嚴格的目標。或者，技術團隊可以判斷應修改目標，以透過可用的資源和技術限制來實現目標。
## 資源
**相關的最佳實務：**
+ [REL09-BP04 定期執行資料復原以驗證備份的完整性和程序](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_periodic_recovery_testing_data.html)
+ [REL12-BP01 使用程序手冊調查失敗](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency.html)
+ [REL13-BP02 使用定義的復原策略來滿足復原目標](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)
+ [REL13-BP03 測試災難復原實作以驗證實作](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)
**相關文件：**
+ [AWS 架構部落格：災難復原系列](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS 上工作負載的災難復原：在雲端中復原 (AWS 白皮書)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [使用 AWS Resilience Hub 管理彈性政策](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html)
+ [APN 合作夥伴：可協助進行災難復原的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace：可用於災難復原的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**相關影片：**
+ [AWS re:Invent 2018：適用於多區域主動-主動應用程式的架構模式](https://youtu.be/2e29I3dA8o4)
+ [ 上工作負載的災難復原AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
# REL13-BP02 使用定義的復原策略來滿足復原目標
定義一個符合工作負載復原目標的災難復原 (DR) 策略。選擇如下策略：備份與還原；待命 (主動/被動)；或是主動/主動。
**預期成果：**對於每個工作負載，都有已定義並實作的 DR 策略，可讓工作負載實現災難復原目標。工作負載之間的 DR 策略會利用可重複使用模式 (例如上述策略)，
**常見的反模式：**
+ 針對具有類似 DR 目標的工作負載實作不一致的復原程序。
+ 災難發生時臨時實作 DR 策略。
+ 沒有災難復原的計劃。
+ 復原期間依賴控制平面操作。
**建立此最佳實務的優勢：**
+ 使用定義的復原策略可讓您使用常用的工具和測試程序。
+ 使用定義的復原策略可改善在團隊之間分享知識，並更輕鬆地在他們擁有的工作負載上實作 DR。
**未建立此最佳實務時的風險暴露等級：**高。若沒有事先規劃、實作和測試災難復原策略，您就不可能在發生災難時實現復原目標。
## 實作指引
如果您的主要位置變成無法執行工作負載，則災難復原策略會依賴在復原站點中支持您工作負載的能力。最常見的復原目標為 RTO 和 RPO，如 [REL13-BP01 定義停機和資料遺失的復原目標](rel_planning_for_recovery_objective_defined_recovery.md) 中所討論。
單一 AWS 區域 內跨多個可用區域 (AZ) 的 DR 策略可以緩解火災、洪水和重大停電等災難事件。如果需要實作保護，以防範阻止您的工作負載在給定 AWS 區域 中執行且不太可能發生的事件，您可以使用一個使用多個區域的 DR 策略。
在跨多個區域架構 DR 策略時，您應該選擇下列其中一個策略。其按成本和複雜性的升序以及 RTO 和 RPO 的降序排列。*復原區域*是指用於工作負載的主要區域以外的 AWS 區域。
![\[顯示 DR 策略的圖表\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/images/disaster-recovery-strategies.png)
+ **備份與還原** (RPO 以小時為單位，24 小時以內的 RTO)：將您的資料和應用程式備份至復原區域。使用自動或連續備份將允許時間點復原 (PITR)，在某些情況下可以將 RPO 降低至 5 分鐘。如果發生災難，您將部署您的基礎設施 (使用基礎設施架構即程式碼來減少 RTO)、部署您的程式碼，並還原備份的資料以從復原區域中的災難中復原。
+ **指示燈** (RPO 以分鐘為單位，RTO 以十分鐘為單位)：在復原區域佈建核心工作負載基礎設施的副本。將您的資料複寫到復原區域並在該處建立其備份。支援資料複寫和備份所需的資源 (例如資料庫和物件儲存) 始終處於開啟狀態。其他元素 (例如應用程式伺服器或無伺服器運算) 未部署，但可在需要時使用必要的組態和應用程式碼建立。
+ **暖待命** (RPO 以秒為單位，RTO 以分鐘為單位)：維持始終在復原區域中執行，規模縮減但功能完整的工作負載版本。業務關鍵系統會完全複製且持續開啟，但叢集會縮小。資料會被複寫並存在於復原區域中。當需要復原時，系統會迅速擴展以處理生產負載。暖待命的縱向擴增越多，對 RTO 和控制平面的依賴就越低。當完全擴展時，這稱為*熱待命*。
+ **多區域 (多站台) 主動-主動式** (RPO 接近零，RTO 可能為零)：您的工作負載會部署到多個 AWS 區域，並可主動為其流量提供服務。此策略需要您跨區域同步資料。必須避免或處理在兩個不同區域複本中寫入同一記錄所引起的可能衝突，這可能很複雜。資料複寫對於資料同步很有用，而且可以保護您防範某些類型的災難，但它不能保護您防範資料損毀或破壞，除非您的解決方案也包括時間點復原的選項。
**注意**
指示燈和暖待命之間的差異有時可能很難理解。這兩者都在您的復原區域中包含一個環境，其中具有主要區域資產的副本。區別在於，若未先採取額外動作，指示燈無法處理請求，而暖待命可以立即處理流量 (容量層級降低)。指示燈將需要您開啟伺服器，可能會部署額外 (非核心) 基礎設施並向上擴展，而暖待命只需要您向上擴展 (一切都已部署並執行中)。根據您的 RTO 和 RPO 需求在這兩者之間進行選擇。
當成本是一大顧慮時，且想要達到與暖待命策略所定義類似的 RPO 和 RTO 目標，您可以考慮雲端原生解決方案，例如 AWS 彈性災難復原，它會採取指示燈方法並且提供改善的 RPO 和 RTO 目標。
**實作步驟**
1. **決定將滿足此工作負載復原需求的 DR 策略。**
選擇 DR 策略是在減少停機時間和資料遺失 (RTO 和 RPO) 與實作策略的成本和復雜性之間進行取捨。您應該避免實作比其所需更嚴格的策略，因為這會產生不必要的成本。
例如，在下圖中，企業已確定其最大允許的 RTO 以及其可以在服務還原策略上花費的限制。鑑於業務目標，DR 策略指示燈或暖待命將同時滿足 RTO 和成本準則。
![\[圖形：顯示根據 RTO 和成本選擇 DR 策略\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/images/choosing-a-dr-strategy.png)
如需進一步了解，請參閱[業務持續性計劃 (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html)。
1. **審核如何實作所選 DR 策略的模式。**
此步驟在於了解您將如何實作所選策略。使用 AWS 區域 做為主要站點和復原站點來解釋這些策略。不過，您也可以選擇使用單一區域內的可用區域，做為您的 DR 策略，這會利用其中多個策略的元素。
在下列步驟中，您可以將策略套用到您的特定工作負載。
**備份與還原**
*備份和還原*是最不複雜的實作策略，但還原工作負載需要更多時間和精力，從而導致更高的 RTO 和 RPO。始終對資料進行備份並將其複製到另一個站點 (例如另一個 AWS 區域) 是一種很好的做法。
![\[圖表：顯示備份和還原架構\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/images/backup-restore-architecture.png)
如需此策略的詳細資訊，請參閱 [Disaster Recovery (DR) Architecture on AWS, Part II: Backup and Restore with Rapid Recovery](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/)。
**指示燈**
使用*指示燈*方法，可以將資料從主要區域複製到復原區域。用於工作負載基礎設施的核心資源會部署在復原區域中，不過，仍需要額外的資源和任何相依性，才能使其成為功能堆疊。例如，在圖 20 中，未部署任何運算執行個體。
![\[顯示指示燈架構的圖表\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/images/pilot-light-architecture.png)
有關此策略的詳細資訊，請參閱 [AWS 上的災難復原 (DR) 架構，第 III 部分：指示燈和暖待命](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)。
**暖待命**。
*暖待命*方法包括確保在另一個區域中有規模縮減但功能完整的生產環境副本。這種方法擴充了指示燈概念並減少了復原時間，因為您的工作負載始終在另一個區域中開啟。如果復原區域已部署全部容量，則稱為*熱待命*。
![\[顯示圖 21 的圖表：暖待命架構\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/images/warm-standby-architecture.png)
使用暖待命或指示燈需要縱向擴展復原區域中的資源。若要確認容量在需要時可用，請考慮使用 EC2 執行個體的[容量保留](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html)。如果使用 AWS Lambda，[佈建並行](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html)可以提供執行時期環境，以便立即回應函數的調用。
有關此策略的詳細資訊，請參閱 [AWS 上的災難復原 (DR) 架構，第 III 部分：指示燈和暖待命](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)。
**多站點主動/主動**
作為*多站台主動/主動策略*的一部分，您可以在多個區域同時執行工作負載。多站點主動/主動會為來自其部署至的所有區域的流量提供服務。客戶可以出於 DR 以外的原因選擇此策略。它可以用來提高可用性，或在將工作負載部署至全球對象 (使端點更靠近使用者和/或將本地化的堆疊部署到該區域的對象) 時使用它。作為 DR 策略，如果工作負載無法在其部署至的其中一個 AWS 區域中得到支援，則會撤離該區域，而其餘區域則會用來維護可用性。多站點主動/主動是災難復原策略中操作最複雜的策略，因此只有在業務要求有此需要時才應選取它。
![\[顯示多站點主動/主動架構的圖表\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/images/multi-site-active-active-architecture.png)
如需此策略的詳細資訊，請參閱 [Disaster Recovery (DR) Architecture on AWS, Part IV: Multi-site Active/Active](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)。
**AWS 彈性災難復原**
如果您正在考慮用於災難復原的指示燈或暖待命策略，AWS 彈性災難復原 可以提供具有改進效益的替代方法。Elastic Disaster Recovery 可以提供類似於暖待命的 RPO 和 RTO 目標，但維持指示燈的低成本方法。Elastic Disaster Recovery 會使用持續的資料保護功能，實現以秒為單位測量的 RPO，以及以幾分鐘為單位測量的 RTO，將您的資料從主要區域複製到復原區域。只有複寫資料所需的資源會在復原區域中部署，保持低成本，類似於指示燈策略。使用 Elastic Disaster Recovery 時，服務會在容錯移轉或練習過程中啟動時進行協調。
![\[架構圖說明 AWS 彈性災難復原 如何操作。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/images/drs-architecture.png)
**保護資料的其他實務**
使用所有策略時，您還必須緩解資料災難。持續資料複寫可以保護您防範某些類型的災難，但它不能保護您防範資料損毀或破壞，除非您的策略也包括所存放資料的版本控制，或時間點復原的選項。除了複本之外，您還必須備份復原站點中的複寫資料，以建立時間點備份。
**在單一 AWS 區域內使用多個可用區域 (AZ)**
在單一區域內使用多個 AZ 時，您的 DR 實作會使用上述策略的多個元素。首先，您必須建立高可用性 (HA) 架構，使用多個 AZ，如圖 23 所示。由於 [Amazon EC2 執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones)和 [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) 已在多個 AZ 中部署了資源，因此架構可使用多站點主動/主動方法，以積極處理請求。該架構也示範熱待命，如果主要 [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) 執行個體發生故障 (或 AZ 本身失敗)，則待命執行個體會升級為主執行個體。
![\[顯示圖 24 的圖表：多可用區域架構\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/images/multi-az-architecture2.png)
除了這種 HA 架構之外，您還需要新增執行工作負載所需之所有資料的備份。這對於受限於單一區域的資料 (例如 [Amazon EBS 磁碟區](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html)或 [Amazon Redshift 叢集](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html)) 尤其重要。如果 AZ 失敗，您需要將此資料還原至另一個 AZ。可能的話，您也應該將資料備份複製到另一個 AWS 區域，做為額外的保護層。
部落格文章[使用 Amazon 應用程式復原控制器建置高彈性應用程式，第 1 部分：單一區域堆疊](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)中說明了單一區域、多可用區域災難復原的不常見替代方法。在這裡，策略是盡可能地在 AZ 之間保持隔離，就像區域的操作方式一樣。使用這種替代策略，您可以選擇主動/主動或主動/被動方法。
**注意**
某些工作負載具有法規資料落地要求。如果在目前只有一個 AWS 區域的區域性中，這適用於您的工作負載，則多區域將不適合您的業務需求。異地同步備份策略提供良好的保護，可防範大部分災難。
1. **在容錯移轉之前 (在正常操作期間)，評估工作負載的資源，以及其在復原區域中的組態。**
對於基礎設施和 AWS 資源，請使用基礎設施即程式碼 (例如 [AWS CloudFormation](https://aws.amazon.com/cloudformation)) 或諸如 Hashicorp Terraform 之類的第三方工具。若要透過單一操作在多個帳戶和區域中進行部署，可以使用 [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)。對於多站點主動/主動和熱待命策略，您的復原區域中部署的基礎設施具有與您主要區域相同的資源。對於指示燈和暖待命策略，部署的基礎設施將需要額外的動作，才能為生產做好準備。使用 CloudFormation [參數](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html)和[條件邏輯](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html)，可透過[單一範本](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)來控制已部署的堆疊是處於作用中還是待命。使用 Elastic Disaster Recovery 時，服務會複寫和協調應用程式組態和運算資源的還原。
所有 DR 策略都需要在 AWS 區域 中備份資料來源，然後將這些備份複製到復原區域。[AWS Backup](https://aws.amazon.com/backup/) 提供集中式檢視，您可以在其中設定、排程和監控這些資源的備份。對於指示燈、暖待命和多站點主動/主動式，您還應該將資料從主要區域複寫到復原區域中的資料資源，例如 [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds) 資料庫執行個體或 [Amazon](https://aws.amazon.com/dynamodb) DynamoDB 資料表。因此，這些資料資源是即時的，而且可以為復原區域中的請求提供服務。
若要深入了解 AWS 服務如何跨區域運作，請參閱 [Creating a Multi-Region Application with AWS Services](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/) 部落格系列。
1. **確定並實作如何讓復原區域在需要時 (在災難事件發生時) 做好容錯移轉的準備。**
對於多站點主動/主動，容錯移轉意味著撤離一個區域，並依賴剩餘的主動區域。通常，這些區域已準備好接受流量。對於指示燈和暖待命策略，您的復原動作將需要部署遺漏的資源，例如圖 20 中的 EC2 執行個體，以及任何其他遺漏的資源。
對於上述所有策略，您可能需要提升資料庫的唯讀執行個體，以變成主要讀取/寫入執行個體。
對於備份和還原，從備份還原資料會為該資料建立資源，例如 EBS 磁碟區、RDS 資料庫執行個體和 DynamoDB 資料表。您也需要還原基礎設施和部署程式碼。您可以使用 AWS Backup，還原復原區域中的資料。如需詳細資訊，請參閱[REL09-BP01 識別並備份所有需要備份的資料，或從來源複製資料](rel_backing_up_data_identified_backups_data.md)。重建基礎設施包括建立 EC2 執行個體等資源，以及所需的 [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc)、子網路和安全群組。您可以將大部分還原程序自動化。若要了解如何操作，請參閱[此部落格文章](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/)。
1. **確定並實作如何在需要時 (在災難事件發生時) 重新路由流量以進行容錯移轉。**
此容錯移轉作業可以自動或手動啟動。應謹慎使用根據運作狀態檢查或警示自動啟動的容錯移轉，因為不必要的容錯移轉 (誤報) 會產生非可用性和資料遺失等成本。因此通常使用手動啟動的容錯移轉。在此情況下，您仍應將容錯移轉的步驟自動化，讓手動啟動就像按下按鈕一樣簡易。
使用 AWS 服務時，有數個流量管理選項需要考慮。一種選擇是使用 [Amazon Route 53](https://aws.amazon.com/route53)。使用 Amazon Route 53，您可以將一個或多個 AWS 區域中的 IP 端節與一個 Route 53 網域名稱建立關聯。若要實作手動啟動的容錯移轉，您可以使用 [Amazon 應用程式復原控制器](https://aws.amazon.com/application-recovery-controller/)，它可提供高可用性的資料平面 API，將流量重新路由到復原區域。實作容錯移轉時，使用資料平面操作並避免控制平面操作，如 [REL11-BP04 復原期間需使用資料平面，而非控制平面](rel_withstand_component_failures_avoid_control_plane.md) 中所述。
若要進一步了解此選項和其他選項，請參閱[《災難復原白皮書》中的此章節](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light)。
1. **設計一個工作負載故障恢復計畫。**
容錯恢復是指在災難事件減弱後將工作負載操作回復到主要區域。將基礎設施和程式碼佈建到主要區域通常遵循最初使用的相同步驟，依賴基礎設施即程式碼和程式碼部署管道。容錯恢復的挑戰是還原資料存放區，並確保它們與操作中的復原區域保持一致。
在容錯移轉狀態下，復原區域中的資料庫是即時的並具有最新資料。後續目標是從復原區域重新同步到主要區域，確保它是最新的。
有些 AWS 服務將會自動執行此動作。如果使用 [Amazon DynamoDB 全域表](https://aws.amazon.com/dynamodb/global-tables/)，即使主要區域中的資料表變得無法使用，當它重新上線時，DynamoDB 會繼續傳播任何擱置的寫入。如果使用 [Amazon Aurora 全球資料庫](https://aws.amazon.com/rds/aurora/global-database/)並使用[受管計劃容錯移轉](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover)，則維護 Aurora 全球資料庫的現有複寫拓撲。因此，主要區域中先前的讀取/寫入執行個體將成為複本，並從復原區域中接收更新。
如果這不是自動的，您將需要在主要區域中重建資料庫，做為復原區域中資料庫的複本。在許多情況下，這將涉及刪除舊的主要資料庫並建立新的複本。
容錯移轉後，如果您可以繼續在復原區域中執行，請考慮使其成為新的主要區域。您仍會執行上述所有步驟，使先前的主要區域成為復原區域。有些組織會執行排程輪換，定期 (例如每三個月) 交換其主要區域和復原區域。
容錯移轉和復原所需的所有步驟都應保持在可供所有團隊成員使用的程序手冊中，並定期進行審查。
使用 Elastic Disaster Recovery 時，該服務會協助協調和自動化容錯恢復程序。如需詳細資訊，請參閱 [Performing a failback](https://docs.aws.amazon.com/drs/latest/userguide/failback-performing-main.html)。
**實作計劃的工作量：**高
## 資源
**相關的最佳實務：**
+ [REL09-BP01 識別並備份所有需要備份的資料，或從來源複製資料](rel_backing_up_data_identified_backups_data.md)
+ [REL11-BP04 復原期間需使用資料平面，而非控制平面](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL13-BP01 定義停機和資料遺失的復原目標](rel_planning_for_recovery_objective_defined_recovery.md)
**相關文件：**
+ [AWS 架構部落格：災難復原系列](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS 上工作負載的災難復原：在雲端中復原 (AWS 白皮書)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [雲端中的災難復原選項](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)
+ [一小時建置無伺服器的多區域、主動-主動後端解決方案](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf)
+ [多區域無伺服器後端 - 重新載入](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0)
+ [RDS：跨區域複寫僅供讀取複本](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn)
+ [Route 53：設定 DNS 備援](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [S3：跨區域複寫](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html)
+ [什麼是 AWS Backup？](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [什麼是 Amazon 應用程式復原控制器？](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [AWS 彈性災難復原](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [HashiCorp Terraform：入門 - AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started)
+ [APN 合作夥伴：可以幫助災難復原的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace：可用於災難復原的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**相關影片：**
+ [AWS 上工作負載的災難復原](https://www.youtube.com/watch?v=cJZw5mrxryA)
+ [AWS re:Invent 2018：適用於多區域主動-主動應用程式的架構模式 (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS Elastic Disaster Recovery 入門 \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as)
# REL13-BP03 測試災難復原實作以驗證實作
定期測試容錯移轉到您的復原站點以確認它正常操作，並符合 RTO 和 RPO。
**常見的反模式：**
+ 切勿在生產環境中執行容錯移轉。
**建立此最佳實務的優勢：**定期測試您的災難復原計畫，可驗證該計畫能在需要時運作，也能讓您的團隊知道如何執行策略。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
要避免的模式是：開發鮮少執行的復原路徑。例如，您可能有一個次要資料存放區，只供唯讀查詢之用。當您寫入資料存放區而主資料存放區發生故障時，您可能需要容錯移轉到次要資料存放區。如果您不經常測試此容錯移轉，則可能會發現您對次要資料存放區的功能的假設不正確。次要資料存放區的容量 (在您上次測試時可能已經足夠) 在這種情況下可能無法再容忍負載。我們的經驗顯示，唯一能發揮功用的錯誤復原，是您經常測試的路徑。因此，最好擁有少量的復原路徑。您可建立復原模式，並定期進行測試。若擁有複雜或關鍵復原路徑，您還是需要定期在生產環境中執行該故障，說服自己該復原路徑能發揮功用。在我們剛剛討論的範例中，無論是否需要，您都應定期容錯移轉到備用資料庫。
**實作步驟**
1. 為復原設計您的工作負載。定期測試您的復原路徑。復原導向運算可識別系統中能增強復原能力的特性：隔離和備援，系統範圍內的回復變更能力，監控和確定運行狀態的能力，提供診斷、自動復原和模組化設計的能力，以及重新啟動的能力。練習復原路徑，以確認您可以在指定時間內完成復原到指定狀態。在復原過程中使用您的執行手冊，以記錄問題並在下一次測試前找出其解決方案。
1. 對於以 Amazon EC2 為基礎的工作負載，請使用 [AWS 彈性災難復原](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) 為 DR 策略實作和啟動演練執行個體。AWS 彈性災難復原 提供有效執行演練的功能，協助您準備容錯移轉事件。您也可以使用 Elastic Disaster Recover 頻繁啟動您的執行個體進行測試和演練，而不需要重新導向流量。
## 資源
**相關文件：**
+ [APN 合作夥伴：可以幫助災難復原的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS 架構部落格：災難復原系列](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace：可用於災難復原的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS 彈性災難復原](https://aws.amazon.com/disaster-recovery/)
+ [AWS 上工作負載的災難復原：在雲端中復原 (AWS 白皮書)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [AWS 彈性災難復原 準備容錯移轉](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html)
+ [柏克萊加州大學/史丹佛大學復原導向的運算專案](http://roc.cs.berkeley.edu/)
+ [什麼是 AWS Fault Injection Simulator？](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**相關影片：**
+ [AWS re:Invent 2018：適用於多區域主動-主動應用程式的架構模式](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019：使用 AWS 的備份與還原和災難復原解決方案](https://youtu.be/7gNXfo5HZN8)
# REL13-BP04 管理 DR 站點或區域的組態偏移
若要執行成功的災難復原 (DR) 程序，您的工作負載必須能夠及時恢復正常運作，而且在 DR 環境上線後，不會發生相關的功能喪失或資料損失。若要實現此目標，請務必在 DR 環境與主要環境之間維護一致的基礎設施、資料和組態。
**預期成果：**您的災難復原站點的組態和資料與主要站點相同，這有助於在需要時快速且完整的復原。
**常見的反模式：**
+ 當主要位置發生變更時，您未能更新復原位置，這會導致組態過時，進而阻礙復原工作。
+ 您未考量潛在的限制，例如，主要和復原位置之間的服務差異，這可能會導致容錯移轉期間發生非預期的失敗。
+ 您依賴手動程序來更新和同步 DR 環境，這會增加人為錯誤和不一致的風險。
+ 您未能偵測到組態偏移，這會導致在事件發生之前對 DR 站點整備度產生錯誤的認知。
**建立此最佳實務的優勢：**DR 環境與主要環境之間的一致性可大幅改善事件發生後成功復原的可能性，並降低復原程序失敗的風險。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
一套完整的組態管理和容錯移轉整備方法，可協助您確認 DR 站點持續更新，並準備好在主要站點故障時接管。
若要實現主要與災難復原 (DR) 環境之間的一致性，請確定您的交付管道會將應用程式同時分配到主要和 DR 網站。經過適當的評估期 (也稱為*交錯部署*) 之後，將變更推展至 DR 站點，以偵測主要站點的問題，並在問題擴大之前停止部署。實作監控來偵測組態偏移，並追蹤整個環境的變更和合規性。在 DR 站點中執行自動修復，使其完全一致，並準備好在事件發生時接管。
### 實作步驟
1. 確定 DR 區域包含成功執行 DR 計畫所需的 AWS 服務和功能。
1. 使用基礎設施即程式碼 (IaC)。保持正式作業基礎設施和應用程式組態範本的準確性，並定期將其套用至災難復原環境。[AWS CloudFormation](https://aws.amazon.com/cloudformation/) 可偵測 CloudFormation 範本所指定內容與實際部署內容之間的偏移。
1. 設定 CI/CD 管道，將應用程式和基礎設施更新部署到所有環境，包括主要和 DR 站點。CI/CD 解決方案 (例如 [AWS CodePipeline](https://aws.amazon.com/codepipeline/)) 可以自動化部署程序，進而降低組態偏移的風險。
1. 在主要環境和 DR 環境之間交錯部署。此方法允許一開始在主要環境中部署和測試更新，這樣會隔離主要站點中的問題，避免後續傳播到 DR 站點。此方法可防止同時將瑕疵推送至正式作業環境和 DR 站點，並維護 DR 環境的完整性。
1. 同時主要和 DR 環境中持續監控資源組態。[AWS Config](https://aws.amazon.com/config/) 這類解決方案可協助強制執行組態合規性並偵測偏移，這有助於在環境之間維持組態的一致性。
1. 實作警示機制，以追蹤任何組態偏移或資料複寫中斷或延遲的情形，並發出通知。
1. 自動修復偵測到的組態偏移。
1. 排程定期稽核和合規檢查，以確認主要和 DR 組態之間持續保持一致。定期審查可協助您保持符合既定規則，並識別任何需要解決的差異。
1. 檢查 AWS 佈建的容量、服務配額、限流限制是否不相符，以及組態和版本的差異。
## 資源
**相關的最佳實務：**
+ [REL01-BP01 了解服務配額和限制](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_aware_quotas_and_constraints.html)
+ [REL01-BP02 管理帳戶與區域之間的服務配額](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_limits_considered.html)
+ [REL01-BP04 監控和管理配額](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_monitor_manage_limits.html)
+ [REL13-BP03 測試災難復原實作以驗證實作](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)
**相關文件：**
+ [依 AWS Config 規則 修補不合規的 AWS 資源](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS CloudFormation：偵測堆疊和資源的未受管組態變更](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html)
+ [AWS CloudFormation：在整個 CloudFormation 堆疊上偵測偏差](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS 上工作負載的災難復原：在雲端中復原 (AWS 白皮書)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [如何在 AWS 上實作基礎設施組態管理解決方案？](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/?ref=wellarchitected)
+ [依 AWS Config 規則 修補不合規的 AWS 資源](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
**相關影片：**
+ [AWS re:Invent 2018：適用於多區域主動-主動應用程式的架構模式 (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
**相關範例：**
+ [CloudFormation 登錄](https://aws.amazon.com/blogs/devops/identify-regional-feature-parity-using-the-aws-cloudformation-registry/)
+ [適用於 AWS 的配額監控](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [使用 Amazon CloudWatch 和 AWS Lambda 實作自動修復 AWS CloudFormation 的偏移](https://aws.amazon.com/blogs/mt/implement-automatic-drift-remediation-for-aws-cloudformation-using-amazon-cloudwatch-and-aws-lambda/)
+ [AWS 架構部落格：災難復原系列](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace：可用於災難復原的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [自動化安全、無人為介入的部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
# REL13-BP05 自動化回復
實作經測試、可靠、可觀測且可重現的自動復原機制，以減少故障的風險和業務影響。
**預期成果：**您已針對復原程序實作記錄完整、標準化且經過徹底測試的自動化工作流程。您的復原自動化會自動修正資料遺失或無法使用屬於低風險的次要問題。您可針對嚴重事件快速調用復原程序、觀察執行修復過程時的行為，並且在發現危險情況或故障時結束程序。
**常見的反模式：**
+ 您依賴處於失敗或降級狀態的元件或機制做為復原計畫的一部分。
+ 您的復原程序需要手動介入，例如主控台存取 (也稱為*點按操作*)。
+ 您在資料遺失或無法使用處於高風險的情況下，自動初始化復原程序。
+ 您未納入中止無法運作或會產生其他風險的復原程序的機制 (例如 *Andon cord* 或 *大型紅色停止按鈕*)。
**建立此最佳實務的優勢：**
+ 復原操作擁有更高的可靠性、可預測性和一致性。
+ 能夠實現更嚴格的復原目標，包括復原時間點目標 (RTO) 和復原點目標 (RPO)。
+ 降低在事件期間復原失敗的可能性。
+ 降低容易發生人為錯誤的手動復原程序伴隨的失敗風險。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
若要實作自動復原程序，您需要一套使用 AWS 服務和最佳實務的全方位方法。若要開始進行，請找出工作負載中的關鍵元件和潛在的失敗點。制定可在不需要人為介入的情況下復原您的工作負載和資料的自動化程序。
使用基礎設施即程式碼 (IaC) 原則來制定復原自動化。這可讓復原環境與來源環境保持一致，並允許復原程序的版本控制。若要協調複雜的復原工作流程，請考慮 [AWS Systems Manager Automations](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 或 [AWS Step Functions](https://aws.amazon.com/step-functions/) 等解決方案。
自動化復原程序可提供顯著的優勢，並可協助您更輕鬆地達成復原時間點目標 (RTO) 和復原點目標 (RPO)。不過，這些程序可能會遇到非預期的情況，而導致程序失敗或本身產生新風險，例如額外的停機時間和資料遺失。為了降低此風險，請提供可快速停止進行中復原自動化的功能。停止後，您就可以調查並採取修正步驟。
對於支援的工作負載，請考慮採用 AWS 彈性災難復原 (AWS DRS) 這類解決方案來提供自動容錯移轉。AWSDRS 會持續將您的機器 (包括作業系統、系統狀態組態、資料庫、應用程式和檔案) 複寫至您的目標 AWS 帳戶 和慣用區域中的預備區域。如果事件發生，AWS DRS 會自動將複寫的伺服器轉換到 AWS 上復原區域中完整佈建的工作負載。
自動復原的維護和改善是一個持續進行的過程。根據學到的經驗持續測試和精進復原程序，並隨時掌握可增強復原功能的新 AWS 服務和功能。
### 實作步驟
1. **規劃自動復原**
1. 徹底檢閱工作負載架構、元件和相依性，以識別和規劃自動復原機制。將工作負載的相依性分類為*硬*和*軟*相依性。硬相依性是指工作負載無法在沒有此相依性的情況下運作，且此相依性無法替代。軟相依性是指工作負載平常使用的相依性，此相依性可使用臨時替代系統或程序取代，也可以透過[正常降級](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation)處理。
1. 建立程序以識別和復原缺少或損毀的資料。
1. 定義在復原動作完成後，用來確認復原穩定狀態的步驟。
1. 考慮讓復原的系統就緒可提供完整服務所需的任何動作，例如預熱和填入快取。
1. 考慮在復原過程中可能遇到的問題，以及如何偵測和修復這些問題。
1. 考慮無法存取主要站點及其控制平面的情況。確認復原動作可以在不依賴主要站點的情況下單獨執行。考慮採用 [Amazon 應用程式復原控制器 (ARC)](https://aws.amazon.com/application-recovery-controller/) 這類解決方案來重新導向流量，而不需要手動改變 DNS 記錄。
1. **制定自動復原程序**
1. 實作自動故障偵測和容錯移轉機制，不需手動介入即可自動復原。建置像是 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 中的儀表板，用來報告自動復原程序的進度和運作狀態。納入確認成功復原的程序。提供中止進行中復原程序的機制。
1. 針對無法自動復原的故障，製作[程序手冊](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency)做為備援程序，並考量您的[災難復原計畫](https://aws.amazon.com/disaster-recovery/faqs/#Core_concepts)。
1. 依照 [REL13-BP03](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_dr_tested.html) 中所述，測試復原程序。
1. **準備復原**
1. 評估復原站點的狀態，並提前部署關鍵元件。如需詳細資訊，請參閱 [REL13-BP04](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_config_drift.html)。
1. 定義明確的角色、責任，以及復原操作的決策流程，並且讓整個組織的利害關係人和團隊參與其中。
1. 定義初始化復原程序的條件。
1. 建立計畫來還原復原程序，並視需要或在安全時恢復您的主要站點。
## 資源
**相關的最佳實務：**
+ [REL07-BP01 取得或擴展資源時使用自動化](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_adapt_to_changes_autoscale_adapt.html)
+ [REL11-BP01 監控工作負載的所有元件以偵測故障](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_withstand_component_failures_monitoring_health.html)
+ [REL13-BP02 使用定義的復原策略來滿足復原目標](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)
+ [REL13-BP03 測試災難復原實作以驗證實作](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_dr_tested.html)
+ [REL13-BP04 管理 DR 站點或區域的組態偏移](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_config_drift.html)
**相關文件：**
+ [AWS 架構部落格：災難復原系列](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS 上工作負載的災難復原：在雲端中復原 (AWS 白皮書)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [使用 Amazon Route 53 ARC 和 AWS Step Functions 協調災難復原自動化](https://aws.amazon.com/blogs/networking-and-content-delivery/orchestrate-disaster-recovery-automation-using-amazon-route-53-arc-and-aws-step-functions/)
+ [使用 AWS CDK 建置 AWS Systems Manager Automation 執行手冊](https://aws.amazon.com/blogs/mtbuild-aws-systems-manager-automation-runbooks-using-aws-cdk/)
+ [AWS Marketplace：可用於災難復原的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS 彈性災難復原](https://aws.amazon.com/disaster-recovery/)
+ [使用彈性災難復原進行容錯移轉和容錯恢復](https://docs.aws.amazon.com/drs/latest/userguide/failback.html)
+ [AWS 彈性災難復原資源](https://aws.amazon.com/disaster-recovery/resources/)
+ [APN 合作夥伴：可協助進行災難復原的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
**相關影片：**
+ [AWS re:Invent 2018：適用於多區域主動-主動應用程式的架構模式 (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2022: AWS On Air 搭配 AWS 彈性災難復原的 AWS 容錯恢復](https://youtu.be/Ok-vpV8b1Hs)