Theoretical Foundation: Configure Object Replication

1. Initial Intuition

Imagine your company has two offices: one in São Paulo and one in Lisbon. Every time a document is created or updated in the São Paulo office, an identical copy must automatically appear in the Lisbon office, without anyone having to do this manually.

Object Replication is exactly this mechanism applied to Azure Blob Storage: a functionality that automatically copies blobs from a source container to a destination container, asynchronously, where source and destination can be in different regions, subscriptions, and even tenants.

The fundamental difference compared to geographic redundancy (GRS/GZRS) studied previously is that Object Replication is explicitly configured by the administrator, operates at the container and individual blob level and offers granular control over what is replicated and when.

2. Context

2.1 Why Object Replication exists

Geographic redundancy (GRS) replicates all data from an entire Storage Account to a secondary region, opaquely and without granular control. It doesn't allow:

Choosing which containers or blobs to replicate
Replicating to accounts in different subscriptions
Replicating to accounts in different Azure AD tenants
Using replicated data for reading without additional failover cost
Filtering blobs by prefix or creation date

Object Replication fills this gap. It is a controlled replication functionality, while GRS is an automatic durability functionality.

2.2 Main use cases

Geographic content distribution: Replicate images or files to a region closer to end users.
Environment separation: Copy production data to an analytics account without impacting production.
Compliance and retention: Keep an auditable copy in a separate account with immutability policies.
Latency reduction: Serve content from a region geographically close to the client.
Cross-tenant replication: Share data between different organizations in Azure.

3. Building the Concepts

3.1 The fundamental components

Before understanding how to configure, you need to know the three elements that make up Object Replication:

1. Source account The Storage Account where blobs originally exist. Blobs are created or updated here.

2. Destination account The Storage Account to where blobs will be automatically copied.

3. Replication policy The set of rules that defines what to replicate, from where and to where. A policy contains one or more rules.

4. Replication rule Each rule within a policy defines:

The source container
The destination container
Optional filters (by name prefix)
Creation date filter (replicate only blobs created after a certain date)

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

3.2 Mandatory prerequisites

This is a point where many errors occur in practice. Object Replication requires:

Requirement	Detail
Blob type	Only Block Blobs are supported
Blob Versioning	Must be enabled on both accounts (source and destination)
Change Feed	Must be enabled on the source account
Account type	Standard GPv2 or Premium Block Blob
Public access	Not required, but the destination container must exist
Access tier	Archive is not supported on source for active replication

Why are Blob Versioning and Change Feed mandatory? Change Feed records all changes to blobs in the source account (creations, modifications, deletions). Object Replication reads this log to know which blobs need to be copied. Without Change Feed, the service has no way to detect changes. Versioning ensures that different versions of a blob are tracked correctly during the process.

3.3 How replication is asynchronous

Object Replication is not instantaneous. There is a replication window that can vary from a few minutes to a few hours depending on:

Volume of data being replicated
Geographic distance between source and destination
Rate of new blob creation at the source

This means that data at the destination may be out of date compared to the source. The destination is eventually consistent with the source.

3.4 Relationship between policy at source and destination

An important technical detail: when you create a replication policy, it needs to be registered on both accounts:

On the destination account: you create the complete policy (defining source and rules).
On the source account: you apply the same policy with the generated ID, so the source account knows it should feed this replication.

The automatically generated Policy ID is the unique identifier that links both sides of the configuration.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

4. Structural View

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

5. Practical Operation

5.1 What is and isn't replicated

Element	Replicated?	Notes
Blob content	Yes	Complete binary data
Blob metadata	Yes	Including index tags
Access tier	No	Destination assumes account's default tier
Soft-deleted blobs	No	Only active blobs
Snapshots	No	Only current version and versioning versions
Blobs in Archive	No	Must be in Hot or Cool
Blob deletion at source	Yes (with conditions)	Replicated if versioning is active and configured

5.2 Deletion behavior

This is one of the most subtle points of Object Replication:

If a blob is deleted at the source, the blob at the destination is not automatically deleted by default.
This happens because the destination may have its own retention or immutability policy.
Deletion is only propagated if versioning at the source marks the blob as deleted and the replication rule is configured for this.

Analogy: It's like a one-way file synchronization where the destination folder doesn't automatically delete what was deleted in the source, unless you explicitly configure this behavior.

5.3 Rule filters

Each rule can have filters that limit which blobs are replicated:

Prefix filter: Replicates only blobs whose name starts with the specified prefix.

Example: Prefix images/2025/ replicates only blobs within this "virtual folder".

Creation date filter: Replicates only blobs created after a specific date. Useful for not replicating old historical data during initial setup.

You can have up to 10 rules per replication policy.

5.4 Historical data replication

When you create a new replication policy, by default, only new blobs created after policy activation are replicated. Existing data is not automatically copied.

To replicate historical data, you have two options:

Use the creation date filter to include past dates.
Manually copy historical data with AzCopy and then activate the policy for new data.

6. Implementation Methods

6.1 Azure Portal

When to use: Initial configuration, learning environments, checking existing configurations.

Portal steps:

Enable Blob Versioning on source account: Storage Account > Data Protection > Enable versioning
Enable Change Feed on source account: Storage Account > Data Protection > Enable blob change feed
Enable Blob Versioning on destination account
On the destination account: Data Management > Object Replication > Set up replication rules
Define source account, source and destination containers, and filters
Save and copy the generated Policy ID
On the source account: apply the policy with the Policy ID

Limitation: The portal doesn't clearly show the bidirectional configuration flow, which confuses beginners.

6.2 Azure CLI

Enable prerequisites on source:

# Enable Blob Versioning
az storage account blob-service-properties update \
  --account-name sourceaccount \
  --resource-group myRG \
  --enable-versioning true

# Enable Change Feed
az storage account blob-service-properties update \
  --account-name sourceaccount \
  --resource-group myRG \
  --enable-change-feed true

Enable Versioning on destination:

az storage account blob-service-properties update \
  --account-name destaccount \
  --resource-group myRG \
  --enable-versioning true

Create policy on destination:

az storage account or-policy create \
  --account-name destaccount \
  --resource-group myRG \
  --source-account sourceaccount \
  --destination-account destaccount \
  --source-container photos \
  --destination-container photos-replica \
  --prefix-match "images/2025/"

The command returns the generated Policy ID and Rule ID.

Apply policy on source:

az storage account or-policy show \
  --account-name destaccount \
  --resource-group myRG \
  --policy-id <policy-id> | \
az storage account or-policy create \
  --account-name sourceaccount \
  --resource-group myRG \
  --policy "@-"

Check active policies:

az storage account or-policy list \
  --account-name sourceaccount \
  --resource-group myRG

6.3 Azure PowerShell

# Create policy rules
$rule1 = New-AzStorageObjectReplicationPolicyRule `
  -SourceContainer "photos" `
  -DestinationContainer "photos-replica" `
  -PrefixMatch "images/2025/"

# Create policy on destination
$policy = Set-AzStorageObjectReplicationPolicy `
  -ResourceGroupName "myRG" `
  -StorageAccountName "destaccount" `
  -PolicyId "default" `
  -SourceAccount "sourceaccount" `
  -Rule $rule1

# Apply policy on source using the returned object
$policy | Set-AzStorageObjectReplicationPolicy `
  -ResourceGroupName "myRG" `
  -StorageAccountName "sourceaccount"

Using the $policy object ensures the same Policy ID is applied to both accounts.

6.4 Bicep / ARM

// On destination account
resource replicationPolicy 'Microsoft.Storage/storageAccounts/objectReplicationPolicies@2023-01-01' = {
  name: '${destStorageAccount.name}/default'
  properties: {
    sourceAccount: sourceStorageAccount.id
    destinationAccount: destStorageAccount.id
    rules: [
      {
        sourceContainer: 'photos'
        destinationContainer: 'photos-replica'
        filters: {
          prefixMatch: [
            'images/2025/'
          ]
          minCreationTime: '2025-01-01T00:00:00Z'
        }
      }
    ]
  }
}

Warning in Bicep/ARM: It's necessary to deploy the policy on the destination first to get the Policy ID, and then deploy on the source with this ID. This requires two sequential deployments or careful use of dependsOn.

7. Control and Security

7.1 Authentication and required permissions

To configure Object Replication, the administrator needs permissions on both accounts:

Permission	Where	Minimum role
Create/edit policy	Source account	Storage Account Contributor
Create/edit policy	Destination account	Storage Account Contributor
Enable Change Feed	Source account	Storage Account Contributor
Enable Versioning	Both accounts	Storage Account Contributor

7.2 Cross-tenant replication

Object Replication supports replication between different Azure AD tenants. For this:

The source account must have cross-tenant replication enabled (opt-in configuration)
By default, this capability is disabled for security reasons
The source account administrator needs to explicitly allow external tenants to configure replication policies pointing to it

Enable via CLI:

az storage account update \
  --name sourceaccount \
  --resource-group myRG \
  --allow-cross-tenant-replication true

Critical security point: Keeping allow-cross-tenant-replication disabled on accounts with sensitive data is a good practice. A malicious external administrator with account access could configure replication to a tenant outside the organization's control.

7.3 Replicated data and encryption

Replicated blobs maintain encryption at rest (AES-256).
If the destination account uses Customer-Managed Keys (CMK), replicated data is re-encrypted with the destination's keys.
Transfer in transit uses HTTPS mandatorily.

8. Decision Making

8.1 Object Replication vs other strategies

Situation	Best choice	Reason
Replicate all data from an account for DR	GRS or GZRS	Automatic and total replication, no manual configuration
Replicate only specific blobs to another region	Object Replication	Granular control by container and prefix
Replicate to another subscription	Object Replication	GRS doesn't support cross-subscription replication
Replicate to another tenant	Object Replication	Only available option for cross-tenant
Distribute static content globally	Object Replication + Azure CDN	Replication + CDN for minimum latency
Copy historical data once	AzCopy	Object Replication is for continuous replication
Synchronize data between dev/prod environments	Object Replication	Automatic, no manual intervention
Replication with near-zero RPO	GRS (MS-managed replication)	Object Replication is asynchronous with no latency SLA

8.2 Filters: when to use each one

Scenario	Recommended filter	Example
Replicate only a "virtual directory"	Prefix	`videos/2025/`
Avoid replicating old historical data	Creation date	`minCreationTime: 2025-01-01`
Replicate everything from container	No filter	Leave fields blank
Separate by file type	Prefix by extension	`documents/` vs `images/`

9. Best Practices

Enable Change Feed and Versioning before creating the policy. Creating the policy first and enabling the prerequisites later can result in blobs not being captured.
Use prefix filters to avoid replicating unnecessary data and reduce cross-region transfer costs.
Use creation date filter when configuring policies on accounts with large volumes of historical data that don't need to be replicated.
Name destination containers clearly, indicating they are replicas (e.g., photos-replica-westeurope), to avoid operational confusion.
Don't use the destination container as the source of truth. Treat it as operationally read-only.
Disable cross-tenant replication on production accounts with sensitive data unless explicitly necessary.
Monitor replication lag with Azure Monitor metrics to detect abnormal delays.
Document the Policy ID for each policy, as it's necessary to manage and remove policies.

10. Common Errors

Error	Why it happens	How to avoid
Policy created but blobs don't replicate	Change Feed or Versioning not enabled	Always enable prerequisites first
Policy applied only to destination	Forgot to apply Policy ID to source	The process is mandatory bidirectional
Historical data doesn't appear in destination	No date filter, only new blobs are replicated	Configure `minCreationTime` in the past or use AzCopy for history
Blobs in Archive don't replicate	Archive not supported as active source	Rehydrate to Hot/Cool first or filter by prefix
Confusing Object Replication with GRS	They're different mechanisms with distinct purposes	GRS is automatic durability; OR is controlled replication
Delete blob in source expecting deletion in destination	Deletion is not automatically propagated	Understand the unidirectional and asynchronous replication model
Using Premium Block Blob accounts without checking support	Not all types support Object Replication equally	Check support documentation by account type
Policy ID lost after creation	Not documented	Always record the Policy ID after creation

11. Operation and Maintenance

11.1 Checking replication status

In the portal, access the source or destination account and navigate to Data Management > Object Replication. There you'll see:

Active policies
Status of each rule
Last synchronization moment

Via CLI:

# View all policies in an account
az storage account or-policy list \
  --account-name sourceaccount \
  --resource-group myRG \
  --output table

# View details of a specific policy
az storage account or-policy show \
  --account-name sourceaccount \
  --resource-group myRG \
  --policy-id <policy-id>

11.2 Monitoring metrics

In Azure Monitor, configure alerts for:

BlobCount per container: Check if the number of blobs in the destination grows proportionally to the source.
Replication latency: There's no native "Object Replication lag" metric directly, but you can use Last-Modified timestamps on blobs to calculate.
Change Feed events: Monitor volume of unprocessed events.

11.3 Adding rules to an existing policy

az storage account or-policy rule add \
  --account-name sourceaccount \
  --resource-group myRG \
  --policy-id <policy-id> \
  --source-container videos \
  --destination-container videos-replica

11.4 Removing a policy

Removal must be done on both accounts:

# Remove from source
az storage account or-policy delete \
  --account-name sourceaccount \
  --resource-group myRG \
  --policy-id <policy-id>

# Remove from destination
az storage account or-policy delete \
  --account-name destaccount \
  --resource-group myRG \
  --policy-id <policy-id>

11.5 Important limits

Limit	Value
Maximum policies per destination account	2
Maximum rules per policy	10
Maximum destination accounts per source account	2
Supported blob types	Block Blobs only
Supported tiers in source	Hot and Cool (not Archive)

12. Integration and Automation

12.1 Integration with Azure Event Grid

Object Replication uses Change Feed internally, and Change Feed can emit events to Event Grid. This allows building reactive pipelines:

Blob created in source → Change Feed records → Event Grid emits event → Azure Function processes → validates if it reached destination.

12.2 Integration with Azure CDN

A common pattern is using Object Replication to distribute static content (images, videos, JS/CSS files) to multiple regions, and then configure Azure CDN pointing to the Storage Account in the region closest to each user group.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

12.3 Automation with Azure DevOps / GitHub Actions

To ensure new production Storage Accounts always have Object Replication configured:

- task: AzureCLI@2
  inputs:
    azureSubscription: 'MyServiceConnection'
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    inlineScript: |
      # Enable prerequisites
      az storage account blob-service-properties update \
        --account-name $(SOURCE_ACCOUNT) \
        --enable-versioning true \
        --enable-change-feed true

      # Create replication policy
      az storage account or-policy create \
        --account-name $(DEST_ACCOUNT) \
        --source-account $(SOURCE_ACCOUNT) \
        --source-container $(SOURCE_CONTAINER) \
        --destination-container $(DEST_CONTAINER)

13. Final Summary

Essential concepts:

Object Replication copies blobs asynchronously and unidirectionally from a source account to a destination account.
Configuration is done through a policy containing rules, each mapping a source container to a destination container.
The policy must be registered in both accounts using the same Policy ID.

Non-negotiable prerequisites:

Change Feed enabled on the source account.
Blob Versioning enabled on both accounts.
Only Block Blobs are supported.
Blobs in Archive tier are not replicated.

Critical differences:

Object Replication vs GRS: GRS replicates the entire account automatically for durability. Object Replication selectively replicates for distribution, compliance, or environment separation purposes.
New blob vs historical replication: By default, only blobs created after policy activation are replicated. Use date filter or AzCopy for historical data.
Deletion in source doesn't delete in destination automatically.
Destination is eventually consistent with source. There's no replication latency SLA.

What needs to be remembered:

Maximum 2 policies per destination account and 10 rules per policy.
Cross-tenant replication requires explicit enablement (allow-cross-tenant-replication).
Policy ID is the link between source and destination configurations: document it.
Removing a policy requires deletion in both accounts.
Premium Block Blob accounts support Object Replication, but check specific restrictions.

1. Initial Intuition​

2. Context​

2.1 Why Object Replication exists​

2.2 Main use cases​

3. Building the Concepts​

3.1 The fundamental components​

3.2 Mandatory prerequisites​

3.3 How replication is asynchronous​

3.4 Relationship between policy at source and destination​

4. Structural View​

5. Practical Operation​

5.1 What is and isn't replicated​

5.2 Deletion behavior​

5.3 Rule filters​

5.4 Historical data replication​

6. Implementation Methods​

6.1 Azure Portal​

6.2 Azure CLI​

6.3 Azure PowerShell​

6.4 Bicep / ARM​

7. Control and Security​

7.1 Authentication and required permissions​

7.2 Cross-tenant replication​

7.3 Replicated data and encryption​

8. Decision Making​

8.1 Object Replication vs other strategies​

8.2 Filters: when to use each one​

9. Best Practices​

10. Common Errors​

11. Operation and Maintenance​

11.1 Checking replication status​

11.2 Monitoring metrics​

11.3 Adding rules to an existing policy​

11.4 Removing a policy​

11.5 Important limits​

12. Integration and Automation​

12.1 Integration with Azure Event Grid​

12.2 Integration with Azure CDN​

12.3 Automation with Azure DevOps / GitHub Actions​

13. Final Summary​

1. Initial Intuition

2. Context

2.1 Why Object Replication exists

2.2 Main use cases

3. Building the Concepts

3.1 The fundamental components

3.2 Mandatory prerequisites

3.3 How replication is asynchronous

3.4 Relationship between policy at source and destination

4. Structural View

5. Practical Operation

5.1 What is and isn't replicated

5.2 Deletion behavior

5.3 Rule filters

5.4 Historical data replication

6. Implementation Methods

6.1 Azure Portal

6.2 Azure CLI

6.3 Azure PowerShell

6.4 Bicep / ARM

7. Control and Security

7.1 Authentication and required permissions

7.2 Cross-tenant replication

7.3 Replicated data and encryption

8. Decision Making

8.1 Object Replication vs other strategies

8.2 Filters: when to use each one

9. Best Practices

10. Common Errors

11. Operation and Maintenance

11.1 Checking replication status

11.2 Monitoring metrics

11.3 Adding rules to an existing policy

11.4 Removing a policy

11.5 Important limits

12. Integration and Automation

12.1 Integration with Azure Event Grid

12.2 Integration with Azure CDN

12.3 Automation with Azure DevOps / GitHub Actions

13. Final Summary