S3 Replication Complete Guide: CRR vs SRR - When to Choose What?

Key Takeaway

CRR (Cross-Region Replication) replicates to another region for disaster recovery and latency reduction, while SRR (Same-Region Replication) replicates within the same region for log aggregation, cross-account replication, and data sovereignty compliance.

---

1. S3 Replication Basics

What is Live Replication?

S3 Live Replication is a feature that automatically and asynchronously replicates objects uploaded to a source bucket to a destination bucket.

┌─────────────────────────────────────────────────────────┐
│                  S3 Live Replication Overview            │
├─────────────────────────────────────────────────────────┤
│                                                         │
│   Source Bucket                  Destination Bucket     │
│   ┌──────────┐    Auto Repl.    ┌──────────┐           │
│   │ Object A │ ─────────────────▶│ Object A │           │
│   │ Object B │    (Async)        │ Object B │           │
│   │ Object C │                   │ Object C │           │
│   └──────────┘                   └──────────┘           │
│                                                         │
│   Replication Types:                                    │
│   - CRR: Replicate to different AWS region              │
│   - SRR: Replicate within same AWS region               │
└─────────────────────────────────────────────────────────┘

Replication Requirements

Requirement	Description
Versioning	Must enable versioning on both source/destination buckets
IAM Permissions	IAM role required for S3 to replicate objects
Ownership	Source bucket owner creates replication rules

---

2. CRR (Cross-Region Replication)

Concept

CRR replicates objects between S3 buckets in different AWS regions. Available since 2015.

Use Cases

┌─────────────────────────────────────────────────────────┐
│                   CRR Use Cases                          │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  1️⃣ Disaster Recovery (DR)                              │
│     Seoul Region ──────────────────▶ Tokyo Region       │
│     (Primary)          CRR          (DR Site)           │
│                                                         │
│  2️⃣ Latency Minimization                                │
│     US Users ◀── Virginia Region                        │
│     EU Users ◀── Frankfurt Region (replica)             │
│                                                         │
│  3️⃣ Compliance (Geographic Distribution Requirement)    │
│     Keep primary data and backup in distant regions     │
│                                                         │
│  4️⃣ Analytics Cluster Operations                        │
│     EMR clusters in two regions need same data          │
└─────────────────────────────────────────────────────────┘

CRR Configuration Example

# Create CRR rule with AWS CLI
aws s3api put-bucket-replication \
  --bucket source-bucket-seoul \
  --replication-configuration '{
    "Role": "arn:aws:iam::123456789012:role/S3ReplicationRole",
    "Rules": [{
      "ID": "CRR-to-Tokyo",
      "Status": "Enabled",
      "Priority": 1,
      "Filter": {},
      "Destination": {
        "Bucket": "arn:aws:s3:::destination-bucket-tokyo"
      },
      "DeleteMarkerReplication": {"Status": "Disabled"}
    }]
  }'

---

3. SRR (Same-Region Replication)

Concept

SRR replicates objects between S3 buckets within the same AWS region. Launched in 2019.

Use Cases

┌─────────────────────────────────────────────────────────┐
│                   SRR Use Cases                          │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  1️⃣ Log Aggregation                                     │
│     App-A Logs ──┐                                      │
│     App-B Logs ──┼──▶ Central Log Bucket (for analysis) │
│     App-C Logs ──┘                                      │
│                                                         │
│  2️⃣ Dev/Test Environment Replication                    │
│     Production Account ────SRR────▶ Dev Account         │
│     (Real data)                    (Test copy)          │
│                                                         │
│  3️⃣ Data Sovereignty Compliance                         │
│     Regulations requiring data cannot leave a region    │
│     Backup to different account within same region      │
│                                                         │
│  4️⃣ Storage Class Conversion                            │
│     Standard ────SRR────▶ Glacier (auto archive)        │
└─────────────────────────────────────────────────────────┘

---

4. CRR vs SRR Comparison

Core Comparison Table

Feature	CRR	SRR
Replication Scope	Different AWS region	Same AWS region
Primary Purpose	Disaster recovery, latency reduction	Log aggregation, cross-account replication
Data Transfer Cost	Cross-region transfer fees apply	Same region transfer (lower)
Latency	Varies by region distance	Very low
Data Sovereignty	Data moves to another region	Data stays within region

Selection Criteria

Question 1: Must data stay within a specific region?
├── Yes → SRR
└── No → Go to Question 2

Question 2: Is disaster recovery the main purpose?
├── Yes → CRR
└── No → Go to Question 3

Question 3: Need to reduce latency for users in other regions?
├── Yes → CRR
└── No → SRR (log aggregation, cross-account replication, etc.)

---

5. Key Configuration Options

Replication Target Filtering

Replication Rule Filter Options:
├── Replicate entire bucket
├── Prefix-based (e.g., logs/)
└── Tag-based (e.g., Replicate=true)

Replication Time Control (RTC)

S3 Replication Time Control provides an SLA to replicate 99.99% of objects within 15 minutes.

Option	Description
Regular Replication	Most within 15 minutes, no SLA
RTC Enabled	99.99% of objects guaranteed within 15 minutes

Bidirectional Replication

┌─────────────────────────────────────────────────────────┐
│                Bidirectional Replication                 │
├─────────────────────────────────────────────────────────┤
│                                                         │
│   Bucket A (Seoul)          Bucket B (Tokyo)            │
│   ┌──────────┐            ┌──────────┐                 │
│   │          │ ─────────▶ │          │                 │
│   │          │ ◀───────── │          │                 │
│   └──────────┘            └──────────┘                 │
│                                                         │
│   Bidirectional = Active-Active configuration           │
│   - Write from any region                               │
│   - Use with Multi-Region Access Points                 │
└─────────────────────────────────────────────────────────┘

---

6. Items Not Replicated

Important Limitations

Item	Replicated?	Description
Existing Objects	❌	Objects before rule creation not auto-replicated
Delete Markers	Optional	Configure with DeleteMarkerReplication
Permanent Deletes	❌	Deletes with version ID not replicated
SSE-C Encrypted Objects	❌	Customer-provided key encrypted objects
Lifecycle Actions	❌	Deletions/transitions by Lifecycle rules

S3 Batch Replication

To replicate existing objects that existed before replication rule creation, use S3 Batch Replication.

# Create batch replication job
aws s3control create-job \
  --account-id 123456789012 \
  --operation '{"S3ReplicateObject": {}}' \
  --manifest '{...}' \
  --report '{...}' \
  --priority 10 \
  --role-arn arn:aws:iam::123456789012:role/BatchReplicationRole

---

7. Replication Monitoring

Replication Metrics

Monitorable Items:
├── ReplicationLatency: Replication delay time
├── BytesPendingReplication: Bytes pending replication
├── OperationsPendingReplication: Operations pending replication
└── OperationsFailedReplication: Failed replication operations

EventBridge Notifications

Receive notifications on replication failures:

{
  "source": ["aws.s3"],
  "detail-type": ["Object Replication Failed"],
  "detail": {
    "bucket": {"name": ["source-bucket"]}
  }
}

---

8. Cost Considerations

Cost Components

Item	CRR	SRR
Replication Requests	PUT request charges	PUT request charges
Data Transfer	Cross-region transfer fees	None (same region)
Destination Storage	Destination region storage fees	Same region storage fees
RTC Additional Fee	Yes	Yes

Cost Optimization Tips

1. Use Filters
   └── Only replicate needed objects (prefix/tag filters)

2. Specify Storage Class
   └── Use cheaper storage class for destination bucket

3. Combine with Lifecycle Policies
   └── Transition to Glacier after certain period post-replication

---

Exam Focus Points

Common Question Types

1. Scenario-Based Selection

   • "Replicate data to another region for disaster recovery?" → CRR
   • "Data sovereignty prevents data from leaving the region?" → SRR
   • "Aggregate logs from multiple buckets to central bucket?" → SRR

2. Limitation Related

   • "Existing objects before replication rule creation?" → Not auto-replicated, batch replication needed
   • "Is versioning required?" → Yes, both source/destination

3. Delete Behavior

   • "Does deleting in source also delete in destination?" → By default no (delete marker replication is optional)

---

FAQ

Q1: Can I use CRR and SRR simultaneously?

Yes. You can replicate from a single source bucket to multiple destination buckets. You can set up replication rules to both buckets within the same region (SRR) and buckets in other regions (CRR).

Q2: Can replicated objects be replicated again?

No. By default, replicated objects (replicas) are not replicated again. This prevents infinite replication loops. However, replica replication is enabled when configuring bidirectional replication.

Q3: What is the replication delay time?

Typically most objects are replicated within 15 minutes. If SLA is needed, enable Replication Time Control (RTC) to guarantee 99.99% of objects are replicated within 15 minutes.

Q4: Can I accidentally lose data if deletes are replicated?

By default, delete operations are not replicated. If you enable DeleteMarkerReplication, delete markers are replicated, but permanent deletes with version IDs are not replicated, so destination bucket data is preserved.

Q5: Can I replicate to buckets in other AWS accounts?

Yes. Cross-account replication is possible. You need to add a bucket policy to the destination bucket allowing replication from the source account, and also consider object ownership settings.

---

Summary

S3 replication is a key feature for improving data protection and availability:

• CRR: Disaster recovery, latency reduction, compliance (geographic distribution)
• SRR: Log aggregation, cross-account replication, data sovereignty compliance

For exams, remember: "different region replication" → CRR, "same region replication" → SRR, "existing object replication" → S3 Batch Replication.