Introduction
If one is new to Azure it’s important to understand the concept of the Azure Resource Group. Resource Group understanding and structure is paramount to be successful in your Azure architecture. An Azure architecture that does not properly leverage Resource Groups can lead to issues down the road as environments scale. If you are new to Azure from AWS an Azure Resource Group is completely different then it’s AWS equivalent.
What is a Resource Group?
Every resource in Azure requires a Resource Group. It is required and is in fact part of the Resource ID for an Azure Resource. Microsoft defines a Resource Group as:
…a container that holds related resources for an Azure solution. The resource group can include all the resources for the solution, or only those resources that you want to manage as a group.
https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal
Boil it down to a resource group is a collection of Azure resources that will adhere to the same lifecycle and region. In a real world architecture this may mean having your front end web resources in one resource group, the backend in another, database in yet another, and a global resource like Azure Front Door in yet another.
Seems like overload? Don’t worry stop and think this through. First the database will adhere to it’s own access requirements and typically when decommissioning an application the database tends to be kept for auditing purposes.
A backend can have multiple front end components so placing it in it’s own resource group will also help ensure the existence of a loosely coupled architecture.
A front end can come and go. Not to mention we may want to have front ends in different regions for performance and/or legal requirements so again splitting this out will assist in a loosely coupled architecture.
Lastly Front Door is a globally available resource. As such, it should be in it’s own resource group. This allows for all the other components to scale out to different regions without having to manage which region will be “primary” and have the front door associated with it.
A Resource Group should be seen as a self encapsulated LEGO block for your application. This LEGO block can be duplicated, interchanged, redeployed at any given time with minimal impact to your architecture outside the scope of the Resource Group.
Resource Group Needs a Location?
Yes. A Resource Group though a logical container will need a region to write it’s deployment logs to.
So when writing your Azure architectures assume what happens if a region goes down and can’t be deployed to. If this happens then are your architecture/deployments resilient? All the resources in a resource group should belong to the same region as the resource group. Furthermore the region for all resources and resource group should be defined in your Infrastructure as Code (IaC). For more information on IaC check out my Many Flavors of Azure IaC Repo.
Resource Group Security
A Resource Group is pivotal when we talk about the resource structure within Azure:
As seen here a Resource Group lies between an Azure Subscription and the individual resources. As such a Resource Group can have it’s own Role Based Access Controls (RBAC) assignments. Any resources within the Resource Group will inherit the RBAC assignment.
This is an important concept in a scenario such as wanting to provision a “sandbox” for a developer. One could grant Owner permissions at just the Resource Group to the developer. As such the developer could do whatever they need to within the Resource Group and nowhere else. Here is an overview of such a scenario.
Another typical scenario is if wanting to provision access at different management planes. for the various resources.
What a Resource Group Is Not
There are a lot of misconceptions on what a Resource Group is and how to use them. Here are just some of them.
Separate Environment
I’ve seen organizations resolve themselves to having a Resource Group per environment. Think a Resource Group for Development, Test, and Production all in the same subscription. Please don’t do this. By doing this adds overhead to the security model mentioned above. This type of seperation is best served by having individual subscriptions. By doing so one can still leverage the subscription access control. Additionally by having Dev/Test in a separate subscription an organization can take advantage of Azure Dev/Test pricing.
An Application Boundary
This is a scenario where all parts of application are stored in the same Resource Group. This again though will restrict how access can be assigned at the Resource Group level and will lead teams to assign RBAC roles on individual resources.
Additionally if their IaC follows this then odds are all the IaC is contained in the same file/repo. Which can be problematic if needing to scale out to a different region a specific element of the application. Coupling all the components to the same Resource Group and tied to the same IaC is a poor DevOps design as it will also increase risk of deployments since the entire Resource Group is being redeployed every time.
Resource Group Location Doesn’t Matter
As mentioned above this matters. When we start talking about truly resilient architectures we can’t have a Resource Group live in East US and have the individual resources be in West US. Assume there is an outage in East US during your deployment. This construct then follows that your resources that are housed and running in the West US may not be deployable based on the outage in East US.
Conclusion
There is a lot of misconception and misunderstanding on how to best leverage the Azure Resource Group. At the end of the day a Resource Group should be contained with elements are housed in the same region, related to the specific component of the application, share the same lifecycle, and whose resources are deployed/managed together.