azure-dr-multiregion

Standard IDs

ID	Severity	What it checks
ADR-001	P1	Production workload has no paired-region secondary deployment
ADR-002	P1	No Traffic Manager/Front Door failover routing configured
ADR-003	P2	No documented RPO/RTO targets for the workload
ADR-004	P1	Database has no cross-region replication/geo-redundant backup matching the RPO/RTO

---

Check A — No paired-region secondary deployment (ADR-001)

Detection

Check whether the Bicep templates deploy only a single region for a production workload with no secondary-region module using an Azure paired region (e.g., East US paired with West US). A single-region deployment means a regional Azure outage takes the whole workload down with no failover target — this is azure-waf-review's WAF-REL-004 ("single-region deployment with no geo-redundancy note") made concrete with an actual pattern to fix it.

BAD — one region, no secondary

// main.bicep — deploys only to East US
param location string = 'eastus'

resource containerApp 'Microsoft.App/containerApps@2023-05-01' = {
  location: location
  // No secondary-region module; an East US outage takes the whole app down.
}

GOOD — primary + paired-region secondary via a shared module

// main.bicep
module primary 'modules/region.bicep' = {
  name: 'primary'
  params: { location: 'eastus', isPrimary: true }
}

module secondary 'modules/region.bicep' = {
  name: 'secondary'
  params: { location: 'westus', isPrimary: false } // Azure paired region for East US
}

---

Check B — No Traffic Manager/Front Door failover routing (ADR-002)

Detection

With two regional deployments (Check A) in place, confirm a Traffic Manager profile (Microsoft.Network/trafficManagerProfiles) or Front Door (Microsoft.Cdn/profiles) with Priority routing is configured to actually fail over — two independent regional deployments with no shared front door still requires a manual DNS change during an outage.