Amazon Route 53 应用程序恢复控制器的***实践

在灾难恢复 (DR) 场景中，通过使用简单的方法访问 AWS 和执行恢复任务，将系统依赖关系降至***。专门为 DR 任务创建 IAM 长期凭证，并将凭证安全地保存在本地物理保险箱或虚拟保险库中，以便在需要时访问。借助 IAM，您可以集中管理安全凭证，例如访问密钥和访问 AWS 资源的权限。对于非 DR 任务，我们建议您继续使用联合访问，使用AWS Single Sign-On等 AWS 服务.

要使用恢复集群数据平面 API 在 Route 53 ARC 中执行故障转移任务，您可以将 Route 53 ARC IAM 策略附加到您的 IAM 用户。要了解更多信息，请参阅Amazon Route 53 应用程序恢复控制器的基于身份的策略示例。

对于在故障转移机制中可能需要更改的 DNS 记录，尤其是经过健康检查的记录，使用较低的 TTL 值是合适的。将 TTL 设置为 60 或 120 秒是此方案的常见选择。

DNS TTL（生存时间）设置告诉 DNS 解析器在请求新记录之前缓存记录多长时间。当您选择 TTL 时，您需要在延迟和可靠性以及对变化的响应能力之间进行权衡。由于记录上的 TTL 较短，DNS 解析器会更快地注意到记录的更新，因为 TTL 指定它们必须更频繁地查询。

有关更多信息，请参阅Amazon Route 53 DNS ***实践中的为 DNS 记录选择 TTL 值。

我们建议您将 Route 53 ARC 区域集群终端节点的本地副本保存在书签中，或者在您用于重试终端节点的自动化代码中硬编码。在故障事件期间，您可能无法访问某些 API 操作，包括未托管在极其可靠的数据平面集群上的 Route 53 ARC API 操作。您可以使用 DescribeCluster API 操作列出 Route 53 ARC 集群的终端节点。

使用 Route 53 ARC 数据平面 API，使用 ListRoutingControls操作查看您的路由控制和状态，并使用UpdateRoutingControlState 操作更新路由控制状态以重定向流量以进行故障转移 。您可以使用 AWS CLI （如这些示例中所示） 或使用 AWS 开发工具包之一编写的代码。Route 53 ARC 通过数据平面中的 API 提供极高的可靠性，以对流量进行故障转移。我们建议使用 API 而不是在 AWS 管理控制台中更改路由控制状态。

连接到 Route 53 ARC 的区域集群端点之一以使用数据平面 API。如果端点不可用，请尝试连接到另一个集群端点。

如果安全规则阻止路由控制状态更新，您可以绕过它来进行更新和故障转移流量。有关详细信息，请参阅覆盖安全规则以重新路由流量。

您可以使用任何区域集群端点来获取或更新路由控制状态。我们建议您的系统准备好使用每个可用端点重试。我们建议您将对集群终端节点的 API 调用次数限制为每秒不超过 3 次 (3 TPS)。有关将代码示例与 AWS 开发工具包一起使用的信息，包括按顺序尝试集群终端节点的示例，请参阅使用 AWS 开发工具包的应用程序恢复控制器的代码示例。

使用 Route 53 ARC 路由控制定期测试故障转移，以便从主应用程序堆栈故障转移到辅助应用程序堆栈。请务必确保您添加的 Route 53 ARC 结构与堆栈中的正确资源对齐，并且一切都按您的预期工作。您应该在为您的环境设置 Route 53 ARC 之后对此进行测试，并继续定期测试，以便在您遇到需要辅助系统快速启动和运行以避免故障情况之前准备好您的故障转移环境您的用户的停机时间。

在 Amazon EventBridge 中设置一条规则，以便在就绪检查状态更改时发送通知，例如从READY到NOT READY。收到通知后，您可以调查并解决问题，以确保您的应用程序和资源在您预期的情况下已准备好进行故障转移。

您可以设置 EventBridge 规则以发送多个就绪性检查状态更改的通知，包括针对您的恢复组（针对您的应用程序）、针对一个单元（例如 AWS 区域）或针对资源集的就绪性检查。

有关更多信息，请参阅将 Route 53 ARC 与 Amazon EventBridge 结合使用。