Something I constantly and am running into are scenarios where applications and their components are built in a giant monolithic resource group. Within these giant resource groups are the contents and components for numerous related or sometimes unrelated applications. The reason is a logical one, let’s set our boundary as per team, department, without understanding the reasion to have multiple resource groups.
To take a step back a resource group is defined as:
“A resource group is 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. You decide how you want to allocate resources to resource groups based on what makes the most sense for your organization. Generally, add resources that share the same lifecycle to the same resource group so you can easily deploy, update, and delete them as a group.” –Microsoft Docs
Based on this definition placing everything in the same resource group is not recommended. What people and organizations don’t realize by shoving all these components into on giant resource group they are losing the ability to administer RBAC roles at the resource group level. Say there is sensitive data in your database and all of this is stored in the same resource group as your application. Well by giving a developer contributor permissions at the resource group you are also giving the developer contribute access to those databases, even if they don’t pertain to the application or line of business they are actively working on.
The other fallacy that I always scratch my head at is when a resource group contains the resource, say a website, for two different regions in the same resource group. Sure this is technically geo-redundant…..unless there are problems with the region the resource group is housed in. Individuals aren’t aware that part of the reason a resource group requires a region is to store the deployment logging information and meta data. Thus if a region goes down the ability to deploy to that resource group will then be jeopardy. Resource Groups should be laid by life cycle of the resources inside the application and then by region.
Here is an example architecture to illustrate such a point at the resource group level:
Each resource group is defined by life cycle and then location. In this example the Front Door Resource Group is hit first and then each region resource group can be hit and then traffic will flow the shared logging. By implementing an architecture in this way the resource group is separated first by life cycle and then by region.
This will allow for a completely geo redundant application as well as one where application promotion, security, and life cycle is optimized.