skip to content

Your team proposes relying on Amazon S3 Cross-Region Replication as protection against someone accidentally deleting production objects. Which deletions does S3 replication propagate to the destination, which does it never propagate, and why is replication still a poor substitute for backup?

level: seniorimportance: should knowfreq 50%

answer

  1. two kinds of delete, two behaviours
  2. marker replication is opt-in per rule
  3. version-ID deletes never propagate, on purpose
  4. mirror of now, not history
  5. overwrites replicate within minutes

basics

~20 s

S3 replication optionally propagates delete markers if the rule enables delete-marker replication, but it never propagates a DELETE that names a specific version ID. Replication mirrors live state rather than preserving history, so it protects against losing a Region or a bucket, not against a person or process destroying data.

solid answer

~50 s

There are two kinds of delete in a versioned S3 bucket, and replication treats them very differently. A plain `DELETE` on a key creates a **delete marker**, and whether that marker is copied to the destination is a per-rule choice — delete-marker replication is off unless you enable it, and it is not available on rules that filter by object tags. A `DELETE` that specifies a **version ID** permanently removes that version, and S3 never replicates it — deliberately, so that a destructive action on the source cannot cascade into the replica. Delete markers created by S3 Lifecycle expiration are also not replicated. The wider point is that replication mirrors the current state of the source; it is not a point-in-time copy, so a bad overwrite replicates immediately and there is no snapshot to roll back to. Real protection comes from versioning with noncurrent-version retention, restrictive delete permissions, Object Lock where immutability is required, and a separate backup with its own retention.

go deeper

for a junior

Know that deleting an object in a versioned S3 bucket writes a delete marker rather than erasing data, and that replication copying that marker is an option on the rule, not automatic.

for a middle

Explain both delete paths and their replication behaviour, including that version-ID deletes are never replicated and that delete-marker replication is unavailable on tag-filtered rules.

for a senior

Push back on the proposal with the failure modes: corrupt overwrites replicate immediately, lifecycle expiries drift the two buckets apart, and recovery depends on retained versions rather than on the replica existing.

for a principal

Own the data-protection architecture: which risks are covered by versioning and permissions, which need immutability, which need an independently retained backup, and where cross-Region replication genuinely earns its ongoing cost.

## Two deletes, two behaviours In a versioned S3 bucket, "delete" is ambiguous, and the ambiguity is exactly what this question tests. **A simple `DELETE` on a key** does not remove data. It writes a **delete marker** as the new current version; the previous versions remain and the object stops appearing in a plain `ListObjects` result. Whether that marker travels to the replica is controlled by the rule's `DeleteMarkerReplication` status. In the current (V2) replication configuration it is a required field once a filter is present, and it defaults to disabled in most tooling. Delete-marker replication is **not supported for rules whose filter selects objects by tag**, which is a genuine surprise for teams that filter that way. **A `DELETE` that specifies a version ID** permanently destroys that version. S3 **never** replicates it. This is intentional design, not an omission: if a compromised credential or a buggy script purges versions in the source, the whole point of the second copy is that it does not follow. The consequence is that the two buckets legitimately diverge. That is a feature for durability and a hazard for anyone who assumed the destination is a mirror. ## What else never travels Beyond deletes, several source-side actions are invisible to replication: - **Delete markers created by S3 Lifecycle expiration** are not replicated. A lifecycle rule that expires current versions on the source leaves the destination untouched, so the two buckets drift apart on a schedule. - **Lifecycle transitions on the source** are not mirrored either. The destination bucket needs its own lifecycle configuration if you want the replica to age the same way — and often you deliberately want different retention there. - **Objects that existed before the rule was created** are never replicated by live traffic. - **Objects already in S3 Glacier Flexible Retrieval or S3 Glacier Deep Archive** in the source are not replicated. - **Objects that arrived in the source by replication from another bucket** are not chained onward by a live rule. ## Why replication is not backup A backup has three properties replication lacks: 1. **Point-in-time recovery.** Replication mirrors the current state. If an application overwrites a million objects with corrupted content, those corrupt versions replicate within minutes and are now the current version in both buckets. Recovery depends entirely on versioning retaining the previous versions, not on replication. 2. **Independent retention.** A backup keeps history according to a policy you control. Replication keeps whatever the source currently has, modulated by the destination's own lifecycle rules. 3. **A different failure domain for the control plane, not just the data plane.** Replication does isolate the copy — especially cross-account SRR, where the application's credentials cannot reach the destination. But if the same automation manages both buckets, the same mistake reaches both. What replication genuinely protects against: losing the source Region, losing the source bucket wholesale, or needing a copy under different ownership. Those are real risks and worth engineering for. They are simply not the risk in the proposal. ## What the correct answer looks like For accidental-deletion protection on the **source** side: - keep **versioning** on and set noncurrent-version expiration long enough to cover your detection window, so a delete marker or a bad overwrite can be undone by removing the marker or restoring the prior version; - deny `s3:DeleteObjectVersion` to application roles entirely, so no routine credential can perform the destructive delete in the first place; - where immutability is a compliance requirement rather than a convenience, use **Object Lock**, which prevents version deletion for a retention period; - and keep a real backup with its own retention and its own credentials for the cases none of the above cover. Replication then sits alongside these as the Regional-resilience layer, which is the job it is actually good at. ## Saying it crisply "Replication will copy delete markers only if we turn that on, and it will never copy a version-ID delete — that is by design. So a person who truly purges versions in the source purges them only there, and a person who overwrites data has that overwrite replicated in minutes. Replication buys us Region and bucket loss. Accidental deletion is a versioning, permissions and Object Lock problem, plus a backup with independent retention."

  • If delete-marker replication is enabled, can a deleted object still be recovered from the destination?
    Usually yes, because the marker is only a new current version — the earlier versions still exist in the destination unless its own lifecycle rules expired them. You recover by deleting the marker or by reading the previous version ID directly. That also shows why the destination's noncurrent-version retention matters as much as the source's.
  • Why does AWS deliberately refuse to replicate version-ID deletes?
    Because the second copy exists to survive destructive actions against the first. If a purge propagated, one compromised credential or one bad script would erase both copies simultaneously and the replica would add nothing to your recovery posture. The asymmetry is the safety property, even though it means the buckets diverge.
  • What breaks if a rule filters by object tags and the team expects deletes to propagate?
    Delete-marker replication is not supported for tag-based filter rules, so markers silently do not travel while object writes do. The destination keeps serving an object the source considers deleted, which is a correctness problem for any consumer treating the replica as authoritative. If deletes must propagate, filter by prefix instead.
  • Does an overwrite of an object on the source reach the destination?
    Yes — an overwrite creates a new object version, and new versions are exactly what replication copies, typically within minutes. That is why replication offers no protection against data corruption: the corrupt content becomes the current version in both buckets, and recovery depends on the previous versions still being retained.

saying these in an interview costs you the question

  • Calling cross-Region replication a backup strategy
  • Assuming deletes always propagate to the replica
  • Thinking a version-ID delete is mirrored to the destination
  • Expecting lifecycle expiries on the source to reach the replica
  • Believing replication gives point-in-time recovery

context

resolving links…