Design for High Availability — Lesson

This lesson synthesizes three critical learning objectives for designing resilient Azure architectures: ensuring high availability for compute resources across multiple zones, implementing failover and redundancy for relational databases, and building multi-region strategies for unstructured data. Whether you're deploying a critical financial application or a global content delivery network, these patterns determine whether your system survives zone failures, region outages, or sudden traffic spikes.

Reference: Ch. 3, §3.2, p. 120–135 of the AZ-305 exam book.

Why This Matters

High availability (HA) is not optional for production systems—it is the foundation of customer trust and business continuity. Azure's infrastructure is built on regions and availability zones, but deploying resources into those zones requires intentional design decisions.

Consider the economics: a single zone failure in a major metropolitan area might affect $10 million in daily revenue. A misconfigured failover group could lose transactional consistency when you need it most. An unplanned region outage could render your entire backup strategy useless if all copies live in the same geographic footprint.

HA design spans three layers:

1. Compute: Distributing application instances across availability zones so one zone failure doesn't cascade.
2. Data (relational): Ensuring transactional databases remain available and consistent during zone/region failures.
3. Data (unstructured): Protecting blobs, files, and document stores from datacenter loss through redundancy and replication.

The AZ-305 exam tests your ability to architect solutions that balance resilience, cost, and consistency. This lesson synthesizes the three specialized learning objectives into an integrated framework.

Prerequisites

Before beginning this lesson, you should be familiar with:

• Azure regions and availability zones: What they are, how they differ, and why they matter for geographic distribution.
• Basic networking: Virtual networks, NSGs, and load balancer fundamentals.
• Azure compute basics: VM SKUs, App Service tiers, container basics (ACI/AKS).
• Azure storage models: Blobs, tables, queues, and relational databases at a high level.
• Replication concepts: RPO, RTO, and the tradeoffs between sync and async replication.

If you haven't completed the prerequisite units on Azure fundamentals and networking, we recommend starting there.

Learning Objectives

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

1. LO26: Design high-availability compute architectures using availability zones, availability sets, zone-redundant services, and load balancer health probes to tolerate zone failures.
2. LO27: Implement high-availability relational databases using Azure SQL Database with geo-failover, auto-failover groups, and Always On Availability Groups on VMs.
3. LO28: Build high-availability unstructured data layers using Cosmos DB multi-region writes, storage account redundancy (ZRS, GZRS, RA-GZRS), and replication strategies.

Building Blocks

Availability Zones

Analogy: Like having duplicate fire stations in different neighborhoods—if one burns down, others can still respond.

Definition: Availability zones are unique physical locations within an Azure region, each with independent power, cooling, and networking. Deploying resources across zones ensures that a single datacenter failure doesn't take your application offline.

Why it matters: Azure's SLA for zone-redundant services is typically 99.99%; single-zone deployments offer lower SLAs (often 99.9% or less).

Availability Sets

Analogy: A scheduling system that spreads your VMs across physical racks so hardware failures affect only a subset of your fleet.

Definition: Availability sets use update domains and fault domains to ensure that VMs don't share single points of failure. Fault domains isolate hardware failures; update domains sequence maintenance windows.

Why it matters: Within a single zone, availability sets can achieve 99.95% SLA; they are cheaper than multiple zones but offer less resilience against zone-wide outages.

Redundancy Models for Storage

Analogy: Different insurance plans—LRS is self-insured within one building, GRS is insured across cities, RA-GZRS is insured with immediate access everywhere.

Definition:

• LRS (Locally Redundant Storage): Replicates across fault domains in a single zone.
• ZRS (Zone-Redundant Storage): Replicates synchronously across three zones in a region.
• GRS (Geo-Redundant Storage): Replicates to a secondary region asynchronously.
• RA-GZRS (Read-Access Geo-Zone-Redundant): Combines zone redundancy (primary) with read-only access to a geographically distant replica.

Why it matters: ZRS and RA-GZRS provide 99.99999999% (11 nines) durability; LRS provides only 99.999999% (8 nines).

Failover and Replication

Analogy: A heart transplant—the secondary organ must be a perfect match and ready to take over instantly.

Definition: Failover is the automated process of shifting traffic and data access from a failed primary resource to a healthy replica. Synchronous replication ensures consistency (RPO = 0); asynchronous allows higher throughput at the cost of potential data loss.

Why it matters: RPO (Recovery Point Objective) and RTO (Recovery Time Objective) are critical SLA metrics. Mis-matching your replication strategy to your business requirements is a leading cause of architecture failures.

Deep Dive

HA for Compute (LO26)

Compute high availability spans VMs, App Services, container services, and PaaS web tiers. The key is distribution: no single point of failure should take down your service.

Availability Zones for Compute

When you create a VM and specify an availability zone (e.g., Zone 1), Azure guarantees that hardware failures affecting other zones won't impact your VM:

For true HA, deploy three or more VMs across different zones (zone 1, zone 2, zone 3) behind a Standard Load Balancer:

Health probes are critical: the load balancer only routes traffic to VMs that pass the health check. A failing probe should trigger removal from the pool within 30 seconds (2 failed probes × 15-second interval).

Availability Sets (Zone-Redundant Fallback)

If zones are unavailable or cost-prohibitive, availability sets distribute VMs across fault domains:

With an availability set, Azure guarantees that:

• Only one fault domain is affected by hardware failures at a time.
• Only one update domain undergoes maintenance at a time.

This achieves 99.95% SLA within a single zone but offers no protection against zone outages.

Zone-Redundant Services

Some Azure services handle zone redundancy automatically:

• Azure App Service (Premium/Isolated tiers): Can be pinned to zones; Azure spreads instances across zones.
• Azure SQL Database (Premium/Business Critical tiers): Zone-redundant configuration available.
• Azure Cosmos DB: Multi-region writes inherently distribute across zones.

For these services, you request zone redundancy in the SKU or configuration; Azure handles the replication.

Composite SLA for Compute

If you deploy three zone-redundant VMs, each with 99.95% SLA (availability set), the composite SLA is:

ext{SLA}_{ ext{composite}} = 1 - (1 - 0.9995)^3 = 1 - (0.0005)^3 pprox 99.99999875\%

This is dramatically better than a single VM (99.9%) or even two VMs (99.9999%). However, the calculation assumes independent failures, which zones enforce by design.

[!TIP] Always deploy at least three replicas across three availability zones for production workloads. Two-zone deployments still leave you vulnerable to a single zone failure taking out half your capacity.

See the LO-level lesson (LO26) for more.

HA for Relational Data (LO27)

Relational databases present unique HA challenges: you must preserve consistency (ACID transactions) while enabling failover. Azure SQL and Always On Availability Groups solve this in different ways.

Azure SQL Database: Geo-Failover Groups

Azure SQL Database automatically replicates to a secondary region. The primary handles reads and writes; the secondary is read-only until a failover:

Then configure a failover group:

Key parameters:

• Failover policy: Automatic triggers failover without human intervention; Manual requires explicit invocation.
• Grace period: The number of hours to wait before initiating failover if the primary is unresponsive (prevents accidental failovers). Set to 1 hour for most workloads.

Once failover occurs, the secondary becomes the new primary; applications using the failover group's listener endpoint automatically reroute. RPO is typically 0 to 5 seconds; RTO is 30 seconds to 1 minute.

Always On Availability Groups on VMs

If you deploy SQL Server on VMs, Always On AG provides synchronous replication within a region and asynchronous to secondary regions:

This provides strong consistency (synchronous commit before acknowledging writes) and automatic failover within milliseconds.

Consistency vs. Failover Tradeoff

The choice between Azure SQL (managed) and Always On (self-managed) reflects this tradeoff:

For exam purposes: Use Azure SQL failover groups for most scenarios. Only choose Always On if you need sub-second failover or synchronous cross-region replication.

[!WARNING] auto-failover groups do not support cross-subscription failover. Both the primary and secondary server must reside in the same Azure subscription. Plan your subscription topology accordingly.

See the LO-level lesson (LO27) for more.

HA for Unstructured Data (LO28)

Unstructured data—blobs, files, Cosmos DB documents—requires different HA patterns than relational databases because they lack transactions.

Storage Account Redundancy

Azure Storage accounts offer four redundancy tiers:

RA-GZRS is the gold standard for critical, globally distributed applications. It provides:

• Zone redundancy on the primary (protect against zone failure).
• Geo-redundancy to the secondary (protect against region failure).
• Read access to the secondary (no application changes needed for reads).

Cosmos DB Multi-Region Writes

Azure Cosmos DB goes further than storage accounts: it supports multiple write regions, allowing your application to write to the nearest replica:

With enableMultipleWriteLocations: true, your application can write to any region. Cosmos DB asynchronously syncs changes to all regions, respecting the consistency level you specify (eventual, bounded staleness, session, strong, consistent prefix).

Composite SLA for Cosmos DB: If you have three write regions, each with 99.99% availability, and multi-region writes are configured with automatic failover, your composite SLA is:

$ext{SLA}_{ ext{composite}} = 1 - (1 - 0.9999)^3 = 99.97\%$

This accounts for the probability that all three regions fail simultaneously.

Storage Replication Strategies

For advanced scenarios, combine storage redundancy with application-level replication:

1. Blob snapshots + scheduled copy to secondary region.
2. Event-triggered replication using Azure Data Factory or Logic Apps.
3. Blob-to-Blob replication using the native Copy Blob from URL in a scheduled pipeline.

These are typically used when RA-GZRS doesn't provide the RTO/RPO you need.

[!NOTE] RA-GZRS provides read access to the secondary region even before a failover is initiated, making it ideal for read-heavy global applications that need the lowest possible RTO.

[!IMPORTANT] Storage account failover for GRS/RA-GZRS is a manual operation and may result in data loss equal to the replication lag. Always check Last Sync Time before initiating failover.

See the LO-level lesson (LO28) for more.

Worked Examples

Example 1: Regional Financial Services Platform (Medium)

Scenario: Contoso Financial Services runs a transaction processing system (order entry, clearing, settlement) that must tolerate zone failures with RPO ≤ 5 minutes and RTO ≤ 1 minute. Traffic is regional (North America primary, Europe secondary for disaster recovery).

Requirements:

• Compute: High availability within a zone and across zones.
• Relational data: Transactional consistency, automatic failover.
• Unstructured data: Audit logs, customer documents (read-heavy, RA access acceptable).

Solution:

1. Compute: Deploy the order-entry web tier across three zones using App Service Premium tier (zone-redundant instances). Behind a Standard Load Balancer with TCP health probes every 15 seconds.
2. Database: Azure SQL Database with auto-failover group to a secondary region (Europe). Premium tier supports zone redundancy. Grace period set to 1 hour to prevent accidental failovers.
3. Audit logs: RA-GZRS storage account with lifecycle policy (move to Archive after 30 days).

Composite SLA:

• App Service (zone-redundant): 99.95%
• SQL Database (auto-failover): 99.99%
• Storage (RA-GZRS): 99.99999999%

Overall: $99.95% imes 99.99% imes 99.99999999% pprox 99.94%$ ✅ Exceeds business SLA of 99.9%.

Cost: ~$15k/month (App Service Premium + SQL Premium + RA-GZRS storage).

---

Example 2: Global Media Streaming (Hard)

Scenario: Fabrikam Media streams video to users in 50 countries. Content must be cached globally with RPO ≈ 0 (no data loss) and RTO < 1 minute (automatic failover). Read latency must be < 100 ms from any region.

Requirements:

• Compute: Stateless streaming servers, globally distributed.
• Data: Video metadata (relational), video blobs (unstructured), both replicated globally.

Solution:

1. Compute: Azure Front Door (global load balancing) + App Service multi-region deployment (zone-redundant instances in each region).
2. Metadata: Cosmos DB with multi-region writes enabled, consistency set to "Session" (readers see their own writes, good for user sessions). Three replicas (US, EU, APAC).
3. Video blobs: Azure Blob Storage with RA-GZRS in primary region (US East), with Blob Replication Rules to secondary regions (EU, APAC) for failover.

Composite SLA (assuming 3 write regions):

• Front Door + App Service (multi-region): ~99.99%
• Cosmos DB (3 regions, multi-write): $1 - (1-0.9999)^3 pprox 99.97%$
• Blob Storage (RA-GZRS + replication): 99.99999999%

Overall: ~99.96% ✅

Cost: ~$45k/month (Front Door, multi-region App Service, Cosmos DB multi-write, global blob replication).

---

Example 3: On-Premises Integration with Azure Failover (Easy)

Scenario: Fabrikam runs a hybrid system: primary database on-premises (SQL Server), with Azure SQL Database as a warm standby. Failover must be manual and infrequent; the business can tolerate 15 minutes of downtime.

Requirements:

• Compute: Hybrid integration (on-prem + Azure).
• Data: Manual failover to Azure SQL.

Solution:

1. On-prem to Azure replication: Use SQL Server Always On AG with Azure as an asynchronous replica.
2. Manual failover: When on-prem fails, DBA manually promotes Azure SQL to primary using Azure CLI or portal.
3. Connection strings: Application uses provider=azure.contoso.com;failoverpartner=onprem.contoso.com, allowing fast reconnection on failover.

Composite SLA: On-prem (99.5%) × Azure (99.99%) = 99.49% while on-prem is primary. On failover to Azure, SLA improves to 99.99%.

Cost: ~$3k/month (Azure SQL Standard tier + hybrid connectivity).

Visual Explanations

Availability Zone Distribution

Figure: Zone-redundant deployment across three availability zones. The load balancer distributes traffic to VMs spread across all three zones, ensuring that a single zone failure affects at most one-third of capacity.

Mermaid 1: HA Architecture Decision Tree

Mermaid 2: Failover Group Topology

Mermaid 3: Cosmos DB Multi-Region Writes

TikZ: Availability Zone Distribution

Comparison Table: HA Patterns

Common Mistakes

Understanding SLA composition is essential to avoid overestimating your architecture's availability:

Myth 1: Availability Zones Are in Different Data Centers

Reality: Zones are geographically isolated within a region, typically 50+ km apart. But they share border patrol, power infrastructure for the broader region, and sometimes backbone networks.

Why it's tricky: You might think "I have three zones, so I'm protected against 99.9% of outages," but if a region-wide power grid failure happens (rare but possible), all zones fail together. For true protection against that risk, use multi-region replication (GRS, RA-GZRS, Cosmos DB multi-write).

Exam insight: On the AZ-305, if the question asks "protect against a region-wide failure," the answer is never just zones—you need multi-region replication.

---

Myth 2: Load Balancer Health Probes Guarantee No Traffic to Failed VMs

Reality: Health probes are probabilistic. If a VM is unhealthy, the load balancer removes it from the rotation after $2 imes ext{probe interval}$ (by default, 30 seconds). During this window, the LB may still send traffic to the failing VM.

Why it's tricky: If your VM crashes mid-request, the client sees an error. Adding a number of probes setting (e.g., numberOfProbes: 3) increases the threshold for removing a VM, reducing false positives but delaying failover.

Best practice: Pair health probes with connection draining (allow in-flight requests to finish before closing) and short probe intervals (5–10 seconds for critical workloads).

---

Myth 3: Geo-Failover Groups Provide Zero Data Loss

Reality: Azure SQL auto-failover groups use asynchronous replication. Writes are committed to the primary first; the secondary is updated with a lag. If the primary fails mid-write, uncommitted transactions are lost.

Why it's tricky: RPO is typically 0–5 seconds, not zero. For applications requiring zero data loss (e.g., financial transactions), you must use synchronous replication, which increases latency and cost.

Exam insight: On AZ-305, if the question emphasizes "zero data loss," consider Always On AG (VMs) or premium Cosmos DB consistency levels, not managed Azure SQL failover groups.

---

Myth 4: RA-GZRS Means You Have Two Complete Copies

Reality: RA-GZRS has a primary (zone-redundant in primary region) and a secondary (zone-redundant in secondary region), but the secondary is read-only until failover. Writes only go to the primary.

Why it's tricky: If your workload has high write volume, replicating to the secondary takes time (typically seconds to minutes). If the primary fails before all writes are replicated, the secondary won't have them.

Best practice: For write-heavy workloads, use Cosmos DB multi-write or Azure SQL failover groups (which replicate faster), not RA-GZRS.

---

Myth 5: Zone Redundancy in Azure SQL Means Three Separate Databases

Reality: Zone redundancy in Azure SQL Database (Premium tier) means one database replicated synchronously across three zones. You see one connection string, one endpoint. Azure manages the internal replication.

Why it's tricky: You can't directly access or read from the secondary replicas. The secondary is for failover only. If you need read scale-out, use read replicas (separate databases) or geo-failover groups.

Exam insight: For "read-scale-out across zones," use multiple read replicas, not zone redundancy. Zone redundancy is for failover only.

Practice Exercises

Exercise 1: Sizing a Multi-Zone Load Balancer 🟢

Scenario: Fabrikam runs a stateless web tier handling 10 requests/second per instance. Each instance can handle 100 req/s. They require no single point of failure.

Question: How many instances should they deploy, and how should they distribute them?

▶💡 Hint

Consider fault domains and zone tolerance. If one zone fails, can the remaining zones absorb the load?

▶📋 Solution

Minimum: 3 instances (one per zone).

Capacity math:

• Baseline load: 10 req/s
• Capacity per instance: 100 req/s
• 3 instances: 300 req/s total capacity

Fault tolerance:

• If Zone 1 fails (1 instance down): 2 instances remain → 200 req/s capacity
• Baseline load (10 req/s) << 200 req/s ✅

Better: 9 instances (3 per zone, 100% headroom):

• Baseline: 10 req/s
• Capacity: 900 req/s
• After 1-zone failure: 600 req/s >> 10 req/s ✅ with headroom for spikes

Answer: Deploy at least 3 instances (one per zone); 9 instances provides safer capacity headroom.

---

Exercise 2: Selecting Storage Redundancy 🟡

Scenario: Contoso stores customer backup files (total ~1 TB, read infrequently). RPO tolerance: up to 1 week. RTO tolerance: up to 24 hours. Budget: minimize cost.

Question: Should they use LRS, ZRS, GRS, or RA-GZRS? Justify your choice.

▶💡 Hint

RPO and RTO are loose. What's the cheapest redundancy that still meets these requirements? What disaster could happen that you're protecting against?

▶📋 Solution

LRS is the best choice here.

Justification:

• RPO = 1 week: LRS is immutable; once data is written, it's replicated across 3 fault domains synchronously. RPO is effectively 0. ✅
• RTO = 24 hours: LRS doesn't protect against region failure, but Contoso can manually restore from another region's backup or accept loss. Loose RTO. ✅
• Cost: LRS is the cheapest tier ($0.015/GB/month), vs. ZRS ($0.02), GRS ($0.02), RA-GZRS ($0.03).
• Disaster scenario: Single zone failure? LRS still works (other fault domains have copies). Region failure? Contoso can re-upload backups from source systems.

Why not ZRS: Extra cost for zone protection not needed for backups. Why not GRS: Extra cost for geo-redundancy not needed; RTO = 24 hours is loose. Why not RA-GZRS: Overkill; read access to secondary isn't needed for infrequent, periodic restores.

Answer: LRS minimizes cost while meeting RPO/RTO. If region-failure risk increased, upgrade to GRS.

---

Exercise 3: Failover Group Configuration 🟡

Scenario: Fabrikam Financial runs Azure SQL Database (Premium, zone-redundant) in East US with an auto-failover group to West Europe. Every morning, they run a batch job that inserts $10,000 records (takes ~30 seconds). The business can tolerate 5 minutes of downtime.

Question: What grace period should they set for the failover group, and why?

▶💡 Hint

Grace period delays automatic failover to prevent flapping. But if it's too long, what happens if the primary truly fails during the batch job?

▶📋 Solution

Recommended: 30 minutes (or longer, depending on batch window).

Reasoning:

• Batch job duration: ~30 seconds, but network blips might cause temporary unavailability.
• Grace period = 5 minutes is too short. If the primary experiences a transient blip (e.g., a 3-minute network hiccup) during the batch job, automatic failover might trigger, interrupting the job mid-execution and causing data inconsistency.
• Grace period = 30 minutes covers the batch window and typical transient failures. If the primary is down for > 30 minutes, it's likely a real failure, not a blip. Automatic failover is safe.
• RTO = 5 minutes is satisfied: If the primary truly fails (not a transient), failover completes within 1 minute, well before the 5-minute SLA.

Why not longer: Grace periods >1 hour reduce the benefit of automatic failover; manually failing over faster might be cheaper.

Answer: 30 minutes (or tune to match your batch/maintenance window), to avoid premature failover during transient issues.

---

Exercise 4: Composite SLA Calculation 🟡

Scenario: Fabrikam Media deploys:

• Front Door (global): 99.99% SLA
• App Service (multi-region, 3 regions, zone-redundant each): 99.95% SLA per region
• Azure SQL (auto-failover, premium): 99.99% SLA
• RA-GZRS Blob Storage: 99.99999999% SLA

Question: Calculate the composite SLA assuming each service must be available simultaneously (all-or-nothing).

▶💡 Hint

Composite SLA is the product of individual SLAs, assuming independent failures.

▶📋 Solution

Composite SLA = (Front Door) × (App Service) × (SQL) × (Storage) $= 0.9999 imes 0.9995 imes 0.9999 imes 0.9999999999$

Breaking it down:

• Front Door (99.99%): $0.9999
• App Service (99.95%): $0.9995 ← Weakest link
• SQL (99.99%): $0.9999
• Storage (99.99999999%): $0.9999999999 ← So strong it's negligible

Product: $0.9999 imes 0.9995 imes 0.9999 pprox 0.99940$

Composite SLA ≈ 99.94%

Insight: The App Service tier (99.95%) is the bottleneck. Upgrading it to Premium with zone redundancy (99.95%) or to a higher tier wouldn't directly improve SLA; you'd need multiple regions or architectural changes.

Answer: 99.94% composite SLA (limited by App Service).

---

Exercise 5: Multi-Region Write Strategy 🔴

Scenario: Fabrikam Media has Cosmos DB with write regions in East US, West Europe, and Southeast Asia. Consistency is set to "Bounded Staleness" with maxStalenessPrefix = 100,000 items and maxIntervalInSeconds = 300.

A user in Southeast Asia writes a document to the Southeast Asia region. A user in East US reads the same document 50 seconds later. Will the East US user see the write?

▶💡 Hint

Bounded staleness allows writes to be invisible for up to maxIntervalInSeconds. Multi-region write means writes must propagate across regions.

▶📋 Solution

No, not necessarily.

Explanation:

• The Southeast Asia user's write is committed to the Southeast Asia region.
• Cosmos DB asynchronously replicates to East US and West Europe.
• With Bounded Staleness, East US is allowed to see data that's up to 300 seconds old.
• The write happened only 50 seconds ago; it might not have replicated to East US yet.
• East US reader might see the previous version (older by 50 seconds).

What if we wanted to guarantee the East US user sees the write?

Use a stronger consistency level:

• Session: If East US user has the same "session token" as the write, they see their own write. Good for single-user sessions.
• Strong: Guarantees readers see all committed writes. But replication latency increases; not recommended for multi-region writes.
• Consistent Prefix: Guarantees causal consistency (if A → B → C in write order, readers see A, then B, then C, never B without A). Better for applications that care about causality.

Answer: Not guaranteed with Bounded Staleness. Upgrade to Session or Consistent Prefix if the application requires stronger guarantees.

---

Exercise 6: Availability Set Fault Domain Sizing 🟢

Scenario: Fabrikam runs a batch processing system with 8 VMs in an availability set. Azure guarantees that a single fault domain can hold at most 5 VMs (due to hardware topology). Can Fabrikam ensure that no more than 2 VMs fail simultaneously?

▶💡 Hint

Availability sets spread VMs across fault domains, but can't guarantee a specific upper bound on failures if the fault domain limit is exceeded.

▶📋 Solution

No.

Explanation:

• Fabrikam has 8 VMs but a single fault domain can hold 5 VMs (worst case).
• If Azure schedules VMs unevenly (e.g., 5 VMs in FD0, 3 in FD1), and FD0 fails, 5 VMs go down—not 2.
• Availability sets do not guarantee an upper bound on simultaneous failures if VMs exceed the fault domain capacity.

How to ensure max 2 VMs fail?

Deploy at most $2 imes ext{num fault domains}$ VMs. If Azure has 3 fault domains:

• $ext{max VMs} = 2 imes 3 = 6$
• Even in worst-case (one FD completely fails), max 2 VMs are lost.

Alternatively, use availability zones (no fault domain limits; zones are independent).

Answer: No. 8 VMs exceeds the fault domain safety threshold. Reduce to 6 VMs (or use zones).

---

Exercise 7: RA-GZRS Failover Scenario 🔴

Scenario: Fabrikam stores customer data in RA-GZRS in East US (primary) + West Europe (secondary, read-only). At 10:00 AM, East US experiences a catastrophic failure (all datacenters down for 24 hours). What can Fabrikam do immediately?

▶💡 Hint

The secondary is read-only by design, not write-enabled. But there's a mechanism to promote it.

▶📋 Solution

Immediate actions (next 10 minutes):

1. Read data from West Europe (secondary is read-only, so reads work immediately; no application code change needed if you support reading from the secondary).
2. Initiate an account failover (Azure portal or CLI: az storage account failover) to promote West Europe to the new primary.
   • This is a one-time, irreversible operation.
   • Once initiated, West Europe becomes the new primary and becomes writable.
   • RTO: 10–15 minutes (Azure processes the failover request).

What's lost?

• Any writes to East US in the 60–300 seconds before failure (depends on geo-replication lag) are lost (RPO ≥ 1 minute).
• The original East US region can never be a primary again (must manually delete and recreate the resource).

Can you undo the failover?

• No. Failover is one-time. If East US comes back online, you must manually copy data back or create a new account.

Better architecture for RTO < 10 min?

• Use Blob Replication Rules (application-initiated, continuous replication).
• Use Cosmos DB multi-region writes (sub-second failover, not storage account limitations).

Answer:

1. Read from West Europe immediately.
2. Perform account failover (10–15 min).
3. Accept that some writes (up to 5 min old) are lost.
4. Plan for permanent East US decommission if outage is extended.

Summary & Concept Map

Key Takeaways

1. Zones vs. regions: Availability zones protect against single-datacenter failures within a region; multi-region replication (GRS, RA-GZRS, Cosmos DB) protects against region-wide outages. Both are necessary for truly critical systems.

2. Load balancer + health probes are the compute backbone: They distribute traffic across instances and remove unhealthy VMs, achieving 99.95%+ SLA within a zone. Pair with zones for higher SLAs.

3. Azure SQL failover groups are the default for relational HA: Managed, automatic, low operational overhead. RPO = 5 seconds, RTO = 1 minute. Use Always On AG on VMs only if you need synchronous cross-region replication.

4. Storage redundancy is a spectrum: LRS (cheap, single zone), ZRS (zone-redundant, same region), GRS (two regions, read-only secondary), RA-GZRS (best: zone-redundant both regions, read access to secondary).

5. Cosmos DB multi-region writes are the future of global databases: Sub-second failover, write anywhere, automatic replication. RPO and RTO are tunable via consistency levels.

6. Composite SLA is multiplicative: Three services at 99% each yield $0.99^3 = 97.03%$ composite. The weakest service becomes the bottleneck. Optimize the bottleneck first.

Concept Map

Connections & Next Steps

This lesson synthesizes three critical learning objectives. To deepen your understanding, review each objective in the following order:

1. LO26: Design for High Availability — Compute

   • Focus on: availability zones, availability sets, load balancer health probes, zone-redundant services.
   • Key skill: Distributing stateless workloads across zones and selecting appropriate VM tiers.

2. LO27: Design for High Availability — Relational Data

   • Focus on: Azure SQL Database failover groups, Always On Availability Groups on VMs, consistency models.
   • Key skill: Choosing between managed (SQL) and self-managed (VMs) high availability.

3. LO28: Design for High Availability — Unstructured Data

   • Focus on: Storage account redundancy (LRS, ZRS, GRS, RA-GZRS), Cosmos DB multi-region writes, replication strategies.
   • Key skill: Designing global, resilient storage architectures.

Related exam domains:

• AZ-305 Domain 1: Design identity, governance, and monitoring solutions (how to monitor HA health).
• AZ-305 Domain 3: Design data storage solutions (HA for all data layers).
• AZ-305 Domain 4: Design business continuity (HA is the foundation of DR).

Next lessons after completing these LOs:

• Disaster recovery (RTO/RPO for cross-region failures).
• Cost optimization (balancing HA resilience with budget).
• Security in HA systems (encryption, network isolation, identity).