S3 Cross-Region Replication: a resilience and DR guide

S3 Replication copies objects asynchronously from one bucket to another. Point it at a bucket in a different AWS Region and it is Cross-Region Replication (CRR), the feature most teams reach for when they want a second copy of critical data that survives losing a Region. Keep the destination in the same Region and it is Same-Region Replication (SRR), used for log aggregation, account isolation, or keeping a copy that satisfies data-residency rules without ever leaving the Region. Same mechanism, different blast radius.

Here is the thing the marketing page does not tell you. Creating a replication rule is the easy half, and it is the half that gives you a green tick and a false sense of safety. The half that actually buys resilience is harder: deciding which buckets are critical enough to warrant a second copy, getting the existing objects across, choosing how deletes behave, and verifying the replica is complete before an outage tests it for you. This guide walks the whole path, and ends on the part nobody owns: the critical bucket that was never replicated at all.

What S3 Replication actually does

Replication is asynchronous, version-aware copying. You attach a replication rule to a source bucket, and from that point on S3 copies qualifying object versions to the destination bucket, along with their metadata and tags. The copy is eventually consistent and usually lands within seconds to minutes, but by default it carries no timing guarantee. A rule can cover the whole bucket or be scoped to a prefix or an object tag, so you can replicate a critical prefix while leaving scratch data behind. The replica can even use a different storage class and a different owner from the source, which is useful when the destination is a separate account with its own cost and access model.

Cross-Region versus Same-Region: when to use each

The only mechanical difference is where the destination bucket lives, but the use cases pull in opposite directions. Cross-Region Replication puts the copy in a different AWS Region, which is what you want for disaster recovery: a single Region is a single point of failure, and CRR gives you a live second copy somewhere a regional outage cannot reach. Same-Region Replication keeps the copy in the same Region, which has no disaster-recovery value against a regional event but solves a different set of problems.

• Use CRR when the goal is regional resilience, lower-latency access from a second geography, or a recoverable copy outside the Region the original lives in.
• Use SRR when you need to aggregate logs from many buckets into one, isolate a copy into a separate account for blast-radius or access reasons, or satisfy a compliance or data-residency rule that requires a second copy without leaving the Region.
• The cost profiles differ too: CRR incurs cross-Region data transfer out on every byte replicated, while SRR has no inter-Region transfer because the copy never crosses a Region boundary.

The prerequisite that catches everyone: versioning

Replication tracks object versions, not just keys, so versioning must be enabled on both the source and the destination bucket. This is enforced, not advisory: without versioning on both sides, the replication configuration will not apply. Enable it on both buckets before you do anything else, because every other step assumes it is already in place. This single prerequisite is the most common reason a first attempt fails, and it is the first thing to check when a rule refuses to take.

Setting it up: the rule, the role, and RTC

Once both buckets are versioned, a replication rule needs an IAM role that S3 can assume to do the work, granting permission to read objects from the source and replicate them to the destination. With the role in place you apply the rule, scoped to the whole bucket or to a prefix or tag. Two behaviours are opt-in and worth choosing deliberately: replica modification sync, which propagates changes made on the replica back to the source for bidirectional setups, and delete-marker replication, which controls whether a delete on the source places a delete marker on the destination. Leave delete-marker replication off and the destination keeps objects the source has dropped, which leans towards a backup posture; turn it on and the buckets stay a closer mirror.

If the source objects are encrypted with SSE-KMS, replication needs extra configuration: the IAM role needs KMS permissions, and you specify the destination KMS key the replica will be encrypted under. Skip this and KMS-encrypted objects silently fail to replicate while everything else looks healthy.

For buckets whose downstream consumers have timing assumptions, Replication Time Control (RTC) converts best-effort replication into a contract: a 15-minute replication SLA backed by CloudWatch metrics so you can alarm on lag. RTC costs extra, so you enable it where the timing genuinely matters rather than everywhere by default.

The trap: existing objects do not replicate

By default, a replication rule only copies objects written after the rule was created. The objects already sitting in the bucket, frequently the bulk of the data, do not move. Teams enable replication on a long-lived bucket, watch new writes show a COMPLETED replication status, and assume they now hold a full second copy. They do not. The history stays unreplicated until you run a one-time S3 Batch Replication job to back-fill it. Enabled replication and a complete second copy are two different states, and the gap between them is exactly the data you already had, which is exactly the data you reach for during a real recovery.

What it costs

Replication is the rare improvement that raises the bill on purpose, so it pays to know what you are buying. You pay for storage of the replicated data in the destination, which roughly doubles the storage cost for anything you mirror. You pay a per-request charge for the replication PUT operations. For CRR you pay cross-Region data transfer out on every byte replicated, including a one-time charge to seed existing objects when you back-fill; SRR has no inter-Region transfer because nothing crosses a Region. And if you enable RTC, you pay an additional premium for the SLA. None of this is a reason to avoid replication on data you cannot lose, but it is the reason replication is a per-data-class decision rather than a blanket one: replicating regenerable or ephemeral data is money spent buying down a risk that does not exist.

What replication does not protect against

This is the misconception that costs people their data. Replication is a copy mechanism, not a safety net against your own mistakes. With delete-marker replication enabled, a delete on the source propagates a delete marker to the destination, so an accidental deletion or a ransomware event that wipes the source can be mirrored straight onto the copy you were relying on. Replication keeps two buckets in step; it does not give either of them a memory of what was there before. For protection against accidental or malicious deletion you need a different set of controls layered on top.

• Versioning, so a deleted object leaves a recoverable previous version behind rather than vanishing.
• MFA delete, so permanently removing a version requires a second factor and cannot be done casually or by a compromised credential.
• S3 Object Lock, so objects are immutable for a retention period and genuinely cannot be deleted or overwritten, by anyone, until it expires.

Replication answers the question can I survive losing the Region. Versioning, MFA delete, and Object Lock answer can I survive someone, or something, deleting the data. You need both conversations, and replication only covers the first.

Turning it on is the easy part

By now the shape of the problem should be clear. Creating the rule, attaching the role, ticking RTC: that is the work that takes an afternoon and produces a reassuring green status. The work that actually buys resilience is the part that does not show up on a dashboard tick. Which buckets did you decide were critical enough to replicate, and who made that call? Did you back-fill the history, or is your replica a half-populated hypothesis? Did you verify a real read from the destination Region, proving IAM, KMS access, and bucket policy all line up, or are you trusting a status field? And most of all: which critical bucket did nobody replicate at all, because it was never on anyone's list?

Switching replication on is the cloud doing its job. Owning resilience is yours: decide which buckets are critical, prove the second copy is complete, and find the one bucket nobody replicated before an outage finds it for you.

A disaster-recovery plan built on a replica you have never failed over to is not a plan, it is an assumption that fails precisely when you depend on it. The valuable half of replication is not the configuration. It is the coverage: a short, owned list where every critical data store has an explicit, named, dated decision about whether it survives losing a Region, and a way to know that the decision still holds.