Design Business Continuity Solutions — Lesson

This unit surveys the essential patterns for designing robust business continuity solutions on Microsoft Azure. We examine two pillars: backup and disaster recovery (DR), which preserve data and application state after failures; and high availability (HA), which minimizes downtime through redundancy and automated failover. Together, these patterns protect against data loss, regulatory violations, and business interruption across compute, storage, and database workloads.

Reference: Ch. 3, §§3.1–3.2, p. 97–112 of the AZ-305 exam book.

---

Why This Matters

Unplanned outages and data loss cost organizations millions of dollars in lost revenue, damaged reputation, and regulatory fines. A 2023 industry survey found that the average enterprise outage costs $5,600 per minute. Even a one-hour incident can exceed $300,000. Beyond the financial impact, customers expect near-continuous availability; any service interruption erodes trust.

Business continuity solutions address two correlated risks:

1. Data Loss Risk: System failures, human error, ransomware, and natural disasters can destroy critical data. Without backups and replication, recovery is impossible.
2. Service Unavailability Risk: Single points of failure—a failed VM, a downed data center, a corrupted database—can halt operations. Redundancy and failover mechanisms keep services online.

Azure provides native services (Azure Site Recovery, Azure Backup, availability zones, geo-replication) that automate these patterns. Understanding their tradeoffs—RPO vs. cost, RTO vs. complexity, 99.9% SLA vs. 99.99% SLA—is central to designing systems that balance protection, performance, and budget.

---

Prerequisites

Before this unit, you should be familiar with:

• Azure Compute Fundamentals: VMs, managed disks, VM scale sets, availability sets, and Azure Container Service (AKS).
• Azure Storage: Blob storage, file shares, managed disks, and replication modes (LRS, GRS, ZRS).
• Azure Databases: SQL Database, Azure Database for PostgreSQL, SAP HANA, and backups at the application level.
• Networking & Load Balancing: Traffic Manager, Azure Load Balancer, Application Gateway, and how they route traffic to healthy instances.
• Monitoring & Alerting: Azure Monitor, Application Insights, and using telemetry to detect failures.
• Security & Compliance: Role-based access control (RBAC), encryption, and audit logging.

This unit assumes you have completed Units 1 and 2 (identity, governance, and monitoring) and are ready to apply those foundations to resilience design.

---

Learning Objectives

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

1. Define and calculate RPO, RTO, and RLO and map them to business requirements.
2. Design a backup strategy using Azure Backup service, selecting vaults, tiers, retention policies, and redundancy levels for VMs, databases, and unstructured data.
3. Architect disaster recovery solutions using Azure Site Recovery for application-level failover, including replication policies, recovery plans, and failover testing.
4. Plan high availability architectures by choosing between availability sets, availability zones, and multi-region patterns to meet SLA targets.
5. Select redundancy modes (LRS, ZRS, GRS, GZRS, RA-GRS, RA-GZRS) for storage and databases based on durability and availability goals.
6. Evaluate tradeoffs between RPO/RTO, cost, operational complexity, and compliance.
7. Implement monitoring and failover automation to detect failures and trigger recovery within the target RTO.

---

Building Blocks

Core Concepts

Recovery Point Objective (RPO): The maximum acceptable data loss, measured in time. If an RPO is 1 hour, you can afford to lose up to 1 hour of transactions. Lower RPO requires more frequent backups or continuous replication, increasing cost.

Recovery Time Objective (RTO): The maximum acceptable downtime. If an RTO is 4 hours, the system must be back online within 4 hours of failure detection. Lower RTO requires pre-positioned failover infrastructure and automated failover logic.

Recovery Level Objective (RLO): The organizational unit being recovered—VM, application, database, or entire region. Influences the scope and cost of the solution.

Redundancy: Creating multiple copies of data or compute across locations so that a single failure does not cause loss. Redundancy adds cost and complexity but is essential for HA and DR.

Failover: The process of detecting a failure and switching to a backup component (another VM, another region, another replica). Automated failover reduces RTO; manual failover increases it.

Azure Site Recovery (ASR): A managed service that orchestrates continuous replication from primary to secondary infrastructure and provides one-click failover. ASR integrates with Azure VMs, on-premises Hyper-V and VMware, and physical servers.

Azure Backup Service: A managed service that captures point-in-time snapshots of VMs, managed disks, databases, and file shares. Backups are stored in a Recovery Services vault with optional geo-redundancy.

Key Azure Services

---

Deep Dive

Topic 1: Backup and Disaster Recovery

Backup and DR serve complementary but distinct roles. A backup captures a snapshot at a point in time and stores it for later restore—days, weeks, or years later. Disaster recovery replicates live data continuously and enables rapid failover when the primary system fails.

Recovery Service Vaults and Backup Strategy

Azure Backup stores snapshots in a Recovery Services vault, which offers:

• Redundancy Options: LRS (locally redundant, 99.9% durability), GRS (geo-redundant, 99.99999999% durability), ZRS (zone-redundant).
• Backup Tiers: Hot (immediate recovery), Cold (longer retrieval), Vault (offline copy for long-term retention).
• Retention Policies: Daily, weekly, monthly, yearly snapshots with configurable retention (e.g., keep 7 daily, 4 weekly, 12 monthly, 5 yearly).

Azure Backup Capabilities:

• VM Backup: Full VM snapshots, application-consistent snapshots via VSS (Volume Shadow Copy Service).
• Database Backup: SQL Server on VMs with transaction log backups (15-minute RPO); Azure SQL Database with automated backups (7–35 days PITR) and long-term retention (up to 10 years in RA-GRS).
• File Share Backup: Azure Files snapshots for quick file recovery.
• Unstructured Data: Blob snapshots, soft delete, versioning for accidental deletion protection.

Cost Drivers:

• Data volume being backed up.
• Frequency of snapshots (more snapshots = lower RPO = higher cost).
• Retention duration (longer retention = higher vault storage cost).
• Redundancy mode (GRS more expensive than LRS).

Azure Site Recovery for Application DR

Azure Site Recovery (ASR) replicates live VMs and workloads continuously, enabling near-instantaneous failover (RPO as low as 30 seconds). ASR supports:

• Replication Sources: Azure VMs, on-premises Hyper-V, VMware VMs, physical servers.
• Replication Targets: Secondary Azure region, on-premises secondary site, or third-party cloud.
• Replication Engine: Uses change tracking to send only deltas, minimizing bandwidth.
• Recovery Plans: Orchestrate multi-VM failover, boot order, and post-failover scripts (e.g., update DNS, reconfigure network).
• Test Failover: Failover to an isolated test environment without affecting production.

Common ASR Pattern: A company replicates its primary-region VMs to a secondary region. In a region-wide outage, a single recovery plan command fails over all VMs, updates DNS, and restores service in < 5 minutes.

Database Backup and Point-in-Time Recovery

Databases require specialized backup strategies:

• Azure SQL Database: Automated full, differential, and transaction-log backups with 7–35 day PITR. Long-term retention via RA-GRS storage up to 10 years. Supports geo-replication and auto-failover groups.
• SQL Server on VMs: Leverages Azure Backup for full + log backups; controlled RPO via log shipping frequency. Requires careful scheduling to balance RPO and I/O overhead.
• Azure Database for PostgreSQL: Automated backups with 7-day retention. Geo-backup to paired region. Supports read replicas for HA.
• SAP HANA: Azure Backup for HANA with application-consistent snapshots, managed via the Azure Backup plugin.

---

Topic 2: High Availability

High availability ensures that a service remains available despite infrastructure failures. The target is expressed as an SLA uptime percentage: 99.9% (8.76 hours downtime/year), 99.95% (4.38 hours), or 99.99% (52 minutes). Each "9" adds roughly a $10 imes$ cost multiplier in redundancy and operational complexity.

HA Fundamentals

Redundancy + Monitoring + Failover = HA.

• Redundancy: Multiple independent copies or instances so no single failure is catastrophic.
• Monitoring: Continuous health checks detect failures quickly.
• Failover: Automatic rerouting of traffic to a healthy instance.

Key Metrics:

• MTTR (Mean Time To Repair): Average time from failure detection to recovery. Shorter MTTR reduces downtime.
• MTBF (Mean Time Between Failures): Average time between failures. Longer MTBF reduces incidents.
• SLA Availability = rac{ ext{MTBF}}{ ext{MTBF} + ext{MTTR}} (approximate).

Compute HA Patterns

Azure offers increasingly resilient compute options:

Availability Sets group VMs in the same region across multiple fault domains (FDs) and update domains (UDs). Azure guarantees that only one FD and one UD are updated during maintenance, ensuring at least one VM remains online.

Availability Zones are physically separate data centers in the same region. Each zone has independent power, cooling, and network. Zone-redundant services (Load Balancer, Application Gateway) distribute incoming traffic across zones, achieving 99.99% SLA.

Storage HA and Redundancy

Storage replication ensures durability against hardware failure and region-level outages:

[!NOTE] GRS replication is asynchronous; the secondary may lag the primary by up to a minute. For synchronous replication (zero RPO), use availability zones or active geo-replication in databases.

Database HA

Azure SQL Database provides:

• Automated Backups: Full + differential + log backups stored in RA-GRS vault.
• Active Geo-Replication: Continuous replication to a secondary region (readable); customer-initiated manual failover.
• Auto-Failover Groups: Automatic failover to secondary region on detection of primary failure; application sees no connection string change.
• Zone-Redundant DB: Replicas spread across zones; synchronous replication within region.

Azure Database for PostgreSQL:

• Automated backups with 7-day retention to geo-redundant storage.
• Read replicas for scaling reads; can promote to standalone database for failover.
• No built-in auto-failover; failover is application-driven.

Temporal Tables in SQL Database record data changes over time, enabling recovery of accidentally deleted or modified rows from a specific point in the past.

Monitoring and Failover Automation

Effective HA requires continuous monitoring and rapid detection:

• Azure Monitor: Tracks VM CPU, memory, disk I/O, and network.
• Application Insights: Monitors application health, dependencies, and user impact.
• Health Probes: Load balancers send periodic requests to backend instances; unhealthy instances are removed from rotation.
• Recovery Automation: Logic apps, runbooks, or ARM templates trigger failover on alert thresholds.

---

Worked Examples

Example 1: Small E-Commerce Platform (Medium Difficulty)

Scenario: A growing e-commerce company runs a 3-tier application (web, application, database) on Azure. Currently, all infrastructure is in a single region. Recent downtime cost $50,000. The CTO sets targets: RPO = 1 hour (accept max 1-hour transaction loss), RTO = 4 hours (customer-facing app acceptable down 4 hours).

Requirements:

• Web and app tiers: tolerate transient failure; cost-conscious.
• SQL Database: mission-critical, must not lose transactions beyond 1 hour.
• Compliance: must retain backups for 7 years.

Design:

1. Compute Tier: Deploy web and app tier VMs in an availability set within the primary region (East US). Uses standard LB + health probes. Cost-effective for an RTO of 4 hours; availability set guarantees 99.95% SLA.
2. Storage: Blob storage for product images and user uploads uses GRS (geo-redundant). RPO = a few minutes (asynchronous replication); RTO = a few minutes (read from secondary on primary failure).
3. Database: Azure SQL Database (Standard tier) with geo-replication to a secondary region (West US). Enable auto-failover group for automatic failover within 1 minute. Transaction-log backup frequency: every 5 minutes (achieves ~5-minute RPO). Long-term retention: weekly backups in RA-GRS vault for 7 years.
4. Backup: Azure Backup configured to snapshot VMs daily. Backup vault uses GRS. Retention: 30 daily, 12 monthly, 5 yearly snapshots (sufficient for 7-year compliance).
5. Recovery Plan: Document manual failover steps: (a) promote secondary SQL replica via auto-failover group, (b) update DNS to redirect traffic to secondary-region VMs, (c) manually start VMs in secondary region from latest backup. RTO = 4 hours (acceptable).

Cost Estimate:

• Availability set: included with VM licensing.
• GRS storage: ~$1.5 imes$ LRS cost.
• SQL auto-failover group: ~$10–20 per month.
• Backup vault storage: ~$50–100/month.
• Total monthly increment: ~$150–200 above base infrastructure.

---

Example 2: Mission-Critical SaaS with Strict SLA (Hard)

Scenario: A SaaS company provides customer-facing analytics. The SLA: 99.99% uptime (5 nines = 26 seconds downtime/year). Customers demand < 30 second recovery from region failure.

Requirements:

• RPO: < 30 seconds (near real-time).
• RTO: < 30 seconds (automatic failover).
• Data residency: EU and US regions.
• Multi-region active-active (spread traffic across regions).

Design:

1. Compute: Deploy identical application stacks in East US and West Europe regions. Each region has availability zone-redundant VMs (across 3 zones) behind a zone-redundant load balancer (99.99% SLA per region). Use Azure Front Door (global load balancer) to distribute traffic across regions with health probes every 10 seconds. If one region fails, Front Door detects and reroutes in < 10 seconds.
2. Database: Azure SQL Database with active geo-replication (read replicas in both regions) + auto-failover groups. All writes go to primary (East US); failover group automatically promotes secondary (West Europe) on primary failure. Synchronous replication within each region via zone redundancy. RPO = 30 seconds (acceptable loss).
3. Caching: Azure Managed Redis in each region with geo-replication or separate caches. Keep cache in sync via application logic or event-driven architecture.
4. Storage: RA-GZRS (read-access geo-redundant, zone-redundant) for all blobs and managed disks. Enables reads from secondary region without additional failover logic.
5. Monitoring & Failover Automation: Application Insights monitors latency, errors, and dependency health. Alert on any region-level failure; trigger:
   • (Auto) Front Door health probe detects region down and reroutes within 10 seconds.
   • (Auto) SQL auto-failover group promotes secondary replica.
   • (Manual/Automated) Failover runbook updates service dependencies (caching, event hubs) to secondary region.

Cost Estimate:

• Dual-region infrastructure: $2 imes$ base cost.
• Premium Front Door: ~$100/month.
• Active geo-replication & auto-failover group: ~$50–100/month.
• RA-GZRS storage: ~$2 imes$ LRS cost.
• Monitoring & automation (Logic Apps, runbooks): ~$50/month.
• Total monthly premium: +$200–300% above single-region base.

[!IMPORTANT] Achieving 99.99% SLA requires multi-region redundancy, automated failover, and continuous monitoring. Expect 3–4x infrastructure cost compared to single-region designs.

---

Example 3: Hybrid On-Premises to Azure DR (Hard)

Scenario: A large enterprise runs critical workloads on-premises (VMware and Hyper-V). Regulatory requirements mandate off-site disaster recovery. Current RTO: 8 hours. Desired RTO: 1 hour.

Requirements:

• Replicate on-premises VMs to Azure.
• Recover within 1 hour.
• Minimize bandwidth (network link is 50 Mbps).
• Test failover quarterly.

Design:

1. Azure Site Recovery: Deploy ASR Replication Server in on-premises vSphere/Hyper-V environment. ASR continuously replicates VM disks to Azure (primary region) using delta sync over ExpressRoute or VPN. RPO = 5 minutes (configurable based on network).
2. Recovery Infrastructure: Prepare secondary infrastructure in Azure (VMs in standby state, pre-configured). ASR recovery plans define boot order, network mapping, and post-failover script (e.g., update DNS).
3. Failover Process:
   • Test Failover: Monthly. Spin up test VMs from latest recovery point; verify application health; discard test VMs.
   • Actual Failover: On-premises site becomes unavailable; trigger ASR failover command. VMs boot in Azure from latest recovery point. RTO = 1 hour (includes boot + DNS propagation).
4. Bandwidth Optimization: Delta replication + compression reduces bandwidth; initial full sync scheduled during off-hours.
5. Failback: Once on-premises site is restored, ASR reverse-replicates from Azure back to on-premises and performs reverse failover.

Cost Estimate:

• ASR Replication Server: one-time $2,000–5,000 hardware cost.
• Azure Backup Vault (for long-term retention): ~$100–200/month.
• Standby VM infrastructure in Azure: ~$500–1,000/month.
• Total monthly: ~$600–1,200.

---

Visual Explanations

Figure 1: Backup vs. Disaster Recovery Timeline

Figure 2: Azure Redundancy and SLA Tiers

Figure 3: HA Compute Patterns and SLA

Figure 4: Azure Site Recovery Workflow

---

Figure 5: TikZ Redundancy Model

Common Mistakes

Myth 1: "Backups alone are sufficient for disaster recovery."

Reality: Backups are point-in-time snapshots; they cannot provide the continuous protection needed for an RPO of minutes or seconds. A ransomware infection at 2 PM but discovered at 4 PM means losing 2 hours of transactions even with hourly backups. Disaster recovery requires replication (ASR) for low RPO. Use backups for long-term compliance and for scenarios where RTO of hours is acceptable.

Myth 2: "Single-region availability sets meet SLA requirements for critical workloads."

Reality: Availability sets protect against hardware failure and maintenance events within a single region (99.95% SLA), but a region-wide outage (power loss, natural disaster) affects all VMs in that region. For SLA targets of 99.99% or higher, deploy across availability zones or multiple regions.

Myth 3: "GRS is always the right choice for production data."

Reality: GRS replication is asynchronous (lag up to minutes); you can lose that lag's worth of data. If your RPO is 30 seconds, asynchronous GRS replication is insufficient; you need synchronous replication (ASR, availability zones, active geo-replication). Additionally, GRS costs $2 imes$ LRS; for non-critical data, LRS may be acceptable.

Myth 4: "Manual failover plans are faster than automated ones."

Reality: Manual failover introduces human delay—detecting the failure, interpreting alerts, deciding to failover, and executing steps manually can easily exceed 1 hour. Automated failover (ASR recovery plans, auto-failover groups, health probes) reduces RTO to minutes or seconds. Automation is key to meeting RTO < 1 hour.

Myth 5: "HA and DR are the same thing."

Reality: HA prevents downtime by eliminating single points of failure (redundancy + failover). DR restores service after a disaster. An availability set provides HA (local redundancy) but not DR (no cross-region replication). A multi-region design provides both.

---

Code Examples: Implementation Patterns

Bash: Deploy Zone-Redundant Load Balancer

Bicep: Backup Vault with GRS

T-SQL: Enable Long-Term Retention

PowerShell: Test ASR Failover

Practice Exercises

Exercise 1: Calculate RPO and RTO for a Retail Application

Scenario: A retail chain operates e-commerce across 20 Azure regions. Transactions average 50 per second; revenue per transaction = $50. Every hour of downtime costs $180,000. Every hour of data loss affects customer trust and regulatory compliance, incurring $20,000/hour in fines.

Task:

• If an RPO of 1 hour is chosen, how much revenue and regulatory cost is at risk per outage?
• If an RTO of 4 hours is chosen, what is the total cost per outage (revenue + fines)?
• Propose an RPO and RTO that balances cost of protection against cost of failure.

▶✅ Solution

RPO Risk: 1 hour × 50 transactions/sec × $50/transaction = $180,000 per outage. Plus regulatory fine = $20,000. Total RPO cost = $200,000 per outage.

RTO Risk: 4 hours × $180,000/hour = $720,000 revenue loss per outage.

Proposal:

• Target RPO = 5 minutes (continuous replication via ASR). Cost per outage drops to ~$25,000.
• Target RTO = 30 minutes (multi-region active-active + automated failover). Cost per outage drops to $90,000.
• Monthly investment: Multi-region infrastructure (~$20,000), ASR ($2,000), monitoring ($1,000) = $23,000/month.
• Break-even: If one outage occurs every 2 months, protection costs are offset by avoided losses.

---

Exercise 2: Design a Backup Strategy for a PostgreSQL Database

Scenario: A SaaS analytics platform uses Azure Database for PostgreSQL (Premium tier). Critical customer reports depend on this database. Compliance requires 5-year data retention. Current backup is: none (disaster!)

Task:

• Define RPO for PostgreSQL (consider transaction-log backup frequency vs. I/O overhead).
• Propose a backup tiers strategy (hot, cold, vault) to minimize cost while meeting compliance.
• Estimate monthly backup storage cost for 500 GB database.

▶✅ Solution

RPO:

• Azure Database for PostgreSQL automated backups: 7-day retention, full daily + logs.
• To improve RPO, enable log shipping to external blob storage (e.g., hourly). RPO = 1 hour.
• For < 5-minute RPO, use read replicas and log-based replication; not available in standard PostgreSQL (requires managed replication services).

Backup Tiers:

• Hot (Backup Vault, first 30 days): Daily snapshots for quick restore. 500 GB × $0.015/GB = $7.50/day = $225/month.
• Cold (Blob archive, days 31–90): Weekly snapshots. 500 GB × $0.004/GB = $2/week = $8/month.
• Vault (RA-GRS, 5-year compliance): Monthly snapshots in RA-GRS storage. 500 GB × $0.05/GB (RA-GRS) × 12 months/year × 5 years = $150/month (average).

Total monthly: $225 + $8 + $150 = $383/month.

---

Exercise 3: Evaluate HA Patterns for Cost vs. SLA

Scenario: A company currently runs a monolithic app on a single VM in East US (no SLA guarantee, downtime frequent). The CTO wants SLA targets but is cost-constrained. Base VM + storage: $500/month.

Task:

• Estimate monthly infrastructure cost for each pattern: (a) availability set, (b) availability zone, (c) multi-region active-active.
• For each, estimate the achieved SLA and expected downtime/year.
• Recommend the best cost/SLA ratio for a small startup.

▶✅ Solution

Pattern A: Availability Set (2 VMs in same region, different FDs)

• Cost: $500 (VM 1) + $500 (VM 2) + $50 (LB) = $1,050/month.
• SLA: 99.95% (4.38 hours downtime/year).

Pattern B: Availability Zone (2 VMs across zones, zone-redundant LB)

• Cost: $500 (VM 1, zone 1) + $500 (VM 2, zone 2) + $100 (zone-redundant LB) = $1,100/month.
• SLA: 99.99% (52 min downtime/year).
• Delta: +$50/month for $99.95% → 99.99% (5% better SLA for 5% more cost).

Pattern C: Multi-Region Active-Active (2 VMs in each of 2 regions, Front Door)

• Cost: ($500 + $500 + $100) × 2 regions + $100 (Front Door) = $2,300/month.
• SLA: 99.99% or higher (26 sec downtime/year if both regions fail simultaneously, unlikely).
• Delta: +$1,250/month ($219% increase) for marginal SLA improvement.

Recommendation for Startup: Availability Zone (Pattern B). Achieves strong 99.99% SLA at modest cost increase. Easier to operate than multi-region. Sufficient for most startups until scale demands it.

---

Exercise 4: Site Recovery for Legacy VMware

Scenario: An enterprise has 200 on-premises VMs in VMware, currently unprotected. Regulatory requirement: disaster recovery capable of restoration within 2 hours. Network link: 100 Mbps dedicated for replication. Average VM size: 500 GB.

Task:

• Propose an Azure Site Recovery deployment.
• Calculate initial replication time for 200 VMs.
• Estimate monthly cost.

▶✅ Solution

ASR Deployment:

• Deploy ASR Replication Server in on-premises environment (virtual appliance or physical).
• Configure replication to Azure primary region (East US). Target RPO = 5 minutes.
• Create recovery plans: failover order (database first, then app servers, then web), network mapping.

Replication Time:

• Initial sync: $200 imes 500$ GB = 100 TB.
• Bandwidth available: 100 Mbps = $12.5 MB/s.
• Time: 100 TB / $12.5 MB/s = $8,388,608 seconds ≈ 97 days (unacceptable!).
• Solution: Schedule initial sync off-hours; use compression (50% typical) → 49 days. Or seed with physical disk shipment.
• Ongoing delta replication: 5-minute RPO easily achievable with 100 Mbps (far less than 100 TB/5 min).

Monthly Cost:

• ASR license: $150/month.
• Azure backup vault (for long-term DR snapshots): $200/month.
• Standby VM infrastructure (always on): $200 imes $20/month = $4,000/month.
• Total: $4,350/month.

---

Exercise 5: Database HA with Auto-Failover Groups

Scenario: An Azure SQL Database (Standard tier, 100 GB) serves a web application. Customers are distributed across US and EU. Current SLA: 99.9% (availability set, single region). Goal: 99.99% SLA with minimal application code changes.

Task:

• Propose an architecture using auto-failover groups.
• Estimate additional monthly cost vs. current setup.
• What changes are required in the application connection string?

▶✅ Solution

Architecture:

• Primary Azure SQL Database in East US (Standard tier, 100 GB).
• Secondary readable replica in West Europe (Standard tier, 100 GB).
• Auto-failover group with 1-minute failover grace period. Automatic failover on primary failure.
• Synchronous replication within East US via zone redundancy (if available in Standard tier; otherwise ~30 second RPO).
• Connection string: Server=mydb-group.database.windows.net,3342;... (application-level failover transparent).

SLA Achieved:

• Zone redundancy + auto-failover group → 99.99% SLA.

Cost:

• Primary DB (Standard, 100 GB): $200/month.
• Secondary DB (Standard, 100 GB): $200/month.
• Auto-failover group: $15/month.
• Total: $415/month vs. current $200/month. Delta: +$215/month (107% increase).

Application Changes:

• Minimal. Connection string changes from Server=primary.database.windows.net; to Server=mydb-group.database.windows.net,3342; (failover transparent).
• No code changes if using connection pooling (recommended).
• Optional: implement retry logic for connection timeouts during failover.

---

Exercise 6: Compliance-Driven Backup Retention

Scenario: A financial services company processes loans. Regulatory requirement (GDPR): retain customer data for 7 years; capability to retrieve any historical version within 5 business days. Current backup: none.

Task:

• Design an Azure Backup strategy for 10 TB SQL Database + 50 TB blob storage (documents).
• Calculate monthly storage cost.
• Propose a data retention schedule (daily, weekly, monthly, yearly snapshots).

▶✅ Solution

Retention Schedule:

• Daily: Keep 30 daily snapshots (1 month). Cost: Hot tier.
• Weekly: Keep 12 weekly snapshots (3 months). Cost: Cool tier.
• Monthly: Keep 84 monthly snapshots (7 years). Cost: Archive tier.

Cost Calculation (SQL Database, 10 TB):

Tier	Snapshots	Duration	Storage (TB)	Unit Cost (/GB/month)	Cost/month
Hot	30 daily	1 month	300	$0.015	$4,500
Cool	12 weekly	3 months	120	$0.005	$600
Archive	84 monthly	7 years	840	$0.0005	$420
Subtotal			1,260		$5,520

Cost Calculation (Blob Storage, 50 TB):

Tier	Snapshots	Duration	Storage (TB)	Unit Cost (/GB/month)	Cost/month
Hot	30 daily	1 month	1,500	$0.015	$22,500
Cool	12 weekly	3 months	600	$0.005	$3,000
Archive	84 monthly	7 years	4,200	$0.0005	$2,100
Subtotal			6,300		$27,600

Total Monthly Cost: $5,520 + $27,600 = $33,120/month.

Alternative (Cost Optimization): Use RA-GRS for hot tier (slight cost increase but built-in geo-redundancy for compliance). Reduce hot snapshots to 7 daily (one week) to save on Hot tier storage.

---

Exercise 7: RTO vs. Cost Tradeoff

Scenario: An IT department manages a mission-critical ERP system used by 500 employees. Current RTO: 8 hours (manual recovery from backup). CTO wants to reduce to 1 hour. Budget: max $$5,000/month additional.

Task:

• Compare two RTO strategies: (a) ASR to secondary region, (b) availability zone-redundant setup with automated failover.
• For each, estimate RTO and cost.
• Which is recommended, and why?

▶✅ Solution

Strategy A: ASR to Secondary Region

• Deploy ASR replication to West US (secondary).
• RTO: Failover command (~2 min) + VM boot (~5 min) + DNS update (~1 min) = ~8 minutes (acceptable).
• Cost:
  • Primary infrastructure: $2,000/month.
  • ASR Replication Server: $150/month.
  • Secondary region standby infrastructure: $2,000/month.
  • Backup vault: $200/month.
  • Total: $4,350/month. Within budget.

Strategy B: Availability Zone Redundancy

• Deploy identical ERP app tier across 3 AZs in East US (same region).
• Deploy zone-redundant load balancer + health probes.
• RTO: Health probe detects failure (~10 sec) + LB removes unhealthy instance (~immediate) = < 30 seconds (excellent).
• Cost:
  • Primary infrastructure (3x): $2,000 × 3 = $6,000/month.
  • Zone-redundant LB: $200/month.
  • Monitoring/automation: $100/month.
  • Total: $6,300/month. Over budget.

Recommendation: Strategy A (ASR). Achieves acceptable 8-minute RTO within budget. If budget were $$6,500+$, Strategy B would be preferred for sub-second failover. For now, ASR provides strong protection at acceptable cost.

---

[!TIP] Use health probes (health check requests every 5–10 seconds) in load balancers to detect instance failures rapidly. Azure health probes can trigger automatic rerouting in under 30 seconds.

[!WARNING] GRS replication is asynchronous with lag of 1–5 minutes. For RPO < 5 minutes, do not rely on GRS alone; use ASR (continuous replication) or database active geo-replication.

Summary & Concept Map

Business continuity on Azure rests on two pillars—backup/disaster recovery (preserve data after failure) and high availability (prevent downtime)—each with distinct tools and tradeoffs.

Key Takeaways:

1. Define RPO and RTO first: These drive all design decisions. Lower RPO/RTO = higher cost and complexity.
2. Backup ≠ DR: Backups are for point-in-time restore; disaster recovery requires continuous replication (ASR, geo-replication).
3. SLA is not free: Jumping from 99.9% to 99.99% SLA requires multi-region or zone redundancy, doubling infrastructure cost.
4. Redundancy mode matters: LRS is cheap but offers only local durability. GRS/GZRS for DR; RA-GRS for read access from secondary region.
5. Automated failover is essential: Manual failover exceeds RTO targets. Use ASR recovery plans, auto-failover groups, and health probes.
6. Compliance drives retention: GDPR, HIPAA, PCI-DSS often mandate 5–7 year retention; plan storage tiering (hot → cool → archive) to minimize cost.

---

Connections & Next Steps

Within AZ-305:

• Unit 1 (Identity & Governance): RBAC controls who can trigger failover and restore data; audit logging tracks all backup/restore operations.
• Unit 2 (Monitoring & Alerting): Continuous monitoring detects failures; alerts trigger automated failover. Application Insights tracks application health end-to-end.
• Unit 4 (Workload Architecture): Business continuity concepts apply to specific workloads (compute, databases, containers, applications).

Deeper Learning:

• Topic 3.1 (Backup and DR) explores per-workload strategies: VM backup with VSS, SQL PITR, SAP HANA, AKS with Velero, blob versioning, and soft delete.
• Topic 3.2 (High Availability) dives into compute patterns (VMSS, PPGs), database HA (temporal tables, sync replication), and monitoring-driven failover.

Exam Readiness:

• Expect scenario-based questions: "A company has RPO of 1 hour and RTO of 30 minutes. Which Azure services would you recommend?"
• Practice designing end-to-end recovery for multi-tier applications.
• Understand the cost/SLA tradeoff: when to choose availability sets vs. zones vs. multi-region.

---

Real-World Applications

Case Study 1: E-Commerce Retailer — Holiday Downtime Prevention

Company: Regional e-commerce chain, $$200$ million annual revenue. Peak season: November–December.

Challenge: Black Friday 2022 saw a 2-hour outage in production database. Revenue loss: $$500,000. Regulatory fines (CCPA):$$50,000. CTO mandates: zero downtime during peak season.

Solution Implemented:

• Migrated from single-region VMs to availability zone-redundant app tier (East US, 3 zones).
• Deployed Azure SQL Database with auto-failover groups (East US primary + West US read replica for HA).
• Integrated Azure Front Door for global load balancing and region failover.
• Automated health monitoring with Application Insights; alert + runbook-triggered failover on any anomaly.

Results:

• SLA improved from 99.9% to 99.99%.
• RTO reduced from 4 hours to $< 5$ minutes.
• Peak season 2023: zero unplanned outages. Revenue protection: $$1$ million estimated (avoided downtime).
• Monthly infrastructure cost: +$$15,000$ (acceptable against revenue impact).

---

Case Study 2: Financial Services — Compliance and Disaster Recovery

Company: Mid-sized mortgage lender, $$5$ billion assets under management.

Challenge: Regulatory requirement (FDIC, GLBA) mandates business continuity and disaster recovery capability. Current manual processes incur 8-hour RTO. Loan processing delays cost $$50,000/day in interest income.

Solution Implemented:

• Deployed Azure Site Recovery replicating all on-premises loan origination systems (legacy VM-based) to Azure secondary region (Texas).
• Configured ASR recovery plans automating VM boot order, network remapping, and database synchronization.
• Implemented automated failover testing quarterly; RTO validated at 1 hour.
• Integrated Azure Backup with 7-year retention (archive tier) for FDIC/GLBA compliance.

Results:

• RTO reduced from 8 hours to 1 hour (avoids $$200,000$ daily loss).
• Regulatory audit: passed with "excellent" rating on disaster recovery controls.
• Monthly cost: $$12,000$ for ASR + secondary infrastructure.
• Payback period: $< 1$ month if single disaster averted.

---

Case Study 3: SaaS Analytics Platform — Multi-Region High Availability

Company: Cloud-native SaaS, 500 customers in 20 countries.

Challenge: Customer SLA: 99.99% uptime. Geographic distribution requires low latency from all regions. Any region failure must failover automatically without service interruption.

Solution Implemented:

• Designed active-active multi-region architecture across US (East + West) and Europe (West).
• Each region: availability zone-redundant compute, zone-redundant load balancer, 99.99% per-region SLA.
• Azure Front Door routes global traffic; health probes detect region failure and reroute within 10 seconds.
• Azure SQL Database with active geo-replication across all regions; auto-failover groups ensure writes always reach a healthy primary.
• RA-GZRS storage (read-access, geo + zone redundant) for customer data; reads available from any region even during primary region outage.
• Continuous synthetic monitoring (simulated user transactions) from every region validates RTO/RPO.

Results:

• SLA exceeded: 99.99% achieved; estimated uptime 99.995% (single 13-second global outage in 12 months).
• Latency optimized: $P95$ latency = 120 ms from all regions.
• Customer retention: SLA credits rare; zero customer churn due to availability.
• Infrastructure cost: $$150,000/month. Revenue:$$2$ million/month. Cost of uptime: 7.5% (justified for premium SaaS).

---

End of Lesson