Cross-region replication (CRR) automatically and asynchronously (in near real time) replicates object operations like creation, updates, and deletions from a source bucket to a destination bucket in another region. You can configure CRR for buckets in the same or different accounts. CRR helps you meet compliance requirements, reduce latency, and ensure data security and availability.
Use cases
CRR meets the needs for cross-region disaster recovery and data replication. Objects in the destination bucket are exact replicas of the objects in the source bucket. They share the same object names, versioning information, metadata, and content, such as creation time, owner, user-defined metadata, and object ACLs. You can configure CRR rules to meet the requirements of the following use cases.
Meet compliance requirements
Although OSS provides a default data redundancy mechanism for every stored object, some compliance requirements mandate that data replicas are stored in geographically distant locations. With CRR, you can replicate data between distant OSS data centers to meet these requirements.
Minimize latency
If your customers are in two or more geographical locations, you can maintain object replicas in OSS data centers that are geographically closer to your customers, which minimizes latency when they access the objects.
Data backup and disaster recovery
If you have high requirements for data security and availability, you can maintain an explicit replica of all written data in a separate data center. This practice ensures that you can activate the backup data in the other data center if a major disaster, such as an earthquake or tsunami, destroys one OSS data center.
Data migration
You can use CRR to migrate data from one OSS data center to another for business reasons.
Operational efficiency
If you have compute clusters in two different data centers that analyze the same set of objects, you can maintain object replicas in both regions.
Features
CRR provides the following features:
Replication Time Control (RTC)
When you enable RTC, OSS replicates most objects within seconds and 99.99% of objects within 10 minutes. RTC also provides real-time monitoring of data replication, allowing you to track various metrics for your replication tasks.
Near real-time data replication
Object operations such as creation, deletion, and modification are replicated to the destination bucket in near real time.
Data consistency
By default, OSS ensures eventual data consistency between the source and destination buckets during replication. However, if you write an object with the same name directly to the destination bucket during the replication process, OSS cannot guarantee eventual data consistency between the two buckets.
Replicate existing data
In addition to replicating new data written to the source bucket after a replication rule is configured, you can also replicate data that existed in the bucket before the rule was configured.
Track replication progress
You can view the timestamp of the most recent replication for new data, and track the migration progress as a percentage for existing data.
Versioning
For source and destination buckets that both have versioning enabled, CRR ensures eventual consistency for all object versions. If the replication rule is configured for write operations (create and update), a delete operation on a specific version in the source bucket is not replicated. However, a delete marker created in the source bucket is replicated to the destination bucket.
Transfer acceleration
You can use transfer acceleration to improve the data transfer speed for CRR between regions in the Chinese mainland and regions outside the Chinese mainland. For more information about transfer acceleration, see Access OSS using transfer acceleration.
Replicate encrypted data
CRR supports the replication of unencrypted objects and objects that are encrypted by using SSE-KMS or SSE-OSS. For more information, see Replication with server-side encryption.
Configure event notifications
You can configure event notification rules to monitor changes in the source and destination buckets during data replication. Set the event types to
ObjectReplication:ObjectCreated,ObjectReplication:ObjectRemoved, andObjectReplication:ObjectModifiedto receive notifications about object creation, update, deletion, and overwriting. For more information, see Use event notifications to monitor object changes in real time.
Considerations
Billing
When you use CRR, you are charged for the data transfer traffic generated by replication. For more information, see Cross-region replication traffic fees. For CRR across accounts, these traffic fees are billed to the account that owns the source bucket.
If you enable RTC, additional RTC fees are incurred. For more information, see RTC fees. For CRR across accounts, the RTC fees are billed to the account that owns the source bucket.
For each object successfully replicated, OSS counts the operation as a request and charges API request fees. For more information, see Request fees.
If you enable transfer acceleration, additional transfer acceleration fees are incurred for the destination bucket. These fees are billed to the account that owns the destination bucket. For more information, see Transfer acceleration fees.
When CRR replicates Infrequent Access (IA) or Archive objects, the objects are not restored first. Therefore, no data retrieval fees are incurred.
Replication time
CRR uses an asynchronous (near real-time) mechanism. Replication time can range from a few minutes to several hours, depending on the amount of data. If replication takes an excessive amount of time, check whether the task is delayed due to bandwidth limits. If bandwidth is the issue, contact technical support to request a bandwidth increase to improve replication efficiency.
You can view the inbound CRR bandwidth usage on the OSS console. Go to the tab and find the Inbound CRR Bandwidth metric in the Used Bandwidth section. This metric shows the bandwidth used to transfer data to the destination bucket during CRR. For more information, see Record bandwidth usage for a bucket.
Risk of overwriting objects with the same name
Since you can write to both buckets simultaneously, a replicated object from the source can overwrite an existing object with the same name in the destination.
Limitations
Region limitations
You must enable transfer acceleration to configure CRR between a region in the Chinese mainland and a region outside the Chinese mainland.
Number of rules
Data in a source bucket can be replicated to multiple destination buckets. A single bucket can be associated with a maximum of 100 replication rules.
If your use case requires more than 100 replication rules, contact technical support.
Operation limitations
The source and destination buckets must have the same versioning state. The state cannot be suspended.
You cannot change the versioning state of two buckets in a replication relationship.
Because you can perform operations on both buckets while a replication rule is active, a replicated object from the source can overwrite a same-named object in the destination.
A bucket is limited to 100 replication rules, regardless of whether it is the source or destination. If your use case requires more, contact technical support.
You cannot replicate Cold Archive or Deep Cold Archive objects from a source bucket to a destination bucket, regardless of whether the objects have been restored.
You cannot replicate Appendable objects from a source bucket to a destination bucket whose storage class is Cold Archive or Deep Cold Archive.