Single-Region S3 is a single point of failure for your data plane. Cross-Region Replication (CRR) asynchronously copies objects to a destination bucket in another AWS Region — so a Regional outage does not take your backups with it.
CRR is powerful and easy to misconfigure. Teams treat it as "backup" and skip versioning, encryption policy alignment, and failover runbooks. Then us-east-1 sneezes and nobody knows which bucket is canonical.
What S3 CRR actually does
When you enable replication on a source bucket, S3 automatically replicates new objects (and optionally existing ones via batch replication) to a destination bucket in a different Region. Replication is:
- Asynchronous — not instantaneous; lag depends on object size and load
- One-way by default — bidirectional replication is possible but requires careful loop prevention
- At the object level — metadata, tags, and ACLs can be replicated depending on configuration
Requirements checklist
Before replication works, all of these must be true:
- Both buckets must have versioning enabled (CRR requires versioning on source; destination must enable it too)
- Destination bucket must be in a different Region than the source
- IAM role that S3 assumes must allow replication actions on both buckets
- Source bucket owner must have permissions to replicate to the destination (including cross-account if applicable)
- KMS keys: if objects are SSE-KMS encrypted, destination key policies must allow the replication role
Replication rule options that matter
- Scope — entire bucket or prefix/filter (e.g. only
production/)
- Storage class — replicate into STANDARD, IA, or Glacier depending on DR vs cost
- Delete marker replication — choose explicitly; deleting in source can delete visibility in DR copies
- S3 RTC (Replication Time Control) — SLA-backed replication within 15 minutes (additional cost)
- S3 Batch Replication — backfill existing objects not covered when the rule was created
CRR vs other "backup" options
| Approach | Protects against | Does not replace |
|---|
| Cross-Region Replication | Regional outage, local corruption if versioning retained | Accidental delete without versioning / MFA Delete policy |
| Cross-Account replication | Compromised account in source | Application-level bugs writing bad data |
| S3 Versioning | Overwrite / accidental delete (soft) | Regional failure without CRR |
| AWS Backup | Policy-driven snapshots across services | Real-time hot standby by itself |
Disaster recovery patterns
Active-passive (most common)
Primary Region serves traffic; DR Region holds replicated data. Failover means updating DNS (Route 53), pointing applications to DR buckets or rehydrating from replicated prefixes, and promoting downstream dependencies. Run failover drills — untested DR is wishful thinking.
Active-active (hard mode)
Bidirectional replication between Regions for low-latency local reads. Requires conflict handling (last writer wins is not always acceptable), strict key naming, and often S3 Transfer Acceleration or CloudFront in front. Only pursue when the business truly needs it.
Compliance copy
Replicate to a locked-down account/Region with Object Lock (WORM) for regulatory retention. Source stays operational; DR copy is immutable evidence.
Cost factors
- Replication PUT requests on the destination
- Inter-Region data transfer OUT from source Region
- Storage in both Regions (often overlooked in TCO models)
- S3 RTC premium if you need bounded replication lag
- KMS API costs for re-encrypting with a destination CMK
Common mistakes
- Enabling CRR without versioning — replication silently fails setup validation
- Assuming delete in source should always delete DR copies — tune delete marker replication deliberately
- Ignoring KMS key policies in cross-account setups — objects replicate as failures, not successes
- Using CRR as the only backup while allowing permanent deletes without MFA Delete or Object Lock
- Never measuring replication lag until the day of an outage
Lab it once
Create two buckets in different Regions, enable versioning, configure a replication rule with an IAM role, upload test objects, and confirm they appear in the destination. Then enable versioning, delete an object in source, and observe what happens in DR with and without delete marker replication. That 30-minute lab saves hours in a real incident.