Profile picture of Liam Moat

Liam Moat

Premier Field Engineer.


Naming convention for Azure Resources January, 2019

For a long time, I have wanted to document my naming conventions for Azure Resources - this post does just that. A consistent naming convention makes resources easier to find and easier to understand. It can provide structure amongst the chaos of potentially hundreds (if not, thousands) of resources deployed across different regions and environments. A consistent naming standard is the first pillar of the Azure enterprise scaffold and a best practice for cloud applications.

Remember that it’s difficult to rename resources in Azure, so a few minutes now will save you trouble later.

Important Note: The naming convention that I use, is unique to me. It provides me with the information that I need and organises resources in such a way that makes sense to me. This means it might not work for you. It may, however, be a great starting point.

Consider naming rules and restrictions:

Each resource or service type in Azure enforces a set of naming restrictions. Before defining your own standards for naming resources, I strongly recommend you take a look at the Naming rules and restrictions for Azure cloud services.

Common guidelines

This convention provides a naming standard for subscriptions, resource groups and resources. The following rules are shared across all three:




Organisation Portfolio Product Line Environment Name
Contoso Human Resources N/A Development con-hr-sub-dev
Contoso Human Resources N/A Production con-hr-sub-prd
Contoso Information Technology Internal Apps Development con-it-internal-sub-dev
Fabrikam Core Services N/A N/A fab-core-sub

Resource Group



Organisation Product Environment Region Name
Contoso Payroll System Development North Europe con-payr-rg-dev-n-eu
Contoso Payroll System Production North Europe con-payr-rg-prd-n-eu
Contoso Payroll System Production West Europe con-payr-rg-prd-w-eu
Fabrikam Expenses Service Production UK South fab-exp-rg-prd
Fabrikam Infrastructure N/A UK South fab-infra-rg




Organisation Product Resource Identifier Environment Name
Contoso Payroll System App Service Plan N/A Development con-payr-asp-dev
Contoso Payroll System App Service Plan Internal Development con-payr-asp-int-dev
Contoso Payroll System Web App Service N/A Development con-payr-web-dev
Fabrikam Expenses Service Azure SQL Server N/A Production fab-exp-sqlsrv-prd
Fabrikam Expenses Service Azure SQL DB N/A Production fab-exp-sqldb-prd
Fabrikam Infrastructure Virtual Network N/A N/A fab-infra-vnet
Fabrikam Infrastructure Storage Account N/A N/A fabinfrastor

Full example

Let’s take a look at a full example, including a subscription, resource group and a selection of resources - deployed into both development and production.

In this example, we will omit the environment identifier for production across all names:

Multiple instances

The naming convention so far assumes a single instance of each resource group or resource will be deployed into each environment. For a number of reasons, this isn’t always the case. For example, you may have multiple production instances deployed across multiple regions. In this scenario, we can use the <env> variable for the resource name and replace it with <instance>.

<instance> could be an incrementing number (e.g. 01, 02, 03) or we could use the uniqueString function to generate a unique name for each resource.


As you start to define your own naming convention, I encourage you to review and adopt where possible Microsoft’s Patterns and Practices guidance. In addition to a well defined naming convention, consider how to organize resources with tags. Resource tags give resources metadata to logically organize them into a taxonomy - and can be used to capture all the information that doesn’t make sense to store in the name.

If you decide to use this convention let me know how you get on in the comments below. Please let me know if you have any feedback too!

Thanks to Paul for reviewing this content pre-publish!

Import JSON files with TypeScript January, 2019

TypeScript 2.9, which was released in May 2018, introduced a new compiler option called resolveJsonModule. This allows you to import .json files and interpret the contents as a well-typed JavaScript Object - which means the compiler will recognise types like string, number and boolean.

Take the example below. This file is called config.json. It has two properties isProduction and logLevel with type boolean and string respectively.

    "isProduction": false,
    "logLevel": "info"

With resolveJsonModule enabled, you can import this file like any other module:

import * as config from './config.json';
config.isProduction === true; // Okay

config.logLevel === 2; // Error - Can't compare a `string` and `number`

By default, this feature is disabled. You can enable it in your project’s tsconfig.json file:

    "compilerOptions": {
        "module": "commonjs",
        "resolveJsonModule": true,
        "esModuleInterop": true,
        "outDir": "lib"
    "include": ["src"]

Alternatively, you can enable it when running tsc:

tsc --resolveJsonModule 

You can also selectively import individual properties from your .json file:

import {isProduction} from './config.json';
isProduction === true; // Okay

Take a look at TypeScipt 2.9 announcement to see what other new features came with TypeScript 2.9.

My Annual Retrospective - 2018 in Review December, 2018

I recently read Jeremy Likness’s 2018 in Review. I was drawn to the section titled “Goals Retrospective.” As an agile advocate, I was inspired by the idea of an annual retrospective - an opportunity to reflect on the previous year. It felt like a simple way to apply “Inspect and Adapt” to my goals, aspirations and objectives (both professional and personal). Jeremy also shared his major goals for 2019. Six measurable and achievable objectives that ensure both personal and professional development.

Push a Docker image to Azure Container Registry from VSTS May, 2018

Azure Container Registry (ACR) is a fully managed private Docker registry in Azure. In this post, I will show you how to create a continuous integration pipeline in Visual Studio Team Services to build a Docker image and push it to Azure Container Registry.

Create a Visual Studio solution using the dotnet cli March, 2018

The .NET Core command-line interface (CLI) is a cross-platform toolchain for developing .NET applications. This post will explore creating a Visual Studio solution using the CLI without needing to rely on Visual Studio.

Subscribe here.