What's changed: Deepened AZ-305 Chapter 3 (added comparison tables, scenarios, FAQs, exam traps, deep-dive paragraphs to each section; localized figures to Japanese)
3.3Designing Disaster Recovery
Understand DR design—Azure Site Recovery (ASR), region pairs, RTO/RPO, and database geo-replication/failover groups. Design strategies to recover from regional failures.
For regional failures, prepare with cross-region replication and failover. ASR for VMs; geo-replication for databases.
3.3.1DR means and metrics
- Azure Site Recovery (ASR): continuously replicate VMs to another region with failover/failback.
- Region pairs: replicate to a geographically distant paired region for regional disasters.
- DB geo-replication: SQL uses active geo-replication/failover groups; Cosmos uses multi-region writes.
- RTO/RPO: RTO = recovery time, RPO = data loss; requirements drive the DR setup (replication/standby).
Common on AZ-305: cross-region VM DR = Azure Site Recovery, cross-region SQL DR = active geo-replication/failover groups, Cosmos multi-region writes, storage geo-redundancy = GRS, and choose setup by RTO/RPO. Failover groups auto-fail over without changing connection strings.
AZ-305 DR design probes "which replication and failover method meet the RTO/RPO requirement." RPO (recovery point objective) is tolerable data loss; RTO (recovery time objective) is tolerable time to recover—the tighter they are, the more always-on standby (cost) is needed. Azure Site Recovery (ASR) continuously block-level replicates VMs to another region and performs ordered failover via recovery plans (validated non-disruptively with test failover) and failback. For databases, Azure SQL Database offers active geo-replication (readable secondary) and failover groups (auto/manual failover via a listener without changing connection strings), and SQL Managed Instance supports failover groups. Cosmos DB uses multi-region writes (multi-master) so each region accepts writes, driving RPO/RTO near zero. Storage replicates cross-region with GRS/RA-GRS and promotes via account failover. Select regions based on Azure region pairs (favored for sequential maintenance and recovery prioritization). DR strategy spans, like AWS, backup & restore < pilot light < warm standby < active/active, chosen by the RTO/RPO-vs-cost trade-off, and validated with periodic failover drills.
| Target | Cross-region DR means | Key point |
|---|---|---|
| Virtual machines | Azure Site Recovery (ASR) | Continuous replication; recovery plans |
| Azure SQL Database | Failover groups / geo-replication | Auto-failover without changing connection strings |
| Cosmos DB | Multi-region writes | Writable in each region; near-zero RPO/RTO |
| Storage | GRS/RA-GRS | Cross-region replica; account failover |
Scenario: Recover a core app (IaaS VMs + Azure SQL Database) to another region within minutes of RTO and minutes of RPO even on a regional failure. → Continuously replicate VMs to another region with ASR, defining boot order in a recovery plan (validated via test failover). Replicate the DB cross-region with a failover group, switching via the listener without changing connection strings. Choose a region pair and run periodic failover drills.
FAQ: Active geo-replication vs failover groups? Both replicate Azure SQL cross-region, but failover groups provide a listener (read-write/read-only endpoints) and group-level auto/manual failover without changing connection strings. Active geo-replication is the finer-grained mechanism creating a readable secondary per database. For operational simplicity, failover groups are the go-to.
Exam trap: Handling cross-region VM disaster recovery with Azure Backup alone is a weak design—Backup is restore from recovery points and tends to have a long RTO. For low-RTO cross-region failover, ASR (continuous replication) fits. Also, thinking of Cosmos DB DR as the same "failover groups" as SQL is wrong—Cosmos centers on multi-region writes.
3.3.2Section summary
- VM = ASR (cross-region replication/failover) / DB = geo-replication
- Metrics = choose setup by RTO (recovery time)/RPO (data loss)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Continuously replicate VMs to another region and fail over on disaster. What?
Q2. Replicate Azure SQL Database to another region and auto-fail over without changing connection strings. What?
Q3. Which are the two key metrics when choosing a DR configuration?