Recommend a High Availability Solution for Semi-Structured and Unstructured Data — Lesson

A media company streams videos and serves user-uploaded thumbnails from Azure Blob Storage accounts in three regions. One Friday evening their Singapore region experiences a 40-minute storage outage. Customer-visible impact: zero. Internal impact: an oncall engineer logs into Azure Monitor, sees the storage account has failed over to its paired region, and goes back to dinner. Six months earlier the architect had picked RA-GZRS over LRS to save the business roughly $4{\times}$ on storage replication cost — and the executives second-guessed the line item every quarter. The Friday-night non-event paid back the entire premium in a single outage. This lesson is about making that kind of decision deliberately for both semi-structured (Cosmos DB) and unstructured (Storage Account, Azure Files) data.

We will work through Azure's high availability story for non-relational data the way the AZ-305 exam expects you to: choosing storage account replication SKUs (LRS, ZRS, GRS, GZRS, RA-GZRS), configuring Cosmos DB multi-region writes against the right consistency level, designing Azure Files replication for SMB/NFS workloads, and understanding when storage account failover is automatic, customer-initiated, or impossible. Reference: the AZ-305 exam study guide, particularly the modules on storage redundancy, Cosmos DB consistency models, and storage account failover.

Why This Matters

Unstructured data is where customers' real assets live — videos, documents, images, telemetry blobs, ML feature stores. When the storage account that serves a global app goes offline, customer-facing failures begin within seconds and continue until either the storage layer recovers or the application fails over. The mistake architects most often make is assuming that a regional outage is rare enough to ignore. Microsoft has had multiple multi-hour regional storage incidents in the last five years; every one of them was a board-level meeting at the affected customers.

This LO is also the place where the exam mines the largest pricing surface: LRS is the cheapest at $1\times$, ZRS is roughly $1.25\times$$, `GRS` is roughly $$2\times$$, `GZRS` is roughly $2.5\times, and RA-GZRS adds a small read-access premium. The right SKU is rarely the most expensive — it is the one whose protection matches the workload's blast-radius requirement. If you can match a workload — analytics, transactional, archival, compliance — to the right replication SKU and configure Cosmos DB consistency correctly, you will pass this slice of the exam and design unstructured-data HA like a senior architect. The career payoff is concrete: every "what's our blast radius?" workshop, every cost-optimisation review, every data-platform RFP touches this LO.

Prerequisites

Before working through this lesson, make sure you can answer each prompt below in one or two sentences.

• Storage account services. Can you list the four services a storage account exposes: Blob, Files, Queues, Tables? — Self-check: which one is HTTP-only and which one supports SMB/NFS?
• Azure regions and zones. Do you know which regions have AZ support and what a region pair is? — Self-check: what is the difference between North Europe and West Europe as a pair?
• Consistency models. Can you recite the five Cosmos DB consistency levels — Strong, Bounded Staleness, Session, Consistent Prefix, Eventual? — Self-check: which is the default and why?
• CAP theorem essentials. Can you explain why a partition forces a choice between consistency and availability? — Self-check: which side does Cosmos DB default to?
• Storage redundancy SKU names. Can you read LRS, ZRS, GRS, GZRS, RA-GZRS and say what each one protects against? — Self-check: which SKUs include read access to the secondary?

If any of these feels shaky, pause and review the storage and Cosmos modules from Unit 2 and Unit 3 of the AZ-305 guide before continuing.

Learning Objectives

By the end of this lesson, you will be able to:

1. Analyse an unstructured or semi-structured workload's availability requirements (RPO, RTO, blast radius, geographic constraints) and translate them into a storage replication SKU or a Cosmos DB topology.
2. Evaluate the trade-offs between LRS, ZRS, GRS, GZRS, and RA-GZRS for a given workload, including cost.
3. Design a Cosmos DB multi-region topology with the right consistency level for the application's read/write pattern.
4. Recommend an Azure Files redundancy and replication strategy (ZRS plus Azure File Sync cloud tiering, for example) for a hybrid SMB workload.
5. Recognise failover constraints — single-region SKUs cannot fail over, read-access secondaries are eventually consistent, write replication lags — that silently break a design.
6. Compute the storage cost premium of each SKU choice and defend it with the workload's blast-radius profile.

Building Blocks

Read this section as a glossary. Each term follows the same shape: an everyday analogy, a formal definition, then the reason it matters for the exam.

LRS (Locally Redundant Storage) — Three copies in one rack-isolated cluster within one datacentre. Like three photocopies stored in three folders of the same cabinet. Formally, LRS writes synchronously to three replicas in one Azure datacentre. Durability: eleven nines (99.999999999%) for one-year availability. It matters because LRS is the cheapest SKU and the right answer for ephemeral or easily reproducible data (e.g., transient logs).

ZRS (Zone-Redundant Storage) — Three copies spread across three availability zones in one region. Like three photocopies stored in three buildings on the same block. Formally, ZRS writes synchronously to one replica in each of three AZs within a region. Durability: twelve nines (99.9999999999%). It matters because ZRS is the cheapest SKU that survives an entire datacentre going dark.

GRS (Geo-Redundant Storage) — LRS in the primary region plus async-replicated LRS in the paired region. Like one folder in your office and a copy mailed to a sister office overnight. Formally, GRS writes synchronously to three replicas in the primary and asynchronously to three replicas in the paired region. RPO: roughly 15 minutes. It matters because it protects against full regional disasters but does not survive a zone failure in the primary as cleanly as ZRS does.

GZRS (Geo-Zone-Redundant Storage) — ZRS in the primary region plus async-replicated LRS in the paired region. Combines zone redundancy and geo-redundancy. Formally, GZRS writes synchronously to three AZs in the primary and asynchronously to three replicas in the paired region. RPO: roughly 15 minutes. It matters because it is the most resilient single SKU — survives zone failure with no RPO impact and regional failure with $\sim 15$-minute RPO.

RA-GZRS / RA-GRS — The "read-access" flavour of geo-redundant storage. Formally, adds an HTTPS endpoint (<account>-secondary.blob.core.windows.net) that allows reads from the paired-region replica. Reads are eventually consistent (the secondary trails the primary). It matters because it lets applications fall back to reads from the secondary during regional outages without waiting for a full failover.

Storage account failover (customer-initiated) — A manual operation that promotes the secondary region to be the new primary. Formally, available on GRS, GZRS, RA-GRS, RA-GZRS accounts. After failover the account is LRS in the new primary; you have to re-enable geo-redundancy afterwards. RTO: typically under an hour. It matters because most regional outages do not auto-fail-over — you have to initiate it.

Cosmos DB multi-region writes (active-active) — A topology where multiple Azure regions can accept writes for the same Cosmos DB account. Formally, an account property (enableMultipleWriteLocations: true) that turns all configured regions into write regions, replicating asynchronously with last-write-wins or custom conflict resolution. It matters because it is the only NoSQL pattern Azure offers that gives single-digit-millisecond writes globally.

Cosmos DB consistency levels — Five levels from Strong (linearizable, single-write-region only) through Bounded Staleness, Session (default), Consistent Prefix, and Eventual. Formally, the contract Cosmos DB makes about what reads will and will not see relative to writes. It matters because the choice trades latency, availability, and developer ergonomics — and the exam tests the trade-off matrix directly.

Azure File Sync — A service that turns an on-prem Windows Server into a cache for an Azure Files share. Formally, a multi-master replication topology that tiers cold files to Azure and keeps hot files local. It matters because it is the right answer when a customer asks for "a global file share that survives a regional outage" — sync the share to multiple endpoints across regions for read-only access during outages.

Deep Dive

1. Storage account redundancy SKUs — pick the right one, not the most expensive one

The redundancy SKU is set per storage account at creation (and can be changed afterwards within limits). The decision is driven by two questions: what failure modes must the data survive, and how much cost premium is the workload worth?

[!TIP] A single SKU choice covers 90% of the design question. For production user-facing workloads, default to GZRS; downgrade to ZRS only when cross-region risk is explicitly out of scope; downgrade to LRS only for transient data.

[!WARNING] LRS and ZRS accounts have no failover ability — you cannot promote them to a different region because there is no replica there. Customers who later need cross-region protection must do a one-time account migration with copy tooling.

2. Storage account failover — when it happens and when it does not

Microsoft splits storage outages into two tracks. Customer-initiated failover is the path for most outages: the customer (after Microsoft confirms the primary is unreachable for an extended period) clicks "failover" in the portal, the secondary is promoted to primary, and the account becomes LRS in the new primary region. Microsoft-initiated failover is reserved for extreme, prolonged regional disasters and happens automatically — but this path is rare and not part of the SLA.

The exam frequently tests the post-failover state. After failover, the storage account is LRS in the new primary region — geo-redundancy is gone until you re-enable it. Customers who fail over and forget to re-enable geo-redundancy run unprotected against the next regional event.

[!IMPORTANT] The Microsoft-published SLA for storage durability does not include any guarantee about RTO during customer-initiated failover. The published RTO of "less than 1 hour" is operational guidance, not a contract — design with margin.

3. Cosmos DB HA — regions, consistency, and conflict resolution

Cosmos DB is the canonical Azure NoSQL service and the only PaaS database that offers true multi-region writes with bounded latency. HA design for Cosmos DB has three orthogonal dials: number of regions, consistency level, and (if multi-write is enabled) conflict resolution.

Cosmos DB is the only Azure DB whose financially-backed SLA covers reads (it gives 99.999% read availability on multi-region accounts and 99.99% on single-region accounts). The exam will sometimes phrase a workload requirement as "five-nines for reads" — the answer is Cosmos DB multi-region, period.

[!NOTE] isZoneRedundant: true per region is the AZ flag for Cosmos DB. The exam may test that you remember Cosmos DB zone redundancy is configured per region, not globally — you can have zone redundancy in your primary writeable region while keeping a cheaper, non-zone-redundant secondary.

4. Azure Files HA — ZRS, geo-redundancy, and Azure File Sync

A quick reference for which Azure Files performance tier supports which redundancy SKU:

Azure Files exposes SMB and NFS shares from a storage account and inherits the redundancy SKU rules. Two practical nuances matter for the exam.

First, Premium Files shares (the FileStorage account kind) only support LRS and ZRS — there is no geo-redundant Premium tier. For Premium workloads that need cross-region protection, the pattern is Azure File Sync or third-party replication.

Second, Azure File Sync is the recommended cross-region story for SMB workloads. Configure two on-prem (or in-cloud) Windows Server endpoints as sync targets for the same cloud share. Each endpoint becomes a hot cache; cold files tier to the cloud. During a regional cloud outage, the on-prem caches continue to serve reads.

5. RPO / RTO matrix for unstructured and semi-structured workloads

Worked Examples

Easy — pick the right redundancy SKU

Problem. A company stores user-uploaded profile photos in Azure Blob Storage. The photos are easily re-uploadable but losing a photo is annoying. Cost matters. The region has AZ support. Recommend a redundancy SKU.

Solution. Use ZRS. It protects against an entire-datacentre failure (so a zone outage does not lose photos) at a cost premium of $\sim 1.25\times$ over LRS. GRS or GZRS would be overkill: photos are re-uploadable, so the additional regional protection is not worth $2\times$ cost. The exam pattern: when data is reproducible, prefer ZRS over geo-redundant SKUs.

[!NOTE] If the photos held legal or contractual value (e.g., signed PDFs in a regulated industry), the recommendation flips to GZRS or RA-GZRS despite the cost.

Medium — multi-region Cosmos DB with the right consistency

Problem. A retail app needs $< 10$ ms write latency for users in three continents (Europe, North America, Asia). The product team is comfortable with users in Europe occasionally seeing a 1-second-old inventory count from a write in Asia. Recommend a Cosmos DB topology and consistency level.

Solution. Deploy a multi-write Cosmos DB account in West Europe, East US 2, and Southeast Asia. Enable enableMultipleWriteLocations: true. Set consistency to Session (the default) for application-scoped strong reads, or Bounded Staleness with maxStalenessSeconds: 1 if the product team prefers a strict global bound. Configure zone redundancy in each region. Single-digit-ms write latency is achievable because clients write to their nearest region.

[!TIP] Default to Session consistency unless the workload specifically needs Bounded Staleness or Strong. Session covers most real-world apps with the best latency.

Hard — storage cost decision under blast-radius pressure

Problem. A media analytics workload writes 50 TB of new blobs per month and serves them globally. Leadership requires that no single regional outage cause the workload to lose data; reading from a slightly stale secondary during such an outage is acceptable. Cost is being scrutinised. The current account is GRS. Recommend a change.

Solution. Move to RA-GZRS. The change adds two protections: zone redundancy in the primary (whereas GRS is only zone-fragile LRS in the primary), and read access to the secondary, which lets the workload serve traffic during a regional outage without waiting for an explicit failover. The cost premium over GRS is roughly 25% — a fraction of the cost of the outage it prevents. Reads from the secondary are eventually consistent with the primary (typically $\le 15$ minutes behind); the workload tolerates this.

[!IMPORTANT] The exam will sometimes phrase this as "reduce blast radius without losing the existing geo-redundancy". The answer is upgrade GRS → GZRS (free zone-redundancy in the primary) or GRS → RA-GZRS (also adds read fallback) — not an additional account in a third region.

Visual Explanations

Figure 1 — Decision flow for unstructured-data redundancy

Walk the tree top-down. Most production workloads land at GZRS or RA-GZRS; the exam often phrases the question so that LRS looks attractive on cost — but the correct answer is rarely LRS for production.

Figure 2 — Multi-region Cosmos DB with active-active writes

In multi-write mode each region accepts writes locally; replication to peers is asynchronous. Conflicts are resolved at write time using a configurable policy (last-write-wins on a numeric timestamp by default, or a custom stored procedure for application-defined merging).

Figure 3 — Storage redundancy SKU summary

The "Survives one datacentre" column maps to AZ protection in the primary region; the "Survives one region" column maps to geo protection. The cost figures are illustrative — actual pricing varies by region and tier — but the ratios are what the exam tests.

Common Mistakes

❌ Myth: LRS is fine for production because Azure storage is durable. ✅ Reality: LRS is durable (eleven nines) but not available across datacentre failures. An entire zone going dark takes an LRS account offline until that zone recovers. Production workloads should default to ZRS minimum. Why it's tricky: Durability marketing language (eleven nines!) conflates with availability. They are different.

❌ Myth: Geo-redundant storage auto-fails-over during a regional outage. ✅ Reality: GRS, GZRS, RA-GRS, and RA-GZRS failover is customer-initiated for nearly all outages. Microsoft-initiated failover is reserved for catastrophic, prolonged events. Why it's tricky: "Geo-redundant" sounds like "geo-failover" but the customer holds the button. Runbooks should explicitly include the failover step.

❌ Myth: Cosmos DB with multi-region writes always gives Strong consistency globally. ✅ Reality: Strong consistency is incompatible with multi-region writes. The valid combinations are: Strong + single write region; or Bounded Staleness / Session / Consistent Prefix / Eventual + multi-region writes. Why it's tricky: Cosmos DB marketing pitches "global plus strong" — but Strong here means linearizable, which requires a single source of truth.

❌ Myth: After a customer-initiated storage account failover, the account stays geo-redundant. ✅ Reality: After failover the account is LRS in the new primary region. You must explicitly re-enable GRS / GZRS to re-establish geo-redundancy with the old primary (now the new secondary). Why it's tricky: Operators forget to re-enable. The account silently becomes single-region until the next outage.

Practice Exercises

🟢 Exercise 1. A workload uses LRS blob storage in East US. The East US zone 2 datacentre fails. What happens to the workload?

▶💡 Hint

LRS places all three replicas in one datacentre.

▶✅ Solution

If the storage account's three replicas happen to be in zone 2 (which is opaque to the customer), the account is offline until the zone recovers. The blobs are not lost — they are durable — but they are not available. The fix is to recreate the account as ZRS so the three replicas are spread across zones, or to migrate to GZRS for both zone and region protection.

🟡 Exercise 2. A Cosmos DB account is configured for Strong consistency with a single write region in West Europe and read regions in North Europe and East US 2. Reads from East US 2 are slow ($\sim 100$ ms). Why, and what is the cheapest fix?

▶💡 Hint

Strong consistency requires a synchronous round trip on reads.

▶✅ Solution

Strong consistency requires every read to be linearizable, which means each read in East US 2 must verify the latest value with West Europe — adding the cross-Atlantic round trip. The cheapest fix is to relax consistency to Bounded Staleness (with a small maxStalenessSeconds if the app needs it) or Session if the app fits the session model. Reads then complete locally in East US 2.

🟡 Exercise 3. A team configures Azure Files Premium with the requirement of cross-region protection. The portal does not offer GRS for Premium Files. What is the supported pattern?

▶💡 Hint

Premium Files is restricted to LRS and ZRS. Cross-region protection must come from a different layer.

▶✅ Solution

Premium Azure Files only supports LRS and ZRS. For cross-region protection, the supported pattern is Azure File Sync with two Windows Server endpoints in different regions (or one on-prem and one in-cloud). Each endpoint caches hot files locally; cold files tier to the cloud share. Pair this with a ZRS cloud endpoint for zone-redundant primary storage.

🔴 Exercise 4. A retail app needs 99.999% availability for reads from Cosmos DB. The account is currently single-region. What is the minimum change?

▶💡 Hint

Cosmos DB only commits five-nines on reads when configured a specific way.

▶✅ Solution

Add at least one additional read region (a second locationName in locations). With $\ge 2$ regions, the SLA for read availability rises from 99.99% (single region) to 99.999% (multi-region). The write region need not change; consistency level can stay Session. Optional: set enableAutomaticFailover: true so a regional outage promotes a secondary read region automatically.

🔴 Exercise 5. A storage account was migrated from GRS to LRS last quarter to save cost. Today a regional outage hits the primary. Walk through the recovery.

▶💡 Hint

LRS has no secondary. There is no failover path.

▶✅ Solution

The data is unavailable for the duration of the regional outage. No customer-initiated failover is possible because LRS has no paired-region replica. Recovery options are limited to: wait for the primary to recover, or restore from an independent backup (e.g., Azure Backup for blobs, if configured). The lesson is that switching from GRS to LRS is a strategic blast-radius decision, not a cost-saving line item.

🟢 Exercise 6. True or false: a Cosmos DB account with enableAutomaticFailover: true and enableMultipleWriteLocations: false automatically promotes the secondary region when the primary fails.

▶💡 Hint

Read both flags. One is about write failover; the other is about multi-write topology.

▶✅ Solution

True. enableAutomaticFailover: true on a single-write-region account causes Cosmos DB to promote the next-priority read region to the new write region during a primary regional outage. Multi-write would have made each region already-writeable; with single-write, the failover flag matters.

🟡 Exercise 7. Design a Bicep snippet for a RA-GZRS general-purpose v2 storage account with HTTPS-only, minimum TLS $1.2, and blob soft-delete enabled for 30 days.

▶💡 Hint

Look up the Microsoft.Storage/storageAccounts resource and the blobServices/default child for soft-delete.

▶✅ Solution

bicepCopy

resource sa 'Microsoft.Storage/storageAccounts@2023-05-01' = { name: 'stprodragzrs' location: 'westeurope' kind: 'StorageV2' sku: { name: 'Standard_RAGZRS' } properties: { minimumTlsVersion: 'TLS1_2' supportsHttpsTrafficOnly: true allowBlobPublicAccess: false } } resource blobSvc 'Microsoft.Storage/storageAccounts/blobServices@2023-05-01' = { parent: sa name: 'default' properties: { deleteRetentionPolicy: { enabled: true, days: 30 } containerDeleteRetentionPolicy: { enabled: true, days: 30 } } }

Summary & Concept Map

The headline takeaways from this lesson:

• Replication SKU choice is blast-radius choice. LRS survives disks; ZRS survives zones; GRS survives regions (with failover); GZRS survives both; RA-* variants add read fallback.
• Geo-redundant failover is customer-initiated. Plan runbooks accordingly. After failover the account becomes LRS until you re-enable geo-redundancy.
• Cosmos DB HA is about regions + consistency + multi-write. Multi-region writes deliver active-active globally; consistency level governs reads and is the latency lever.
• Cosmos DB Strong consistency is incompatible with multi-write. Use Bounded Staleness if you need a strict global staleness bound while keeping multi-write.
• Premium Azure Files is LRS/ZRS only. Cross-region protection for Premium Files uses Azure File Sync.
• RA-GZRS is the default for production user-facing unstructured data. The cost premium over LRS is real but small compared to the cost of a regional outage.

Walk the map workload-down: storage account or Cosmos DB, then SKU or region count, then the constraint that the choice imposes (failover semantics, consistency level, conflict resolution). Most exam traps live in the last column.