Configuring Object Replication

Primary services involved:

• Azure Blob Storage
• Azure Storage Account

1️⃣ What Is Object Replication?#

Object replication is a feature that:

• Asynchronously copies block blobs
• From a source storage account
• To a destination storage account
• Based on a replication policy

It is used for:

• Reducing read latency
• Regional data distribution
• Data processing in multiple regions
• Cost optimization strategies

Official documentation:

2️⃣ Core Requirements (Very Important)#

For object replication to work:

✔ On Source Storage Account:#

Blob versioning must be enabled

Blob change feed must be enabled

✔ On Destination Storage Account:#

• Blob versioning must be enabled
• Change feed NOT required
• Why?
• Blob change feed tracks create/update/delete events
• Versioning ensures consistent replication of blob states

Docs:

Versioning:

Change feed:

3️⃣ Architecture Concept#

• Source Storage Account (Region A)
• └── Source Container
• └── Block Blobs
• ↓ (Asynchronous replication policy)
• Destination Storage Account (Region B)
• └── Destination Container
• └── Replicated Block Blobs

Important:

• Replication is asynchronous
• Only block blobs are supported
• Page blobs and append blobs are NOT supported

4️⃣ Where Replication Can Occur#

Object replication supports:

• ✔ Same region ✔ Cross-region ✔ Cross-subscription ✔ Cross–Microsoft Entra ID tenants
• Cross-tenant requires explicit configuration.

5️⃣ Why Use Object Replication?#

🔹 1. Minimize Latency#

If users are far from Region A:

• Replicate to Region B closer to them.

Reduces:

• Read latency
• Cross-region bandwidth usage

🔹 2. Data Distribution#

You can:

• Process data in one region
• Replicate to another region
• Run analytics there

🔹 3. Regional Processing#

Support:

• Multi-region applications
• Regional compliance needs

🔹 4. Cost Optimization#

You can:

• Replicate data
• Move replicated copy to archive tier
• Reduce storage costs for secondary workloads

6️⃣ Replication Policy Details#

When creating a replication rule, you must define:

• Source container
• Destination container
• Prefix filter (optional)
• Copy scope

🔹 Prefix Filtering (Important Concept)#

• Blob storage uses flat namespace.
• Folders are just prefixes.

Example:

• awesomefolder/file3.txt

Internally:

• Blob name = awesomefolder/file3.txt

If you configure prefix filter:

• awesomefolder/
• Only blobs with that prefix are replicated.

This enables:

• Selective replication.

🔹 Copy Scope Options#

You can choose:

• Everything
• Only new objects
• Custom time-based configuration

7️⃣ Important Behavior Notes#

✔ Replication is asynchronous ✔ Replication delay depends on workload ✔ Only block blobs supported ✔ Replication respects versions ✔ Destination blobs are read-only copies

8️⃣ Versioning Interaction#

Since versioning is enabled:

• Each blob version is replicated
• Updates generate new versions
• Delete operations are tracked

This ensures:

• Consistency between source and destination.

9️⃣ Replication vs Redundancy (Common Confusion)#

Do NOT confuse:

• Storage account redundancy (LRS/ZRS/GRS)
• with
• Object replication.

Difference:

Object replication gives:

• Granular control.

🔟 Demonstration Summary#

Steps performed:

• Enabled versioning (source + destination)
• Enabled change feed (source only)
• Created source container
• Created destination container
• Uploaded blobs to source
• Created replication policy
• Added prefix filter
• Verified replicated blob in destination
• Only blobs matching prefix were replicated.

11️⃣ Replication Monitoring#

You can view:

• Objects copied from this account
• Objects copied into this account
• Replication policy status

Each storage account shows:

• Inbound and outbound replication rules.

12️⃣ Real-World Scenarios#

🌍 Multi-Region SaaS App#

Users in US and Europe: Replicate to both regions.

📊 Analytics Pipeline#

Raw data in Region A: Replicate to Region B for ML processing.

🏛 Compliance#

Primary region + regulated secondary region.

💰 Cost Optimization#

Primary hot tier: Replicate + archive secondary.

13️⃣ Limitations & Considerations#

• Only block blobs supported
• Requires versioning
• Requires change feed (source)
• Replication policy per container
• Destination must exist
• Cross-tenant requires permissions
• Asynchronous (not instant)

14️⃣ Security Considerations#

• Use RBAC instead of access keys
• Configure private endpoints if needed
• Control cross-tenant replication carefully
• Replicated blobs inherit access controls

15️⃣ Exam-Relevant Concepts#

🚩 Change feed required on destination → False 🚩 Versioning required on both accounts → True 🚩 Object replication is synchronous → False 🚩 Supports append blobs → False 🚩 Supports cross-region replication → True 🚩 Can filter by prefix → True

16️⃣ Conceptual Summary#

Object replication =

Controlled, policy-driven, asynchronous copying of block blobs between storage accounts with version awareness and optional prefix filtering.

17️⃣ Mental Model#

Think of it as:

• Event-driven blob mirroring powered by change feed.

If you'd like next:

• 🔄 Object replication vs GRS comparison deep dive
• 🧠 AZ-104 / AZ-305 storage replication exam questions
• 🏗 Multi-region storage architecture design patterns
• 💰 Cost optimization scenarios with archive + replication
• 🔐 Secure cross-tenant replication walkthrough
• Tell me your focus (exam prep, architecture, cost optimization, or advanced design).

Hands-on: Configure Blob Object Replication#

Goal: Replicate block blobs from one storage account to another using version-aware object replication.

1. Create source storage account az104src<random>.
2. Create destination storage account az104dst<random>.
3. Enable blob versioning on both accounts.
4. Enable change feed on the source account.
5. Create container replication-demo in both accounts.
6. Open the destination account and create an object replication policy.
7. Select the source account and container.
8. Add a rule for prefix images/ or leave prefix blank for the full container.
9. Save the policy.
10. Upload a new blob to the source container.
11. Confirm it appears in the destination container after replication completes.
12. Update the source blob and confirm a new version is replicated.