亚马逊云存储的数据保护和弹性

亚马逊云存储的数据保护和弹性

关键字: [Amazon Web Services re:Invent 2024， 亚马逊云科技， Amazon Backup， Data Protection， High Availability， Amazon Backup， Disaster Recovery， Cyber Resilience]

导读

数据持续成为世界上最宝贵的资源之一。数据保护和弹性对业务成功至关重要，有助于保持工作流程的运行，并使企业能够从数据丢失事件中恢复，如意外中断、自然灾害和勒索软件。参加本次会议，深入了解亚马逊云科技存储如何为组织提供深度防御的数据保护和弹性，以保护跨恢复点和时间目标的应用程序数据，通过不可变解决方案、恢复测试、基于策略的访问控制、加密以及审计和报告来帮助降低风险。

演讲精华

以下是小编为您整理的本次演讲的精华。

本次会议由Ken Hoy，一位亚马逊云科技解决方案架构师主持。他热情地欢迎与会者参加STG 301会议，该会议将深入探讨由Wayver Jackson主讲的亚马逊云科技存储数据保护和弹性问题。Ken介绍了自己，提到下个月将是他在亚马逊云科技工作的第五年，期间主要专注于数据保护策略，包括亚马逊云科技备份，帮助客户制定健壮的方法。

Palak Desai是亚马逊云科技备份产品管理的负责人，她向观众表示欢迎并表示很高兴能参加本次会议。会议正式开始后，Ken确保与会者都能清楚地听到他的声音。

Ken概述了会议议程，表示他们将探讨弹性的重要性，并深入探讨高可用性和数据保护等具体策略。此外，他还承诺会有一个深入的演示，最后将进行互动环节来解答任何疑问或疑虑。

Palak Desai上台发言，承认数据呈指数级增长，对于许多客户而言，数据在做出业务决策时发挥着关键作用。她强调，数据已成为当今许多企业的命脉，因此保护数据免受任何潜在损失以确保业务持续运营至关重要。认识到数据的巨大价值及其不断增长的数量，Palak强调了数据保护的重要性。她保证，本次会议将围绕数据保护策略、在不同环境中可能有益的架构模式以及全面的演示进行讨论。

Palak引用了研究结果，这些结果强调了未能保护数据或在发生故障时保持弹性所带来的巨大财务和声誉损失。然而，她表示亚马逊云科技现在提供了许多原生功能，客户可以利用这些功能来确保其应用程序和数据的弹性。

为了奠定基础，Palak将弹性定义为工作负载能够承受任何部分或间歇性故障，并且能够从这些故障中有效恢复的能力，这个概念被广泛称为数据保护。她解释说，数据保护包括多个支柱和方面，高可用性是第一个支柱。

Palak举了一个生动的例子，描述了在像Chime或Zoom这样的视频通话平台上，突然的互联网中断或过多的流量可能会降低应用程序的性能，导致视频或音频质量下降的情况。然而，她解释说，在这种情况下，应用程序将继续运行，尽管体验会受到影响，这就是高可用性的概念。

另一方面，Palak将高可用性与数据保护进行了对比，当应用程序完全失败时，需要通过数据保护机制从故障中恢复。

Palak承认故障的原因有很多种，其中人为错误，如意外地错误配置设置或参数，是最常见的原因之一。此外，她还提到了系统负载过大的情况，并以电子商务网站在黑色星期五等活动期间遇到的流量激增而导致中断为例。她解释说，这些都是高可用性策略至关重要的典型场景，当某个组件发生故障时，可以进行故障转移，确保应用程序继续运行。

在另一端，Palak强调了区域性中断、自然灾害或不可抗力(如飓风或地震)等情况，这些情况可能会导致整个地区无法运行。在这种情况下，她强调了灾难恢复和数据保护策略的重要性，并指出对这两个概念的方法应该由所涉及的应用程序的关键性来决定。

对于关键任务应用程序，如金融或票务领域的应用程序，Palak主张同时设计高可用性和数据保护。这种方法的理由有两个:首先是防止应用程序停机，其次是在发生故障时能够高效恢复。

Palak随后深入探讨了亚马逊云科技采用的共享责任模型，阐明了亚马逊云科技和客户之间的责任划分。她解释说，亚马逊云科技负责云基础设施的弹性，包括区域、可用区、边缘位置以及底层计算、存储、数据库、网络和硬件服务。相反，客户则负责确保云环境中应用程序和数据的弹性。

为了说明这一概念，Palak举了Amazon Simple Storage Service (S3)的例子。虽然亚马逊云科技负责确保S3享有11个9的持久性，在一个区域内的可用区之间维护存储在S3存储桶中对象的完整性，但保护数据本身的责任则完全落在客户身上。

Ken Hoy插话提供了一个生动的类比。他表示，如果客户无意中损坏了他们在S3中的数据，亚马逊云科技将会在可用区内以11个9的持久性忠实地维护这种损坏状态。然而，亚马逊云科技不会自动为存储在S3中的客户数据创建备份，这凸显了客户实施数据保护措施的责任。

Palak重申，客户负责弹性的各个方面，包括备份应用程序、实施适当的访问权限和许可权以防止由于访问控制过于宽松而导致的意外操作、制定灾难恢复方案，以及通过保护运行在亚马逊云科技基础设施之上的应用程序来确保网络弹性。

转移到亚马逊云科技的存储产品组合，Palak强调了可用的多种服务，包括使用Elastic Block Store (EBS)的块存储、使用S3和S3 Glacier的对象存储，以及Amazon FSx、Amazon Elastic File System (EFS)和Amazon File Cache等文件存储解决方案。她指出，每种存储系统都提供了各种机制来增强应用程序的弹性。

Palak强调了亚马逊云科技备份作为跨亚马逊云科技服务备份应用程序数据的一致机制，从而实现数据保护的作用。此外，她还提到了其他功能，如S3 Object Lock、版本控制和灾难恢复功能，客户可以利用这些功能来加强其数据保护策略。

Ken Hoy随后上台讨论高可用性策略。他首先重温了区域和可用区的概念，这应该是观众熟悉的。他解释说，区域是亚马逊云科技在全球运营数据中心的地理位置，确保世界各地的客户都可以轻松访问亚马逊云科技资源。区域还有利于灾难恢复，允许客户在区域之间设置故障转移机制，并有助于满足客户将数据保留在特定位置的数据驻留要求。

Ken强调，亚马逊云科技坚持一项严格政策:如果客户在某个区域存储数据，除非客户明确要求，否则亚马逊云科技不会将该数据移动到另一个区域。

在每个区域内，Ken阐述说，亚马逊云科技将多个物理数据中心组合成逻辑构造，称为可用区。他解释说，可用区不是单一位置，而是多个物理设施的集合。这种设计确保了同一区域内的每个可用区之间有足够的距离，避免共享风险因素，如电网、自然灾害区或地震区，同时又足够接近以实现可用区之间的同步复制。

Ken解释说，可用区是一个故障域，允许客户在任何单个可用区发生故障时继续运行，而不会影响其他可用区。他进一步指出，每个数据中心和可用区都配备了冗余电源、网络和连接，提供了额外的冗余层，使客户能够设置高可用性架构。

不同的亚马逊云科技服务，Ken继续说，在区域内提供不同级别的弹性。他将服务分为三种类型:区域服务、区域服务和全球服务。

区域服务(如EBS)在客户指定或自动分配的单个可用区内存储数据。相比之下，区域服务(如S3)将数据分布在一个区域内的多个可用区，确保如果一个可用区发生中断，客户仍然可以访问其数据。

全球服务(如身份和访问管理(IAM))跨越多个区域，提供统一的服务体验，无需区域特定的配置。

Ken强调，在设计高可用性架构时，了解某项服务是区域服务、区域服务还是全球服务非常重要，因为这将指导采用适当的策略。

转移到设计考虑因素，Ken将传统企业环境与亚马逊云科技云进行了比较。在传统环境中，应用程序通常局限于单个数据中心或几个机架，将故障域限制在这些特定位置。为了实现高可用性，企业通常会维护第二个数据中心作为故障转移用途。

然而，在亚马逊云科技云中，对于弹性的方法可能因所使用的服务而有所不同。Ken介绍了跨多个可用区域实现高可用性的概念，其中客户可以在同一区域内的多个可用区域之间为EC2实例和EBS卷等本质上属于区域性的服务设置高可用性对。

此外，他讨论了跨区域恢复，该功能允许客户从同一区域内但与主资源位于不同可用区域的备份或快照中恢复数据。

对于需要更高级别弹性的场景，Ken强调了跨区域恢复的重要性，这对于备份和灾难恢复用例尤为相关。在这种方法中，客户在多个区域之间维护数据副本，从而能够在发生区域中断或灾难时从辅助区域进行故障转移或恢复。

Ken举例说明了像Netflix和Amazon Prime这样的公司采用了跨多个区域的主动-主动架构。在发生区域故障的情况下，这些架构允许从所有区域的用户无缝地被引导到剩余的单个区域，确保服务不间断。

为了说明这些概念，Ken展示了一个简单的跨区域架构，包括一个具有多个可用区域的单一区域。在这种设置中，应用程序跨可用区域运行，利用网络地址转换(NAT)网关和负载均衡器等服务根据需要在区域之间重定向流量。

Ken强调将Web服务放在负载均衡器后面的最佳实践，不仅可以优化性能，而且还可以在发生故障时实现跨可用区域的流量重定向。在计算层，他建议使用跨越区域内多个可用区域的EC2自动伸缩组，从而实现自动扩展和跨区域故障转移。

对于数据库层，Ken强调了在多个可用区域之间设置Amazon关系数据库服务(RDS)和Amazon Aurora等服务的备用副本或只读副本的能力。这种方法支持自动故障转移到不同区域的备用数据库，或者跨副本负载均衡读取流量，从而提高弹性。

在概述高可用性策略之后，Ken将讨论转向数据保护，并邀请Palak Desai分享她的见解。

Palak首先介绍了两个关键术语:恢复点目标(RPO)和恢复时间目标(RTO)。她解释说，RPO定义了应用程序和业务可以容忍的数据损失量，而RTO指定了在需要恢复之前可接受的最长停机时间。这两个指标决定了企业在发生灾难时的生存能力。

Palak倡导采用3-2-1-0数据保护方法，尽管她承认这个术语有些拗口，但仍继续阐述。第一个原则是维护三份独立于主资源的数据副本。其中两份副本应存储在远程位置，例如跨账户或区域。一份副本应存储在主账户中，以减少RTO并实现更快的恢复。关键是，其中一份副本必须是不可变的和隔离的，作为在发生勒索软件事件时最后的恢复手段。

最后一个原则，即3-2-1-0中的0，规定应定期进行测试，以确保至少有一份副本可以在灾难场景中成功恢复。

为了强调测试的重要性，Palak分享了她在一家银行工作时的一个警示故事。在该银行位于纽约的整个数据中心发生故障的事件中，他们试图将故障转移到距离仅两个街区的另一个数据中心。不幸的是，这个辅助数据中心也受到了影响，导致该银行不得不依赖他们的备份副本。

然而，当他们开始恢复过程时，他们意识到负责设置他们备份的顾问使用了增量永久备份进行配置。这意味着恢复他们环境中的任何服务器都需要惊人的30天时间，这是他们在灾难发生之前从未意识到的事实，因为他们从未真正测试过恢复过程。

这个故事强调了定期进行恢复演练以验证恢复过程并确保恢复的数据来自已知的良好来源的重要性，突出了测试在数据保护策略中的关键作用。

Palak重申了建议的方法，即维护一份本地副本以实现快速恢复，在远程区域或账户中维护副本以进行复制或备份，并维护第三份不可变、安全和隔离的副本专门用于网络恢复。她强调，这第三份副本应定期进行测试，以确保在发生灾难时能够高效恢复。

Palak进一步阐述了备份的作用，解释说备份通常用于合规性目的、从勒索软件事件中恢复以及一般数据保护。确定备份是否合适的指导原则是恢复时间目标(RTO)。对于不需要即时恢复且可以在数据恢复期间容忍一段停机时间的应用程序，备份通过使用备份和恢复技术创建防篡改的不可变备份，提供了有效的数据保护解决方案。

Palak举了一个生动的例子:假设一个主要资源在某个账户中运行良好，但由于人为错误、错误配置或其他意外情况，该资源被意外删除。在这种情况下，在主账户中拥有备份可以快速恢复到数据的干净、正常工作副本。

然而，如果整个账户受到威胁或发生区域中断，那么存储在跨区域、跨账户环境中的备份副本就变得非常宝贵，因为它提供了一个安全的远程位置，可以从中安全地恢复数据。

Palak分享了一个值得注意的统计数据:超过70%的本地恢复使用的是30天或60天前的数据。因此，客户中的一个常见最佳实践是为本地备份保留较短的保留期限，同时在单独的账户中保留较长保留期的副本，以防范勒索软件攻击。

Palak强调要将账户视为一个故障域，因为区域故障很少发生，但账户受损的可能性更大。因此，客户应该优先确保在与工作负载账户隔离的单独账户中保留数据副本，以防范网络安全威胁。

转向亚马逊云科技备份，Palak将其描述为一个一致的平台，提供基于策略的备份管理，跨亚马逊云科技资源和服务，包括混合工作负载。尽管她承认某些资源存在本机备份功能，但她强调亚马逊云科技备份是一种跨计算、存储、文件系统、对象存储、数据传输技术、数据库和应用程序(包括通过支持VMware和SAP HANA的混合应用程序)的一致的、基于策略的方法。

Palak强调了亚马逊云科技备份为备份提供不可变性、实施基于策略的保留机制和锁定、促进定期恢复测试以及生成可审计的报告以向监管机构证明应用程序的弹性的能力。

然而，Palak阐明备份并不是数据保护的唯一机制，接着讨论了复制。

Ken Hoy再次登场，解释说虽然备份适用于获取可在可接受停机时间内恢复的时间点副本，但对于需要接近零RPO和RTO的应用程序，复制是首选方法。复制是一种行业内长期存在的做法，它使生产环境中写入的数据几乎可以立即传播到目标位置，从而实现快速故障转移，并最小化或在某些情况下根据所使用的工具实现零数据丢失。

Ken承认，由于维护如此低的RTO和RPO水平所涉及的成本，复制并不适用于每个应用程序。他幽默地说，如果问业务主管或经理他们能容忍多少数据损失，他们肯定会回答“零”，而当被问及可接受的停机时间时，他们会回答“完全没有”。然而，一旦了解到所涉及的成本，他们通常会重新调整期望值。

Ken强调在决定适当的数据保护工具之前，对应用程序进行分类和记录文档的重要性。他建议采用一个简单的模型，包括金、银和铂金等级，每个级别都分配了特定的RPO和RTO目标。客户可以根据应用程序的关键性将其划分到这些级别中，确保最关键的应用程序获得最高级别的数据保护，尽管成本会更高。

Ken强调了几种支持复制的亚马逊云科技服务，包括可以跨账户配置的S3跨区域复制。使用S3复制，客户可以选择最佳努力模式，在该模式下，源存储桶中的更改会复制到另一个区域或账户中的目标存储桶;或者时间控制模式，该模式允许客户定义服务级别协议(SLA)，确保目标存储桶永远不会落后于源存储桶超过指定的持续时间，例如15分钟。

此外，Ken还提到了在S3中创建备份并将其复制到另一个账户或区域的能力，使其免受完全恶意软件攻击，从而有助于恢复。

对于使用Amazon FSx for ONTAP的客户， Ken强调了其原生数据保护功能，包括创建快照、备份以及将这些快照复制到不同区域的另一个FSx实例的能力。

Ken还讨论了Amazon Elastic File System (EFS)，它内置了创建备份和将文件系统复制到不同区域或账户的功能。

为了说明利用复制实现灾难恢复架构的示例，Ken展示了使用亚马逊云科技 Elastic Disaster Recovery Service (DRS)的案例。在这种情况下，运行在源环境(可能是本地或亚马逊云科技区域)中的服务器或EC2实例上的代理充当过滤器驱动程序，拆分对底层存储进行的写入操作。在源端写入存储的同时，写入操作会被复制到亚马逊云科技内的另一个区域，数据存储在Elastic Block Store (EBS)卷中。

发生灾难时，DRS可以使用灾难恢复区域中复制的数据启动全新的EC2实例。对于本地VMware实例，DRS在故障转移过程中具有将它们转换为亚马逊云科技内的EC2实例的能力。

转而讨论S3数据保护时，Ken询问了观众对S3版本控制和复制的熟悉程度。虽然有一些与会者表示他们正在使用这些功能，但Ken指出，大多数客户并未为其S3存储桶启用版本控制或复制，这与最佳实践相悖。

Ken驳斥了S3著名的11个9的持久性等同于S3存储桶的自动备份的常见误解。事实上，他分享了一个关于S3产品经理不得不为支持人员创建一个脚本来解释，当数据从S3中删除时，亚马逊云科技确保删除本身具有11个9的持久性的轶事，从而强调客户实施自己的数据保护措施的重要性。

为了保护S3中的关键数据，Ken建议遵循Palak概述的3-2-1原则。第一步是为S3存储桶启用版本控制，这是操作恢复的基础，但不构成真正的备份，因为如果整个存储桶被删除或损坏，版本将变得无法访问。

第二步是使用亚马逊云科技备份等工具为存储桶创建备份，将时间点副本存储在同一账户内的不同位置，以便在需要时快速恢复。

对于最关键的数据，Ken主张维护三个恢复副本。第一个副本是本地副本，包括版本控制和备份。第二个副本应该位于第二个账户中，主要用于网络恢复目的。如果发生勒索软件攻击或账户被入侵，客户可以从这个隔离的副本中恢复，而不会有进一步污染的风险。

Ken强调了8月推出的Logical Air Gap (LAG)存储库功能，它提供了一个隔离的、由服务管理的存储库，位于由服务管理的账户中，使用由服务管理的加密。这种隔离确保即使主账户被入侵，导致密钥或资源由于加密而无法访问，客户仍然可以安全地从LAG存储库中恢复。

Palak Desai补充说，定期使用LastLine等合作伙伴解决方案对备份进行恶意软件扫描非常重要，以确保至少有一个副本保持干净和可恢复，以防发生灾难。她还强调了持续进行恢复测试以验证至少有一个副本的可恢复性的必要性。

第三个副本，正如Ken所解释的，主要用于需要低RPO和RTO的灾难恢复场景。它利用S3跨区域复制与时间控制的组合，确保源存储桶中的更改在规定的SLA内复制到不同区域和账户中的目标存储桶，以及S3多区域访问点，它们充当层叠在S3存储桶之上的虚拟端点。

在这种架构中，应用程序通过多区域访问点访问数据，在发生灾难时，该访问点可以无缝切换到故障转移存储桶，实现快速故障转移，无需重新配置。

然而，Ken警告不要将复制作为备份的替代品，因为复制旨在传播对象的最新版本，而不是实现时间点恢复。他举了一个例子，要从五天前恢复存储桶的状态，需要在可能有数百万个对象中识别每个对象在该时间点的特定版本，这需要一个自定义数据库和软件解决方案来公开所需的版本 - 实际上是复制了亚马逊云科技备份的功能。

转移到EBS和EC2的讨论，Ken解释了当前保护EBS卷的方法是通过快照。亚马逊云科技备份和其他备份应用程序与EBS快照原生集成，在同一区域内创建副本。与名称相反，EBS快照不是虚拟副本，而是存储在S3中的完整映像副本，允许在任何快照时间点使用增量永久备份完全恢复卷。

在这种架构中，第一个副本是本地副本，通过在同一区域内创建快照来实现。第二个副本，用于网络恢复目的，涉及使用亚马逊云科技备份的Logical Air Gap (LAG)存储库将备份副本发送到第二个账户。Ken强调了与不同账户共享LAG存储库的能力，如果主账户由于安全问题或保险要求而被入侵，可以将其恢复到全新的可信账户。

第三个副本，用于灾难恢复，利用Amazon Elastic Disaster Recovery (DRS)将数据半同步复制到另一个区域，确保目标环境只比源环境落后几分钟。发生灾难时，客户可以宣布故障转移，DRS将使用存储在灾难恢复区域中的复制数据启动新实例。也可以将故障转移回原始源或新账户。

接下来，Ken演示了这些架构的实现，从一个涉及两台服务器的场景开始:dock server 1和dock server 2，每台服务器都有两个附加卷:一个根卷和一个包含用户数据(如营销视频和音乐评论)的文档存储库卷。

为了模拟故障，Ken分离并删除了dock server 2上的文档存储库卷，导致数据丢失。然后，他导航到亚马逊云科技备份控制台，在那里他有多个本地存储库，其中包含服务器根卷和文档存储库卷的恢复点(备份)。

Ken启动了删除的文档存储库卷的最新恢复点的还原，指定了适当的可用区域。经过短暂等待后，使用快照中的数据实例化了一个新卷，Ken随后将其附加到dock server 2，恢复了丢失的数据和包含用户文档的D驱动器。

接下来，Ken模拟了一种情况，整个实例丢失，本地副本无法访问，可能是由于账户被入侵。他终止了dock server 1，使其无法访问。在亚马逊云科技备份控制台中，他访问了与当前账户共享的Logical Air Gap (LAG)存储库，该存储库属于另一个账户(由账户ID标识)。

在LAG存储库中，Ken发现了在源端创建并复制到隔离存储库中的恢复点。他启动了还原，选择是复制已删除的卷和服务器的规格，还是创建新的更新规格。经过短暂等待后，dock server 2被还原并运行，展示了从隔离的LAG存储库中恢复的能力，如果原始账户被认为是不可信的，还可以恢复到全新的账户。

对于灾难恢复演示，Ken展示了一个环境，其中有两台服务器(一台Web服务器和一台数据库服务器)位于us-west-1区域。在us-east-2区域的DRS控制台中，他显示复制已经启动，实例处于有状态恢复状态，可以通过实例ID识别。

为了模拟源区域的故障，Ken关闭了服务器。在us-east-2的目标端，DRS检测到复制中断，并表示准备就绪以进行故障转移。Ken启动了故障转移过程，选择了特定的恢复时间点，这触发了一个新的恢复作业。

DRS对EC2实例执行了快照(检查点)，必要时进行了转换(例如从VMware转换为EC2)，并在us-east-2区域启动了恢复的实例。Ken展示了在灾难恢复区域中运行的新恢复实例，而原始实例仍然在us-west-1区域中停止，展示了使用DRS跨区域故障转移和恢复的能力。

在总结陈词时，Ken重申了根据关键性和RPO/RTO要求对工作负载进行分类的重要性，利用亚马逊云科技服务功能实现高可用性和数据保护，在不同位置维护多个数据副本，并与亚马逊云科技账户团队密切合作以分析和保护当前环境。他还强调了定期测试恢复流程的必要性。

Palak Desai感谢与会者抽出时间，并鼓励他们通过调查问卷提供反馈，以帮助改进未来提高应用程序弹性的会议。

下面是一些演讲现场的精彩瞬间：

Palak Desai，亚马逊云科技备份产品经理，在reInvent2024活动上欢迎观众。

亚马逊云科技备份推出了逻辑隔离保险库，提供了一个隔离且不可变的副本，以便在发生勒索软件或账户被入侵时进行安全数据恢复。

亚马逊云科技备份简化了数据恢复过程，只需几次点击即可将整个S3存储桶恢复到以前的状态，无需复杂的自定义解决方案。

亚马逊云科技首席执行官解释了EBS快照的工作原理，它允许您随时恢复整个EBS卷，以及尽管名称为“快照”，但它们实际上是存储在S3中。

亚马逊云科技备份的逻辑隔离保险库允许跨账户共享备份，以便在发生安全漏洞或账户被入侵时进行安全恢复。

亚马逊云科技灾难恢复服务演示了从模拟的源区域故障中恢复EC2实例的故障转移和恢复过程，展示了快照、转换以及恢复到以前时间点的能力。

Andy Jassy解释了如何在亚马逊云科技活动YouTube频道上访问录制的re:Invent 2022会话，这些会话将按类别组织到播放列表中。

总结

在这篇全面的叙述中，我们深入探讨了确保业务连续性和保护宝贵数据资产的关键策略和架构模式。核心主题围绕着3-2-1-0数据保护方法，强调维护多个独立副本的重要性，其中至少有一个不可变和隔离的副本用于网络恢复。

首先，我们探讨了高可用性的概念，它使工作负载能够承受跨组件的部分或间歇性故障。这可以通过多区域弹性、多区域恢复和多区域恢复等技术来实现，具体取决于应用程序的关键性及其恢复时间和恢复点目标(RTO和RPO)。

接下来，我们深入探讨数据保护领域，重点关注备份和复制策略。备份非常适合于合规性、勒索软件恢复以及不需要即时恢复的场景。Amazon Backup提供了一个一致的平台，用于跨各种服务进行基于策略的备份管理，包括在逻辑上隔离的保管库中创建不可变备份的能力，以实现网络恢复。

另一方面，复制通过持续将数据复制到目标位置，提供了接近零的RPO和RTO，从而在发生灾难时实现快速故障转移。诸如S3跨区域复制、FSx for ONTAP和EFS等服务支持复制功能，而Amazon Elastic Disaster Recovery (DRS)则支持EC2实例的半同步复制。

最后，我们呼吁根据工作负载的关键性进行分类，在不同位置维护多个副本，并利用各种亚马逊云科技服务和功能实现高可用性和数据保护。强调定期测试和与亚马逊云科技账户团队合作，以确保高效恢复和合规性。

亚马逊云科技（Amazon Web Services）是全球云计算的开创者和引领者。提供200多类广泛而深入的云服务，服务全球245个国家和地区的数百万客户。做为全球生成式AI前行者，亚马逊云科技正在携手广泛的客户和合作伙伴，缔造可见的商业价值 – 汇集全球40余款大模型，亚马逊云科技为10万家全球企业提供AI及机器学习服务，守护3/4中国企业出海。