# 灾难恢复（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 管理灾难恢复站点或区域的配置偏差](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_cn/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_cn/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 Architecture Blog: Disaster Recovery](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)
+ [Managing resiliency policies with 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: Architecture Patterns for Multi-Region Active-Active Applications](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）的灾难恢复策略可以缓解火灾、洪水和重大停电等灾难事件造成的影响。如果需要实施保护措施，为工作负载无法在给定 AWS 区域中运行这种不太可能发生的事件提供保护，您可以使用跨多个区域的灾难恢复策略。
在跨多个区域构建灾难恢复策略时，您应该选择以下某个策略。这些策略按成本和复杂性升序排列，按 RTO 和 RPO 降序排列。*恢复区域*指的是 AWS 区域，而不是用于工作负载的主要区域。
![\[图中显示了灾难恢复策略\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/reliability-pillar/images/disaster-recovery-strategies.png)
+ **备份和还原**（RPO 以小时为单位，RTO 为 24 小时或更短时间为单位）：将数据和应用程序备份到恢复区域。使用自动或连续备份可以实现时间点故障恢复（PITR），在某些情况下，可以将 RPO 降低到 5 分钟。在发生灾难的情况下，您将部署基础设施（使用基础设施即代码来减少 RTO）、部署代码并还原备份的数据，以便在恢复区域从灾难中恢复。
+ **指示灯**（RPO 以分钟为单位，RTO 以数十分钟为单位）：在恢复区域中预置核心工作负载基础设施的副本。将数据复制到恢复区域并在其中创建数据备份。支持数据复制和备份所需的资源（如数据库和对象存储）始终处于启用状态。其他元素（如应用程序服务器或无服务器计算）未部署，但可以在需要时使用必要的配置和应用程序代码创建。
+ **温备用**（RPO 以秒为单位，RTO 以分钟为单位）：保证在恢复区域中始终运行缩减但功能齐全版本的工作负载。业务关键型系统是完全重复且始终可用的系统，只是其队列的规模经过缩减。数据在恢复区域中复制并留存。在需要恢复时，系统会快速纵向扩展来处理生产负载。温备用的规模越大，RTO 和控制面板依赖度就越低。当完全扩展时，这称为*热备用*。
+ **多区域（多站点）主动-主动**（RPO 接近于零，RTO 可能为零）：工作负载部署到多个 AWS 区域，并且主动处理来自这些区域的流量。此策略要求您跨区域同步数据。必须避免或处理在两个不同区域副本中写入同一记录可能引起的冲突，因为这种情况很复杂。数据复制对于数据同步非常有用，并且可以防止某些类型的灾难，但是它不能防止数据损坏或破坏，除非您的解决方案还包含时间点故障恢复选项。
**注意**
指示灯和温备用之间的差异有时难以区分。两者都在恢复区域中包含一个环境，其中具有主区域资产的副本。区别在于，如果不先采取额外措施，指示灯无法处理请求，而温备用可以立即处理流量（容量级别降低）。指示灯将要求您启用服务器，可能需要部署额外的（非核心）基础设施并纵向扩展，而温备用只需要您纵向扩展（所有内容都已部署并运行）。根据 RTO 和 RPO 需求在两者之间进行选择。
如果需要考虑成本，并且希望实现与温备用策略中定义的类似 RPO 和 RTO 目标时，您可以考虑云原生解决方案（例如 AWS 弹性灾难恢复），此类解决方案会采用指示灯方法并提供改进的 RPO 和 RTO 目标。
**实施步骤**
1. **确定可满足此工作负载恢复要求的灾难恢复策略。**
选择灾难恢复策略是在减少停机时间和数据丢失（RTO 和 RPO）与策略实施的成本和复杂性之间进行权衡。应该避免实施比所需策略更严格的策略，因为这会产生不必要的成本。
例如，在下图中，企业已经确定了自己允许的最大 RTO 以及可在服务恢复策略上花费的费用限额。考虑到企业目标，指示灯或温备用这样的灾难恢复策略将同时满足 RTO 和成本标准。
![\[图中显示了根据 RTO 和成本选择灾难恢复策略\]](http://docs.aws.amazon.com/zh_cn/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. **查看如何实施所选灾难恢复策略的模式。**
这一步是了解如何实施所选策略。这些策略可以解释为使用多个 AWS 区域作为主要站点和恢复站点。不过，您也可以选择使用单个区域内的多个可用区作为灾难恢复策略，这将利用多个策略的元素。
在后续步骤中，您可以对特定的工作负载应用策略。
**备份和还原**
*备份和还原*是实施起来最简单的策略，但需要更多时间和工作来恢复工作负载，导致更高的 RTO 和 RPO。最好的做法是，始终备份数据并将数据备份复制到另一个站点（例如另一个 AWS 区域）。
![\[图中显示了备份和还原架构\]](http://docs.aws.amazon.com/zh_cn/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_cn/wellarchitected/latest/reliability-pillar/images/pilot-light-architecture.png)
有关此策略的更多详细信息，请参阅《[Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)》。
**温备用**
*温备用*方法涉及到确保在另一个区域中存在生产环境的规模缩减但功能齐全的副本。这种方法扩展了指示灯概念并减少了恢复时间，因为工作负载始终在另一个区域中运行。如果以全部容量部署恢复区域，这种方式就称为*热备用*。
![\[图中显示了温备用架构\]](http://docs.aws.amazon.com/zh_cn/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)可以提供运行时环境，以便这些环境准备好立即响应函数的调用。
有关此策略的更多详细信息，请参阅《[Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)》。
**多站点主动/主动**
作为*多站点主动/主动*策略的一部分，您可以在多个区域中同时运行工作负载。多站点主动/主动策略处理来自其部署到的所有区域的流量。客户可能会出于灾难恢复以外的原因选择此策略。此策略可以用于提高可用性，或者在向全球受众部署工作负载（使端点更靠近用户和/或部署针对该区域受众的本地化堆栈）时使用此策略。作为一种灾难恢复策略，如果工作负载在部署此策略的某个 AWS 区域中不能得到支持，那么该区域将被撤出，使用其余区域维持可用性。多站点主动/主动策略是灾难恢复策略中操作最复杂的策略，只有在业务要求需要时才应选择它。
![\[图中显示了多站点主动/主动架构\]](http://docs.aws.amazon.com/zh_cn/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 弹性灾难恢复 可以提供一种带来更多好处的替代方法。弹性灾难恢复可以提供类似于温备用方法的 RPO 和 RTO 目标，同时保持指示灯方法的低成本。弹性灾难恢复将数据从主区域复制到恢复区域，使用持续数据保护来实现以秒为单位的 RPO 和以分钟为单位的 RTO。在恢复区域中仅部署复制数据所需的资源，从而降低成本，类似于指示灯策略。使用弹性灾难恢复时，如果在失效转移或演练过程中启动，则服务会协调并编排计算资源的恢复。
![\[架构图说明了 AWS 弹性灾难恢复 的运作方式。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/reliability-pillar/images/drs-architecture.png)
**其他保护数据的实践**
对于所有这些策略，您还必须减轻数据灾难的影响。持续的数据复制可以防止某些类型的灾难，但它可能无法防止数据损坏或破坏，除非您的策略还包括存储数据的版本控制或用于时间点故障恢复的选项。除了副本之外，您还必须备份恢复站点中的复制数据以创建时间点备份。
**使用单个 AWS 区域内的多个可用区（AZ）**
使用单个区域内的多个可用区时，实施灾难恢复会用到上述策略的多个元素。首先，您必须使用多个可用区创建一个高可用性（HA）架构，如图 23 所示。此架构使用多站点主动/主动方法，因为 [Amazon EC2 实例](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones)和[弹性负载均衡器](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones)在多个可用区中部署了资源，主动处理请求。此架构还演示了热备用方法，如果主 [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) 实例出现故障（或可用区本身出现故障），则备用实例将提升为主实例。
![\[图中显示了多可用区架构\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/reliability-pillar/images/multi-az-architecture2.png)
除了这种高可用性架构，您还需要添加运行工作负载所需的所有数据的备份。这对于限制在单个区的数据尤其重要，例如 [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)。如果一个可用区发生故障，您需要将这些数据恢复到另一个可用区。如果可能，您还应该将数据备份复制到另一个 AWS 区域，提供另一层保护。
下面的博客文章中介绍了一种不太常见的单区域多可用区灾难恢复的替代方法：[Building highly resilient applications using Amazon Application Recovery Controller, Part 1: Single-Region stack](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/)。这里的策略是尽可能保持可用区之间的隔离，就像区域的运作方式一样。使用这种替代策略，您可以选择主动/主动或主动/被动方法。
**注意**
某些工作负载具有数据驻留法规要求。如果这适用于当前只有一个 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/)控制部署的堆栈处于活动状态还是备用状态。使用弹性灾难恢复时，服务会复制并编排应用程序配置和计算资源的还原。
所有灾难恢复策略都要求在 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 服务如何跨区域运行的信息，请参阅博客系列文章《[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 Global Database](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 全局数据库的现有复制拓扑。因此，主区域中以前的读/写实例将成为副本，并从恢复区域接收更新。
如果这不是自动执行的，则需要在主区域中重新建立数据库，作为恢复区域中数据库的副本。在许多情况下，这将涉及删除旧的主数据库，然后创建新的副本。
失效转移后，如果可以继续在恢复区域中运行，请考虑将此区域设为新的主区域。您仍然需要执行上述所有步骤，将以前的主区域变成恢复区域。有些组织会进行定期轮换，定期交换其主区域和恢复区域（例如每三个月一次）。
失效转移和失效自动恢复所需的所有步骤都应保存在行动手册中且可供所有团队成员使用，并定期接受审查。
使用弹性灾难恢复时，服务会协助编排并自动执行失效自动恢复流程。有关更多详细信息，请参阅 [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 Architecture Blog: Disaster Recovery](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)
+ [Build a serverless multi-region, active-active backend solution in an hour](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf)
+ [Multi-region serverless backend — reloaded](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: Configuring DNS Failover](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)
+ [What is Amazon Application Recovery Controller?](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: Get Started - 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: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Get Started with 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) 为灾难恢复策略实施和启动演练实例。AWS 弹性灾难恢复 可以高效地运行演练，帮助您为失效转移事件做好准备。您还可以使用弹性灾难恢复频繁地启动实例进行测试和演练，无需重定向流量。
## 资源
**相关文档：**
+ [APN 合作伙伴：可帮助进行灾难恢复的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Architecture Blog: Disaster Recovery](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)
+ [The Berkeley/Stanford recovery-oriented computing project](http://roc.cs.berkeley.edu/)
+ [What is AWS Fault Injection Simulator?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**相关视频：**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Backup-and-restore and disaster-recovery solutions with AWS](https://youtu.be/7gNXfo5HZN8)
# REL13-BP04 管理灾难恢复站点或区域的配置偏差
为了成功执行灾难恢复（DR）过程，一旦灾难恢复环境上线，工作负载就必须能够及时恢复正常操作，而不会丢失相关的功能或数据。要实现这一目标，务必在灾难恢复环境和主环境之间保持一致的基础设施、数据和配置。
**期望结果：**灾难恢复站点的配置和数据与主站点相当，这有助于在需要时进行快速而完整的恢复。
**常见反模式：**
+ 当对主位置进行更改时，您未能更新恢复位置，这导致配置过时，从而阻碍恢复工作。
+ 您未考虑潜在的限制，例如主位置和恢复位置之间的服务差异，这些限制可能会在失效转移期间导致意外故障。
+ 您依赖手动流程来更新和同步灾难恢复环境，这会增加人为错误和不一致的风险。
+ 您未能检测到配置偏差，这会导致在事件发生之前错误地感知灾难恢复站点就绪状态。
**建立此最佳实践的好处：**灾难恢复环境和主环境之间的一致性可显著提高事件发生后成功恢复的可能性，并降低恢复过程失败的风险。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
全面的配置管理和失效转移就绪方法有助于您验证灾难恢复站点是否持续更新，并准备好在主站点出现故障时进行接管。
要实现主环境和灾难恢复（DR）环境之间的一致性，请验证您的交付管道是否同时将应用程序分发到主站点和灾难恢复站点。在适当的评估期后推出对灾难恢复站点的更改（也称为*错开部署*），以检测主站点的问题，并在问题蔓延之前停止部署。实施监控以检测配置偏差，并跟踪环境中的更改和合规性。在灾难恢复站点中执行自动修复，以使其保持完全一致，并做好准备在发生事件时立即接管。
### 实施步骤
1. 验证灾难恢复区域包含成功执行灾难恢复计划所需的 AWS 服务和功能。
1. 使用基础设施即代码（IaC）。保持生产基础设施和应用程序配置模板的准确性，并定期将其应用于灾难恢复环境。[AWS CloudFormation](https://aws.amazon.com/cloudformation/) 可以检测 CloudFormation 模板指定的内容与实际部署内容之间的偏差。
1. 配置 CI/CD 管道来将应用程序和基础设施更新部署到所有环境，包括主站点和灾难恢复站点。诸如 [AWS CodePipeline](https://aws.amazon.com/codepipeline/) 等 CI/CD 解决方案可以自动执行部署过程，从而降低配置偏差的风险。
1. 在主环境和灾难恢复环境之间错开部署。这种方法支持在主环境中对更新进行初始部署和测试，这样可以在问题传播到灾难恢复站点之前，将其隔离在主站点中。这种方法可以防止同时将缺陷推送到生产和灾难恢复站点，并保持灾难恢复环境的完整性。
1. 持续监控主环境和灾难恢复环境中的资源配置。诸如 [AWS Config](https://aws.amazon.com/config/) 之类的解决方案有助于强制实施配置合规性并检测偏差，这有助于在不同环境中保持一致的配置。
1. 实施警报机制，以跟踪和通知任何配置偏差或数据复制中断或滞后。
1. 自动修复检测到的配置偏差。
1. 安排定期审计和合规性检查，以验证主配置和灾难恢复配置之间的持续一致性。定期审核可帮助您保持对既定规则的遵守，并确定需要解决的任何差异。
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: Architecture Patterns for Multi-Region Active-Active Applications (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/)
+ [Implement automatic drift remediation for AWS CloudFormation using Amazon CloudWatch and AWS Lambda](https://aws.amazon.com/blogs/mt/implement-automatic-drift-remediation-for-aws-cloudformation-using-amazon-cloudwatch-and-aws-lambda/)
+ [AWS Architecture Blog: Disaster Recovery](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 自动执行恢复
实施可靠、可观测、可重复且经过测试的自动化恢复机制，来降低故障的风险和业务影响。
**期望结果：**您已经为恢复流程实施了有据可查、标准化且经过全面测试的自动化工作流程。恢复自动化功能会自动纠正导致数据丢失或不可用（低风险）的小问题。您可以针对严重事件快速调用恢复流程，在恢复流程运行时观察补救行为，并在观测到危险情况或故障时结束这些流程。
**常见反模式：**
+ 您依赖于处于故障或已降级状态的组件或机制，作为恢复计划的一部分。
+ 恢复流程需要手动干预，例如控制台访问（也称为*单击操作*）。
+ 您在存在数据丢失或不可用高风险的情况下自动启动恢复过程。
+ 您没有包含一个机制来中止不起作用或带来额外风险的恢复过程（如*暗灯* 或*红色的大型停止按钮*）。
**建立此最佳实践的好处：**
+ 提高了恢复操作的可靠性、可预测性和一致性。
+ 能够实现要求更高的恢复目标，包括恢复时间目标（RTO）和恢复点目标（RPO）。
+ 降低了事件期间恢复失败的可能性。
+ 降低了与容易出现人为错误的手动恢复过程相关的故障风险。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
要实施自动恢复，您需要一种使用 AWS 服务和最佳实践的全面方法。首先，请确定工作负载中的关键组件和潜在故障点。开发自动化流程，无需人工干预即可从故障中恢复工作负载和数据。
使用基础设施即代码（IaC）原则开发恢复自动化功能。这使您的恢复环境与源环境保持一致，并支持对恢复过程进行版本控制。要编排复杂的恢复工作流程，可以考虑诸如 [AWS Systems Manager 自动化](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 管理灾难恢复站点或区域的配置偏差](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_config_drift.html)
**相关文档：**
+ [AWS Architecture Blog: Disaster Recovery](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)
+ [Orchestrate Disaster Recovery Automation using Amazon Route 53 ARC and 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/)
+ [Build AWS Systems Manager Automation runbooks using AWS CDK](https://aws.amazon.com/blogs/mtbuild-aws-systems-manager-automation-runbooks-using-aws-cdk/)
+ [AWS Marketplace: Products That Can Be Used for Disaster Recovery](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: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2022: AWS On Air ft. AWS Failback for AWS Elastic Disaster Recovery](https://youtu.be/Ok-vpV8b1Hs)