Azure Resource Groups

Q: What is a resource group in Microsoft Azure?

A: Azure initially started as a Platform as a Service (PaaS) that was focused on the deployment of cloud services; over time, various other types of roles were added, as well as endpoints and then virtual machines. However, the model remained the same: focused around a cloud service and not around the actual resources, which is more important in an Infrastructure as a Service (IaaS) type environment. Trying to perform a large deployment of virtual machines in Azure is fairly complex; everything is done imperatively in scripts, which means you must code all the error handling, looking for links between different virtual machines and substituting variables, checking whether resources already exist, and so on. I've seen Microsoft scripts to deploy a SharePoint farm in Azure, which is a very complex task that people don't want to undertake. The goal is to be able to deploy a service that's made up of many resources; those resources should live in an application lifecycle container so that all the resources share a common lifecycle, allowing access control to be governed on that container, billing to be visible on that container, and resources within that container to be able to talk to each other using their own identity instead of the complex methods that must be used today for resources to communicate and access one another. This container is the resource group; going forward, every resource created lives inside a resource group, and key capabilities such as access control, management, and billing will all be aggregated to the resource group level.

A resource can only exist in a single resource group, and you can't nest resource groups; however, you can link resources from another resource group in a resource group. For example, I might link a SQL Server database from another resource group in my resource group if I use that SQL Server database to make it easier to see the resources used by my service. There are currently no limits to the number of resources in a resource group. However, you can't rename a resource group; in addition, given that a rename operation can be highly destructive to mechanisms that use the name (e.g., role-based access control), I wouldn't expect to see rename happening any time soon.

The following figure is an example view of a resource group in the Azure portal. All the resources can be seen, such as domain names, virtual machines, and networks; if any resources are linked, they will also show.

Resource groups aren't available in the older Azure portal; you need to use the new Azure portal. To see all resource groups, select the Browse button and select Resource Groups, which will open a blade with all resource groups available. Selecting a resource group will show details about the resource group and expose capabilities such as configuring role-based access control. Any new resource created is automatically created within a resource group (you can choose to create a new resource group or add to an existing one), which includes the deployment of templates within the new portal (all resources from the template are placed together into a resource group). It's possible to create an empty resource group using the New-AzureResourceGroup PowerShell cmdlet and then create resources and place them within the resource group.

The real power of resource groups is when they're combined with the new declarative template model that's exposed in the new Azure portal, which enables entire services to be deployed simply and without having to write code to check for errors, to verify whether resources exist, and so on. I'll discuss the Azure template model in a future FAQ.