CRR across accounts - Object Storage Service - Alibaba Cloud Documentation Center

The cross-region replication (CRR) feature enables you to automatically and asynchronously copy objects from a bucket to a destination bucket in a different region under another Alibaba Cloud account. You can use CRR across accounts for disaster recovery, isolated cross-account backups, or to meet data residency compliance requirements.

Configuring cross-account replication requires operations in both the source and destination accounts. The process involves three steps:

Source account: Create a RAM role for data replication and grant it the least privilege required to read data from the source bucket.
Destination account: Modify the authorization policy of the destination bucket to grant the RAM role from the source account permission to write data to the bucket.
Source account: Return to the source account to create a cross-region replication rule that links the source and destination buckets and starts the replication task.

Step 1: Create and authorize a RAM role in the source account

Create a RAM role: Go to the Create Role page. Set Principal Type to Cloud Service and Principal Name to Object Storage Service.
Grant the RAM role permissions to access the source bucket: Create a custom policy that includes only the permissions required to read data from the source bucket and start the replication task.
1. On the Create Policy page, click the JSON tab. Paste the following policy into the policy editor. Replace src-bucket with the name of your source bucket.
```
{
   "Version": "1",
   "Statement": [
      {
         "Effect": "Allow",
         "Action": [
            "oss:ReplicateList",
            "oss:ReplicateGet"
         ],
         "Resource": [
            "acs:oss:*:*:src-bucket",
            "acs:oss:*:*:src-bucket/*"
         ]
      }
   ]
}
```
2. After you create the policy, go to the Roles page. Find the role that you just created in the list and click Grant Permission. In the Grant Permission panel, the principal is automatically populated. In the Policy field, select the custom policy that you created in the previous step, and then click OK.
(Optional) Grant the RAM role permissions to access KMS: If the data replicated to the destination bucket is encrypted with KMS, you must grant the RAM role access permissions for KMS.
On the Roles page, find the role that you just created in the list and click Grant Permission. In the Grant Permissions panel, the principal is automatically populated. Set Policy to AliyunKMSCryptoUserAccess, and then click OK.
Record the role ARN: On the Roles page, find the RAM role that you created. On the Basic Information page, copy the ARN of the role for later use. The format is acs:ram::{Source Account UID}:role/{Role Name}.

Step 2: Authorize the RAM role and prepare resources in the destination account

Authorize the RAM role to write to the destination bucket: In the destination account, modify the authorization policy of the destination bucket to grant write permissions to the RAM role from the source account.
1. Log on to the destination account and go to the Buckets page. Click the destination bucket.
2. In the navigation pane on the left, choose Permission Control > Bucket Policy.
3. Click the Add in GUI tab, and then click Receive Objects to Replicate.
4. In the panel that appears, configure the parameters as follows:
  - Obtain UID and RAM Role From: Select Source RAM role ARN for replication.
  - Source RAM Role ARN for Replication: Enter the RAM role ARN of the source account that you recorded in Step 1.
  - Purpose: Select Cross-account replication.
5. Click Generate Policy, and then click Save.
(Optional) Configure a destination KMS key: If you want to replicate KMS-encrypted objects or if KMS encryption is enabled for the destination bucket, you must configure a KMS key in the destination account, set a key policy for the key, and grant the RAM role from the source account permission to use the key. When you set the key policy, add the ARN of the RAM role that is created in the source account as an Other Account User.
This operation grants the role the necessary permissions by default, such as decryption (kms:Decrypt) and data key generation (kms:GenerateDataKey). This allows the role to use this key to create encrypted objects in the destination bucket. The console wizard typically includes the required permissions by default. However, if you set a custom key policy using OpenAPI, you must manually ensure that these permissions are correctly added.

Step 3: Create a cross-region replication rule in the source account

After you grant the permissions, return to the console of the source account to create a replication rule and start the task.

Log on to the source account and go to the Buckets page. Click the source bucket.
In the navigation pane on the left, choose Data Management > CRR.
Click CRR. In the dialog box that appears, configure the following parameters:
1. Configure Destination Bucket: Select Specify a bucket that belongs to another Alibaba Cloud account. Select the region where the destination bucket is located and enter its name.
2. Configure Replication Policy:
  - Objects to Replicate: Select All Objects in Source Bucket or Objects with Specified Prefix. Objects in the source bucket that have the specified prefix are replicated to the destination bucket. By default, you can add up to 10 prefixes. To increase the prefix limit, contact to request an increase. The limit can be increased to a maximum of 30.
  - Copy and delete operation: Select the data synchronization method. For disaster recovery scenarios, select No to prevent accidental deletions in the source bucket from being replicated to the backup bucket. This enhances data security.
    - No: Replicates only new and modified objects. Deletions of objects in the source bucket do not affect the destination bucket. This method prevents data loss in the destination bucket that is caused by manual deletions or automatic deletions by lifecycle rules in the source bucket.
    - Yes: Replicates new objects, modified objects, and delete operations to keep the destination bucket consistent with the source bucket. This method ensures data consistency and is suitable for multi-user or application environments that need to share and access the same dataset. However, if you select this policy, when an object in the source bucket is deleted manually or automatically by a lifecycle rule, the corresponding object in the destination bucket is also deleted and cannot be recovered.
  - Replicate Historical Data: Select whether to replicate existing data in the source bucket that existed before the rule was created. This operation overwrites objects that have the same name in the destination bucket. To avoid data loss, enable versioning for both the source and destination buckets.
  - Replicate Objects Encrypted Based on KMS: If the source objects are encrypted with KMS and you want them to remain encrypted in the destination bucket, select this option. Provide the ARN of the destination KMS key that you prepared in Step 2.
    Note
    You can query the encryption status of the source object and the destination bucket using HeadObject and GetBucketEncryption, respectively.
  - RAM Role Name: From the drop-down list, select the RAM role created in the source account in Step 1.
3. Configure Replication Speed:
  - Acceleration Type: If a replication task involves regions in the Chinese mainland and outside the Chinese mainland, you can enable this feature to improve data transfer speed. This feature incurs additional transfer acceleration fees.
Note
After a cross-region replication rule is created, it cannot be modified or deleted. Carefully review all configuration items before you click OK. To terminate replication, you can disable the replication task.
After you confirm that all configurations are correct, click OK. Inthe dialog box that appears, check I have read and agree to the preceding compliance commitment and then click Enable.
The replication task starts within a few minutes after the rule is successfully created. Data replication is an asynchronous process. The time required depends on the object size, number of objects, and cross-region network latency, and can range from a few minutes to several hours. You can view the replication progress, including the synchronization status of historical and incremental data, on the CRR tab of the source bucket.

FAQ

Why are changes to an object's storage class or last access time in the source bucket not synchronized to the destination bucket?

Data replication is triggered only by changes to object content, such as additions, deletions, or modifications. Changing the storage class using a lifecycle rule or a CopyObject operation, or updates to the last access time (LastAccessTime), do not involve writing new object content. Therefore, these actions do not trigger a new replication task, and the object replica in the destination bucket is not updated.

Solutions:

Synchronize storage class: Configure a lifecycle rule on the destination bucket that is identical to the one on the source bucket. This ensures the same storage class transitions.
Update LastAccessTime: To update the last access time of the destination object, access the object directly in the destination bucket. For example, you can perform a GetObject request to trigger a refresh of its LastAccessTime.

Are objects uploaded using multipart upload replicated?

When an object is uploaded using multipart upload, each part upload operation is replicated to the destination bucket. After the parts are merged in the source bucket (CompleteMultipartUpload), the complete object is also replicated to the destination bucket.

Is there a simpler way to grant permissions to the source account's RAM role than using a custom policy?

Yes. For quick authorization, you can directly grant the AliyunOSSFullAccess system policy provided by Alibaba Cloud to the RAM role that you created. However, this policy grants all permissions for all OSS resources under your account. Because its scope is too broad, this policy is not recommended for use in a production environment.

Besides the graphical interface, can I configure permissions for the destination bucket using a JSON policy?

Yes. On the Bucket Policy page of the destination bucket, you can select Add Rule by Syntax for more flexible configuration. Keep the following points in mind when you use a JSON policy:

A newly added policy overwrites any existing bucket policy. Ensure that the new policy includes all required authorization rules.
The Principal field in the policy must contain the ARN of the RAM role from the source account.
If the role name contains uppercase letters, you must convert them to lowercase in the policy. For example, the role AliyunOssDrsRole should be written as aliyunossdrsrole in the policy.
You must enter the correct UID of the source account, name of the destination bucket, and UID of the destination account.

The following is an example policy:

{
    "Version":"1",
    "Statement":[
        {
            "Effect":"Allow",
            "Action":[
                "oss:ReplicateList",
                "oss:ReplicateGet",
                "oss:ReplicatePut",
                "oss:ReplicateDelete"
            ],
            "Principal": [
                "arn:sts::{Source Account UID}:assumed-role/{Role Name}/*"
            ],
            "Resource":[
                "acs:oss:*:{Destination Account UID}:{Destination Bucket Name}",
                "acs:oss:*:{Destination Account UID}:{Destination Bucket Name}/*"
            ]
        }
    ]
}