S3 replication and Object Lock: requirements and surprises
The requirements for S3 replication (versioning on both buckets, a role, ownership and ACL grants, Object Lock pairing, cross-account bucket policy) and how Object Lock retention modes and legal holds behave — including why deletes return 403 or create delete markers and what even the root user cannot undo.
markdownreferencev4THC2-NRX3stage: referencetrust: officialservice: s3interface: anyS3 replication requirementsreplication FAILED statusversioning requiredcross-region replicationObject Lockgovernance modecompliance modelegal holds3:BypassGovernanceRetentionx-amz-bypass-governance-retentiondelete markerObject Lock 403 deletereplication Object LockAbortIncompleteMultipartUpload destination
S3 replication and Object Lock
Replication needs versioning on both buckets and a role S3 can use. Object Lock in compliance mode can't be undone by anyone, including the root user, before the retention date. Turn compliance mode on deliberately.
Replication requirements
| Requirement | If missing |
|---|---|
| Source and destination Regions enabled for the respective owners | Replication can't be configured |
| Versioning on both buckets | Configuration refused. Suspending versioning on the source is blocked while replication is configured; suspending it on the destination makes source objects show FAILED |
| A role S3 assumes, with permissions to read the source and replicate to the destination (details on "Setting up permissions for live replication": not fetched) | Nothing replicates |
Objects the source bucket owner doesn't own: the object owner grants the bucket owner READ and READ_ACP (object ACL) | Those objects don't replicate. With Bucket owner enforced, the bucket owner owns everything anyway (reference/s3/access-control.md) |
Source with Object Lock → destination must have Object Lock too. Configure through CLI, API or SDK (not the console), and give the role s3:GetObjectRetention and s3:GetObjectLegalHold | Replication fails for locked objects |
| Cross-account: the destination bucket policy grants the source owner replication permissions | FAILED replicas |
| Destination isn't Requester Pays | Not allowed |
Also:
- Replicas keep the original creation time for lifecycle rules on the destination.
- Multipart objects replicate as multipart uploads. Add an
AbortIncompleteMultipartUploadlifecycle rule on the destination. - Batch Replication and copies count as access for Intelligent-Tiering.
KMS-encrypted objects, delete-marker behaviour, what isn't replicated, and Batch Replication for existing objects are on pages not collected yet (UNVERIFIED here).
Object Lock
Object Lock requires versioning and protects individual object versions.
| Mechanism | Who can remove or shorten it |
|---|---|
| Governance retention | Users with s3:BypassGovernanceRetention, sending x-amz-bypass-governance-retention: true |
| Compliance retention | Nobody, not even the root user. The mode can't be changed and the period can't be shortened. Only deleting the AWS account removes it early |
| Legal hold | No expiry. Anyone with s3:PutObjectLegalHold can remove it. Independent of retention |
- Retention can be a fixed retain-until date, or event-based (a hold plus a duration, with the date set when the hold is released). A default retention can be set on the bucket.
- Extending retention needs
s3:PutObjectRetention. - Deletes:
- A delete with a version ID on a locked version returns 403 Access Denied.
- A delete without a version ID returns 200 OK and only adds a delete marker; the protected version stays, and so does its storage charge.
So a "403 on delete" in a locked bucket isn't an IAM problem (guides/s3/fix-403.md). Check aws s3api get-object-retention and get-object-legal-hold on that version.
Whether Object Lock can be enabled on an existing bucket wasn't stated on the fetched page.