Resource Group Location Matters

Resource groups generally aren’t something you think too much off when deploying your Azure resources. They’re essentially a folder containing your resources; once you create one, you don’t do much with it again. However, there is one concept you should think about - the location of your resource group compared to your resources and how this might impact a disaster recovery or failover scenario.

One of the purposes of a resource group is to store meta-data about the resources deployed into them, so they contain details about how that resource is configured, its current state etc. When you create resources, you can create them in any region, and this can be a different region to the resource group you are deploying them into. This is supported and works fine. However, the meta-data about those resources is stored in the region of the resource group, not the resource.

So why does this matter? Ordinarily, it doesn’t, but it might in a regional outage. If there is an outage in the region of the resource group then resources that are in that resource group, but in a different region will keep running just fine. However, if the outage means you cannot update the meta-data in the resource group region, it will mean that you cannot make any changes to those resources, even if the resources themselves are in a different region. In a disaster scenario where the resource group region goes down, and you want to fail over to a secondary region, the fact that you cannot change any resources could mean you can’t fail over. For example, you may need to change your SQL DB to use a different replica for writes, or you may want to failover a geo-redundant storage account. If the meta-data about those resources is in a region that is down, you won’t be able to do that, even if the resource is running fine.

The exception to this rule is global resources, like Azure Front Door, DNS zones etc. These are independent of the resource group region.

Here’s what the Microsoft Docs have to say about this:

If a resource group’s region is temporarily unavailable, you can’t update resources in the resource group because the metadata is unavailable. The resources in other regions will still function as expected, but you can’t edit them. This condition doesn’t apply to global resources like Azure Content Delivery Network, Azure DNS, Azure DNS Private Zones, Azure Traffic Manager, and Azure Front Door.

So how do we deal with this? If you’re not running applications that need to survive outages and transition to a DR site, then it may not matter. However, if it does matter, then you will want to ensure that your resources are deployed to a resource group that is deployed in the same region. This usually means that in a solution where you want to deploy to two (or more) regions, you split your resources between two different resource groups, one for each region. Resource groups are just logical collections of resources so there is no problem with having resources for the same app or set of infrastructure in two different resource groups.