[SEO 副标题]
本指导介绍了如何为 Amazon Aurora 部署全面的灾难恢复（DR）解决方案。不同的业务需求需要采用不同的方法来实现 DR 目标，而寻找能够满足恢复点目标（RPO）和恢复时间目标（RTO）的最佳选择时，可能让人无从下手。本指导将评估在制定 DR 计划的数据库部分时最常用的路线。通过将数据库资源扩展到辅助 AWS 区域并使用 AWS Backup 或 Aurora 全球数据库，您可以在发生灾难时更轻松地还原数据，从而最大限度地减少业务中断。
请注意：[免责声明]
架构图
-
复制数据
-
备份数据
-
复制数据
-
此架构图显示了如何实施 Aurora 全球数据库以便将数据复制到辅助区域。
单击可放大
步骤 1
先决条件：本指导要求现有 Amazon Aurora 区域集群。应用程序可以运行在 Amazon Elastic Compute Cloud（Amazon EC2）、Amazon Elastic Kubernetes Service（Amazon EKS）、Amazon Elastic Container Service（Amazon ECS）或者您选择的其他服务上。本指导假设您在跨多个可用区（AZ）的虚拟私有云（VPC）中使用了 Amazon EC2 实例。您可以使用默认的 AWS Key Management Service（AWS KMS）或者客户管理的密钥（CMK）对 Aurora 集群进行加密。
步骤 2
AWS CloudFormation 会创建资源，包括在主要 AWS 区域中创建 Aurora 只读副本（如果此副本尚不存在），以及在辅助区域中创建带有读取器实例的 Aurora 全球数据库。在这两个区域中部署 Amazon CloudWatch 控制面板、Amazon Simple Notification Service（Amazon SNS）主题、AWS Lambda 函数和 Amazon EventBridge 规则。步骤 3
在主要区域和辅助区域中配置 CloudWatch 控制面板，以监控与 Aurora 相关的关键指标以及复制状态。步骤 4
在这两个区域中创建 CloudWatch 警报，以通过 Amazon SNS 主题为 AuroraGlobalDBReplicationLag 指标和通知生成警报。步骤 5
为计划的切换和意外的失效转移配置 EventBridge 规则。当发生一个事件时，此规则会在两个区域中使用 Amazon SNS 发送通知并调用 Lambda 函数。步骤 6
Lambda 函数提供了一个框架，用来在失效转移事件期间添加任何其他功能。例如：- 在失效转移事件期间，您可以配置应用程序，以便在新提升的区域中使用 Amazon Route 53，这样，在此事件期间就无需对应用程序进行任何配置。
- 您可以配置应用程序，以便在发生数据库失效转移事件之后重新启动 Amazon EC2 实例或者 Amazon EKS 集群中的应用程序部署容器组（pod）。
步骤 1
先决条件：本指导要求现有 Amazon Aurora 区域集群。应用程序可以运行在 Amazon Elastic Compute Cloud（Amazon EC2）、Amazon Elastic Kubernetes Service（Amazon EKS）、Amazon Elastic Container Service（Amazon ECS）或者您选择的其他服务上。本指导假设您在跨多个可用区（AZ）的虚拟私有云（VPC）中使用了 Amazon EC2 实例。您可以使用默认的 AWS Key Management Service（AWS KMS）或者客户管理的密钥（CMK）对 Aurora 集群进行加密。
步骤 2
AWS CloudFormation 会创建资源，包括在主要 AWS 区域中创建 Aurora 只读副本（如果此副本尚不存在），以及在辅助区域中创建带有读取器实例的 Aurora 全球数据库。在这两个区域中部署 Amazon CloudWatch 控制面板、Amazon Simple Notification Service（Amazon SNS）主题、AWS Lambda 函数和 Amazon EventBridge 规则。步骤 3
在主要区域和辅助区域中配置 CloudWatch 控制面板，以监控与 Aurora 相关的关键指标以及复制状态。步骤 4
在这两个区域中创建 CloudWatch 警报，以通过 Amazon SNS 主题为 AuroraGlobalDBReplicationLag 指标和通知生成警报。步骤 5
为计划的切换和意外的失效转移配置 EventBridge 规则。当发生一个事件时，此规则会在两个区域中使用 Amazon SNS 发送通知并调用 Lambda 函数。步骤 6
Lambda 函数提供了一个框架，用来在失效转移事件期间添加任何其他功能。例如：- 在失效转移事件期间，您可以配置应用程序，以便在新提升的区域中使用 Amazon Route 53，这样，在此事件期间就无需对应用程序进行任何配置。
- 您可以配置应用程序，以便在发生数据库失效转移事件之后重新启动 Amazon EC2 实例或者 Amazon EKS 集群中的应用程序部署容器组（pod）。
-
备份数据
-
此架构图显示了如何使用 AWS Backup 将您的 Amazon Aurora 数据库自动备份到另一个区域和/或另一个账户。
单击可放大
步骤 1
要在两个账户之间建立跨账户 AWS Backup，AWS Organizations 内部必须已经存在一个组织结构：账户 A，用作生产账户或“源”账户，账户 B，用作中央备份账户或“目标”账户。值得注意的是，本指导提供了灵活性，可包括多个目标账户。步骤 2
使用在源账户与目标账户之间共享的 CMK，对源账户中的现有 Aurora 集群进行加密。还应对集群进行适当标记，以使解决方案能够确定所需的备份资源。步骤 3
使用 CloudFormation 在您的源 AWS 账户和区域与目标 AWS 账户和区域中部署解决方案资源。所需的 CloudFormation 堆栈是作为此解决方案的一部分提供的。步骤 4
根据您在部署解决方案时提供的时间表，生产账户的区域 A 中的 Aurora 集群由 AWS Backup 提供支持。将备份存储在使用 AWS KMS CMK 加密的 AWS Backup 文件库中。步骤 5
AWS Backup 将备份复制到跨账户（即目标账户），并将其存储在账户 B 区域 A 的备份文件库中。使用 CloudFormation 创建的 CMK 对备份文件库进行加密。步骤 6
完成跨账户备份复制之后，源账户中的 EventBridge 规则将“备份复制完成”通知转发给目标账户事件总线（账户 B 区域 A）。步骤 7
区域 A 中的目标账户中的 EventBridge 规则将通知标识为传入事件。步骤 8
目标账户收到事件之后，EventBridge 规则调用一个 Lambda 函数，以便最终将备份复制到所需的目的地（账户 B 区域 B），并将其存储在区域 B 中的 AWS Backup 文件库中。步骤 9
Aurora 集群的备份现在存在于区域 B 的目标账户中，并存储在区域 B 的 AWS Backup 文件库中。使用 AWS KMS CMK 对备份文件库进行加密。此备份可用来还原 Aurora 数据库。步骤 1
要在两个账户之间建立跨账户 AWS Backup，AWS Organizations 内部必须已经存在一个组织结构：账户 A，用作生产账户或“源”账户，账户 B，用作中央备份账户或“目标”账户。值得注意的是，本指导提供了灵活性，可包括多个目标账户。步骤 2
使用在源账户与目标账户之间共享的 CMK，对源账户中的现有 Aurora 集群进行加密。还应对集群进行适当标记，以使解决方案能够确定所需的备份资源。步骤 3
使用 CloudFormation 在您的源 AWS 账户和区域与目标 AWS 账户和区域中部署解决方案资源。所需的 CloudFormation 堆栈是作为此解决方案的一部分提供的。步骤 4
根据您在部署解决方案时提供的时间表，生产账户的区域 A 中的 Aurora 集群由 AWS Backup 提供支持。将备份存储在使用 AWS KMS CMK 加密的 AWS Backup 文件库中。步骤 5
AWS Backup 将备份复制到跨账户（即目标账户），并将其存储在账户 B 区域 A 的备份文件库中。使用 CloudFormation 创建的 CMK 对备份文件库进行加密。步骤 6
完成跨账户备份复制之后，源账户中的 EventBridge 规则将“备份复制完成”通知转发给目标账户事件总线（账户 B 区域 A）。步骤 7
区域 A 中的目标账户中的 EventBridge 规则将通知标识为传入事件。步骤 8
目标账户收到事件之后，EventBridge 规则调用一个 Lambda 函数，以便最终将备份复制到所需的目的地（账户 B 区域 B），并将其存储在区域 B 中的 AWS Backup 文件库中。步骤 9
Aurora 集群的备份现在存在于区域 B 的目标账户中，并存储在区域 B 的 AWS Backup 文件库中。使用 AWS KMS CMK 对备份文件库进行加密。此备份可用来还原 Aurora 数据库。
Well-Architected 支柱
当您在云中构建系统时，AWS Well-Architected Framework 可以帮助您了解所做决策的利弊。框架的六大支柱使您能够学习设计和操作可靠、安全、高效、经济高效且可持续的系统的架构最佳实践。使用 AWS 管理控制台中免费提供的 AWS Well-Architected Tool，您可以通过回答每个支柱的一组问题，根据这些最佳实践来检查您的工作负载。
上面的架构图是按照 Well-Architected 最佳实践创建的解决方案示例。要做到完全的良好架构，您应该遵循尽可能多的 Well-Architected 最佳实践。
-
卓越运营阅读《卓越运营》白皮书
使用 Aurora，您可以根据您的 RPO 和 RTO 需求自定义 DR 方案，以便在灾难事件期间保持运营连续性。 CloudWatch 和 AWS CloudTrail 可帮助跟踪和审查日志和信息。通过提高运营可见性，这些服务可实现快速、有效的错误审查和事件响应。
-
安全性阅读《安全性》白皮书
本指导使用 AWS Identity and Access Management（IAM）实施最低权限模型，以限制对资源的访问权限。私有资源受基于 IAM 身份的策略保护，可提供更高的安全性。此外，它还使用 CloudFormation 中由 AWS 管理的角色来控制访问权限。AWS KMS 提供了默认加密以及使用自定义密钥保护数据的选项。Aurora 中的加密数据库集群对底层存储、备份、副本和快照进行加密，以提供一层额外的数据保护，从而帮助您满足合规性要求。
-
可靠性阅读《可靠性》白皮书
Aurora 利用跨多个可用区的复制功能来保持高可用性，从而支持数据弹性。Amazon Simple Storage Service（Amazon S3）为 Aurora 快照和 AWS Backup 数据等关键数据提供持久存储。CloudFormation 可自动部署资源，并在发生故障时进行回滚。CloudWatch 控制面板和 Amazon SNS 通知支持监控和警报，AWS Backup 有助于对 Aurora 数据库执行备份和还原操作，所有这些都为极其可靠的架构做出了贡献。
-
性能效率阅读《性能效率》白皮书
本指导利用精选的服务来增强性能。Aurora 提供了基于低延迟存储的复制功能，Aurora 全球数据库提供了跨区域复制功能，可帮助您最大限度地减少对工作负载性能的影响，同时在发生故障时保持数据可用性。此外，使用 CloudFormation，您可以自定义值，以满足服务水平协议以及 RPO 和 RTO 要求。最后，AWS Backup 利用 Lambda 和 EventBridge 实现可扩展的备份频率，使您能够根据业务需求进行优化。
-
成本优化阅读《成本优化》白皮书
Aurora 全球数据库和 AWS Backup 提供按实际使用量付费模式，可帮助您避免维护开销。您还可以为 Aurora 全球数据库选择无头配置，从而降低存储以及复制的 I/O 的成本。此外，AWS Backup 还允许调整配置，例如保留期，以根据您的恢复目标优化成本。使用这些服务之后，您可以减少不必要的开支，同时保持数据的完整性和可用性。
-
可持续性阅读《可持续性》白皮书
本指导中的服务可根据工作负载需求来扩展资源，从而帮助提高可持续性。Aurora 支持动态调整存储空间大小，以实现最佳资源利用率以及最大限度地减少不必要的消耗。Aurora 全球数据库跨区域复制这些动态更改，以保持一致性。此外，AWS Backup 还提供增量备份和持续备份，从而减少数据冗余以及优化备份效率。通过将本指导与 Aurora 无服务器 v2 集群结合使用，您可以增强容量调整、根据应用程序需求调整资源以及最大限度地减少浪费。
实施资源
提供了在 AWS 账户中进行实验和使用的详细指南。构建指南的每个阶段（包括部署、使用和清理）都将被检查，以便为部署做好准备。
示例代码为起点。它经过行业验证，是规范性但不是决定性的，可以帮助您开始。
免责声明
示例代码；软件库；命令行工具；概念验证；模板；或其他相关技术（包括由我方人员提供的任何前述项）作为 AWS 内容按照《AWS 客户协议》或您与 AWS 之间的相关书面协议（以适用者为准）向您提供。您不应将这些 AWS 内容用在您的生产账户中，或用于生产或其他关键数据。您负责根据特定质量控制规程和标准测试、保护和优化 AWS 内容，例如示例代码，以使其适合生产级应用。部署 AWS 内容可能会因创建或使用 AWS 可收费资源（例如，运行 Amazon EC2 实例或使用 Amazon S3 存储）而产生 AWS 费用。
本指南中提及第三方服务或组织并不意味着 Amazon 或 AWS 与第三方之间存在认可、赞助或从属关系。AWS 的指导是一个技术起点，您可以在部署架构时自定义与第三方服务的集成。