This topic describes how replication (including cross-region replication and same-region replication) interacts with versioning, a lifecycle rule, server-side encryption, and a retention policy.
Replication with versioning
When you use replication with versioning, the following limitations apply:
You can enable replication only between two buckets that have the same versioning state. Both the source and destination buckets must have versioning enabled, or both must have it disabled. You cannot change the versioning state of either bucket while replication is active.
You cannot suspend versioning on the source or destination bucket during replication. To suspend versioning, you must first delete the replication rule.
Deleting an object from a versioning-enabled source bucket can result in the following scenarios:
Delete request type | Replication policy | Result |
Delete request without a specified version ID | Sync additions and modifications | OSS creates a delete marker in the source bucket and replicates it to the destination bucket. |
Sync additions, deletions, and modifications | ||
Delete request with a specified version ID | Sync additions and modifications | The specified version is deleted from the source bucket only. The destination bucket retains the object. |
Sync additions, deletions, and modifications | The specified version is deleted from both the source and destination buckets. |
Replication with lifecycle rules
Using replication with versioning can create multiple noncurrent versions in the destination bucket, which increases storage costs. To reduce storage costs, you can use a lifecycle rule to define a custom data retention policy.
When you use replication with a lifecycle rule, note the following:
Replication propagates the effects of a lifecycle rule from the source bucket, but not the rule itself. To apply the same rule to the destination bucket, you must also configure it on that bucket.
Replicated objects in the destination bucket retain the original object's creation time, not the replication time.
If a lifecycle rule deletes an object in the source bucket during replication, the replication process may still complete. In this case, the replicated object remains in the destination bucket.
When you use cross-region replication for a versioning-enabled bucket, delete markers from the source bucket are replicated to the destination bucket. This makes the delete marker the current version of the object in the destination bucket, and the previous current version becomes a noncurrent version. If the destination bucket has a lifecycle rule that cleans up noncurrent versions (for example, deleting them after one day), the object is permanently deleted when the rule's conditions are met. Therefore, carefully configure any lifecycle rule that cleans up noncurrent versions to avoid unintended data loss in the destination bucket.
Replication with server-side encryption
Replication supports unencrypted objects and objects encrypted by using either SSE-KMS (KMS-managed keys) or SSE-OSS (OSS-managed keys). For more information, see server-side encryption.
When you use SSE-KMS, the encryption key depends on whether you specify a CMK ID.
If you do not specify a CMK ID, the default CMK ID managed by KMS is used for encryption and decryption.
If you specify a CMK ID, the specified CMK ID is used for encryption and decryption.
When you use replication with server-side encryption, one of the following scenarios occurs:
Source object encryption | Destination bucket encryption | Replication rule configuration | Destination object encryption | Description |
Unencrypted | Unencrypted | - | Unencrypted | Based on the destination bucket's encryption method. |
SSE-OSS | SSE-OSS | |||
SSE-KMS (no CMK ID) | SSE-KMS (no CMK ID) | |||
SSE-KMS with CMK ID1 | No CMK ID configured | SSE-KMS with CMK ID1 | The CMK ID in the replication rule takes precedence. | |
CMK ID2 configured | SSE-KMS with CMK ID2 | |||
SSE-OSS | - | - | SSE-OSS | Based on the source object's encryption method. |
SSE-KMS | - | Do not replicate KMS-encrypted objects | Not replicated | Based on the replication rule configuration. |
CMK ID configured | SSE-KMS with the specified CMK ID |
Replication with retention policies
When a bucket's retention policy (WORM) is locked, you can upload and read objects in the bucket, but you cannot modify (overwrite) or delete objects until their retention period expires.
For more information about this feature, see retention policy.
When you use replication with a retention policy, one of the following scenarios occurs:
Source WORM protection | Operation in source bucket | Destination WORM protection | Operation replication |
No | Add object | Yes | No |
Overwrite object | Yes | No | |
Delete object | Yes | No | |
No | Add object | No | Yes |
Overwrite object | No | Yes | |
Delete object | No | Yes | |
Yes | Add object | N/A | Yes |