云原生工作负载的灾难恢复
考虑您的云原生工作负载如何与灾难恢复目标保持一致。AWS 在全球区域中提供多个可用区。许多使用 AWS 云的企业会调整其工作负载架构和灾难恢复目标，以抵御可用区的损失。Well-Architected AWS 框架中的可靠性支柱
但是，实际上，您可能会发现无法为所有组件建立冗余、主动和自动化的架构。检查架构的每一层，确定实现目标所需的灾难恢复流程。这可能因工作负载而异，架构和服务要求也不同。本指南涵盖适用于 Amazon EC2 的注意事项和选项。对于其他 AWS 服务，您可以参考 AWS 文档以确定高可用性和灾难恢复选项。
单个可用区中的 Amazon EC2 灾难恢复
尝试设计您的工作负载，以积极支持和服务来自多个可用区的客户。您可以使用 Amazon EC2 Auto Scaling 和 Elastic Load Balancing 为 Amazon EC2 和其他服务实现多可用区服务器架构。
如果您的架构中有无法进行负载平衡的 EC2 实例，并且在任何给定时刻只能运行一个实例，则可以使用以下任一选项。
-
创建一个自动扩缩组，其最小、最大和所需大小均为 1，并针对多个可用区进行配置。创建一个 AMI，用于在实例出现故障时替换实例。请务必定义正确的自动化和配置，以便可以自动配置来自 AMI 的新配置实例并提供服务。创建一个指向 Auto Scaling 组并为多个可用区配置的负载均衡器。或者，创建一个指向负载均衡器终端节点的 Amazon Route 53 别名。
-
为您的活动实例创建 Route 53 记录，并使用此记录让您的客户端进行连接。创建一个脚本，该脚本为您的活动实例创建新 AMI，并使用该 AMI 在单独的可用区中配置处于停止状态的新 EC2 实例。将脚本配置为定期运行并终止先前已停止的实例。如果可用区出现故障，请在备用可用区启动备份实例。然后更新 Route 53 记录以指向这个新实例。
通过模拟解决方案旨在防范的故障，对解决方案进行全面测试。另外，请考虑您的灾难恢复解决方案在工作负载架构变化时需要的更新。
Amazon EC2 区域故障中的灾难恢复
对可用性要求非常高的客户（例如不能容忍任何停机时间的任务关键型应用程序）可以跨多个区域使用 AWS，以增强区域层面的问题应对能力。客户必须仔细权衡制定和维护多区域灾难恢复计划所需的复杂性、成本和精力与好处。AWS 提供支持多区域架构的功能，以实现全球可用性、故障转移和灾难恢复。本指南涵盖了一些特定于 Amazon EC2 备份和恢复的可用功能。
AWS AMI 和 Amazon EBS 快照是区域资源，可用于在单个区域内配置新实例。但是，您可以将快照和 AMI 复制到另一个区域，然后使用它们在该区域配置新实例。为了支持区域故障灾难恢复计划，您可以自动将 AMI 和快照复制到其他区域。AWS Backup 及 Amazon Data Lifecycle Manager 支持将跨区域复制作为备份配置的一部分。
AWS Elastic Disaster Recovery 可用于自动将一个区域中的 Amazon EC2 服务器持续复制到另一个灾难恢复区域。弹性灾难恢复可以简化您的多区域灾难恢复方法，并通过演练帮助您定期测试跨区域 Amazon EC2 灾难恢复计划。当备份和恢复无法实现您的 RTO 和 RPO 目标时，弹性灾难恢复可以提供帮助。弹性灾难恢复可以帮助您将 RTO 降低到几分钟，将 RPO 降低到亚秒级。
无论使用哪种解决方案，都必须确定在停机时要使用的配置、故障转移和故障恢复流程。您可以将 Route 53 与运行状况检查和域名系统故障转移配合使用，以帮助支持您的解决方案。
