In my first week working at Microsoft, I got access to my work Azure account and logged in to start playing around with some Azure services. I launched the Azure Portal , logged in, and clicked the big “Create a resource” button at the top of my portal homepage. I searched for “aks”, selected “Azure Kubernetes Service” from the results, and hit “Create”.
And immediately I had to answer two questions:
- Which Subscription did I want to provision my new resource into? and
- Which Resource Group did I want to provision my new resource into?
Azure Portal asking which Subscription and Resource Group to use when creating a new resource such as an AKS Cluster
As someone who’s worked extensively with AWS in the past, I found the idea of Azure Resource Groups a bit foreign to start with. I didn’t know what they were, or why they were important. But every time I went to create a new resource, I was asked which Resource Group I wanted to create it in.
What is an Azure Resource Group?
According to the Azure documentation , a Resource Group is “a container that holds related resources for an Azure solution”. This could be anything from virtual machines, storage accounts, and networking components, to databases, web apps, or even machine learning models.
The Azure Portal suggests you “Use resource groups like folders to organize and manage all your resources”. Resource groups allow you to easily organise, manage, deploy, and monitor related resources:
All the resources required to run this website
But there’s much more to Resource Groups than just grouping stuff together! Let’s take a look at some of the other capabilities Resource Groups have to offer.
What Else Can Resource Groups Do?
Besides simplifying the management of related resources, Resource Groups offer a number of other benefits, including:
- Acting as a template for similar deployments
- Monitoring and optimising your costs
- Acting as a security and/or collaboration boundary
- Tagging resources
Templating Similar Deployments
On almost every resource page in the Azure Portal, you can scroll down to the “Automation” header in the left navigation pane, select “Export template”, and Azure will generate a template of the relevant resource(s). When doing this at a Resource Group level, the template will include all the resources that are part of the Resource Group, even if they weren’t initially deployed at the same time. That’s super handy for those times when you’re making iterative changes to figure out the optimal configuration!
Monitoring & Optimising Costs
From your Resource Group, you can scroll to the “Cost Management” header in the left navigation pane, and select “Cost analysis”. This will display a chart showing your accumulated consumption so far in the current billing period, as well as a forecast of expected costs for the remainder of the billing period. If you are reviewing costs at the subscription level, you can easily group costs by Resource Group, giving you a quick and easy way to see which projects are costing the most, as shown in the screengrab below:
My Azure bill broken down by Resource Group in late March 2023
Security & Collaboration Boundary
Security policies and controls can be applied at the Resource Group level, allowing you to provide or enforce different sets of guardrails for different projects. Multiple projects can co-exist in the same Azure subscription, with your development teams only being granted access to the resource groups (and associated resources) that they need access to - this is great for implementing the principal of minimum privilege in a convenient and practical way. You can also invite users from other subscriptions and organisations to your resource group, allowing them a pre-defined level of access to the resources within.
Although resources in Resource Groups don’t currently automatically inherit tags from their parent Resource Group, I did find some documentation that suggests there is a preview feature to enable this, although I wasn’t able to get this working myself. Still, if you tag your Resource Groups with a consistent set of tags then they are quickly discoverable via a tag search, and then another click in the portal will show you all the associated resources. Once tag inheritance becomes more widely available, it will make resource searching and discovery via tags very easy and reliable.
Resource Groups Best Practices
Having played around with Resource Groups (and Azure at large) for the past few months, I have a few suggested best practices to follow to use Resource Groups most effectively:
- Use a logical naming convention for your Resource Groups and the resources you deploy inside them, so that it is easy to understand what the resources in the Resource Group are used for, who they are owned by, etc.
- Use Tags to label your resources within a Resource Group for better management and organisation. When tag inheritance becomes widely available, enable it on your Resource Groups.
- Use Resource Groups to secure your workloads and enforce the principal of minimum privilege.
- Use Infrastructure as Code (e.g. Azure Resource Manager , Azure Bicep , Terraform ) to deploy your resources into Resource Groups for highly repeatable and manageable cloud workloads.
Resource Groups are a great little feature for logically organising your Azure resources, and AWS doesn’t have a comparable feature; you’d have to spread workloads across multiple accounts to achieve the same level of separation or cost analysis as Resource Groups provide out-of-the-box. But they can be much more than “virtual folders” for your cloud resources!
With some careful planning and best practices, Resource Groups can help customers simplify management, optimize costs, enforce security best practices, and enable collaboration. Win win win win!