Cross-account same-region replication - Object Storage Service

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

Configuring cross-account SRR involves three steps that require actions in both the source and destination accounts:

Source account: Create a RAM role dedicated to data replication and grant it the minimum permissions required to read data from the source bucket.
Destination account: Modify the destination bucket policy to allow the RAM role created in the source account to write data to the bucket.
Return to the source account: Create an SRR rule to associate the source and destination buckets, which starts the replication task.

Step 1: Create and authorize a RAM role

Create a RAM role. Go to the Create RAM Role page. For Principal Type, select Cloud Service. For Principal Name, select OSS.
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 initiate the replication task.
1. On the Create Policy page, click the Script 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 you create the policy, go to the Roles page. In the list, find the role you just created and click Add Permissions. In the panel that appears, the principal is automatically populated. Select the custom policy that you created in the previous step, and then click OK.
(Optional) If you plan to replicate KMS-encrypted objects, you must also grant the RAM role permission to access KMS.
1. On the Roles page, find the role you just created and click Add Permissions.
2. In the Add Authorization panel, the principal is automatically filled in. For Policy, select AliyunKMSCryptoUserAccess, and then click Confirm Add Authorization.
Record the role ARN. On the Roles page, find the created RAM role, go to the Basic Information page, and copy the ARN of the role for later use. The ARN is in the following format: acs:ram::{Source Account ID}:role/{Role Name}.

Step 2: Authorize the RAM role and prepare resources

In the destination account, modify the destination bucket policy to allow the RAM role from the source account to write data to the bucket.
1. In the destination account, navigate to the Buckets page and click the destination bucket.
2. In the left-side navigation pane, choose Permission Control > Bucket Policy.
3. Click the Add by GUI tab, and then click Receive Objects to Replicate.
4. In the panel that appears, configure the following parameters:
  - Obtain UID and RAM Role From: Select Source RAM Role ARN for Replication.
  - Source RAM Role ARN for Replication: Enter the RAM role ARN from the source account that you recorded in Step 1.
  - Purpose: Select Cross-account replication.
5. Click Generate Policy, and then click Save.
(Optional) This step is required to replicate KMS-encrypted objects.
1. Log on to the KMS console and go to the Instances page. In the same region as the source bucket, purchase and enable a KMS instance. When you purchase the KMS instance, ensure that Access Management Quantity is 2 or greater, and keep the default settings for other parameters.
  Note
  Cross-account replication of KMS-encrypted objects depends on KMS, and the supported regions are limited by KMS availability. For more information about the regions that support KMS, see Supported regions and endpoints for software key management.
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's ARN from the Basic Information section for later use when you create the replication rule.
3. Set a key policy for the created key. When you set the key policy, add the RAM role ARN from the source account as a Cross-account User and specify the role ARN created in the previous step. For detailed steps, see Set a key policy.
  By default, this operation grants the role necessary permissions, such as for decryption (kms:Decrypt) and data key generation (kms:GenerateDataKey). This allows the role to use this key to create encrypted objects in the target Bucket. Configurations made by using the console wizard typically include the required permissions by default, but if you set a custom key policy by using OpenAPI, you must manually verify that these permissions are correctly added.

Step 3: Create an SRR rule

After you complete the authorization, return to the source account console to create a replication rule and start the task.

In the source account, navigate to the Buckets page and click the source bucket.
In the left-side navigation pane, choose Data Management > SRR.
Click SRR. 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 of the destination bucket, 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 match the specified prefixes are replicated to the destination bucket. By default, you can add up to 10 prefixes. To increase this limit to 100, contact to request an adjustment.
  - Object Tagging:
    Note
    To configure this parameter, the following conditions must be met:
    Tags must already be set on the Object.
    Neither "Replicate Delete Markers" nor "Replicate Delete Operations" is selected.
    After selecting the Configure Rules checkbox, you can replicate Objects with specific tags to the destination bucket. You can add up to 10 tags (key-value pairs). Once tags are added, you can choose one of the following Tag filtering policy:
    - Include all tags: The Object is replicated only if all tags defined in the filtering rule exist on the Object.
    - Include any one tag: The Object is replicated if at least one tag defined in the filtering rule exists on the Object.
      Note
      Tag filtering is currently not supported in the following regions: China (Zhangjiakou), China (Zhongwei), and Mexico.
  - Replicate delete operations: Choose whether to replicate object deletions from the source bucket to the destination bucket. In disaster recovery scenarios, select No to prevent accidental deletions in the source bucket from being replicated to the backup bucket, enhancing data security.
    Note
    After a data replication rule is created, changes to an object's storage class caused by lifecycle rules or the CopyObject operation, and changes to the object's last access time attribute (x-oss-last-access-time) in the source bucket, are not replicated to the destination bucket.
    - No: Replicates new and modified objects. Deleting an object in the source bucket does not affect the destination bucket. This prevents data loss in the destination bucket caused by manual deletions or automatic deletions through lifecycle rules in the source bucket.
      Note
      If versioning is enabled for the source bucket, deleting an object from the source bucket without specifying a version ID creates a delete marker in the source bucket. OSS then replicates this delete marker to the destination bucket.
    - Yes: Replicates create, modify, and delete operations to keep the destination bucket consistent with the source bucket. This ensures data consistency and is suitable for environments where multiple users or applications need to share and access the same dataset. However, with this policy, when an object is deleted from the source bucket either manually or by a lifecycle rule, the corresponding object in the destination bucket is also deleted and cannot be recovered.
    If an Object is uploaded to the source bucket by using multipart upload, the upload of each part is replicated to the destination bucket. The Object that is created after the CompleteMultipartUpload operation is called for all parts is also replicated to the destination bucket. For more information about the replication behavior of SRR with versioning, see SRR with versioning.
  - Replicate historical data: Choose whether to replicate objects that already existed in the source bucket before the rule took effect. 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 KMS encrypted objects: If the source objects are encrypted by using KMS and you want them to remain encrypted in the destination, select Yes and provide the destination KMS key prepared in Step 2. If you select No, KMS-encrypted objects are not replicated to the destination bucket.
    Note
    You can use the HeadObject and GetBucketEncryption operations to query the encryption status of a source object and the destination bucket, respectively.
  - RAM role: From the drop-down list, select the RAM role that you created in the source account in Step 1.
Note
An SRR rule cannot be modified or deleted after it is created. Review all settings carefully before you click OK. To terminate replication, stop data synchronization by disabling the replication task.
After you confirm that all settings are correct, click OK and then Confirm.
The replication task starts 3 to 5 minutes after you configure the SRR rule. You can monitor the replication progress on the SRR tab of the source bucket. Because SRR is asynchronous (near real-time), the time it takes to replicate data to the destination bucket depends on the data size and typically ranges from a few minutes to several hours.

FAQ

Configure permissions with a JSON policy

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

A new policy overwrites any existing bucket policy. Ensure that the new policy includes all required authorization rules.
The Principal field in the policy must be set to the ARN of the RAM role in the source account.
If a role name contains uppercase letters, it must be converted to lowercase when specified in a policy. For example, the role AliyunOssDrsRole must be written as aliyunossdrsrole.
You must accurately specify the UID of the source account, the name of the destination bucket, and the 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}/*"
            ]
        }
    ]
}

Object Storage Service:Cross-account same-region replication

Step 1: Create and authorize a RAM role

Step 2: Authorize the RAM role and prepare resources

Step 3: Create an SRR rule

FAQ

Configure permissions with a JSON policy

Related topics