Object Storage Service:CRR across accounts

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

1. Source account: Create a RAM role for data replication and grant it the least privilege required to read data from the source bucket.

2. 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.

3. Source account: Return to the source account to create a CRR 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

1. To create a RAM role, go to the Create Role page and set Principal Type to Cloud Service and Principal Name to Object Storage Service.

2. 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 Script Editor tab. Paste the following policy into the 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 and click Grant Permission. In the Grant Permission panel, the principal is automatically populated. For the Policy parameter, select the custom policy that you created in the previous step, and then click OK.

3. (Optional) Grant the RAM role permissions to access KMS: If the data to be 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 you just created and click Grant Permission. In the Grant Permission panel, the principal is automatically populated. Set Policy to AliyunKMSCryptoUserAccess and click OK.

4. On the Roles page, find the RAM role that you created. On the Basic Information page, copy the role ARN for later use. The ARN is in the format acs:ram::{Source Account UID}:role/{Role Name}.

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

1. 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 Access 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.

2. (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 to 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 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.

1. Log on to the source account and go to the Buckets page. Click the source bucket.

2. In the navigation pane on the left, choose Data Management > Cross-Region Replication.

3. Click Cross-Region Replication. 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 Synchronize all files 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 . The limit can be increased to a maximum of 30.

      • Replicate Delete Operations: Select whether to replicate the deletion of an object from the source bucket to the destination bucket. 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 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 caused by manual deletions or automatic deletions by lifecycle rules in the source bucket.

          Note

          If versioning is enabled for the source bucket, when you delete an object from the source bucket without specifying a version ID, OSS creates a delete marker in the source bucket. This delete marker is replicated to the destination 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 data that existed in the source bucket 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 KMS-encrypted Objects: If the source objects are encrypted with KMS and you want them to remain encrypted in the destination bucket, select Replicate. Provide the ARN of the destination KMS key that you prepared in Step 2. If you select Do not replicate, KMS-encrypted files are not replicated to the destination bucket.

        Note

        You can query the encryption status of the source object and the destination bucket using HeadObject and GetBucketEncryption, respectively.

      • RAM Role: From the drop-down list, select the RAM role created in the source account in Step 1.

   3. (Optional) Configure Replication Acceleration:

      • Transfer Acceleration: 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.

      • Replication time control (RTC): When enabled, this feature keeps the replication delay for most incremental data within 10 minutes. This feature is supported only between specific regions and incurs additional RTC fees for cross-region replication. For more information, see RTC feature overview.

4. After you confirm that all configurations are correct, click OK and then Confirm 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 Cross-Region Replication 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. Changes to the storage class made by 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:

• To synchronize the 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.

• To update LastAccessTime: Access the object directly in the destination bucket. For example, 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, the upload of each part is replicated to the destination Bucket. After the merge (CompleteMultipartUpload) is complete in the source Bucket, the complete object is then replicated as a whole 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, there is. 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, you can. 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 a policy example:

{
    "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}/*"
            ]
        }
    ]
}