Naming and tagging

Posted by Nikos Tsirmirakis on

With a speed of creating destroying and changing objects in agile environments naming and tagging is extremely important. If it is done right you will have all the information you require available straight away if not you will spend hours looking for it over and over again. There are many naming conventions and policies, the one described below is amalgamate of all good things which I have come across in multiple naming policies and adjustments which works better for me. Please note that there is no single policy fitting all environments but there is a policy which will work well for you. You can find sample implementation in the GitHub repository available here.


In the Windows ecosystem (AD domain) hostnames are limited to 15 characters and within this space, we would like to encapsulate as many information possible including:

  • location (uks, UK South)

    Location in the on-premises world is referring to datacenter or site where the hosts are located, but now with cloud deployment, it rather refers to the region (in Azure UK South). You can either use short names like uks (UK South) or weu (West Europe), alternatively, we can code each region to a single letter like a for UK South and b for West Europe.

  • environment type (prd, dev)

Environment name

For environment names, you can use 3 letter shortcuts plus environment number in case you have more than one environment of each type prd1 (production), tst1 (test), dev1 (development) depending on how many types you have in your environment. Alternatively, you can also code it to a single letter like d1 for development environment 1. For production servers, you can use a number to differentiate between tiers like p1 - mission-critical (tier 1), p2 - regular servers (tier 2).

  • application/project (www, fin)

    The project name is describing a group of servers required for an application ie all finance application servers ie fin.

  • core application (iis, sql, app)

    In cloud deployment you can assign a specific task to each vm/container like web server or database server, it is indicating what is the main application running on the server.

  • server number

    A number of the server of particular type app1, app2.


The first sql server for the financial system in a first development environment located in UK South region.
The third web (IIS) server for the financial system in a tier 2 production environment located in UK West region.

Object names

With Azure object names, we have more characters to play with and it allows us to use longer and more descriptive names. To avoid reinventing the weel we will use Microsoft recommendations as a guide and follow abbreviation suggested for prefixes here.

We will use environment name as a core (a-d1-fin) for resources so we can easily identify it in Azure and ass suffix with a resource type.

  • Resource group: a-d1-fin-rg
  • Virtual Machine: a-d1-fin-sql1-vm
  • Network interface: a-d1-fin-sql1-nic1
  • Subnet: a-d1-fin-s1-snet

You can create multiple objects of the same type and to differentiate we have to either extend name with additional information like in subnet name or add an index on the end like we have done it with network interface in the example above.


Tags are a very flexible and useful way of storing information about the objects, it can be used for reporting and as an extension of your service catalogue. In automated deployment, we can generate it automatically. One of the biggest advantages of the tags is that you can change it during the object life cycle without destroying and recreating it. It is very often used as a grouping parameter for reporting. Sample implementation focusing on tags can be found in the GitHub repository available here.

Basic tags

Basic tags are covering everything we have include in the name with much longer description and all other general information from the service catalogue.

  • Location: UK South
  • Environment: Development 1
  • Project: Finance
  • Tier: 4

Operation tags

  • Support owner: team/person to contact when the application failure is detected (email), who is supporting the application
  • Business owner: team/person to notice when the application failure is detected or maintenance window is required (email), who is using the application
  • Development owner: team/person to contact regarding bugs (email), who is developing the application

Build tags

  • Build version: 20191014.38
  • First apply: 2019-10-15T12:00:00Z
  • Last apply: 2019-10-15T12:00:00Z
  • Build with terraform: yes

Good practices

Avoid leading zeros (a-d1-fin-app01), if you are generating servers automatically it is a much more complicated implementation and “waste” of extra character without tangible benefit.

Characters to use

For hostnames and object names I would recommend to use small letters (a-z) digits (0-9) and minus sign (-) only. Capital letters are not forbidden however it will save a lot of confusion if written with some types of fonts where small l and capital I look the same.

The more complicated environment and more team members are managing it the more you will appreciate good naming and tagging strategy, it can be your best friend or the biggest nightmare. Every environment is different and will require a tailored naming strategy incorporating business logic. The most important is the consistency to achieve tangible benefits of implementing it. To avoid any confusion, it should be written and placed in the Wiki or any other system which you can quickly refer to.

I hope the policy described above will give you some ideas about how to create or improve yours.