skip to content

In Amazon S3, what is the difference between Cross-Region Replication (CRR) and Same-Region Replication (SRR), and what does each one solve?

level: juniorimportance: should knowfreq 68%

answer

  1. same feature, different destination
  2. geography versus account boundary
  3. versioning on both buckets, always
  4. asynchronous copy plus an assumed role
  5. CRR pays inter-Region transfer

basics

~20 s

Both are the same S3 replication feature and differ only in where the destination bucket lives. CRR copies objects to a bucket in another AWS Region for disaster recovery, lower read latency, or data-residency rules. SRR copies within one Region, typically across accounts or for log aggregation.

solid answer

~50 s

S3 replication is one feature with one rule format; CRR and SRR are just names for whether the destination bucket sits in a different Region or the same one. Both are asynchronous, both require versioning enabled on the source **and** destination buckets, and both need an IAM role that S3 assumes to read from the source and write to the destination. I reach for CRR when I need a copy that survives a Regional problem, when readers in another Region need lower latency, or when a regulation says a copy must exist in a particular country. I reach for SRR when the copy is about **isolation rather than geography** — pushing logs from many accounts into one central bucket, handing a sanitised copy to a different account or team, or keeping a second copy under separate credentials. Cross-account works with either.

go deeper

for a junior

Be able to say plainly that both copy objects from one S3 bucket to another automatically, that the only difference is whether the destination is in another Region, and that both buckets need versioning turned on.

for a middle

Explain the mechanics: rules with filters and priorities on the source bucket, an IAM role S3 assumes, asynchronous copy, replicas sharing the source version ID, and the option to change storage class or ownership at the destination.

for a senior

Justify the choice against a real requirement. Say what CRR buys that a CDN or a nightly copy job does not, price in the inter-Region transfer, and be clear about which failure modes a replica does and does not cover.

for a principal

Own the posture question: which datasets warrant a continuously replicated second copy at all, whether the second copy belongs in another Region or another account, and how that decision interacts with recovery objectives, residency obligations, and the ongoing storage and transfer bill.

## One feature, two names Amazon S3 replication copies objects from a source bucket to a destination bucket automatically, in the background, as objects are written. You configure it as a **replication configuration** on the source bucket: a set of rules, each with a filter (whole bucket, a prefix, tags), a status, a priority, and a destination bucket ARN. "Cross-Region Replication" and "Same-Region Replication" are not two products. They are the same rules, distinguished only by whether the destination bucket happens to live in a different AWS Region. The API shape is identical — the destination is just a bucket ARN. AWS documentation and pricing use the two names because the cost profile differs: replicating across Regions adds inter-Region data-transfer charges on top of the request and storage charges you pay either way. ## Prerequisites both share Three things must be true before a rule copies anything: 1. **Versioning is enabled on the source bucket.** Replication works at the object-version level; without versioning there is nothing stable to replicate. 2. **Versioning is enabled on the destination bucket.** This is the check people miss most often. 3. **An IAM role exists that S3 can assume.** Its trust policy names the S3 service principal, and its permissions policy allows reading object versions from the source (for example `s3:GetObjectVersionForReplication`, `s3:ListBucket`) and writing them into the destination (`s3:ReplicateObject`, `s3:ReplicateTags`, and `s3:ReplicateDelete` when delete markers are replicated). Replication is **asynchronous**. A successful `PutObject` on the source returns before the replica exists. Objects typically appear at the destination within minutes, but that is a behaviour, not a contract — the contractual version of it is a separate paid option. ## When CRR is the right answer - **Disaster recovery / Regional resilience.** An S3 bucket lives in one Region. If you need reads to keep working through a Regional impairment, or you need a copy of the data outside the blast radius of one Region, the copy has to be in another Region. - **Read latency for distant users.** A consumer in another continent reading a bucket across the world pays for that distance on every GET. Replicating the data closer, and pointing that Region's consumers at the local bucket, removes the round trip. (A CDN in front of one bucket is often the cheaper answer for read-mostly public content — replication wins when the consumers are compute, not browsers.) - **Data residency and compliance.** "A copy must exist in the EU" or "in this jurisdiction" is a requirement about geography, and only CRR satisfies it. ## When SRR is the right answer SRR moves data across an **account or trust boundary**, not a distance: - **Log and audit aggregation.** Many producing accounts replicate their log buckets into one central security-owned bucket in the same Region, where retention and access are controlled by a different team. - **Blast-radius isolation.** A second copy in an account whose credentials your application does not hold means a compromise of the application account cannot trivially erase both copies. - **Environment fan-out.** Production data replicated into a test or analytics account, optionally filtered by prefix so only the relevant slice moves. - **Storage-class or ownership change on the way.** A rule can write replicas in a different storage class than the source, and for cross-account rules it can transfer object ownership to the destination bucket owner. ## Things worth saying out loud Replicas keep the **same version ID** as the source object version, which makes reconciliation between the two buckets straightforward. Replication is one-way per rule — bidirectional replication means configuring rules on both buckets, with the corresponding roles on both sides. And two limits that shape design more than any Region choice: a rule only applies to objects written **after** it was saved, and replication mirrors the live state of the source rather than preserving history on its own. Both of those catch teams that reached for replication expecting a backup. ## Rule of thumb If the reason for the second copy contains the word *Region*, *outage*, *latency*, or *country*, it is CRR. If it contains *account*, *team*, *audit*, or *isolation*, SRR is usually enough and costs less, because you are not paying inter-Region transfer to solve a trust problem.

  • Can one replication rule write to more than one destination bucket?
    A single rule has one destination, but a bucket's replication configuration can hold several rules with different destinations — that is how multi-destination replication works, for example one replica in another Region for DR and one in a central audit account in the same Region. Each rule has its own filter and priority, and priority decides which rule wins when two filters match the same object.
  • Does replication preserve the object's storage class?
    By default the replica is written in the same storage class as the source, but a rule can override it in the destination configuration. That is common for DR copies: keep the source in S3 Standard for live traffic and write replicas into a cheaper class, accepting the retrieval characteristics of that class if you ever fail over to it.
  • If I need the second copy mainly to serve global readers, is replication always the right tool?
    Not always. For read-mostly content served to browsers, a CDN in front of a single bucket removes the latency without doubling storage or paying continuous replication charges. Replication earns its cost when the remote consumers are compute that must read the bucket directly, when you need the data to survive the source Region, or when a residency rule demands a real copy.

saying these in an interview costs you the question

  • Thinking CRR and SRR are different features with different APIs
  • Claiming replication is synchronous with the PUT
  • Forgetting versioning must be on at the destination too
  • Assuming replication requires both buckets in one account
  • Treating a replica as a point-in-time backup

context

resolving links…