1
votes

Refer to Why are Azure Resource Groups associated with a specific region?

Say that I have a Resource Group A that has been deployed to the Australia South East Region.

In Resource Group A, I have resources that are deployed to multiple regions:

  • Resource B - Australia South East
  • Resource C - Australia East

Suppose that Australia South East Region has a complete outage. I understand that Resource B will be unavailable and that I will not be able to complete deployments into Resource Group A, as its metadata is also stored in Australia South East Region.

However, I'm interested in what the limitations associated with Resource C are? For example, if Resource C is a VM, can I shutdown/start/restart? Can I add a firewall rule? Can I make any other config changes in Portal or via Powershell/CLI?

I can't find this documented in detail anywhere and really need to understand what these restrictions are.

Can anyone help?

Thanks in advance.

2

2 Answers

2
votes

When the region a resource group is contained in is offline, you cannot perform any write operations to that resource group (which is not the same as a write to a resource in the group). Reads are fine as the storage for the metadata is redundant. So in your example, you could do anything you want to resource C as long as it doesn't require a write to the resource group.

There aren't very many operations that write to a group (add a tag to a RG, move a resource to/from a resource group and as you noted deploy to it). If you wanted to add an NSG to the NIC for the VM that should be fine as long as the NSG could be in a different resource group (or already existed).

That help?

0
votes

It will all depend on what resources are located where. For example, as long as any dependent resources are not located in the down data center you should be fine. Such as having a storage outage in A but VMs hosted in B.

Azure offers a great deal of resiliency to outages and many ways for you to build and configure for high availability. Each of this configurations will different based on the service you are using.

So there is not a simple answer to your question as there are many variables involved. Generally it is suggested that a resource group should hold everything related to one project. So if you have a SQL farm all resources should be put into the same resource group. Then if you are done with the farm you simply delete the RG.