Azure Naming Convention

AzureNamingConvention.md

Key Principles

1. Assuming we are doing ARM, everything in Azure is a typed reference, its impossible to create a conflict by naming two different typed items the same, e.g. a 'test' vritual machine and a 'test' storage account are different resources and are always referenced separately by their fully qualified type names
2. Tags are where metadata about an object should be. THe objects name itself should be short or random, but the tags are where the real parsing/filtering/search need to occur by department, etc.
3. A name in Azure is typically immutable, so it should not contain mutable properties, e.g. server environments can change, regions can change, etc.
4. DNS conflicts in the customer DNS zone are a potential source however DNS is mutable and aliases can be created, and there are very few object types that share Azure dns namespaces. The original alias remains clean.
5. While multiregion deployments are common, most
6. An organization prefix is essential to minimize conflicts after organizational mergers. It should be brief, usually not more than 3 characters.
7. Variable length fields are fine. Since we are moving most naming items to tags, more dashes can be introduced to separate fields.
8. Sortability of names is a key factor in a naming convention, wherever tags cannot be used. For instance sequential numbering of systems.
9. Implicit policies allow for brevity and portability. E.g. if an organization specified US West as their "primary" region, the region specifier can be left off these systems. If the organization later chooses a new primary region, they can move these resources without destroy/recreating them where possible with azure migration tools.
10. All characters should be uppercase to avoid potential casing issues.
11. Underscores should not be used as they are not valid in DNS hostnames.

Typical Convention (brackets indicate fields, braces indicate)

[OrganizationPrefix][Category]-[ID]-{Region}-{EnvironmentLetter}

1. OrganizationPrefix - Typically a two or three letter prefix designating the organization, e.g. CON for Contoso, MS for Microsoft, etc. Because the organization prefix is fixed length it does not need a dash to distinguish it.
2. Category - Freeform field indicating the device role, e.g. APP, SRV, FUNCTION. Org may have a fixed defined list of identifiers or allow them to be defined at will, this depends on the org.
3. ID - The ID part is a suffix of the identifier that is used to uniquely identify the system. It can be either a numeric sort (01, 02, 03) or a random identifier typically used in IaC deployments (fdac, xyxx).
4. Region - The region is an identifier of the location of the resource, only used if the resource category + ID is not unique across regions. Region names must have at least two letters to identify them to distinguish them from environments.
5. Environment - A single letter distinguisher of different environments. If this is not present, production is implied unless the ENVIRONMENT tag specifies otherwise. Examples would be T for test, D for dev, U for UAT, S for staging, etc.

Examples

1. MSAPP-01 - App server in primary region deployed manually. Would also have tags ENVIRONMENT:PRODUCTION, DEPARTMENT:FINANCE, etc.
2. MSAPP-01-U - Version of MSAPP01 in primary region in the UAT environment deployed manually. Would also have tags ENVIRONMENT:UAT, DEPARTMENT:FINANCE, etc.
3. MSAPP-01-UW2-T - App server in US West 2 in test environment deployed manually. Would also have tag ENVIRONMENT:TEST, etc.
4. MSAPP-U5A2 - App server in primary region deployed via IaC
5. MSMYAPPNAME-A2Xf - Function app in default region, deployed via IaC. Would also have tags ENVIRONMENT:PRODUCTION, DEPARTMENT:FINANCE, etc.