DR for PaaS Services

Disaster recovery for IaaS services (VMs) typically involves Azure Site Recovery to replicate the entire OS and data disks to a secondary region. PaaS services have different DR models because the underlying infrastructure is managed by Microsoft. For PaaS, DR is usually configured at the data layer — replicating the data to a secondary region while the platform itself spins up automatically.

Azure SQL Database provides built-in high availability at the zone level within a single region. For cross-region DR, it offers two key capabilities: active geo-replication (readable secondary databases in up to four other regions) and auto-failover groups (automated failover with a single listener endpoint). These are configured at the database or server level without needing Azure Site Recovery.

Auto-failover groups add automation and a single connection endpoint on top of geo-replication. You configure a group on the primary server, add the secondary server, and define a grace period — the time Azure waits for the primary to recover before triggering automatic failover. Applications connect to the listener endpoint (e.g., mygroup.database.windows.net) and are automatically redirected after failover without changing connection strings.

Azure SQL Database geo-replication is asynchronous — transactions are committed on the primary and then replicated to the secondary. This means there is a small replication lag, typically less than 5 seconds under normal conditions. The RPO for SQL geo-replication is therefore approximately 5 seconds in most scenarios, making it suitable for Tier 1 and Tier 2 workloads that require very low data loss.

All Azure SQL Database tiers include automated backups: full backups weekly, differential backups every 12 hours, and transaction log backups every 5-12 minutes. This enables Point-in-Time Restore (PITR) — restoring the database to any second within the retention period (7-35 days for Standard/General Purpose, up to 35 days for Business Critical). PITR is useful for recovering from accidental data deletion or corruption.

Azure Cosmos DB with multi-region writes provides near-zero RPO for global applications. All configured regions can accept write operations simultaneously, and Cosmos DB synchronises the data automatically using its proprietary replication protocol. If a region fails, traffic is automatically routed to the remaining healthy regions with no manual failover required — achieving RTO and RPO close to zero.

Azure App Service itself is stateless (application code is deployed from source control or a ZIP file). For DR, the focus is on the data layer (database and blob storage). App Service can be redeployed to a secondary region quickly via CI/CD pipeline. However, you should ensure your custom domain, TLS certificates, and app settings are replicated or scripted so they can be recreated in the secondary region rapidly.

Azure Blob Storage with Geo-Redundant Storage (GRS) automatically replicates data to a secondary region hundreds of miles away. Data is replicated asynchronously (RPO typically under 15 minutes). Read-Access GRS (RA-GRS) allows reading from the secondary endpoint even before failover is triggered, which is useful for analytics and reporting workloads during a primary region outage.

Azure Functions are stateless by design, making them easy to redeploy. For DR, deploy the same function app to a secondary region and use Traffic Manager to route HTTP triggers between regions. For non-HTTP triggers (Service Bus, Event Grid), configure the message source to fan out to both regions, or have the secondary region poll the same source. Function state in Durable Functions is stored in Azure Storage — ensure that storage uses GRS.

Use active geo-replication when you need fine-grained control — for example, directing read traffic to a secondary for performance, or managing multiple secondaries in different regions independently. Use auto-failover groups when you want simplicity: a single listener endpoint, automatic failover on a timer, and built-in orchestration of the failover process without manual intervention.

PaaS DR is often cheaper than VM-based DR for several reasons. SQL Database geo-replication charges only the secondary's storage and compute; you are not paying for a full VM OS license. Azure Cosmos DB charges for the provisioned RUs in each region. Azure Storage GRS adds approximately 2x the storage cost. In contrast, ASR-replicated VMs require full compute, storage, and licensing costs in the secondary region.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: PaaS DR focuses on the data layer rather than VM replication; Azure SQL auto-failover groups provide a single listener endpoint with automated failover; and Cosmos DB multi-region writes deliver near-zero RTO and RPO for global applications. Next up we explore Azure compliance frameworks and the shared responsibility model.