Include the resource group's region in an Azure change-availability plan

Source facts

Azure stores a resource group’s resource metadata in the group’s selected region. Microsoft states that temporary unavailability of that region prevents updates to resources in the group because the metadata is unavailable. Resources located in other regions can continue functioning even though those updates are unavailable. Microsoft Learn.

Applicability

Review designs where the resource group and its resources occupy different regions. Identify both locations explicitly. Separate the requirement to keep a workload serving requests from the requirement to modify its Azure configuration during a regional disruption.

DSE recommendation

DSE recommends adding the resource-group location to the application’s regional dependency record. Ask the recovery owner which response actions require resource updates, and check whether the proposed operating plan assumes those actions remain available. For new deployments, evaluate Microsoft’s recommendation to colocate the group and resources alongside the actual application requirements. Do not reorganize an existing production resource group solely to tidy a diagram.

Verification

Inventory the resource group’s location and each relevant resource location, then walk through the documented disruption scenario with the application and platform owners. Mark which steps observe the workload and which attempt an Azure update. Use a tabletop review or approved test design rather than manufacturing a regional outage. Retain the identified change dependency and any revised response steps separately from ordinary application health-test results.

Official references

Microsoft Learn. Source retrieved September 9, 2026.