I have not seen a lot of official guidance from Microsoft on the number of Resource Groups  (RGs) in a deployment.  Should I put all my resources in one large group? Or use multiple RGs, and what criteria do you use to segment them? Here are some thoughts on granularity and Resource Groups.

  1. Putting all resources in a large group is akin to writing one large monolithic main program with no functions – it is not good modular design and changes later can be an issue. T
  2. Tagging of tiers for monitoring, billing status, and management.   You can tag all resources in one RG (vs each individual resource). If all on one big RG, you can’t differentiate between tiers.
  3. Being able to update all the resources in a RG as one or separately.  Only resources that life cycle together should be in the same RG. A resource group is a unit of provisioning resources as a unit in one action (Application Lifecycle Management – ALM).  You can update and delete them as a unit.
  4. You can restrict access to RGs using RBAC at a more granular level.  This requires more analysis in this architecture but is a administrative positive in multi-tier environments. If everything is in one RG you love this capability. For production applications, you can control the users that may access those resources.  Or for the core infrastructure resources you can limit only infrastructure folks to work with them.
  5. With different RGs, you can define different admin access permissions for each tier. Owner, Reader, Contributor.  Some admins may be owner on one tier, but contributor on other tiers. Not a good security idea to let everyone in the door at the party and let them roam freely in the house into different rooms that they may not have a true business need to administer.  Its why we have different roles/permissions in SQL Server for admins.
  6. Compartmentalizing templates/RGs helps division of responsibility to enhance security. Each template for each tier can be under different RBAC roles for full separation of duties.  Using one large RG you lose the granular security for different tiers of your solution.
  7. Centralized RGs that contain core components (storage, VNETs/subnets, etc.) are an option with >1 RG. As you scale out, creating centralized Resource Groups for your virtual networking and subnets makes it easier to build cross-premises network connections for hybrid connectivity options. When combined with RBAC, you can protect these common groups to only be administered by the correct admin.