Cross-account same-region replication - Object Storage Service

Cross-account same-region replication automatically and asynchronously (near real-time) copies objects from a source bucket to a destination bucket in the same region in another Alibaba Cloud account. This feature helps you implement disaster recovery, create isolated cross-account backups, or meet data residency compliance requirements.

To configure cross-account same-region replication, you must perform actions in both the source and destination accounts. The process involves three main steps:

Source account: Create a dedicated RAM role for data replication and grant it the minimum permissions required to read data from the source bucket.
Destination account: Modify the bucket policy of the destination bucket to grant write access to the RAM role from the source account.
Source account (return): Create a Same-Region Replication rule to link the source and destination buckets to start the replication task.

Step 1: Create and authorize a RAM role

Create a RAM role: On the Create RAM Role page, select Cloud Service for Principal Type and Object Storage for Principal Name.
Grant the RAM role permissions to access the source bucket. Create a custom policy that includes only the permissions required for replication to read data from the source bucket and start the replication task.
1. On the Create Policy page, click the JSON Editor tab. Paste the following policy content into the policy editor, and replace src-bucket with the actual source Bucket name.
```
{
   "Version": "1",
   "Statement": [
      {
         "Effect": "Allow",
         "Action": [
            "oss:ReplicateList",
            "oss:ReplicateGet"
         ],
         "Resource": [
            "acs:oss:*:*:src-bucket",
            "acs:oss:*:*:src-bucket/*"
         ]
      }
   ]
}
```
2. After creating the policy, return to the Roles page. Find the role, click Add Permissions, and in the panel that appears, select the custom policy you just created for the Permissions Policy and click OK. The principal is selected automatically.
To replicate KMS-encrypted data, you must also grant the RAM role permission to access KMS.
1. On the Roles page, find the role that you created and click Add Permissions.
2. In the panel, select AliyunKMSCryptoUserAccess for Permissions Policy and click OK. The principal is selected automatically.
Record the role ARN for later use. On the Roles page, find the RAM role that you created and go to its Basic Information page. The format is acs:ram::{Source-Account-ID}:role/{Role-Name}.

Step 2: Grant permissions and prepare resources

Grant the RAM role permission to write to the destination bucket. In the destination account, modify the destination bucket's bucket policy to grant write access to the RAM role from the source account.
1. Log on with the destination account, go to the Bucket List page, and click the destination bucket.
2. In the navigation pane on the left, choose Permissions > Bucket Policy.
3. Click the Visual Editor tab, and then click Authorize to Receive Replicated Objects.
4. In the panel that appears, configure the following parameters:
  - Method to Obtain UID and RAM Role: Select Obtain from the RAM role ARN of the source.
  - Source RAM Role ARN: Enter the RAM role ARN from the source account that you recorded in Step 1.
  - Authorization Purpose: Select Cross-account same-region replication.
5. Click Generate Policy, and then click Save.
(Optional) Configure a KMS key in the destination account. If you want to replicate KMS-encrypted objects, you must first configure a KMS key in the destination account.
1. Log on to the Instance Management page of the KMS console, and in the same region as the source account's bucket, purchase and enable a KMS instance. When you purchase the KMS instance, make sure that the Access Management Quota is greater than or equal to 2 and leave the other parameters at their default settings.
  Note
  Cross-account replication of KMS-encrypted objects depends on KMS. Supported regions are limited by KMS availability. For more information about supported regions, see Software key management supported regions and endpoints.
2. In the KMS instance, create a software key. The key type must be a non-default key (a software key is recommended). After the key is created, record the Key ARN from the Configure Basic Information section for use when you create a replication rule later.
3. Set a key policy for the created key. In the key policy, add the RAM role ARN created by the source account as a Cross-account User. This is the role ARN that you created in the preceding steps. For more information, see Set a key policy.
  By default, this operation grants the role necessary permissions, such as Decrypt (kms:Decrypt) and GenerateDataKey (kms:GenerateDataKey), allowing the role to use this key to create encrypted objects in the target Bucket. The console wizard includes the required permissions by default, but if you set a custom key policy by using the OpenAPI, you must manually confirm that these permissions are correctly added.

Step 3: Create a Same-Region Replication rule

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

Log on with the source account, go to the Bucket List page, and click the source bucket.
In the navigation pane on the left, choose Data Management > SRR.
Click SRR. In the dialog box that appears, configure the following parameters:
1. Set Destination Bucket: Select Specify a bucket in another account, choose the destination bucket's region, and enter the bucket name.
  - Objects to Replicate: Select Synchronize all files or Objects with Specified Prefix. Objects in the source bucket with specified prefixes are replicated to the destination bucket. By default, you can add up to 10 prefixes. To increase the number of prefixes, contact . The limit can be increased to a maximum of 100.
  - Object Tagging:
    Note
    To configure this parameter, you must meet the following conditions:
    You have set object tags.
    You have not selected the Replicate delete markers and Replicate deletes of specific versions options.
    After you select the Configure Rules checkbox, you can copy objects with specified tags to the destination Bucket. You can add up to 10 tags (key-value pairs). After you add the tags, you can select the following tag filtering policies:
    - Include all tags: An object is replicated if all of its tags are included in the tag set specified in the filter rule.
    - Include any one tag: An Object is replicated if any of its tags are in the tag set specified in the filter rule.
  - Replicate KMS-encrypted objects: If the source object is encrypted with KMS and you want the replicated object to remain encrypted, select Replicate and provide the KMS key that you configured in the destination account in Step 2. If you select Do not replicate, OSS does not replicate KMS-encrypted files.
    Note
    You can use the HeadObject and GetBucketEncryption operations to check the encryption status of the source object and the destination bucket, respectively.
  - Role for Authorization: From the drop-down list, select the RAM role you created in the source account in Step 1.
2. Set Replication Policy:
  - Replicate delete operations (This option appears when versioning is disabled for the source bucket): Choose whether to synchronize delete operations from the source bucket to the destination bucket.
    - Yes: Replicates create, update, and delete operations to keep the destination bucket consistent with the source bucket. This is suitable for environments where multiple users or applications need to share and access the same dataset. However, with this setting, when an object is deleted from the source bucket, either manually or by a lifecycle rule, OSS also deletes the corresponding object in the destination bucket, and it cannot be recovered.
    - No: Replicates only new and updated objects. Deleting an object from the source bucket does not affect the destination bucket. In disaster recovery scenarios, selecting No prevents the replication of accidental deletions from the source bucket, which enhances data security.
  - Replicate historical data: Choose whether to replicate objects that existed in the source bucket before you created the replication rule. This operation overwrites objects with the same name in the destination bucket. To prevent data loss, we recommend that you enable versioning for both the source and destination buckets.
  - Replicate delete markers (This option appears when versioning is enabled for the source bucket): Choose whether to replicate delete markers from the source bucket to the destination bucket.
    - Replicate: When an object is deleted from the source bucket without a version ID specified, OSS replicates the delete marker that it creates in the source bucket to the destination bucket. This is suitable for scenarios where you need to share and access the same dataset and ensure data state consistency between the source and destination buckets.
      Important
      If you configure this policy, when an object is deleted from the source bucket, either manually or by a lifecycle rule, OSS also creates a delete marker in the destination bucket, which makes the data in the destination bucket inaccessible.
    - Do not replicate (Recommended for disaster recovery scenarios): OSS does not replicate delete markers created in the source bucket to the destination bucket. This effectively prevents data loss in the destination bucket due to accidental deletions or automated deletions by lifecycle rules in the source bucket.
  - Replicate deletes of specific versions (This option appears when versioning is enabled for the source bucket): Choose whether to replicate the permanent deletion of a specific object version from the source bucket to the destination bucket.
    - Replicate: When a specific version of a source object, including the current and previous versions, is permanently deleted, OSS also permanently deletes the corresponding version in the destination bucket. This is suitable for scenarios that require source and destination data to be completely identical.
      Important
      With this setting, you cannot recover object versions from the destination bucket that are permanently deleted from the source bucket. Use this option with caution.
    - Do not replicate (Recommended for disaster recovery scenarios): When a specific version of a source object is permanently deleted, OSS does not delete the corresponding version in the destination bucket. This prevents permanent delete operations in the source bucket from affecting data security in the destination bucket.
    If an object is uploaded to the source bucket by using a multipart upload, OSS replicates each part upload operation to the destination bucket. OSS also replicates the final object generated after the CompleteMultipartUpload operation. For more information about replication behavior when versioning is enabled, see Same-Region Replication with versioning.
Note
Once created, a Same-Region Replication rule cannot be modified or deleted. Review all configurations carefully before you click OK. To stop replication, you can disable the replication task.
After you confirm that all settings are correct, click OK and then Confirm Enable.
The replication task starts 3 to 5 minutes after the same-region replication rule is configured. You can view the replication progress on the SRR tab of the source bucket. Because same-region replication between buckets is an asynchronous (near real-time) process, the time required to replicate data to the destination bucket depends on the size of the data and typically ranges from a few minutes to several hours.

FAQ

Can I use a JSON policy for bucket permissions?

Yes. You can select Add Policy by Syntax on the bucket policy page of the destination bucket for more flexible configuration. Note the following points when you use a JSON policy:

A new policy overwrites any existing bucket policy. Make sure that the new policy includes all necessary authorization rules.
Set the Principal field in the policy to the ARN of the RAM role in the source account.
If the role name contains uppercase letters, you must convert them to lowercase in the policy. For example, a role named AliyunOssDrsRole should be written as aliyunossdrsrole in the policy.
You must accurately provide the UIDs of the source and destination accounts, as well as the name of the destination bucket.

The following is an example policy:

{
    "Version":"1",
    "Statement":[
        {
            "Effect":"Allow",
            "Action":[
                "oss:ReplicateList",
                "oss:ReplicateGet",
                "oss:ReplicatePut",
                "oss:ReplicateDelete"
            ],
            "Principal": {
                "RAM": [
                    "acs:ram::{Source-Account-ID}:role/{role-name}"
                ]
            },
            "Resource":[
                "acs:oss:*:{Destination-Account-ID}:{Destination-Bucket-Name}",
                "acs:oss:*:{Destination-Account-ID}:{Destination-Bucket-Name}/*"
            ]
        }
    ]
}

Object Storage Service:Cross-account same-region replication

Step 1: Create and authorize a RAM role

Step 2: Grant permissions and prepare resources

Step 3: Create a Same-Region Replication rule

FAQ

Can I use a JSON policy for bucket permissions?

References