Amazon S3 跨区域复制场景与实现

Amazon Simple Storage Service（Amazon S3）作为 AWS 第一款产品，自 2006 发布以来，因其高可扩展性，数据可靠性以及灵活的定价方式，成为很多客户存储海量数据的首选，目前 Amazon S3 已经拥有超过 350 万亿个对象，平均每秒超过 1 亿个请求（AWS Pi Day 2024)。

对于 Amazon S3， AWS 提供的数据持久性设计为超过 99.999999999% ，默认情况下，S3 至少跨 3 个可用区冗余存储数据，并且提高了多种保护 S3 桶数据持久的设计。尽管如此，对高可用有着更高要求的用户来说，如果某一个区域发生问题，造成 S3 服务不可用，用户希望可以在最短的时间内，切换到备用区域继续使用 S3 服务。为了满足这部分用户的需求， 2015 年，AWS 增加了跨区域复制数据的功能（Cross-Region Replication, CRR）允许自动、异步地将存储在一个区域的 S3 桶中的数据复制到另一个区域的 S3 桶。这一特性对于数据备份、灾难恢复和数据本地化非常重要。

客户使用场景

对于大部分客户而言，高可用在区域级别内即可满足要求，但对于少数对高可用有极高要求的客户，可通过跨区域复制来满足客户的业务场景。客户日常将区域 A 作为主要日常使用 S3 存储桶的区域，并将区域 B 作为数据备份区域，并开启 CRR 双向复制模式，实现跨区域数据复制。通过日常监控报警，在确定可用区 A 遇到问题不可使用后，客户通过手动切换的方式，将数据读写切换至区域 B 的相应的 S3 存储桶。因此前 CRR 为双向复制，在使用区域 B S3 存储桶做为主区域的同时向区域 A 的 S3 桶做为备用进行复制，在区域 A S3 服务恢复后，再将读写业务切换回区域 A。本文将重点介绍 S3 跨可用区复制的步骤以及注意事项。

跨区域复制数据的准备工作

在使用跨区域复制数据之前，首先客户需要对即将开启跨区域复制备份功能的 S3 桶的数据进行梳理，确定数据量，以及对于数据复制是否有时间要求。如果有，可以开启 RTC（Replication Time Control）功能。例如，客户使用 S3 Replication 将数十亿个对象跨存储桶复制到相同或不同区域，开启 S3 RTC 功能后，帮助客户加速上传，完成复制。其中大多数新对象在几秒钟内即可复制，S3 RTC 提供 SLA 支持，并且可以通过 CloudWatch 监控完成复制所需的时间以及待复制对象的总数和大小。但需要注意的是，在开启 CRR 以及 RTC 之前，需要对用户 S3 存储桶的数据量，以及传输速率进行评估，可参考官方文档。默认情况下，复制数据传输速率在 1 Gbps，如果数据量比较大，可以根据评估的输出速率，提前联系 AWS Support 中心或使用 Service Quotas 来请求提高限制，保证传输效率，并且提高带宽的部分不会产生额带宽外费。此外需要注意的是，复制数据传输速率在 1 Gbps以上时，RTC 不支持 SLA。

创建复制规则

首先，分别在区域 A 的 S3 创建 S3 桶作为主桶，在区域 B 创建数据桶做为备用桶。其次，创建跨区域复制规则，可以根据用户的实际情况创建，本文案例针对灾难备份，建议创建双向复制规则，可以创建从区域 A 到区域 B 的复制规则，以及从区域 B 到区域 A 的复制规则，一般情况下，客户会将第二个区域作为备份区域，因此如果数据写入区域 A，则区域 A – 区域 B的复制，只会在灾备切换到区域 B 之后才启动。

在 AmazonS3 控制台 – 选择区域 A 要创建规则的 S3 数据桶 – 管理 – 创建复制规则

值得注意的几点：在创建时，如果对延时有要求，可以开启 RTC，像前文提到，如果数据量较大，需要提高带宽，可通过控制台 Support 来申请；其次，建议开启复制指标，可以通过监控复制指标，对复制的对象总和，数据量大小，进行监控。

在创建完成的前一步骤，最新复制规则支持对现有对象进行复制，无需用户自己手动复制，更加便捷。

创建生命周期

数据复制规则和生命周期规则是独立运行的，也就是说通过生命周期规则删除的数据操作是不会通过复制规则同步到其它区域，主备桶建议创建内容统一的生命周期规则，确保在主备桶内容一致。此外，合理的生命周期规则能减少冗余文件，从而有效节约成本，建议主桶的生命周期规则应该提前创建，在确保没有冗余数据之后，再创建复制规则，这样有利于减少冗余数据同步，节约成本，参考生命周期管理文档。

监控以及告警预案处理

合理有效的监控和告警是保证高可用的重要环节，日常数据监控以及在 S3 发生故障切换区域以及恢复等操作之前，都应该参照相关监控数据来决定下一步操作，用户可以通过 AWS CloudWatch 或用户自建监控系统来监控数据，下图为 S3 控制台数据查找。主要监控以下三类数据：

S3 桶存储指标（Storage Metric）

在 S3 控制台，选择查看的 S3 存储桶，选择指标，可查看某存储桶存储桶总大小，以及对象总数，亦可在 CloudWatch 查看。

复制指标（Replication Metric）

通过 S3 控制台，指标选项的最下方，查看复制指标，选择复制规则，以监控待复制的对象总数和大小、复制到目标区域所需的最长时间，以及复制故障。可以在 S3 控制台查看，或者从 CloudWatch 监控查看。

主要监控指标如下：

对象复制失败：OperationsFailedReplication
对象复制延时状态：BytesPendingReplication/ReplicationLatency/OperationsPendingReplication

请求指标 Request Metrics：AllRequests/TotalRequestLatency/BytesDownloaded/BytesUploaded/4xxErrors/5xxErrors

监控告警

监控指标：例如对复制对象失败 OperationsFailedReplication 进行监控告警，在没有失败的情况下为 0，可直接通过控制台 – S3 桶 – 选择属性 – 事件通知进行创建，亦可以通过 CloudWatch 或客户内部自建系统建立告警。

并可通过创建 Event 机制记录并落盘到某个存储中，建议使用 Dynamodb 或者 S3 来存储数据，后续可以对数据复制失败进行原因分析以及数据修复。

以上指标中，ReplicationLatency 应该处于正常的周期性上升和回落，或者持续稳定。各个 service 可以根据每个桶的数据大小以及历史数据建模，确定一个复制延时的告警阈值。举例：如果 BytesPendingReplication 超过 6GB 并持续 4 小时以上发出告警消息到监控频道，工程师通过监控与 ticket 协同 cloud ops 以及 AWS support 查询原因。更多监控告警细节和建议请请参考 S3 监控与指标。

主备区域切换

S3 主备切换的判定需要综合考虑，首先，S3 在整个区域级别发生故障是低概率事件，在出现 S3 不可用时，需要判断是以下哪种问题。可能出现的问题是区域级别不可用，单个 S3 存储桶出故障，亦或者网络传输问题，S3 复制问题，S3 相关服务问题。因此监控指标的设定，依然需要提前设计明确，例如监控使用 S3 出现故障超过一定时间，或者 AWS Support 部门通知某一个 S3 区域出现问题，则切换到备用区域。

S3 数据灾备测试

尽管 S3 在某区域不可用是低概率事件，需要进行不定期的数据桶切换测试尤为重要。日常测试发生的场景和真实 S3 不可用场景有所不同，测试的过程中，由于并非真实的 S3 不可用，所以我们需要保证测试过程中对用户不会产生影响。

从 S3 主桶区域切换至 S3 备用桶区域

确定参加测试的（主桶/备桶）检查相关监控指标以及双向复制指标是否正常（监控参考）
用户手动切换区域
用户 S3 相关操作测试
通过 CloudWatch 监控流量是否正确导向备用区域（例如：复制指标/请求指标）
监控 Service Log 输出（S3 Error 参考示例）

S3 备用桶切换回 S3 主桶

检查相关监控指标以及双向复制指标是否正常（监控参考）
用户手动切换区域
用户 S3 相关操作测试
通过 CloudWatch 监控流量是否正确导向主桶区域（例如：复制指标/请求指标）
监控 Service Log 输出（S3 Error 参考示例）

在真实的场景中，如果 S3 不可用发生的时间较短，例如区域 A 发生不可用，切换至区域 B，数据将写入区域 B 数据桶，在区域 A 恢复后，可通过之前已开启的数据复制规则，将数据从区域 B 复制回区域 A，如果发生的问题时间较短，通过数据复制规则监控发现，没有复制失败的情况，复制延时正常，可以考虑直接切换回主区域。但如果有数据复制延迟，以及数据主区域中断时间长，担心数据不一致的情况下，可以考虑使用数据比对方案，对数据资产进行盘查，确保数据安全。数据比对方案可参考文章。

总结

在大部分场景下，S3 的跨可用区级别的高可用可以满足绝大多数场景，如果您对 S3 服务有区域级别的高可用需求，可以参考本文进行验证，更好的满足业务需求。

亚马逊AWS官方博客