本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
灾难恢复
Amazon AppStream 2.0 在多达三个可用区域中内置了冗余功能。这意味着，如果用户在已降级的可用区中有一个活动会话，他们只需断开连接并重新连接即可，就能在一个正常的可用区内保留会话，前提是您有足够的容量。虽然这在区域内提供了高可用性，但如果服务在区域层面遇到问题，则无法提供灾难恢复解决方案。
要为您的 WorkSpaces 应用程序用户提供灾难恢复计划，您首先需要在辅助区域构建 WorkSpaces 应用程序环境。从设计角度来看，此环境应与您的本地环境建立冗余连接（如果适用），并且不应依赖主区域。例如，如果您的 WorkSpaces 应用程序队列已加入域，则应在次要区域中配置其他域控制器，并配置了站点和服务。从 WorkSpaces 应用程序的角度来看，此环境应包含与主区域相同的队列和堆栈设置。实例集本身应运行相同的基础映像，该映像可以通过控制台或以编程方式复制到您的辅助区域。如果在您的应用程序会话中运行的 WorkSpaces 应用程序具有与您的主区域相关的后端依赖关系，则该依赖关系也应具有区域冗余，以确保在主区域出现故障时用户仍然可以访问应用程序的后端。您在目标区域的服务级别限制应与您的主区域相匹配。
身份路由
在灾难恢复场景中，有两种不同的方法可以实现对应用程序的访问。总体而言，这两种方法的不同之处在于如何将用户定向到失效转移区域。第一种方法是使用您的 IdP 中的单个 WorkSpaces 应用程序应用程序配置执行的，第二种方法是使用两个单独的应用程序配置。
方法 1：更改应用程序的中继状态
当用户从身份提供商 (IdP) 登录 WorkSpaces 应用程序时，在进行身份验证后，他们会被中继到一个特定 URL，该网址与他们打算访问的区域和堆栈对齐。有关中继状态 URL 的更多信息，请参阅《Amazon WorkSpaces 应用程序管理指南》。管理员可以配置跨区域堆栈，该堆栈建立在与主区域相同的 WorkSpaces 应用程序映像上，供用户进行故障切换。管理员只需更新中继状态 URL，使其指向失效转移堆栈，即可控制此失效转移。要使此方法正常运行，需要让关联的 IAM 策略允许访问两个堆栈（主堆栈和失效转移堆栈）。有关如何配置这些 IAM 策略的更多详细信息，请参阅以下示例策略。
方法 2：在 IdP 中配置两个 WorkSpaces 应用程序应用程序
此方法要求管理员为 IdP 中的应用程序构建两个单独的 WorkSpaces 应用程序。然后，他们可以同时展示两个应用程序并让用户选择去哪里，或者他们 lock/hide 是一个应用程序，直到需要进行故障切换。这种方法更适合让全球用户经常四处走动的使用案例。这些用户应该从最近的端点进行流式传输，因此，分配两个应用程序可以让他们选择为最近的区域配置的应用程序。这也可以自动完成，有关更多信息，请参阅此博客文章
存储持久性
在利用 WorkSpaces 应用程序中包含的数据持久性功能（例如应用程序持久性和主文件夹同步）时，您需要将这些数据复制到故障转移区域。这些功能将永久数据存储在给定 WorkSpaces 应用程序区域的 Amazon S3 存储桶中。要使数据跨区域保存，您需要将源存储桶上的所有更改复制到故障转移区域 WorkSpaces 应用程序存储桶。这可以通过原生 Amazon S3 功能来完成，例如 Amazon S3 跨区域复制。每个用户的持久性数据将存储在经过哈希处理的用户名的文件夹下。由于用户名将统一跨区域进行哈希处理，因此只需复制数据即可确保数据在辅助区域中持久保存。有关 WorkSpaces 应用程序使用的 Amazon S3 存储桶的更多信息，请参阅本指南。
