My Take on Azure Naming Conventions (And Why I Tweaked Microsoft's)

Let's be honest, naming things in Azure is harder than it should be. And once you've picked a name, you're pretty much stuck with it. After a lot of trial and error, I’ve landed on a naming convention that’s simpler, scalable, and one that actually works in real-world environments. I briefly touched on this in my Azure Landing Zone series, but this time I want to go deeper and break down how I approach naming in Azure.

Microsoft highlights the importance of naming in their Cloud Adoption Framework. Here's their official guidance:
Define your naming convention - Cloud Adoption Framework | Microsoft Learn

They suggest a structured format like this:

<resource-type>-<workload/app>-<env>-<region>-<instance>

That’s a decent foundation. It's clean and complete. But in practice, it can feel too rigid and sometimes adds complexity you don’t need.

After working on a wide range of environments, I came up with something a bit leaner and more flexible. Here’s what I use, and why I changed it.

TL;DR:  

Microsoft’s convention is good, but often a bit too much. I stripped out some fields, added company and purpose context, and ended up with something easier to manage and scale.

My Naming Convention

The format I typically use:

<resource-type-prefix>-<company-prefix>-<application>-<env>

Example:

vnet-bolet-blog-dev

Clean and to the point. It keeps things organized without turning names into puzzles.

In some cases, I’ll add an extra piece to indicate the function or role of the resource. This is especially useful when there are several resources of the same type.

<resource-type-prefix>-<company-prefix>-<application>-<function/purpose>-<env>

Examples:

snet-bolet-blog-web-dev  
snet-bolet-blog-api-dev  
snet-bolet-blog-pe-dev

That little function label makes a big difference when you're deep in Azure, trying to find your way.

Why I Decided to Deviate from Microsoft's format

Microsoft naming convention is a fair starting point. It’s structured, consistent, and great for extremely large-scale environments . But in practice, it often feels too rigid. It includes a lot of fields like <region> and <instance> that may not be needed early on, which can lead to long, hard-to-read names that slow teams down.

I simplified the format by:

• Removing fields that aren’t needed in most day-to-day scenarios
• Adding a company prefix to ensure global uniqueness
• Including purpose-driven labels to make roles more obvious

The result is a cleaner, more flexible naming approach that still supports scale but stays easier to read and maintain.

I Add the Company Prefix

Some resources need globally unique names. Something like app-blog-dev might already exist somewhere else. But app-bolet-blog-dev? That’s far less likely to collide. Plus, it instantly tells you who owns it. Super helpful if you're managing multiple tenants or working with different customers.

I Use Purpose Labels When It Helps

In many environments, you’ll end up with several subnets, VMs, or gateways. Without a purpose label, you get names like:

snet-bolet-blog-dev-01  
snet-bolet-blog-dev-02

These don’t tell you much unless you dig deeper in the portal. What’s 01? A public subnet? Backend? No idea.

With purpose labels, it’s immediately clear:

snet-bolet-blog-web-dev  
snet-bolet-blog-api-dev  
snet-bolet-blog-pe-dev

This is especially useful for networking and compute, where roles matter. It helps avoid mistakes like attaching the wrong NSG, speeds up deployments, and makes life easier for new team members.

I Skip Region and Instance (Unless Needed)

Microsoft's default includes <region> and <instance>. And that’s fine. But in most projects I've worked on, things were either single-region or spread across distinct environments anyway. So I leave those parts out unless they actually serve a purpose.

When I do need them, I’ll include them like this:

vnet-bolet-blog-dev-weu  
vm-bolet-blog-dev-01

I treat them as optional, not mandatory.

Side-by-Side Comparison

Microsoft Style	My Style
<type>-<app>-<env>-<region>-<instance>	<type>-<company>-<app>-<env>
	<type>-<company>-<app>-<purpose>-<env>

Both are valid. I just trimmed mine down to better fit the day-to-day environments I’ve seen over the years.

When This Naming Convention Works Best

This simplified style is ideal when:

• You're working on small or mid-sized projects
• You use only one or a few regions
• You're dealing with multi-tenant environments
• You value readability and fast onboarding
• You're not under any strict compliance or naming policy constraints

If you're using things like Azure Policy or heavy automation, you can still adapt this convention to play nicely with those tools.

Common Naming Pitfalls I’ve Seen

These mistakes come up often:

• Generic or meaningless names
  Things like vnet1, webapp-prod, or rg-east tell you almost nothing. That adds friction fast.

• Putting environment first
  Starting with dev- or prod- might seem harmless, but it breaks consistency and makes filtering in the Azure portal a pain.

• No company or tenant prefix
  Seems fine until you run into a global name collision with a storage account or public IP.

• Overcomplicating too early
  Don’t bake in regions or instance numbers until you actually need them. Keep it simple. Grow into the complexity.

Making It DevOps Friendly

Even if you're keeping things clean and human-readable, it's smart to think about automation. A few quick tips:

• Use lowercase letters and dashes. Avoid underscores, dots, and camelCase.
• For Azure Resources that only supports alphanumeric characters like storage accounts I use a 0 instead of a dash.
• Stay within Azure’s character limits. For example, storage accounts cap at 24 characters.
• Test your names in Bicep, ARM templates, or Terraform to make sure they won’t break anything.
• Keep your naming consistent across scripts and pipelines. If your rules vary by environment, write them down.

Your naming convention should work for both humans and automation.

Tradeoffs to Consider

While I prefer a simpler approach, it’s not always the right fit for every organization.

There are good reasons to use <region> and <instance>:

• Multi-region infrastructure? Then region tags help you stay sane.
• Auto-scaling or redundant resources? Use instance suffixes like -01, -02.
• Strictly governed environments? You might have to follow policy-based rules. That’s okay too.

I treat those fields as optional but available when needed. Don't include them just because you saw them in a template. Use them when your architecture actually benefits from them.

Bottom line:
Design your naming convention to fit your environment. Not the other way around.

My Final Thoughts

Naming is hard. But the best naming system is the one your team actually uses and understands every single day.

What I’m sharing here isn’t revolutionary. It’s just a practical take on something that often gets too bloated too fast. You don’t have to follow Microsoft’s template word for word. You can stay aligned with best practices and still simplify where it makes sense.

If the default format feels too heavy, try scaling it back. You can always add more complexity when your architecture needs it.

What’s your take?
I’d love to hear how others are approaching Azure naming. Message me or drop a comment, I’m always learning from the way different teams handle this.

Example

Here is an export of a sample Azure environment I have created to show a bit more of the names being used and how the <function/purpose> comes into play.

A bicep export from an Azure Resource Group showing a naming convention

** Azure Resource Prefix Abbreviation Cheat Sheet** I like to use The Azure Periodic Table to find abbreviations for Azure resources, but usefull page Microsofts own documentation Abbreviation recommendations for Azure resources - Cloud Adoption Framework | Microsoft Learn