Object Replication (Azure Blob Storage)
What it is
Object replication asynchronously copies blobs from a source container in one storage account to a destination container in another storage account — typically in a different region (or the same region) — for DR, latency, or compliance reasons.
Why it exists
To give you asynchronous, account-level blob replication without building your own copy jobs (AzCopy, SDK): a one-way copy of data (blob contents) so the destination has a working copy even if the source region fails.
Key ideas
- Works on block and append blobs (block blobs, and append blobs supported). It does not replicate page blobs.
- Both source and destination accounts must have blob versioning enabled to use object replication.
- A replication policy (defined on the source account) contains one or more rules: each rule maps a source container to a destination container, with an optional prefix filter (only blobs matching the prefix are copied).
- Copies are asynchronous/eventual: replication lag depends on copying in the background.
- Once a policy applies, subsequent changes (new blobs, overwrites, deletes) to the source are copied. Pre-existing blobs and historical versions are only copied if you opt in to copy snapshots / historic versions at configuration time.
- Billing: you pay for destination storage plus the read/write operations used to copy.
How it fits (diagram)
Exam notes
- Memorize the preconditions: both accounts need blob versioning enabled, and you can only replicate block/append blobs (not page blobs).
- It’s one-way and asynchronous — not synchronous geo-replication of an entire account, and not version-to-version for blobs that already exist unless historic versions are selected.
- Use it for DR / BCDR and to keep copies close to users in another region.
Related
blob-storage · blob-versioning · storage-account · storage-performance
📘 Source: Microsoft Learn — Object Replication