Cross-Region & Same-Region Replication

Amazon S3 Replication automatically and asynchronously copies the objects you put in one bucket into another bucket — either in a different AWS Region (CRR, Cross-Region Replication) or in the same Region (SRR, Same-Region Replication). You set it up once with a rule, and from then on S3 keeps the destination bucket in sync for you. It is the standard way to build disaster recovery (a backup that survives a whole Region going down), meet data-residency or compliance rules, and put data closer to users in another part of the world. This page explains how it works, what you must turn on first, and the gotchas that trip up almost everyone.

CRR vs SRR — when to use which

Both features use the same engine; the only difference is where the destination bucket lives.

Feature	What it does	Typical use cases
CRR (Cross-Region Replication)	Copies objects to a bucket in a different Region (e.g. `us-east-1` → `eu-west-1`)	Disaster recovery, lower latency for global users, meeting “keep a copy in another Region” rules
SRR (Same-Region Replication)	Copies objects to a bucket in the same Region	Aggregating logs into one bucket, separating production data into a locked-down account, in-Region compliance copies

When NOT to use replication: if you only need a versioned history of an object to recover from accidental edits, plain S3 Versioning is enough — you do not need a second bucket. Use replication when you need a separate bucket (often a separate account or Region) for resilience or compliance.

Requirements before you start

S3 will refuse to create a replication rule unless these are in place:

Versioning must be enabled on BOTH buckets. Replication relies on object versions to track what to copy. This is the single most common setup error.
An IAM role (Identity and Access Management — AWS’s permission system) that S3 assumes to read from the source and write to the destination. The console can create this role for you.
The destination bucket must already exist (it can be in another account).
If objects are encrypted with KMS (Key Management Service), the role needs permission to use the source key to decrypt and the destination key to encrypt.

How replication actually behaves (read this twice)

Replication is asynchronous. When you upload an object, S3 returns success immediately and copies it in the background — usually within seconds to minutes, but there is no instant guarantee. That means it is a strong DR tool but not a synchronous “always identical” mirror.

Two defaults surprise almost everyone:

Pre-existing objects are NOT copied. A new replication rule only applies to objects uploaded after the rule is created. To copy what is already in the bucket, you must run S3 Batch Replication (a one-time backfill job).
Delete markers are NOT replicated by default. If you delete an object in the source, it stays in the destination unless you explicitly opt in to replicating delete markers. This is a safety feature — it stops an accidental or malicious delete from wiping your DR copy too. Decide deliberately which behaviour you want.

Gotcha: Replication never copies a DELETE of a specific version, and it never deletes data in the destination on your behalf. Treat the destination as protected. If you do enable delete-marker replication, understand you are giving up some of that protection.

Set up replication in the console

Make sure versioning is enabled on both the source and destination buckets (Bucket → Properties → Bucket Versioning → Enable).
Open the source bucket → Management tab → Replication rules → Create replication rule.
Give the rule a name and set Status to Enabled.
Under Source, choose Apply to all objects or limit by prefix/tags.
Under Destination, pick a bucket in this account (or another account) and choose its Region.
For IAM role, select Create new role (let S3 build the permissions).
(Optional) Change the destination storage class, enable Replication Time Control (RTC) for a 15-minute SLA, or enable delete marker replication.
Click Save. To copy objects that already exist, choose Yes when prompted to run a one-time Batch Replication job (or start one later).

Set up replication with the AWS CLI

First enable versioning on both buckets:

aws s3api put-bucket-versioning \
  --bucket my-app-prod-us-east-1 \
  --versioning-configuration Status=Enabled

aws s3api put-bucket-versioning \
  --bucket my-app-dr-eu-west-1 \
  --versioning-configuration Status=Enabled

Create a replication.json describing the rule, then apply it:

aws s3api put-bucket-replication \
  --bucket my-app-prod-us-east-1 \
  --replication-configuration file://replication.json

A minimal replication.json (replicate everything, do NOT replicate deletes):

{
  "Role": "arn:aws:iam::123456789012:role/s3-replication-role",
  "Rules": [
    {
      "ID": "dr-to-eu",
      "Status": "Enabled",
      "Priority": 1,
      "Filter": {},
      "DeleteMarkerReplication": { "Status": "Disabled" },
      "Destination": {
        "Bucket": "arn:aws:s3:::my-app-dr-eu-west-1",
        "StorageClass": "STANDARD_IA"
      }
    }
  ]
}

Confirm it was applied:

aws s3api get-bucket-replication --bucket my-app-prod-us-east-1

Output:

{
    "ReplicationConfiguration": {
        "Role": "arn:aws:iam::123456789012:role/s3-replication-role",
        "Rules": [
            {
                "ID": "dr-to-eu",
                "Priority": 1,
                "Filter": {},
                "Status": "Enabled",
                "DeleteMarkerReplication": { "Status": "Disabled" },
                "Destination": {
                    "Bucket": "arn:aws:s3:::my-app-dr-eu-west-1",
                    "StorageClass": "STANDARD_IA"
                }
            }
        ]
    }
}

To backfill existing objects, create an S3 Batch Operations job from the same console wizard, or via aws s3control create-job using the S3ReplicateObject operation.

Cost note

You pay normal S3 storage in the destination bucket (so a DR copy roughly doubles storage cost — using STANDARD_IA or a Glacier class for the copy helps). CRR also adds inter-Region data transfer charges (often around $0.02 per GB) for every object copied. If you enable Replication Time Control (RTC) you pay a per-GB RTC fee on top, in exchange for a 15-minute replication SLA and CloudWatch metrics. SRR has no inter-Region transfer cost.

Best practices

Turn on versioning on both buckets first — replication will not start without it.
Choose deliberately whether delete markers replicate; defaulting to “off” protects your DR copy from accidental or malicious deletes.
Run S3 Batch Replication right after creating a rule so existing data is covered, not just new uploads.
For CRR DR, put the destination in a different account (cross-account) so a compromise of the source account cannot delete your backup.
Use a cheaper destination storage class (e.g. STANDARD_IA or Glacier) to control the cost of the second copy.
Enable RTC only for workloads that genuinely need a measurable replication SLA — it costs extra.
Monitor replication with the ReplicationLatency and OperationsPendingReplication CloudWatch metrics to catch a stalled rule early.