Applies toAzure VMs, App Service, AKS, Azure SQL, Storage, Cosmos DB; Azure Site Recovery, Azure Backup, failover groups, Front Door/Traffic Manager
Four patterns
| Pattern | Secondary region during normal running | Typical RTO | Typical RPO | Relative cost |
|---|---|---|---|---|
| Backup and restore | Nothing running; backups replicated | Hours to days | Hours (backup frequency) | Low |
| Pilot light | Data replicated; compute off or minimal | Hours | Minutes | Low-medium |
| Warm standby | Scaled-down full stack running | Minutes to an hour | Seconds to minutes | Medium-high |
| Active-active | Full capacity in both regions serving traffic | Near zero | Near zero (engine-dependent) | High |
Numbers are typical ranges, not guarantees. Your own drills decide what you actually achieve.
1. Classify workloads
| Tier | Example | Target |
|---|---|---|
| Tier 0 | Identity, DNS, network connectivity | Must work first; designed with the platform |
| Tier 1 | Customer-facing revenue apps | Warm standby or active-active |
| Tier 2 | Internal business apps | Pilot light |
| Tier 3 | Reporting, dev/test, archives | Backup and restore |
Agree targets with the business owner, not just IT. Higher tiers cost more every month whether or not a disaster happens.
2. Map each layer to services
| Layer | Backup-restore | Pilot light | Warm standby | Active-active |
|---|---|---|---|---|
| VMs | Azure Backup cross-region restore | Site Recovery replication | Site Recovery / running scaled VMs | Running VMs both regions |
| App Service / Functions | Redeploy from IaC | Redeploy from IaC + pre-created plan | Running app in both regions | Both regions behind Front Door |
| AKS | Rebuild from IaC + GitOps, restore volumes | Pre-created cluster, scaled to 0 user nodes | Running cluster, minimal replicas | Both clusters serving |
| Azure SQL | Geo-restore | Geo-replica / failover group | Failover group | Failover group (read in secondary) or app-level sharding |
| Storage | GRS / GZRS | GRS + tested failover | RA-GZRS, app reads secondary | App-level dual writes / object replication |
| Cosmos DB | Continuous backup | Multi-region reads | Multi-region with automatic failover | Multi-region writes |
| Traffic | DNS change | DNS change / Traffic Manager | Front Door priority routing | Front Door weighted/latency routing |
3. Hidden dependencies that break DR
- Identity: Entra ID is global, but on-prem AD DS domain controllers, AD FS, and app secrets in a single-region Key Vault are not. Replicate or pre-provision.
- Networking: secondary hub, firewall rules, private DNS zones linked to secondary VNets, ExpressRoute/VPN to the secondary region.
- Secrets and certificates: Key Vault in the secondary region with the same secrets; certificates valid for the DR hostnames.
- Quotas and capacity: vCPU quota and GPU capacity in the secondary region (consider capacity reservations for Tier 1).
- Third parties: allow-lists at partners using primary-region IPs.
- Monitoring: alerts and dashboards that only watch primary resources.
4. Decide the failover trigger
Who declares a disaster, using which signals, and after how long? Automatic failover at the data layer (failover groups with automatic policy) versus manual decision is a business decision. Document it with names.
5. Test it
A design without a drill is a guess. Run at least an annual DR test per Tier 1/2 workload (see the DR drill post), and record achieved RTO/RPO next to the targets.
Design review questions
- What's the RTO/RPO, who agreed it, and does the pattern meet it on paper?
- What's the order of recovery across dependent workloads?
- What still points at the primary region (DNS names, IPs, connection strings)?
- How do you fail back?
Tip
Zone redundancy inside a region handles far more real incidents than region failover. Get zone resilience right for Tier 1 and 2 before investing in active-active across regions.
Checklist
- Workloads tiered with business-agreed RTO/RPO
- Pattern chosen per tier and mapped per layer
- Identity, network, secrets, quota and third-party dependencies covered
- Failover decision process documented
- Drill scheduled; achieved RTO/RPO recorded
- Failback plan written