Amazon S3 replication explained: same-Region, cross-Region, and what never gets copied

Same-Region or cross-Region

The mechanics are identical; the reason for the second bucket differs.

• Cross-Region Replication: a copy in another Region for disaster recovery, for a compliance rule that requires geographic separation, or to serve users closer to that Region. Inter-Region data transfer is charged per GB replicated.
• Same-Region Replication: a copy in the same Region, usually in a different account, to separate backups from the production account, aggregate logs from several buckets, or give a team a copy with its own permissions. There is no data transfer charge.

What it needs before it runs

Both buckets must have versioning enabled, and it stays locked on: S3 refuses to suspend versioning on a source bucket that has a replication configuration, and suspending it on the destination makes replication fail. S3 also needs an IAM role that it assumes to read from the source and write to the destination.

Across accounts, the destination owner must also allow that role in their bucket policy, and the destination cannot be a Requester Pays bucket. If the source uses Object Lock, the destination must have Object Lock enabled too, and the role needs s3:GetObjectRetention and s3:GetObjectLegalHold. For SSE-KMS objects, the role needs to decrypt with the source key and encrypt with a key in the destination Region.

# Versioning on both sides first; replication will not save without it.
aws s3api put-bucket-versioning --bucket amzn-s3-demo-source \
  --versioning-configuration Status=Enabled
aws s3api put-bucket-versioning --bucket amzn-s3-demo-replica \
  --versioning-configuration Status=Enabled

# One rule: replicate everything, including delete markers, to the replica bucket.
aws s3api put-bucket-replication --bucket amzn-s3-demo-source \
  --replication-configuration '{
    "Role": "arn:aws:iam::111122223333:role/s3-replication",
    "Rules": [{
      "ID": "all-objects",
      "Status": "Enabled",
      "Priority": 1,
      "Filter": {},
      "DeleteMarkerReplication": { "Status": "Enabled" },
      "Destination": { "Bucket": "arn:aws:s3:::amzn-s3-demo-replica" }
    }]
  }'

What replication copies

Live replication copies new object versions written after the rule is saved, with their metadata, tags and ACLs. Unencrypted objects and objects encrypted with SSE-S3, SSE-KMS or SSE-C are all eligible, although SSE-KMS needs the key permissions above. Object Lock retention travels with the object, and overrides the destination bucket's default retention.

Replication is asynchronous. Most objects arrive within seconds to minutes, but large objects can take hours, and there is no guaranteed time unless you pay for S3 Replication Time Control, which is designed to replicate 99.99% of new objects within 15 minutes and comes with replication metrics and missed-threshold events.

What it does not copy

This is the list that decides whether replication fits your plan.

• Objects that existed before the rule. Live replication only sees new writes; existing objects need an S3 Batch Replication job.
• Objects that are themselves replicas. A chain from A to B to C does not carry A's objects to C unless Batch Replication copies them.
• Objects in S3 Glacier Flexible Retrieval, Glacier Deep Archive, or the Intelligent-Tiering archive tiers. They must be restored and copied to another class first.
• Lifecycle actions. Expirations and transitions on the source are not replicated, so give the destination its own lifecycle rules.
• Bucket-level settings such as lifecycle, notifications and policies. Each bucket keeps its own.
• Objects the source bucket owner does not have permission to read, which can happen when another account uploaded them with ACLs.

How deletes behave

A simple delete (no version ID) adds a delete marker. With the current configuration format, delete markers are not replicated unless the rule enables delete marker replication, as in the example above. Enable it when the destination should look like the source; leave it off when the destination is meant to keep files that were deleted from production.

A delete that names a version ID is never replicated. Removing a specific version from the source leaves the replica's copy in place. AWS describes this as protection from malicious deletions, and it is the main reason a replica in a separate account is useful as a recovery copy.

How delete markers and versions work

Replicating the files already in the bucket

Batch Replication is an S3 Batch Operations job that replicates existing objects, objects that previously failed, and replicas that a chain skipped. You can have S3 generate the manifest from the replication configuration, or supply one from S3 Inventory. Set up the live rule first, so that new writes are covered while the job works through the backlog.

Is a replica a backup?

Partly. A replica in another account survives the source account being compromised or closed, and version-ID deletes on the source do not reach it. But everything else does: an overwrite replicates as a new version, ransomware that encrypts files in place replicates its encrypted copies, and enabled delete marker replication makes files disappear from the replica's listings as well. Versioning on the replica keeps the older versions, so recovery is possible, but only for as long as the replica's lifecycle rules keep noncurrent versions.

For a copy that cannot be altered, combine replication with Object Lock on the destination, or with AWS Backup, which keeps point-in-time recovery points. Replication gives you a second location; retention rules decide how far back you can go.

Object Lock for copies nobody can deleteKeys and encryption across buckets

What it costs

There is no charge for the replication feature itself. You pay for storage in the destination bucket (at its storage class, which the rule can set), PUT requests for each replicated object, inter-Region data transfer for CRR, KMS requests for encrypted objects, and the RTC and Batch Operations fees if you use them. Replicating a versioned bucket also replicates every new version, so a frequently overwritten file costs its size each time it changes.

A common saving is to replicate straight into a colder class, such as Standard-IA or Glacier Instant Retrieval, since the replica is rarely read. Check the minimum storage durations first: short-lived versions in those classes are billed for the minimum anyway.

S3 storage classes and minimum durations