This chapter covers Azure Blob Object Replication, a feature that asynchronously replicates block blobs between containers in different storage accounts. For the AZ-104 exam, this is a niche but testable topic under Storage Objective 2.1: Configure blob storage. Expect 1-2 questions on object replication, focusing on its prerequisites, supported blob types, replication rules, and interaction with other features like soft delete and snapshots. Mastering this topic ensures you can design geo-redundant storage solutions without using Azure Site Recovery or geo-replication at the account level.
Jump to a section
Imagine a library system with two branches: a main library and a satellite branch. The main library has a special shelf labeled 'Video Tutorials' (source container). The satellite library has a corresponding shelf labeled 'Video Tutorials' (destination container). The library employs a dedicated courier who works 24/7. Whenever a new book is added to the main library's Video Tutorials shelf, the courier immediately makes a photocopy of the entire book (including any updates to existing books) and delivers it to the satellite library. The courier only copies books that match a specific genre label (e.g., 'Azure' or 'AWS')—if the book doesn't have that label, it's ignored. The courier maintains a manifest (replication policy) that lists which source shelf maps to which destination shelf. If the satellite library's shelf is empty, the courier builds the entire collection from scratch. The courier never deletes books from the satellite shelf—even if the main library removes a book, the copy remains. However, if a book is deleted from the main library, the courier does not remove the copy. The courier works asynchronously: it might take a few minutes for a new book to appear at the satellite library. The courier also logs every copy operation in a ledger (replication status). If the satellite library is temporarily closed (e.g., for maintenance), the courier queues the copies and delivers them when it reopens. This system ensures that the satellite library's Video Tutorials shelf is always a near-real-time copy of the main library's shelf, but only for books that match the genre filter.
What is Azure Blob Object Replication?
Azure Blob Object Replication is a feature that automatically replicates block blobs from a source container to a destination container. The destination can be in the same storage account or a different storage account, and the accounts can be in the same or different regions. This is different from Azure Storage geo-redundant storage (GRS/RA-GRS) which replicates at the storage account level, not at the container level. Object replication is asynchronous, meaning there is a delay between writing to the source and having the blob available at the destination. The typical replication lag is a few minutes, but can be longer under heavy load or if the source blob is large.
Why Use Object Replication?
The primary use cases are: - Latency reduction: Replicate blobs to a region closer to end users. - Compliance: Keep copies in multiple regions for data sovereignty. - Data protection: Maintain a separate copy for disaster recovery scenarios. - Application isolation: Replicate data between development and production environments.
How It Works Internally
Object replication is implemented at the storage front-end layer. When a blob is written or updated in the source container, the Azure Storage service logs the change. A background process then reads the change log and copies the blob to the destination container. The process uses the source blob's URL and SAS token (if needed) to perform a PUT operation on the destination. The replication is block-level: only changed blocks are copied, not the entire blob, for efficiency. However, for append blobs and page blobs, replication is not supported.
Key Components, Values, Defaults, and Timers
Replication Policy: A set of rules that define the source container, destination container, and optional prefix filter. A policy can have up to 10 rules. Each rule maps one source container to one destination container.
Prefix Filter: Optional. If specified, only blobs with names starting with the given prefix are replicated. Multiple prefixes can be specified per rule (up to 10).
Minimum Storage Account Version: Both source and destination storage accounts must be of type StorageV2 (general-purpose v2) or BlockBlobStorage. Premium block blob accounts are not supported.
Blob Types: Only block blobs are supported. Append blobs and page blobs are not replicated.
Replication Scope: Replication is at the block blob level. Snapshots and soft-deleted blobs are not replicated. If a blob has snapshots, only the base blob is replicated. If the source blob is deleted (permanently or soft-deleted), the destination blob is NOT deleted. To remove the destination blob, you must manually delete it or set a lifecycle management rule.
Replication Time: There is no SLA for replication lag. Typically, it completes within a few minutes, but can be up to a few hours for large blobs or high throughput.
Cost: Object replication incurs costs for read operations on the source and write operations on the destination, plus egress charges if the destination account is in a different region.
Configuration and Verification
You can configure object replication using the Azure portal, PowerShell, Azure CLI, or REST API.
Azure CLI Example:
First, install the storage-blob-preview extension:
az extension add --name storage-blob-previewCreate a replication policy:
az storage account blob-service-policy create \
--account-name sourcestorage \
--resource-group myResourceGroup \
--policy @policy.jsonWhere policy.json contains:
{
"rules": [
{
"ruleId": "rule1",
"sourceContainer": "sourcecontainer",
"destinationContainer": "destcontainer",
"filters": {
"prefixMatch": ["log", "backup"]
}
}
]
}Azure PowerShell Example:
$rule = New-AzStorageObjectReplicationRule `
-SourceContainer sourcecontainer `
-DestinationContainer destcontainer `
-PrefixMatch "log", "backup"
$policy = New-AzStorageObjectReplicationPolicy `
-ResourceGroupName myResourceGroup `
-StorageAccountName sourcestorage `
-Rule $ruleVerification:
Check replication status using Azure CLI:
az storage blob show \
--account-name sourcestorage \
--container-name sourcecontainer \
--name myblob.txt \
--query "properties.objectReplicationRules"This shows the replication status of the blob, including whether it has been replicated and the last replication time.
Interaction with Related Technologies
Soft delete: Object replication does not replicate soft-deleted blobs. If a blob is soft-deleted in the source, the destination blob remains unchanged (it is not deleted). To replicate deletes, you must use lifecycle management or custom logic.
Snapshots: Only the base blob is replicated. Snapshots are not replicated. If a snapshot is created after replication, it is not copied to the destination.
Change feed: Object replication uses the change feed internally to track changes. Enabling change feed is a prerequisite for object replication.
Lifecycle management: You can apply lifecycle management rules to the destination container to automatically delete blobs after a certain period. This is useful for cleaning up destination blobs that are no longer needed.
Azure Policy: You can enforce object replication policies using Azure Policy to ensure compliance.
Limitations
Object replication does not support replication of blobs in a storage account that has a firewall or virtual network rules enabled. The source and destination accounts must allow access from all networks, or you must use managed identity and private endpoints.
The source and destination storage accounts must be in the same Azure Active Directory tenant.
Object replication cannot be used to replicate blobs between storage accounts in different sovereign clouds (e.g., Azure Government to Azure Commercial).
If the destination blob already exists and its last modified time is newer than the source blob, the replication is skipped (to prevent overwriting newer data).
The maximum number of replication policies per storage account is 10, and each policy can have up to 10 rules.
Step-by-Step Configuration
1. Create source and destination storage accounts: Both must be StorageV2 or BlockBlobStorage. Enable hierarchical namespace if using Data Lake Storage Gen2 (block blobs only). 2. Enable change feed on the source storage account: This is required for object replication. It can be enabled via the portal under 'Data protection' or via CLI:
az storage account blob-service-properties update --enable-change-feed trueCreate source and destination containers: Ensure they exist.
Create replication policy: Define rules mapping source to destination containers with optional prefix filters.
Monitor replication: Use Azure Monitor metrics or storage logs to track replication progress and errors.
Troubleshooting
If replication is not occurring, check that the change feed is enabled on the source account.
Verify that the source and destination containers exist.
Check that the storage account type is correct (StorageV2 or BlockBlobStorage).
Ensure that the blob type is block blob. Append blobs and page blobs are not replicated.
If using firewall rules, configure service endpoints or private endpoints for the storage accounts.
Use the Azure portal to view the replication policy and check for errors in the 'Object replication' blade.
Enable Change Feed on Source
Object replication relies on the change feed to track blob modifications. The change feed stores ordered records of all changes (create, update, delete) to blobs and blob metadata in the storage account. It must be enabled on the source storage account. This is a prerequisite; without it, replication cannot function. Enable it via the Azure portal under 'Data protection' > 'Change feed' or using Azure CLI: `az storage account blob-service-properties update --enable-change-feed true`. The change feed is stored as blobs in a `$blobchangefeed` container, which is hidden. Enabling it incurs a small storage cost.
Create Source and Destination Containers
Both the source and destination containers must exist before creating the replication policy. The source container holds the blobs to be replicated. The destination container receives the replicas. They can be in the same storage account or different ones. If the destination container does not exist, the replication policy creation will fail. Ensure the containers are created with appropriate access levels (private recommended). The destination container can have a different name than the source.
Define Replication Policy with Rules
A replication policy is a set of rules. Each rule maps one source container to one destination container. You can optionally specify prefix filters to replicate only blobs whose names start with a given string. Multiple prefixes can be specified (up to 10 per rule). The policy is created at the source storage account. The rule ID is optional; if not provided, Azure generates one. The policy can have up to 10 rules. The source and destination containers must be in the same Azure AD tenant. The policy is defined in JSON or via PowerShell/CLI.
Apply the Replication Policy
Once the policy is defined, it is applied to the source storage account. This triggers the replication process. The Azure Storage service immediately starts replicating existing blobs that match the filter criteria. New blobs and updates are replicated as they occur. The replication is asynchronous; there is no SLA for how long it takes. You can check the replication status of individual blobs using the `az storage blob show` command with the `--query` parameter to view `objectReplicationRules`.
Monitor and Verify Replication
After applying the policy, monitor the replication using Azure Monitor metrics such as 'Replication Lag' and 'Replication Success'. Use storage logs to identify errors. Verify that blobs appear in the destination container. Note that if the source blob is deleted, the destination blob is not automatically deleted. You must manually delete or use lifecycle management. Also, if the destination blob has a newer last modified time than the source, replication is skipped to prevent overwrites. Use the Azure portal's 'Object replication' blade to see the policy and its status.
Enterprise Scenario 1: Global Content Distribution
A multinational company hosts training videos in a storage account in the West US region. Employees in Europe experience high latency when accessing videos. The company enables object replication to replicate the video container to a storage account in West Europe. They use a prefix filter to replicate only blobs with the prefix 'training/'. This reduces latency for European employees because they access the local copy. The replication is asynchronous, so new videos appear in Europe within minutes. The company also sets up lifecycle management on the destination to delete videos older than 90 days. Performance considerations: The source account must handle the additional read operations for replication. The company monitors replication lag and ensures the change feed is enabled. If replication lag exceeds 30 minutes, they investigate network issues or throttling.
Enterprise Scenario 2: Compliance Data Replication
A financial institution must keep copies of transaction logs in two different regions for regulatory compliance. They use object replication to replicate a container named 'logs' from a storage account in US East to one in US West. They do not use a prefix filter because all logs must be replicated. The destination storage account has soft delete enabled to protect against accidental deletion. The institution uses Azure Policy to enforce that all storage accounts containing logs have object replication configured. A common issue they face is that if the source storage account has a firewall enabled, replication fails. They resolve this by using a managed identity with private endpoints. They also set up alerts on replication failures. The replication lag is typically under 5 minutes, which meets their compliance requirement of RPO < 15 minutes.
Scenario 3: Application Migration
A company is migrating an application from one Azure subscription to another. They use object replication to replicate the application's blob storage container from the source subscription to a storage account in the target subscription. Both subscriptions are in the same Azure AD tenant. They create a replication policy with a rule mapping the source container to the destination container. After replication is complete, they validate the data and switch the application to point to the new storage account. They then delete the replication policy. During migration, they must ensure that no writes occur to the source after the cutover to avoid data inconsistency. They also need to handle any blobs that were not replicated due to filters. In this scenario, they use no prefix filter to replicate all blobs. The replication completes in a few hours for a 1 TB dataset.
What AZ-104 Tests on Object Replication
The exam covers object replication under Storage Objective 2.1: Configure blob storage. You should know:
The supported storage account types: StorageV2 (general-purpose v2) and BlockBlobStorage.
The supported blob types: block blobs only. Append blobs and page blobs are not supported.
Prerequisites: Change feed must be enabled on the source storage account.
Replication behavior: Asynchronous, no SLA on lag. Destination blobs are not deleted when source blobs are deleted.
Filters: Optional prefix filters, up to 10 per rule.
Interaction with other features: Snapshots and soft-deleted blobs are not replicated.
Limitations: Cannot be used with firewall rules unless using private endpoints. Source and destination must be in same Azure AD tenant.
Common Wrong Answers and Why
Wrong answer: Object replication supports all blob types (block, append, page). Candidates confuse object replication with account-level geo-replication. The exam often presents a scenario where an append blob is being replicated, and the correct answer is that it fails. Remember: only block blobs are supported.
Wrong answer: Replication is synchronous. Candidates assume replication is instant because it is called 'replication'. The exam tests that it is asynchronous and there is no SLA. A question might ask about RPO, and the correct answer is 'a few minutes' or 'asynchronous'.
Wrong answer: Deleting a source blob deletes the destination blob. Candidates think replication mirrors all operations. The exam tests that deletes are not replicated. To remove destination blobs, you must use lifecycle management or manual deletion.
Wrong answer: Object replication works with any storage account type. Candidates forget that only StorageV2 and BlockBlobStorage are supported. A question might present a classic storage account and ask why replication fails.
Specific Numbers and Terms
Maximum rules per policy: 10.
Maximum policies per storage account: 10.
Prefix filters per rule: up to 10.
Supported storage account types: StorageV2 (general-purpose v2), BlockBlobStorage.
Unsupported: Premium block blob, classic, general-purpose v1.
Replication scope: Block blobs only.
Prerequisite: Change feed enabled on source.
Replication lag: Typically minutes, no SLA.
Edge Cases
If the destination blob has a newer last modified time than the source, replication is skipped. This protects against overwriting newer data.
If you enable object replication on a container that already has blobs, those existing blobs are replicated (backfill).
If you delete the replication policy, replication stops, but existing destination blobs remain.
If the source storage account is deleted, replication stops, but destination blobs remain.
How to Eliminate Wrong Answers
If the question mentions 'append blob' or 'page blob', eliminate object replication as the solution.
If the question implies immediate consistency or zero data loss, object replication is not the answer because it is asynchronous.
If the question requires replicating deletes, object replication is insufficient; you need lifecycle management or custom logic.
If the question involves a classic storage account, object replication is not possible.
Object replication only supports block blobs in StorageV2 or BlockBlobStorage accounts.
Change feed must be enabled on the source storage account for replication to work.
Replication is asynchronous; there is no SLA on replication time.
Deletion of source blobs does not delete destination blobs; manage deletes separately.
Snapshots and soft-deleted blobs are not replicated.
Prefix filters can be used to replicate only blobs with specific name prefixes.
Maximum of 10 replication policies per storage account, each with up to 10 rules.
These come up on the exam all the time. Here's how to tell them apart.
Object Replication
Replicates at container level, not account level.
Supports only block blobs.
Asynchronous, no SLA on lag.
Can replicate across regions in different accounts.
Requires change feed enabled on source.
Geo-Redundant Storage (GRS/RA-GRS)
Replicates entire storage account synchronously within a region, then asynchronously to paired region.
Supports all blob types, tables, queues, and files.
Synchronous within primary region, asynchronous to secondary.
Replicates to a Microsoft-managed paired region.
No change feed required; enabled at account creation.
Mistake
Object replication replicates all blob types including append blobs and page blobs.
Correct
Object replication only supports block blobs. Append blobs and page blobs are ignored. This is a common exam trap.
Mistake
Object replication is synchronous with zero lag.
Correct
Object replication is asynchronous. There is no SLA on replication time. Typical lag is a few minutes but can be longer.
Mistake
When you delete a source blob, the destination blob is automatically deleted.
Correct
Deletes are not replicated. The destination blob remains even if the source is deleted. You must manage deletion separately.
Mistake
Object replication can be used with any storage account type.
Correct
Only StorageV2 (general-purpose v2) and BlockBlobStorage accounts are supported. Classic and general-purpose v1 accounts are not.
Mistake
Object replication replicates snapshots and soft-deleted blobs.
Correct
Only the base blob is replicated. Snapshots are not copied. Soft-deleted blobs are not replicated; only the active version is.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, but you must use private endpoints or allow trusted Microsoft services. Object replication requires access to the source and destination accounts. If firewalls are enabled, you need to configure service endpoints or private endpoints. Alternatively, you can allow access from 'All networks' temporarily. The exam tests that firewalls can block replication if not configured correctly.
Yes, when you create a replication policy, existing blobs that match the filter criteria are replicated to the destination. This is called backfill. The replication process starts from the beginning of the change feed, so all existing blobs are eventually copied.
No. Both source and destination storage accounts must be in the same Azure AD tenant. This is a hard limitation. If you need cross-tenant replication, you would need to use AzCopy or other tools.
Replication stops immediately. Existing destination blobs remain. No new changes from the source are copied. You can delete the policy without affecting the blobs already replicated. This is a common exam scenario: a question might ask what happens to destination blobs if the policy is deleted.
Yes, you can create multiple rules in the same policy, each mapping the same source container to different destination containers. However, each rule must have a unique rule ID. You can have up to 10 rules per policy, so you could replicate to up to 10 destinations.
Yes. You incur costs for read operations on the source (to read the blob), write operations on the destination (to write the blob), and egress charges if the destination is in a different region. The change feed also incurs storage costs. The exam may ask about cost implications.
Yes, as long as the storage account is StorageV2 with hierarchical namespace enabled. However, only block blobs are replicated. Directory operations and ACLs are not replicated. The replication is at the blob level.
You've just covered Azure Blob Object Replication — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?