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