Azure Naming Convention: The Kubernetes Approach

Almost all of my customers spend days and weeks thinking about and creating naming conventions for their Azure resources. However, it usually takes a very short time until these naming conventions become inconsistent, because some names are not suitable for certain resource types or some resource types are not considered in the naming convention at all. It often takes a while until they notice that a user-friendly naming convention does not make any sense in a cattle environment.

Instead of using user-friendly resource names I want to show you how to use random strings with very less user-friendly information for your resource names, and resource tags for a user-friendly display name and other kind of information. The idea is based on how Kubernetes creates pod names.

Let me show you the pros and cons of random names compared to user-friendly names.

User-Friendly Names



Random Names



How does it look like?

Instead of thinking about fancy naming constructs, just think about the most suitable term which describes your service the best and concatenate that term with a random string, until you have reached 16 characters in total (or more, depending on the resource type limitations). The rest of the information should be added as resource tags, such as a user-friendly display name, a cost center etc.

The name now looks a bit like a Kubernetes pod name.

So why don’t we just use random strings only? The only reason for a bit of human-readable information is, to better identity resources in dropdown menus and other parts of UIs, such as in the Azure Portal, Azure DevOps, Datadog etc.

Random String Naming Convention on Azure

The above resources are entirely deployed through Terraform, which makes the generation of random strings even easier, thanks to the built-in Terraform uuidv5, sha256, and substr functions.

locals {
  name = "myapp"
  uuid = "9ee29d93-35c8-4447-84f7-7d929e81fbd0"

resource "azurerm_resource_group" "rg" {
  name     = substr("${}-${sha256(uuidv5(local.uuid, "rg"))}", 0, 15)
  location = "West Europe"

  tags = {
    displayName = "My Demo App"
    costCenter  = "1000"
    tfState     = "demo-app.json"

🆕 UPDATE: Instead of using the displayName tag, you could also use the hidden-title tag, which shows the display name in parentheses after each resource name in the portal and is also indexed in the Azure Portals search function. hidden-title tag


Why don’t you just use the naming convention from the Microsoft Cloud Adoption Framework (CAF)?

The naming best practices from the cloud adoption framework are guidelines (like how to abbreviate a certain resource type etc.), rather than a ready to use naming convention. Several resource types are not even considered in the cloud adoption framework (e.g. subnet names, NSG rule names, VNet peering names and many more). From my experience it’s quiet hard to come up with a meaningful and (more importantly) consistent naming convention which also fits your organizational structures if you stick entirely to the cloud adoption framework.