Best Practice when naming Azure Resources

Summary

When creating Azure resources, it’s very easy to get lost in the volume of resources that often get created as part of a simple deployment like a new Virtual Machine. Managing these resources can then become very cumbersome. I’ve worked on some projects where the organisation couldn’t explain why certain resources existed, even though there were costs associated.

In this post I’ll outline some simple recommendations that will help with managing Azure resources.

Resource Groups

Resource groups should be named something that is meaningful to your organisation. It has always been a common practice to group all your Azure resources that have some association, into one container as a Resource Group. In practical terms though, you will find that many resources that once had no association, suddenly want to access a resource in your primary Resource Group. For this reason it is better to split the resource out by the type of function/service they provide.

Here is an example of a Resource Group with the naming convention [stage][resource type][purpose][repository/feature code].

The stage is the environment the resource is currently serving (Dev, SIT, Prod).

The resource type is the Azure resource that will primarily be housed in the Resource Group (AppService, Container, Azure Functions etc.)

The purpose, is the name of the project/purpose for Azure resources being provisioned e.g. MainCompanyWebsite, DataMigration, OnPremiseMigration etc.

The repository/feature code is a unique code that refers to a location where artefacts/documentation is stored that elaborate further on the resources in the Resource Group. These can be technical specifications, User Stories, Architecture diagrams. If there is ever doubt about a particular Resource Group, it should be possible to read the artefacts and understand why a resource was provisioned.

The list of Resource Groups below illustrate a collection of resources neatly packed into groups for a single purpose – to deliver the company website: ‘MainCompanySite’.

DEV01-AppService-MainCompanySite–1010
DEV01-AzContainer-MainCompanySite–1020
DEV01-AzFunctions-MainCompanySite–1030
PROD-SQL-MainCompanySite –1040

With the above, system in place, if a need arose where data needed to be extracted from the PROD-SQL-MainCompanySite –1040 Resource Group, a new Resource Group containing Azure Data Factory could be easily created:

DEV02-AzDataFactory-MainCompanySite –1050.

There is a variation to the above. For larger organisations that have multiple departments, it’s easier to identify a Resource Group by placing the department name at the front:

DataTeam–PROD-SQL-MainCompanySite –1040

Azure Resources

Just like Resource Groups, resources should also be named appropriately.

A SQL Server resource that contains both the Logical Server and the Database might be named as follows:

PROD-SQLLogical-MainCompanySite –1041
PROD-SQLDB-MainCompanySite –1042

Notice that both the resource types have been updated to help with easy identification. Secondly, the code has been incremented by 1. Adding the small increment means that it’s easier to identify that it belongs to a particular Resource Group designed for a single purpose.

Note that sometimes Azure will create resources for you with random names that do not make much sense. Use Tags to deal with this.

Tags

Tags are incredibly useful for managing resources. You have complete control over tags and how and when a resource is tagged.

Tags are designed as Key/Value pairs. Some useful ways to use tags:

Environment: Prod
Type: AzFunction
Code: 892123

In the above, you can easily tell that a particular resource has been promoted to Production and is an Azure Function.

Adding a code as a tag really helps when you want to track down a particular expense in Azure. For example:

In the picture below, I can see that Azure Storage has cost me £31.47. However as I have many storage resources, I can’t tell which Storage resource is costing me the most.

When I filter using Tags, I can clearly see that code 5372 is the resource, from a list of Storage resources that is costing me the most. In this case I was able to lookup the code in the architecture repository and identify that this is Blob storage resource that I used as an experimental Proof-of-concept.

That’s all you really need to do to manage Azure resources. You can of course take it a step further and have separation of subscriptions through Management Groups and have Tag enforcement enabled as a policy.