4.1.2. Design for Azure Site Recovery
💡 First Principle: An orchestrated, automated disaster recovery service is essential for enabling rapid and reliable failover of entire workloads to a secondary location, minimizing business disruption from regional outages.
Scenario: You are designing a DR solution for an on-premises enterprise application running on VMware VMs. This application is critical and needs to be recovered in Azure with an RTO of 4 hours and an RPO of 15 minutes in case of a regional disaster. You also need to regularly test this DR plan without impacting the production environment.
ASR is an Azure service that contributes to your disaster recovery (DR) strategy by replicating and failing over workloads to Azure or a secondary location.
Key Design Considerations:
- Replication: ASR continuously replicates data from primary sites (on-premises VMware, Hyper-V, Azure VMs) to Azure, ensuring up-to-date recovery points.
- Failover & Failback: Supports planned and unplanned failover with orchestrated recovery plans, enabling low Recovery Time Objective (RTO) and Recovery Point Objective (RPO). Failback allows workloads to return to the original site.
- Supported Workloads: Protects Azure VMs, VMware VMs, Hyper-V VMs, and physical servers, offering flexibility for hybrid architectures.
- Network Design: Facilitates IP address retention and automated DNS updates during failover, reducing reconfiguration time and ensuring seamless connectivity.
- Testing: Enables non-disruptive disaster recovery drills, allowing organizations to validate recovery plans without impacting production workloads.
Design decisions in practice:
| Decision | Guidance |
|---|---|
| Vault placement | The Recovery Services vault goes in the TARGET region — the region being recovered TO — so that it survives the loss of the primary |
| Replication | Continuous, giving an RPO measured in seconds to minutes. Crash-consistent points are frequent; app-consistent points are less frequent and require the agent to quiesce the application |
| Recovery plans | Ordered startup groups encode which tier comes up first, with optional scripts or runbooks between groups. This is what stops the sequence being improvised during an incident |
| Drills | Test failover brings the workload up in an ISOLATED network without affecting production or pausing replication. It is the only way to measure a real RTO |
Site Recovery protects virtual machines, and that boundary is examined. It replicates Azure VMs between regions, and on-premises VMware or Hyper-V machines into Azure. It does not protect PaaS services — Azure SQL Database has failover groups, Storage has its own redundancy options, and each managed service brings its own cross-region mechanism.
⚠️ Exam Trap: failover is not symmetric with failback. Data written while running in the secondary has to be reconciled back to the primary, and re-protection must be configured before failback can run — which is why a plan that stops at "fail over to region B" is incomplete.
⚠️ Common Pitfall: Failing to account for dependencies in a recovery plan. A recovery plan must orchestrate the startup of dependent services in the correct order (e.g., Active Directory first, then databases, then application servers) to be successful.
Key Trade-Offs:
- RPO vs. Network Bandwidth/Cost: A lower RPO (more frequent replication) requires more network bandwidth and can increase costs, especially for on-premises to Azure replication.
Reflection Question: How does designing for Azure Site Recovery (ASR), leveraging its continuous replication, orchestrated failover/failback capabilities, and non-disruptive testing, fundamentally deliver automated disaster recovery as a service, enabling rapid recovery of workloads and minimizing business disruption?
