S3 replication is not a backup until you fix three defaults: notes from a Cloud Quest lab
Replication copies new objects to a second bucket, but by default it skips existing objects and KMS-encrypted data, and it shares the fate of the account it lives in. What I set up in the lab and what I would change.
TL;DR: S3 replication copies new objects to a second bucket, but by default it skips everything already in the bucket, skips SSE-KMS objects, and gives no protection against someone with delete rights in the same account. Fix those three before you call the replica a backup.
One of the Cloud Quest Security assignments had me set up replication between a log bucket and a backup bucket. The validator went green in a few minutes. Reading what the console had actually configured took longer, and it changed how I think about "we replicate it, so it is backed up."
What the lab had me build
The setup was small: a primary log bucket, a backup bucket, and an IAM role (s3_replication_role) that S3 assumes to copy objects. Versioning had to be enabled on both buckets first, because a replication rule cannot be saved without it. Then one rule covering all objects, the backup bucket as the destination, and a test upload to confirm the copy arrived.
Default 1: existing objects are not copied
Right after saving the rule, the console asked whether to replicate existing objects. The lab left that off, which is fine for an empty bucket. In a real account the question matters: a replication rule only applies to objects written after it is enabled. Everything already in the bucket needs S3 Batch Replication, a separate job you run and pay for. Add replication to a bucket holding three years of logs and the replica starts empty.
Default 2: deletes are not mirrored, and that is the point
With the current rule format, delete markers are not replicated unless you turn on delete marker replication, and permanently deleting a specific version is never replicated. That sounds like a gap, but it is the security feature: if someone deletes objects in the primary, the replica still has them. The catch is that the replica is only as safe as the account it lives in. In the lab both buckets sat in the same account, so anyone with s3:DeleteObjectVersion on both could still wipe both copies.
Default 3: KMS-encrypted objects are skipped
Objects encrypted with SSE-KMS are not replicated unless the rule explicitly opts in to them and names a destination key. The replication role also needs kms:Decrypt on the source key and kms:Encrypt on the destination key. Miss either one and those objects just show a FAILED status. Sensitive data is usually the data on SSE-KMS, so this is the default that hurts most.
How to check it actually worked
The lab's validator only told me the setup passed. The check worth running yourself is per object, because every object in the source bucket carries a replication status:
1
2
3
4
aws s3api head-object \
--bucket <primary-log-bucket> \
--key DIY_Courses.txt \
--query ReplicationStatusThe source object moves from PENDING to COMPLETED, and the copy in the backup bucket reports REPLICA. FAILED is the status worth alarming on, and S3 can send an event notification for failed replication so you are not relying on a manual check.
What I would do in a real account
- Put the destination bucket in a separate backup account, with a bucket policy that only lets the replication role write to it.
- Deny s3:DeleteObjectVersion on the destination for everyone except a break-glass role, and look at Object Lock if you need compliance-grade retention.
- Opt in to SSE-KMS replication and give the role both key permissions.
- Run S3 Batch Replication once for the objects that existed before the rule.
- Alert on failed replication, not just on a green dashboard.
The lab taught me how to make replication work. Reading the defaults taught me that working replication and a working backup are two different things.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article