Many organizations that adopt cloud solutions in their operation do this rather evolutionarily than all at once. As a result, proper governance of Azure subscriptions and services is a commonly underrated aspect of working with cloud services at the start of such transformations. At some point, an organization might end up with Azure subscriptions that contain a bunch of resources named in a completely different manner with no informative tags about resource ownership, their purpose, links to technical documentation, etc. To bring some order in this mess, people usually try to come up with a naming convention for Azure services they use and follow it to ensure a standard user experience across the teams. This approach helps to some extent, but when there are many teams that create Azure resources, keeping all of them compliant with your naming standard becomes a real challenge.

Using Azure Policy for naming convention

One of the tools that can help you with enforcing naming conventions for Azure resources in your subscriptions is Azure Policy. Their mechanics allow you to create controls that will be used to validate existing and new resources for compliance.

Regarding the naming convention, you can validate resource names against specific naming patterns and forbid the creation of resources which names don’t satisfy pattern requirements. When using this kind of policy, there are a few things to remember.

Firstly, policies for naming conventions are no different from any other Azure policies: they can be assigned at the management group level, subscription level and individual resource groups. This is especially important when testing your policy effects in your target environments – you can assign your naming policies to a test resource group and check their behaviors on a limited scope.

Secondly, if you are targeting your naming policies to the subscriptions that contain already existing but non-compliant resources, you might want to put that resources (resource groups to be more precise) into excluded scopes in the policy assignments. If you don’t exclude those resources from your policy assignments, the “deny” policy effect will prevent you from modifying them as on each change the whole resource definition is processed and validated by Azure Resource Manager against all active policy rules. In some cases, depending on your requirements, you also may choose a looser approach first and only audit policy violations instead of a strict “deny” policy effect.

Thirdly, in a very diverse organization with many independent teams with a high level of freedom to build and operate their products and services, you can create different naming policies for different teams and limit their assignment to their specific subscriptions or resource groups. Keep in mind that naming conventions shouldn’t be enforced for the sake of policies themselves but to improve user experience and help teams to perform better.

Azure Policy support for Regex

If your policy for resource naming is quite simple, the existing ‘like/notLike’ and ‘match/notMatch’ policy conditions should be enough to do the job. However, in more complex infrastructures you might want your names to contain information about resource type, environment, version or another unique identifier, etc., so your resource name looks like the following:

<product name>-<type of resource abbreviated>[-<environment>][-<identifier>]

For those of you who are familiar with regular expressions aka regex, it might be the right place to use them for naming pattern validation. Unfortunately, Azure policy currently doesn’t support regex which makes our work harder. For instance, to implement the mentioned sample pattern, you must put a lot of copy-pasted blocks in your policy definition and it still will be limited only to that specific list of match conditions. So, go to feedback.azure.com, vote for that feature, and hope that Microsoft releases it soon. Until that time, a kludge with all possible naming combinations is your only option.

Using the same Azure Policy for different resource types

Remember, that there are a lot of different Azure resource types? Now, imagine that you have to define naming policies at least for a few dozen of them in your environment. Sounds like a ton shit of work, right? So, how to make it easier?

As you might already know, Azure policy definitions support input parameters, and you can use policy functions to reference them. So, why not provide Azure resource type as an input parameter during policy assignment? There is even a corresponding ‘strongType’ metadata property – resourceTypes, to validate inputs against existing resource types in your subscription:

Now, you can reference these parameters in a policy rule:

Having such a policy definition in hand, you can create multiple assignments for the same policy with different inputs: basically, for different resource types.

Of course, you might consider defining separate policies for resource types that don’t allow hyphens in their names, such as storage accounts, container registries, etc. So, take into account the existing naming rules and restrictions for Azure resources:  the length of resource names and valid characters vary for different resource types. So, pay attention to that.

Although it might be helpful to follow the best practices for resource naming when designing your naming convention, you should understand that naming policies as a part of your governance framework will have to evolve with time to satisfy changing conditions. So, don’t try to make them perfect. The chances are high that you might want to reconsider them in a while. Likely, with Azure services, it’s much easier to spin up new copies of your environments and migrate data to them than it used to be with physical servers.

What naming convention do you prefer for your Azure resources? How do you ensure that your resources are compliant with it?

P.S. You can find sample Azure policies for naming defined in ARM templates in the following repository on GitHub.