云中的灾难恢复选项
从低成本、低复杂性的制作备份到使用多个活动区域的较复杂策略，可在 AWS 中使用的灾难恢复策略大致分为四种方法。定期测试灾难恢复策略至关重要，这样您就有信心在必要时启用该策略。
图 6 – 灾难恢复策略
对于架构完善
备份与还原
备份与还原是缓解数据丢失或损坏后果的合适方法。此方法还可用于通过将数据复制到其他 AWS 区域来缓解区域性灾难，或者减轻部署到单个可用区的工作负载的冗余不足问题。除数据外，您还必须在恢复区域中重新部署基础设施、配置和应用程序代码。为确保快速重新部署基础设施而不出错，应始终使用基础设施即代码（IaC）进行部署，IaC 使用 AWS CloudFormation
图 7 – 备份与还原架构
AWS 服务
您的工作负载数据需要定期运行或持续运行的备份策略。运行备份的频率将决定可实现的恢复点（应与您的 RPO 保持一致）。备份还应提供一种方法，以还原到制作备份的时间点。可通过以下服务和资源制作具有时间点恢复功能的备份：
对于 Amazon Simple Storage Service（Amazon S3），您可以使用 Amazon S3 跨区域复制（CRR）
AWS Backup
AWS Backup 支持跨区域复制备份，例如复制到灾难恢复区域。
作为 Amazon S3 数据的额外灾难恢复策略，请启用 S3 对象版本控制。对象版本控制通过在执行删除或修改操作之前保留原始版本，来保护 S3 中的数据免受这些操作的影响。对象版本控制可以有效缓解人为错误类型的灾难。如果您使用 S3 复制将数据备份到灾难恢复区域，则默认情况下，在源存储桶中删除对象时，Amazon S3 仅在源存储桶中添加删除标记。此方法可保护灾难恢复区域中的数据不受源区域中恶意删除的影响。
除了数据之外，您还必须备份重新部署工作负载和实现恢复时间目标（RTO）所需的配置和基础设施。AWS CloudFormation
故障转移时必须还原灾难恢复区域中作为备份存储的任何数据。AWS Backup 提供还原功能，但目前未启用计划还原或自动还原。您可以使用 AWS SDK 调用适用于 AWS Backup 的 API，以实施到灾难恢复区域的自动还原。您可以将其设置为定期重复的任务，也可以在每次备份完成时触发还原。下图显示了使用 Amazon Simple Notification Service（Amazon SNS）
图 8 – 还原和测试备份
注意
您的备份策略必须包括测试备份。有关详细信息，请参阅测试灾难恢复部分。请参阅 AWS Well-Architected Lab：测试数据的备份与还原
Pilot light
利用 Pilot Light 方法，您可以将数据从一个区域复制到另一个区域，并预置核心工作负载基础设施的副本。支持数据复制和备份所需的资源（如数据库和对象存储）始终处于开启状态。其他元素（例如应用程序服务器）加载了应用程序代码和配置，处于关闭状态，仅在测试期间或调用灾难恢复故障转移时使用。不同于备份与还原方法，您的核心基础设施始终可用，而且您始终可以选择通过打开和横向扩展应用程序服务器来快速预置完整的生产环境。
图 9 – Pilot Light 架构
Pilot Light 方法通过尽可能地减少活动资源来尽可能地降低灾难恢复的持续成本，并简化灾难发生时的恢复操作，因为核心基础设施要求均已就位。此恢复选项要求您更改部署方法。您需要对每个区域的核心基础设施进行更改，并将工作负载（配置、代码）更改同时部署到每个区域。通过自动部署以及使用基础设施即代码（IaC）跨多个账户和区域部署基础设施（在主区域完整部署基础设施，在灾难恢复区域缩减/关闭基础设施部署），可以简化此步骤。建议您在每个区域使用不同的账户，以提供最高级别的资源和安全隔离（在针对凭证被盗也制定了灾难恢复计划的情况下）。
使用这种方法，您还必须缓解数据灾难。连续数据复制可以保护您免受某些类型灾难的影响，但它可能无法防范数据损坏或销毁，除非您的策略还包括存储数据的版本控制或时间点恢复选项。您可以在灾难区域中备份复制的数据，以便在同一区域中创建时间点备份。
AWS 服务
除了使用备份与还原部分介绍的 AWS 服务创建时间点备份之外，制定 Pilot Light 策略时还要考虑以下服务。
对于 Pilot Light，将数据连续复制到灾难恢复区域中的实时数据库和数据存储是实现低 RPO 的最佳方法（与前面讨论的时间点备份一起使用时）。AWS 使用以下服务和资源为数据提供连续、跨区域的异步数据复制：
通过连续复制，您的数据版本几乎可以立即在灾难恢复区域中使用。可以使用服务功能（例如针对 S3 对象的 S3 复制时间控制（S3 RTC））和 Amazon Aurora Global Database 的管理功能监控实际复制时间。
当调用故障转移以从灾难恢复区域运行读/写负载时，必须将 RDS 只读副本提升为主实例。对于 Aurora 以外的数据库实例，该过程需要几分钟才能完成，并且需要重启。对于跨区域复制（CRR）和通过 RDS 实现故障转移，使用 Amazon Aurora Global Database 具有多项优势。Global Database 使用专用基础设施，使您的数据库完全可用于为应用程序提供服务，并且可以复制到一个辅助区域，延迟通常不到一秒（AWS 区域内的延迟远少于 100 毫秒）。借助 Amazon Aurora Global Database，如果您的主区域性能下降或中断，即使在区域完全中断的情况下，您也可以在不到 1 分钟的时间内提升其中一个辅助区域以承担读/写责任。提升可以自动进行，并且不会重启。
必须在灾难恢复区域中部署核心工作负载基础设施的缩减版本（资源较少或较小）。使用 AWS CloudFormation，您可以定义基础设施，并在 AWS 账户和 AWS 区域之间一致地进行部署。AWS CloudFormation 使用预定义的虚拟参数来标识 AWS 账户及其部署所在的 AWS 区域。因此，您可以在 CloudFormation 模板中实施条件逻辑，以便在灾难恢复区域中仅部署缩减版本的基础设施。对于 EC2 实例部署，Amazon Machine Image（AMI）提供硬件配置和已安装软件等信息。您可以实施 Image Builder 管道来创建所需的 AMI，然后将其复制到主区域和备份区域。这有助于确保在发生灾难事件时，这些黄金 AMI 拥有在新区域重新部署或横向扩展工作负载所需的一切。Amazon EC2 实例以缩减配置（实例少于主区域中的实例）进行部署。您可以使用休眠将 EC2 实例置于停止状态，在这种状态下，您无需支付 EC2 费用，只需为使用的存储空间付费。要启动 EC2 实例，您可以使用 AWS 命令行界面（CLI）
对于活动/备用配置（如 Pilot Light），所有流量最初都会流向主区域，如果主区域不再可用，则会切换到灾难恢复区域。使用 AWS 服务可以考虑两种流量管理选项。第一种选项是使用 Amazon Route 53
第二种选项是使用 AWS Global Accelerator
CloudEndure Disaster Recovery
CloudEndure Disaster Recovery
图 10 – CloudEndure Disaster Recovery 架构
温备用
温备用方法包括确保在另一个区域中有一个缩减但功能齐全的生产环境副本。这种方法扩展了 Pilot Light 的概念，缩短了恢复时间，因为您的工作负载在另一个区域中始终可用。此方法还使您能够更轻松地执行测试或实施连续测试，从而增强从灾难中恢复的信心。
图 11 – 温备用架构
注意：Pilot Light 和温备用之间的差异有时难以区分。两者都包含灾难恢复区域中的环境，该环境包含主区域资产的副本。区别在于，如果不首先执行其他操作，Pilot Light 就无法处理请求，而温备用可以立即处理流量（在产能降低的情况下）。Pilot Light 方法要求您“打开”服务器，可能还需要部署其他（非核心）基础设施并纵向扩展；而温备用只需纵向扩展（一切均已部署并正在运行）。请结合您的 RTO 和 RPO 需求，帮助您在这些方法之间进行选择。
AWS 服务
备份与还原和 Pilot Light 涵盖的所有 AWS 服务也用于温备用，进行数据备份、数据复制、活动/备用流量路由，以及部署包括 EC2 实例在内的基础设施。
AWS Auto Scaling
多站点主动/主动
作为多站点主动/主动或热备用主动/被动策略的一部分，您可以在多个区域同时运行工作负载。多站点主动/主动服务于它所部署的所有区域的流量，而热备用只服务于单个区域的流量，其他区域仅用于灾难恢复。通过多站点主动/主动方法，用户可以在部署该方法的任何区域中访问工作负载。这种方法是最复杂且成本最高的灾难恢复方法，但通过正确的技术选择和实施，它可以将大多数灾难的恢复时间缩短至接近零（然而，数据损坏可能需要依赖备份，这通常会导致恢复点不为零）。热备用采用主动/被动配置，用户只定向到单个区域，并且灾难恢复区域不占用流量。大多数客户发现，如果他们要在辅助区域中建立一个完整的环境，那么采用主动/主动配置行得通。或者，如果您不想同时使用这两个区域来处理用户流量，那么可以采用温备用，这是一种更经济、操作上不那么复杂的方法。
图 12 – 多站点主动/主动架构（将一条“活动”路径更改为“非活动”以实现热备用）
使用多站点主动/主动时，由于工作负载在一个以上的区域中运行，这种情况下不存在故障转移的问题。在这种情况下，灾难恢复测试将侧重于工作负载对区域损失的反应：流量是否从发生故障的区域移出？ 其他区域能否处理所有流量？ 还需要测试数据灾难。仍然需要备份和恢复，并应定期测试。还应注意的是，涉及数据损坏、删除或模糊处理的数据灾难的恢复时间将始终大于零，并且恢复点将始终位于发现灾难之前的某个时间点。如果需要增加多站点主动/主动（或热备用）方法的复杂性和成本，以保持接近零的恢复时间，则应做出更多努力来维护安全并防止人为错误，以减轻人为灾难。
AWS 服务
备份与还原、Pilot Light 和温备用涵盖的所有 AWS 服务也在此处用于时间点数据备份、数据复制、主动/主动流量路由以及基础设施（包括 EC2 实例）的部署和扩展。
对于前面讨论的主动/被动场景（Pilot Light 和温备用），Amazon Route 53 和 AWS Global Accelerator 均可用于将网络流量路由到活动区域。对于此处的主动/主动策略，这两项服务还允许定义确定哪些用户转到哪个活动区域终端节点的策略。借助 AWS Global Accelerator，您可以设置流量拨盘，以控制定向到每个应用程序终端节点的流量百分比。Amazon Route 53 支持这种百分比方法，还支持多种其他可用策略，包括地理位置临近度策略和基于延迟的策略。Global Accelerator 会自动利用广泛的 AWS 边缘服务器网络，尽快将流量引导至 AWS 网络主干，从而降低请求延迟。
使用此策略进行数据复制可实现接近零的 RPO。AWS 服务（例如 Amazon Aurora Global Database）使用专用基础设施，使您的数据库完全可用于为应用程序提供服务，并且可以复制到一个辅助区域，延迟时间通常不到一秒。对于主动/被动策略，只对主区域执行写入操作。主动/主动的区别在于设计如何处理对每个活动区域的写入。通常将用户读取设计为从离他们最近的区域提供服务，称为本地读取。对于写入，有以下几种选项：
-
全局写入策略会将所有写入操作路由到单个区域。如果该区域出现故障，将提升另一个区域以接受写入。Aurora Global Database 非常适合全局写入，因为它支持跨区域同步只读副本，而且您可以在不到 1 分钟的时间内提升其中一个辅助区域以承担读/写责任。
-
局部写入策略会将写入路由到最近的区域（就像读取操作一样）。Amazon DynamoDB 全局表支持这样的策略，允许从部署全局表的每个区域进行读取和写入。Amazon DynamoDB 全局表在并发更新之间使用以最后写入者为准原则。
-
分区写入策略根据分区键（如用户 ID）将写入操作分配到特定区域，以避免写入冲突。双向配置的
Amazon S3 复制可用于这种情况，目前支持在两个区域之间进行复制。实施此方法时，请确保在存储桶 A 和 B 上均启用副本修改同步，以复制副本元数据更改，例如对象访问控制列表（ACL）、对象标签或已复制对象上的对象锁定。您还可以配置是否在活动区域中的存储桶之间复制删除标记。除了复制之外，您的策略还必须包括时间点备份，以防止发生数据损坏或数据销毁事件。
AWS CloudFormation 是一款功能强大的工具，可在多个 AWS 区域的 AWS 账户之间强制实施一致部署的基础设施。AWS CloudFormation StackSets 扩展了此功能，您只需一次操作即可跨多个账户和区域创建、更新或删除 CloudFormation 堆栈。尽管 AWS CloudFormation 使用 YAML 或 JSON 定义基础设施即代码，但 AWS Cloud Development Kit (AWS CDK)
