9.4 Semi-Structured & Unstructured Data High Availability Design
Key Takeaways
- Azure Cosmos DB availability is driven by three independent choices: consistency level, zone redundancy, and single- vs. multi-region write topology — each affects your effective SLA and RPO.
- Strong consistency requires 2+ regions for dynamic quorum but is incompatible with multi-region writes; only single-write-region accounts can use Strong consistency.
- Per-partition automatic failover (PPAF) lets a single-write-region Cosmos DB account fail over individual partitions to a secondary region automatically, typically within about 3 minutes, without losing data at Strong consistency.
- Azure Storage's four core redundancy tiers form a durability ladder: LRS (11 nines, single datacenter), ZRS (12 nines, 3+ zones), GRS (16 nines, +secondary region, async), GZRS (16 nines, zones + region).
- Only RA-GRS and RA-GZRS grant read access to the secondary region without a failover; plain GRS/GZRS data in the secondary is invisible to applications until you trigger an account failover.
Why This Topic Matters
This is the last of the four high-availability sections in Domain 3, and it closes the loop with the non-relational services from Domain 2 (Cosmos DB, Blob Storage, Azure Files). AZ-305 pairs these services with scenario language like "must survive a region outage with no data loss" or "must remain writable in every region" — and the correct answer usually hinges on a subtle interaction (e.g., Strong consistency being incompatible with multi-region writes) that a candidate who only memorized service names will miss.
Cosmos DB: Zone Redundancy, Consistency, and Write Topology
Zone redundancy for Cosmos DB works like other Azure services — it replicates a region's data across Availability Zones with no impact on performance or latency and no application changes required. Microsoft recommends enabling it wherever supported, especially for single-region accounts, because it raises the account's availability SLA above the non-zone-redundant baseline.
Consistency level interacts directly with multi-region behavior. Cosmos DB offers five levels (Strong, Bounded Staleness, Session, Consistent Prefix, Eventual), but for HA design the critical rule is: Strong consistency is only available for single-write-region accounts, because it requires synchronous quorum writes across 2+ regions, and quorum cannot be maintained once multiple regions are simultaneously accepting writes.
Write topology is the core design fork:
- Single-region writes, multi-region reads: one write region, any number of read regions. Supports Strong consistency. Failure recovery options include per-partition automatic failover (PPAF) — individual partitions fail over to a healthy region automatically, typically completing in about 3 minutes, with no data loss if the account uses Strong consistency — and service-managed failover, which is slower (can take an hour or more) and manual forced failover, which is the recommended way to restore availability quickly during a real outage.
- Multi-region writes ("multi-master"): every configured region can accept writes. This gives the lowest write latency globally and the best write availability, but data is replicated asynchronously between regions, Strong consistency is not supported, and concurrent writes to the same item in different regions can conflict — Cosmos DB resolves these using a configurable conflict resolution policy, with a designated hub region acting as tie-breaker.
| Topology | Consistency support | Failure recovery | Best for |
|---|---|---|---|
| Single-region write, multi-region read | All 5 levels, including Strong | PPAF (~3 min, no data loss at Strong) or forced failover | Workloads needing Strong consistency with global read scale |
| Multi-region write | All except Strong | Automatic SDK re-routing to healthy regions | Globally distributed apps needing local low-latency writes everywhere |
Azure Storage: The Redundancy Ladder
Unstructured and semi-structured object storage (Blob, Files, Tables, Queues, and managed disks where supported) shares a single redundancy model with four core SKUs:
| SKU | Replication | Durability (per year) | Read availability | Survives zone loss? | Survives region loss? |
|---|---|---|---|---|---|
| LRS (Locally Redundant) | 3 copies, 1 datacenter | ≥99.999999999% (11 nines) | ≥99.9% | No | No |
| ZRS (Zone-Redundant) | Synchronous, 3+ zones, 1 region | ≥99.9999999999% (12 nines) | ≥99.9% | Yes | No |
| GRS (Geo-Redundant) | LRS in primary + async copy (LRS) in secondary region | ≥99.99999999999999% (16 nines) | ≥99.9% (secondary not readable) | Yes (secondary intact) | Yes, after failover |
| GZRS (Geo-Zone-Redundant) | ZRS in primary + async copy (LRS) in secondary region | ≥99.99999999999999% (16 nines) | ≥99.9% (secondary not readable) | Yes | Yes, after failover |
Appending RA- (Read-Access) to GRS or GZRS — RA-GRS or RA-GZRS — is what actually lets an application read from the secondary region during a primary-region outage, without waiting for a failover; that raises read availability to ≥99.99%. Plain GRS/GZRS replicate the data for durability, but the secondary copy stays invisible to your application until you trigger an account failover, which is a customer-initiated (or, for a severe outage, Microsoft-initiated) operation that promotes the secondary region to primary. Azure Files does not support RA-GRS/RA-GZRS at all — only GRS/GZRS without the read-access option.
Exam Scenarios
Scenario 1: A globally distributed IoT ingestion pipeline needs to accept writes with low latency in three regions simultaneously and can tolerate eventual conflict resolution. Design decision: Cosmos DB with multi-region writes enabled and a custom conflict resolution policy — Strong consistency is off the table by definition here.
Scenario 2: A financial ledger requires Strong consistency and must recover a failed write region automatically within minutes with zero data loss. Design decision: single-write-region Cosmos DB with Strong consistency and per-partition automatic failover (PPAF) enabled — roughly 3-minute recovery, no data loss.
Scenario 3: An application stores compliance documents in Blob Storage and must continue serving read traffic from a secondary region during a declared primary-region outage, without performing a failover. Trap: choosing plain GRS looks sufficient because it "replicates to another region," but GRS alone gives no read access to that data — only RA-GRS (or RA-GZRS) satisfies the "read without failover" requirement.
Takeaways
- Strong consistency and multi-region writes are mutually exclusive in Cosmos DB — this is one of the highest-yield facts in the entire business-continuity domain.
- PPAF gives single-write-region Cosmos DB accounts near-automatic, ~3-minute, no-data-loss recovery at Strong consistency — know it as the modern alternative to slower service-managed failover.
- Recite the storage durability ladder by nines: LRS 11, ZRS 12, GRS/GZRS 16 — and remember durability (won't lose the data) is a different promise than availability (can read/write it right now).
- "Read access to the secondary" always means RA-GRS or RA-GZRS, never plain GRS/GZRS — and Azure Files never gets the RA option at all.
A team wants an Azure Cosmos DB account where every region can accept both reads and writes simultaneously, to minimize write latency for a globally distributed user base. Which consistency level can this account NOT use?
An application must be able to read blob data from a secondary Azure region during an outage in the primary region, without first performing a manual account failover. Which storage redundancy option is required?