Nested Resource groups
The resource group concept is great, by recently, we started hitting a limit. Resource groups is Azure can't be nested (a Resource group that contains other Resource groups), and consequently, when assigning user permissions to a resource group, it is simplier to create a single resource group and include all the needed resource groups in that group, then assigning the user permissions on that parent resource group. This is one of the many benefits and advantages of having nested resource groups
Mark E commented
Nesting resources by means of a tree or folder structure provides better visual organization and allows a logical grouping of associated resources.
Toan Tran commented
Please support the feature
Please add the feature.
Ashish Patel commented
I agree with this request, nested resource group will help us to define logical group of resources of the micro-services
It would be nice to group everything associated with a VM (disk, IP, network interface, VM itself, sometimes more) into a unit for ease of management. Nested resource groups would let me do this.
Would like this for logical organization of resources. We have many many apps that all share one subscription. We can organize each app into a resource group, but within an app there may be many parts, and it would be nice to organize each of those parts in their own sub-resource group. Similarly, we have subscriptions with many users. It would be nice if each user can have their own resource group, but then within that resource group they can organize their various services into sub-resource groups. It would make browsing and finding relevant resources much simpler.
Patrick Mawyer commented
In addition to Resource Groups, you might want to consider implementing a tagging strategy for your resources which could help resolve some of your problems.
Daniel Earwicker commented
Our application consists of a number of separately deployed parts with their own redeployment cycles. So each is continuously delivered (by its own TFS release config) that includes an ARM template, running in "complete" mode. So each ARM template must have its own dedicated resource group.
But we have (at least) two instances of our whole application: test and production. We will likely add more production instances for different regions. We call these environments. Each has a dozen resource groups. At the moment there is nothing connecting them.
If resource groups could form a tree, we could have a top level named after our application, under which would be complete environments such as Test, US, UK, etc., which in turn would contain resource groups for separately deployable parts of the application (ARM templates).
SURYA PRAKASH SINGH commented
what is the plan to incorporate nested resource group feature? today I tried but seems this feature is not available.
We service multiple systems for multiple clients and having nested resource groups would allow us to partition first by client as well as system. We would also be able to separate resources used for staging/development vs production systems.
Alan M commented
I would like nested resource groups to group resources into logical groupings so that it is easier to recognize which resources are related to each other within a large deployment. Once you go beyond a simple application with 3 to 4 resources in it, keeping track of which ones are related and dependent on each other is hard.
I'd love to have nested resource groups. I can create a DMZ RG, then nest PublicDMZ and PrivateDMZ from there, and then break it down even further.
Having 2-3 levels of nested capabilities will help organize things greatly.
I agree with this too. Nested resource group will help with organizing and RBAC
Sebastian Fyda commented
There is a lot to gain from nested RG - from cost tracking to permissions management. I also do a lot of PoC where I cannot keep all the stuff in one RG. Having nested groups would make my life easier and my subscription cleaner.
I agree that this is a need, particularly for large global organizations with geo-distributed environments and IT departments. This is just like delegation of administration through OUs in AD. Now we can do this with RBAC and Resource Groups. This would be great for global orgs :)