Azure Resource Group Best Practices – From the Vault: Part 2

So I've talked about subscriptions and why fewer is better. Now lets talk about the things that make that true, namely resource groups.

What is a resource group anyway?

Resource Groups are a critical concept in Azure Resource Management. A Resource Group is an ideal way to group a collection of resources for management, deployment and billing. When thinking about resource groups there is one key rule: Resources that life cycle together are grouped together into a resource group

Ok, so what are some examples/tests for resources that live together?

If you have an application and it contains a SharePoint farm, a SQL Azure database, and a Azure Web site, you should consider "When I do an update to code, which systems are updated?" The answer could be, "all of them", in which case it makes sense to group all of these resources into a single resource group (with a separate group for Test, Dev, staging, etc. since they don't life cycle with production). If the answer is that updates are pushed to the SharePoint components of the system separately from the SQL Azure and Azure Website portion, then the resources should be split into different resource groups, one for each group of resources that life cycle together.

You would then multiply this resource grouping by the number of environments (e.g. "Test SharePoint", "Test Web/SQL", "Dev SharePoint", "Dev Web/SQL", and so on). This enables teams to push code directly from development tools in the form of an ARM template or web deploy to the correct component. This also enables teams to perform role based access control at a life cycle component level (perhaps the SharePoint farm is administered by a different group then the web app, and perhaps test and dev are open to the whole dev team to deploy to, but production is only select people). Finally you can use tagging to tie resource groups together into a unified application for billing and viewing on dashboards.

So, Some Key takeaways here:

1. Resources that life cycle together live together in a resource group
2. Applications may contain N number of resource groups for production, based on the application design.
3. Applications may then contain Y number of resource groups for other environments (dev/test/etc) where Y = the number of environments times the number production resource groups.
4. A resource group can contain tags to determine its place in the application hierarchy (see my past post on tagging here).
5. Resource group resources are updated together when a code or infrastructure update is pushed out

We view the proper use of resource groups as a key requirement in leveraging your Azure subscriptions effectively. Even most ASM (Old Portal) resources can now be associated to a Resource group via the new portal.

New! You may find this PowerShell script useful for reporting on tags for Resource Groups in Azure.