# REL 13 您如何規劃災難復原 (DR)？
備妥備份和冗餘工作負載元件是 DR 策略的開始。[RTO 和 RPO 是您還原](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) 工作負載的目標。根據業務需求設定這些目標。實作策略以滿足這些目標，考量工作負載資源和資料的位置和功能。發生中斷的可能性和復原成本也是重要因素，可反映為工作負載提供災難復原的商業價值。
**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)* 是自上次資料復原點之後的最大可接受時間長度。這會決定最後一個復原點與服務中斷之間可接受的資料遺失。
在為您的工作負載選取適用的災難復原 (DR) 策略時，RTO 和 RPO 值是重要的考慮因素。這些目標是由企業決定，然後由技術團隊用來選取和實作 DR 策略。
**預期成果：**
每個工作負載都獲指派一個 RTO 和 RPO，其是根據業務影響來定義的。工作負載會指派給預先定義的層級，定義服務可用性和可接受的資料遺失，以及相關聯的 RTO 和 RPO。如果這類分層不可行，則可以根據工作負載以定制方式指派此分層，旨在稍後建立層級。RTO 和 RPO 會在選取工作負載的災難復原策略實作時的主要考量之一。挑選 DR 策略的其他考量是成本限制、工作負載相依性和營運要求。
對於 RTO，了解基於中斷持續時間的影響。它是線性的，還是有非線性的影響？(例如，四個小時後，您關閉了一條生產線，直到下一個輪班開始)。
如下的災難復原方法可以協助您了解工作負載關鍵性與復原目標之間的關係。(請注意，X 軸和 Y 軸的實際值應根據您的組織需求加以自訂)。
![\[圖表：顯示災難復原方法\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/disaster-recovery-matrix.png)
**常用的反模式：**
+ 沒有已定義的復原目標。
+ 選擇任意復原目標。
+ 選擇過於寬鬆且不符合業務目標的復原目標。
+ 不了解關機時間和資料遺失的影響。
+ 選取不切實際的復原目標，例如零時間復原和零資料遺失，這對於您的工作負載組態可能無法實現。
+ 選擇比實際業務目標更嚴格的復原目標。這會被迫進行比工作負載所需更昂貴和更複雜的 DR 實作。
+ 選取的復原目標與工作負載的復原目標不相容。
+ 您的復原目標未考慮法規合規性要求。
+ 已定義工作負載的 RTO 和 RPO，但從未進行測試。
**建立此最佳實務的優勢：** 需以時間和資料損失的復原目標來引導 DR 實作。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
對於給定的工作負載，您必須了解停機時間和資料遺失對您業務的影響。隨著停機時間或資料遺失的增加，影響會大幅地增長，但這種增長形式可能會根據工作負載類型而有所不同。例如，您可以容忍長達一小時的停機時間而影響不大，但在此之後影響會迅速加大。對業務的影響會以多種形式顯現，包括貨幣成本 (例如收益損失)、客戶信任 (以及對信譽的影響)、營運問題 (例如發不出薪資或生產力下降)，以及監管風險。使用下列步驟來了解這些影響，並為您的工作負載設定 RTO 和 RPO。
**實作步驟**
1. 確定此工作負載的業務利害關係人，並與他們一起實作這些步驟。工作負載的復原目標是業務決策。然後，技術團隊與業務利害關係人合作，使用這些目標來選取 DR 策略。
**注意**
針對步驟 2 和 3，您可以使用 [實作工作表](#implementation-worksheet)。
1. 收集必要資訊，藉由回答下列問題來做出決策。
1. 對於組織中的工作負載影響，您是否具有關鍵性的類別或層級？
1. 若是，請將此工作負載指派給類別。
1. 若否，請建立這些類別。建立五個或更少的類別，然後縮小每個類別的復原時間目標範圍。範例類別包括：重大、高、中、低。若要了解工作負載如何對應至類別，請考慮工作負載是任務為主、業務為主，還是非業務推動。
1. 根據類別設定工作負載 RTO 和 RPO。一律選擇比進入此步驟所計算的原始值更嚴格的類別 (更低的 RTO 和 RPO)。如果這導致值發生不適當的大變更，則考慮建立一個新類別。
1. 根據這些答案，將 RTO 和 RPO 指派給工作負載。這可以直接完成，也可以透過將工作負載指派給預先定義的服務層來完成。
1. 在工作負載團隊和利害關係人可存取的位置記錄此工作負載的 [災難復原計劃 (DRP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html)，這是貴組織業務持續性計劃 (BCP) 的一部分。
1. 記錄 RTO 和 RPO，以及用來決定這些值的資訊。包括用於評估對業務之工作負載影響的策略。
1. 記錄除 RTO 和 RPO 之外的其他指標，您是否正在追蹤或規劃追踨災難復原目標。
1. 建立 DR 策略和執行手冊的詳細資訊時，會將這些資訊新增至此計劃。
1. 藉由在如圖 15 所示的矩陣中查看工作負載的關鍵性，您可以開始建立針對組織定義的預先定義服務層。
1. 在您根據 實作了 DR 策略 (或 DR 策略的概念證明) 之後[REL13-BP02 使用定義的復原策略來滿足復原目標](rel_planning_for_recovery_disaster_recovery.md)，請測試此策略以判定工作負載的實際 RTC (復原時間能力) 和 RPC (復原點能力)。如果這些不符合目標復原目標，則可與您的業務利害關係人合作，一起調整這些目標，或可對 DR 策略進行變更以符合目標。
**主要問題**
1. 在對業務產生嚴重影響之前，工作負載可以關閉的時間上限
1. 如果工作負載中斷，請判定每分鐘對業務造成的貨幣成本 (直接財務影響)。
1. 考慮到影響並非總是線性的。一開始影響可能會受到限制，然後在超過關鍵時間點後迅速增加。
1. 在對業務產生嚴重影響之前，可以遺失的資料量上限
1. 考慮將此值用於您最關鍵的資料存放區。識別其他資料存放區的各自關鍵性。
1. 如果遺失工作負載資料，可以重建嗎？ 如果在操作上這樣做比備份和還原更容易，則根據用來重建工作負載資料之來源資料的關鍵性來選擇 RPO。
1. 依賴下游游相依性的工作負載或依賴上游相依性的工作負載，其復原目標和可用性期望是什麼？
1. 選擇可讓此工作負載符合上游相依性要求的復原目標
1. 鑑於下游相依性的復原能力，選擇可實現的復原目標。可以執行非關鍵的下游相依性 (您可以「解決」的相依性)。或者，使用關鍵的下游相依性，在必要時改善其復原能力。
**其他問題**
考慮這些問題，以及它們如何套用至這個工作負載：
1. 您是否有不同的 RTO 和 RPO，取決於中斷的類型 (區域與可用區域等)？
1. 您的 RTO/RPO 是否會在特定時間 (季節性、銷售活動、產品發佈) 發生變化？ 若是，有什麼不同的測量和時間界限？
1. 如果工作負載中斷，有多少客戶會受到影響？
1. 如果工作負載中斷，對信譽有何影響？
1. 如果工作負載中斷，可能會發生哪些其他營運影響？ 例如，如果電子郵件系統無法使用，或如果薪資系統無法提交交易，則會影響員工的生產力。
1. 工作負載 RTO 和 RPO 如何與業務線和組織 DR 策略保持一致？
1. 是否有提供服務的內部合約義務？ 未符合它們時會受到處罰嗎？
1. 資料的法規或合規限制是什麼？
## 實作工作表
您可以將此工作表用於實作步驟 2 和 3。您可以調整此工作表以滿足您的特定需求，例如新增其他問題。
![\[工作表\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/worksheet.png)
**實作計劃的工作量： **低
## 資源
**相關的最佳實務：**
+ [REL09-BP04 定期執行資料復原以驗證備份的完整性和程序](rel_backing_up_data_periodic_recovery_testing_data.md)
+ [REL13-BP02 使用定義的復原策略來滿足復原目標](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 測試災難復原實作以驗證實作](rel_planning_for_recovery_dr_tested.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)
+ [使用 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：適用於多區域主動-主動應用程式的架構模式 (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS 上工作負載的災難復原](https://www.youtube.com/watch?v=cJZw5mrxryA)
# REL13-BP02 使用定義的復原策略來滿足復原目標
定義一個符合工作負載復原目標的災難復原 (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/2022-03-31/framework/images/disaster-recovery-strategies.png)
+ **備份與恢復** (RPO 幾小時，RTO 24 小時以內)：將您的資料和應用程式備份至復原區域。使用自動或連續備份將啟用時間點復原，在某些情況下可以將 RPO 降低至 5 分鐘。如果發生災難，您將部署您的基礎設施 (使用基礎設施架構即程式碼來減少 RTO)、部署您的程式碼，並還原備份的資料以從復原區域中的災難中復原。
+ **指示燈** (RPO 幾分鐘，RTO 幾十分鐘)：在復原區域中佈建核心工作負載基礎設施的副本。將您的資料複寫到復原區域並在該處建立其備份。支援資料複寫和備份所需的資源 (例如資料庫和物件儲存) 始終處於開啟狀態。其他元素 (例如應用程式伺服器或無伺服器運算) 未部署，但可在需要時使用必要的組態和應用程式碼建立。
+ **暖待命** (RPO 幾秒鐘，RTO 幾分鐘)：維持工作負載的縮減但完整功能版本，該工作負載始終在復原區域中執行。業務關鍵系統會完全複製且持續開啟，但叢集會縮小。資料會被複寫並存在於復原區域中。當需要復原時，系統會迅速擴展以處理生產負載。熱待命的縱向擴增越多，對 RTO 和控制平面的依賴就越低。完全擴展時，稱之為 **熱待命**。
+ **多區域 (多站點) 主動-主動** (RPO 近乎零，RTO 可能為零) 您的工作負載會部署至多個 AWS 區域，並主動處理來自多個 AWS 區域 的流量。此策略需要您跨區域同步資料。必須避免或處理在兩個不同區域複本中寫入同一記錄所引起的可能衝突，這可能很複雜。資料複寫對於資料同步很有用，而且可以保護您防範某些類型的災難，但它不能保護您防範資料損毀或破壞，除非您的解決方案也包括時間點復原的選項。
**注意**
指示燈和暖待命之間的差異有時可能很難理解。這兩者都在您的復原區域中包含一個環境，其中具有主要區域資產的副本。區別在於，若未先採取額外動作，指示燈無法處理請求，而暖待命可以立即處理流量 (容量層級降低)。指示燈將需要您開啟伺服器，可能會部署額外 (非核心) 基礎設施並縱向擴展，而暖待命只需要您縱向擴展 (一切都已部署並執行中)。根據您的 RTO 和 RPO 需求在這兩者之間進行選擇。
**預期成果：**
對於每個工作負載，都有一個已定義和實作的 DR 策略，讓該工作負載能夠實現 DR 目標。工作負載之間的 DR 策略會利用可重複使用模式 (例如上述策略)。
**常用的反模式：**
+ 針對具有類似 DR 目標的工作負載實作不一致的復原程序。
+ 災難發生時臨時實作 DR 策略。
+ 沒有 DR 計劃。
+ 復原期間依賴控制平面操作。
**建立此最佳實務的優勢：**
+ 使用定義的復原策略可讓您使用常用的工具和測試程序。
+ 使用定義的復原策略可讓您更有效地在團隊之間分享知識，並更輕鬆地在他們擁有的工作負載上實作 DR。
**若未建立此最佳實務，暴露的風險等級為：** 高
+ 若沒有事先規劃、實作和測試災難復原策略，您就不可能在發生災難時實現復原目標。
## 實作指引
對於其中每一個步驟，請參閱下列詳細資訊。
1. 確定將滿足此工作負載之復原要求的 DR 策略。
1. 審查如何實作所選 DR 策略的模式。
1. 評估工作負載的資源，以及在容錯移轉之前 (在正常操作期間) 其哪個組態將位於復原區域中。
1. 確定並實作如何在需要時 (在災難事件期間) 使您的復原區域為容錯移轉做好準備。
1. 確定並實作如何在需要時 (在災難事件期間) 將流量路由至容錯移轉。
1. 設計您的工作負載將如何復原的計劃。
**實作步驟**
1. **確定將滿足此工作負載之復原要求的 DR 策略。**
選擇 DR 策略是在減少停機時間和資料遺失 (RTO 和 RPO) 與實作策略的成本和復雜性之間進行取捨。您應該避免實作比其所需更嚴格的策略，因為這會產生不必要的成本。
例如，在下圖中，企業已確定其最大允許的 RTO 以及其可以在服務還原策略上花費的限制。鑑於業務目標，DR 策略指示燈或暖待命將同時滿足 RTO 和成本準則。
![\[圖形：顯示根據 RTO 和成本選擇 DR 策略\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/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/2022-03-31/framework/images/backup-restore-architecture.png)
如需此策略的詳細資訊，請參閱 [AWS 上的災難復原 (DR) 架構，第 II 部分：具有快速復原的備份和還原](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/2022-03-31/framework/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/)。
**暖待命**
AWS Well-Architected *基礎架構* 方法涉及確保在另一個區域中有一個縮減規模，但功能完全的生產環境副本。這種方法擴充了指示燈概念並減少了復原時間，因為您的工作負載始終在另一個區域中開啟。如果部署完整容量的復原區域，這稱為 *熱待命*。
![\[顯示圖 21 的圖表：暖待命架構\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/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/2022-03-31/framework/images/multi-site-active-active-architecture.png)
如需此策略的詳細資訊，請參閱 [AWS 上的災難復原 (DR) 架構，第 IV 部分：多站點主動/主動](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)。
**其他保護資料的做法**
使用所有策略時，您還必須緩解資料災難。持續資料複寫可以保護您防範某些類型的災難，但它不能保護您防範資料損毀或破壞，除非您的策略也包括所存放資料的版本控制，或時間點復原的選項。除了複本之外，您還必須備份復原站點中的複寫資料，以建立時間點備份。
**在單一 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 本身失敗)，則待命執行個體會提升至主要執行個體。
![\[顯示圖 23 的圖表：異地同步備份架構\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/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 區域，做為額外的保護層。
下列部落格文章中描述了一種不太常見的單一區域替代方法 (異地同步備份 DR)： [使用 Amazon Route 53 應用程式復原控制器建置高彈性應用程式，第 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)，您可以使用單一範本控制部署的堆疊是主動還是待命。這類 CloudFormation 範本的範例包含在 [這篇部落格文章](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)。
所有 DR 策略都要求在 AWS 區域內備份資料來源，然後將這些備份複製到復原區域。[AWS Backup](https://aws.amazon.com/backup/) 提供了一個集中檢視，您可以在其中設定、排定和監控這些資源的備份。對於指示燈、暖待命和多站點主動/主動，您還應該將資料從主要區域複寫到復原區域中的資料資源，例如 [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds) 資料庫執行個體或 [Amazon DynamoDB](https://aws.amazon.com/dynamodb) 資料表。因此，這些資料資源是即時的，而且可以為復原區域中的請求提供服務。
若要深入了解 AWS 服務如何跨區域操作，請參閱此部落格系列，其位於 [使用 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 Route 53 應用程式復原控制器](https://aws.amazon.com/route53/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 全球資料庫的現有複寫拓撲。因此，主要區域中先前的讀取/寫入執行個體將成為複本，並從復原區域中接收更新。
如果這不是自動的，您將需要在主要區域中重建資料庫，做為復原區域中資料庫的複本。在許多情況下，這將涉及刪除舊的主要資料庫並建立新的複本。例如，如需如何在假設非計劃容錯移轉的情況下使用 Amazon Aurora *全球資料庫* 執行此動作的指示，請參閱此實驗室： [復原全球資料庫](https://awsauroralabsmy.com/global/failback/)。
容錯移轉後，如果您可以繼續在復原區域中執行，請考慮使其成為新的主要區域。您仍會執行上述所有步驟，使先前的主要區域成為復原區域。有些組織會執行排程輪換，定期 (例如每三個月) 交換其主要區域和復原區域。
容錯移轉和復原所需的所有步驟都應保持在可供所有團隊成員使用的程序手冊中，並定期進行審查。
**實作計劃的工作量**：高
## 資源
**相關的最佳實務：**
+ [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)
+ [什麼是 Route 53 應用程式復原控制器？](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 彈性災難復原入門 \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as)
**相關範例：**
+ [AWS Well-Architected 實驗室 - 災難復原](https://wellarchitectedlabs.com/reliability/disaster-recovery/) - 說明 DR 系列的研討會系列
# REL13-BP03 測試災難復原實作以驗證實作
定期測試容錯移轉到您的復原站點以確保正常操作，並符合 RTO 和 RPO。
要避免的模式是：開發鮮少執行的復原路徑。例如，您可能有一個次要資料存放區，只供唯讀查詢之用。當您寫入資料存放區而主資料存放區發生故障時，您可能需要容錯移轉到次要資料存放區。如果您不經常測試此容錯移轉，則可能會發現您對次要資料存放區的功能的假設不正確。次要資料存放區的容量 (在您上次測試時可能已經足夠) 在這種情況下可能無法再容忍負載。我們的經驗顯示，唯一能發揮功用的錯誤復原，是您經常測試的路徑。因此，最好擁有少量的復原路徑。您可建立復原模式，並定期進行測試。若擁有複雜或關鍵復原路徑，您還是需要定期在生產環境中執行該故障，說服自己該復原路徑能發揮功用。在我們剛剛討論的範例中，無論是否需要，您都應定期容錯移轉到備用資料庫。
**常用的反模式：**
+ 切勿在生產環境中執行容錯移轉。
**建立此最佳實務的優勢：** 定期測試您的災難復原計畫，可確保該計畫能在需要時運作，也能讓您的團隊知道如何執行策略。
**若未建立此最佳實務，暴露的風險等級為：** 高
## 實作指引
+ 為復原設計您的工作負載。定期測試您的復原路徑：復原導向運算 (ROC) 可識別系統中能增強復原能力的特性。這些特性包括：隔離和冗餘，系統範圍內的回復變更能力，監控和確定運行狀態的能力，提供診斷、自動復原和模組化設計的能力，以及重新啟動的能力。練習復原路徑，以確保您可以在指定時間內完成復原到指定狀態。在復原過程中使用您的執行手冊，以記錄問題並在下一次測試前找出其解決方案。
+ [柏克萊加州大學/史丹佛大學復原導向的運算專案](http://roc.cs.berkeley.edu/)
+ 使用 CloudEndure Disaster Recovery 實作和測試您的 DR 策略。
+ [透過 CloudEndure 測試災難復原解決方案](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [AWS 的 CloudEndure Disaster Recovery](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
## 資源
**相關文件：**
+ [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)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [AWS 上工作負載的災難復原：在雲端中復原 (AWS 白皮書)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [透過 CloudEndure 測試災難復原解決方案](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [柏克萊加州大學/史丹佛大學復原導向的運算專案](http://roc.cs.berkeley.edu/)
+ [什麼是 AWS Fault Injection Simulator？](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**相關影片：**
+ [AWS re:Invent 2018：適用於多區域主動-主動應用程式的架構模式 (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019：使用 AWS 的備份與還原和災難復原解決方案 (STG208)](https://youtu.be/7gNXfo5HZN8)
**相關範例：**
+ [AWS Well-Architected 實驗室 - 測試彈性](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# REL13-BP04 管理 DR 站點或區域的組態偏移
確保根據需要在 DR 站點或區域提供基礎設施、資料和組態。例如，檢查 AMI 和服務配額是否為最新版本。
AWS Config 會持續監控和記錄 AWS 資源組態。它可以偵測偏移，並觸發 [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 修正並引發警示。AWS CloudFormation 可額外偵測您已部署之堆疊中的偏移。
**常用的反模式：**
+ 當您在主要位置進行組態或基礎設施變更時，無法在復原位置進行更新。
+ 未考量主要和復原位置中潛在的限制 (例如服務差異)。
**建立此最佳實務的優勢：** 確保 DR 環境與現有環境一致，便可保證完整復原。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 確保您的交付管道同時交付到主要站點和備份站點。用於將應用程式部署到生產中的交付管道，應分發到所有指定的災難復原策略位置，包括開發和測試環境。
+ 啟用 AWS Config 追蹤潛在的偏移位置。使用 AWS Config 規則建立系統，以執行災難復原策略，並在發現偏移時產生提醒。
+ [依 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 偵測您的基礎設施。AWS CloudFormation 可以偵測 CloudFormation 範本指定項目與實際部署項目之間的偏移。
+ [AWS CloudFormation：在整個 CloudFormation 堆疊上偵測偏移](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
## 資源
**相關文件：**
+ [APN 合作夥伴：可以幫助災難復原的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS 架構部落格：災難復原系列](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS CloudFormation：在整個 CloudFormation 堆疊上偵測偏移](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
+ [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 上工作負載的災難復原：在雲端中復原 (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)
# REL13-BP05 自動化復原
使用 AWS 或第三方工具自動化系統復原，並將流量路由到 DR 站點或區域。
根據設定的運作狀態檢查，Elastic Load Balancing 和 AWS Auto Scaling 等 AWS 服務可將負載分散到運作狀態良好的可用區域，而 Amazon Route 5、AWS 和 Global Accelerator 等服務則可將負載路由到運作狀態良好的 AWS 區域。Amazon Route 53 應用程式復原控制器可協助您使用準備度檢查和路由控制功能，來管理和協調容錯移轉。這些功能會持續監控應用程式從失敗中復原的功能，以便您跨多個 AWS 區域、可用區域和內部部署來控制應用程式復原。
對於現有實體或虛擬資料中心或私有雲端上的工作負載， [AWS 彈性災難復原](https://aws.amazon.com/cloudendure-disaster-recovery/)(可透過 AWS Marketplace 取得) 可讓組織設定 AWS 的自動化災難復原策略。CloudEndure 也支援 AWS 中的跨區域/跨可用區域災難復原。
**常用的反模式：**
+ 實作相同的自動化容錯移轉和容錯回復會在失敗發生時導致翻動。
**建立此最佳實務的優勢：** 自動化復原可以消除手動錯誤的機會，減少您的復原時間。
**若未建立此最佳實務，暴露的風險等級為：** 中
## 實作指引
+ 自動化復原路徑。若復原時間較短，則人為判斷和行動無法用於可用性高的方案。系統應在每種情況下都能自動復原。
+ 使用 CloudEndure Disaster Recovery 進行自動化容錯移轉和容錯回復：CloudEndure Disaster Recovery 會持續將您的機器 (包括作業系統、系統狀態組態、資料庫、應用程式和檔案) 複寫至您的目標 AWS 帳戶和慣用區域中的低成本階段區域。發生災難時，您可以指示 CloudEndure Disaster Recovery 在數分鐘內自動啟動處於完全佈建狀態的數千部機器。
+ [執行災難復原容錯移轉和退回](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Performing_a_Disaster_Recovery_Failover/Performing_a_Disaster_Recovery_Failover.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
## 資源
**相關文件：**
+ [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 Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS 的 CloudEndure Disaster Recovery](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
+ [AWS 上工作負載的災難復原：在雲端中復原 (AWS 白皮書)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
**相關影片：**
+ [AWS re:Invent 2018：適用於多區域主動-主動應用程式的架構模式 (ARC209-R2)](https://youtu.be/2e29I3dA8o4)