What is a Resource Group? What’s it used for? And what are the recommendations for usage? The first two questions are really rather easy.
A Resource Group is merely a container to hold resources in Azure. The Resource Group itself stores metadata about the resources that are contained within it, and it can be used as both as security and/or cost boundary to the resources. In addition, control plane operations against those resources are routed through the region where the Resource Group is deployed to (build / edit / delete).
Resource Groups, while not costing money, are very easy to create and forget about. Without any sort of plan or governance, you could end up in a situation where you’re close to the limit of 980 – like this:
Resource Groups are one of the few resource types in Azure that have no way of backing up. There’s really no need since it’s essentially just metadata and security attributes. But what happens if a region goes down where your Resource Group is defined? Well…it depends what’s in there.
Let’s say you have a Resource Group in Azure West US. In it you have a Key Vault in West US and a Virtual Machine in West US 2. If the West US region goes down, what happens? Well, the Key Vault deployed in West US is unavailable, but the Virtual Machine continues to run. Additionally, you can’t make any control-plane changes to that Virtual Machine (no resizing the SKU, no adding disks, etc). The metadata for that machine is tied to the Resource Group, which would also be unavailable.
So what are the recommendations for usage? Again, we fall back to the “it depends” answer. Much of the documentation and guidance points at having a Resource Group defined for a solution where all the components share the same lifecycle. This could be interpreted a number of ways and is a conversation to have with your cloud governance team (or cloud architect).
In this sample, your application may have separate resource groups for the Production and Development environments. This can help both from a security and cost perspective.
Your network team may want all production networking to land in a single resource group. This is a great method to ensure only the network team have the ability to build / configure virtual networking.
Be careful, though, in allowing individual users to create a resource group for their own testing, as that can quickly create sprawl. If you only a handful of people, sure. But if you have hundreds? Gets messy.
I say keep it simple. Be thoughtful. Use a naming convention (preferably leverage Microsoft’s existing recommended naming convention). Single RSG per app, per region. Build your application in a resilient manner according to your systemic requirements, taking into account the resiliency options for your resources. Don’t complicate the creation of your resource groups!