Deep Diving into the Azure Naming Tool
RSS feed
Date: Dec 02, 2022
Tags: .net azure
Share: Share on Twitter
NOTE: Technology changes fast, so some of the images and/or code in this article maybe be out of date. Feel free to leave a comment if you notice something that needs updating.
The Azure Naming Tool is the evolution of a solution to a common problem when working with Azure. For anyone managing Azure resources, naming is key to understanding what a service is, where it’s at, and (most importantly) who it belongs to. The Azure Naming Tool was created to help administrators define and manage their naming conventions, while providing a simple interface for users to generate a compliant name. In this article, I’m going to take you on a very deep dive of the architecture and processes within the tool.


Originally created as a PowerShell utility, the Azure Naming Tool (“ANT” from here on out) was designed to provide a way for users to generate Azure resource names that matched their company’s naming convention. ANT V1 was a great success, allowing Azure customers a way to define their naming structure, set optional/excluded properties, and generate a simple to use UI for end-users to self-service their naming needs. V1 was adopted into the Microsoft Cloud Adoption Framework tool list and became a part of many organizations’ toolsets.

In order to improve performance and adoption, the ANT was completely re-written into a modern framework/architecture, providing a simplified user interface, a robust API for extensibility, and customizable deployment options. The project is 100% open-source and available to everyone. Due to the complexity of tool and how it functions, I wanted to give an in-depth look at the technology and architecture behind the tool.

Azure Naming Tool on GitHub

The Azure Naming Tool is a web application that allows you to generate unique names for Azure resources. It is a free, open-source tool that is available on GitHub.


The ANT has a very specific architecture, designed to provide the required functionality, while limiting the number of dependencies. The tool is 100% self-contained, meaning it can run anywhere, even without internet connectivity. This architecture was chosen to remove the barrier for entry for adoption, allowing users on any platform to use the tool.  

The ANT consists of a few key components:

.NET 6.0 Blazor Server 

The ANT is a .NET 6.0 Blazor Server application, providing a fluid and simple UI for all functionality. The site relies heavily on modals and toasts to interact with components, update configurations, and provide user feedback. The site caches data when possible, improving performance and responsiveness. Configuration and name generation activities are logged to the file system, as well.


You can find more details about the UI in the Overview documentation.

Helpers, Services, & Pages

The ANT heavily uses a helpers and services pattern for the code. Services provide functionality to work with components (standard and custom components), as well as name generation, logging, admin activities, and importing/exporting. This allows the tool to have a single location for functionality and simplifies development & integration. Additionally, all interaction with the JSON configuration files is done via the services classes.

Multiple helper classes exist for file system processes, logging, service interaction, and messaging. Additional helpers may be added in the future. All UI functionality is contained in pages, along with shared modals and layouts.


The tool leverages a robust API for all functionality. This allows every aspect of the tool to be integrated with other systems easily. All API calls require an API Key (configurable in the Admin utility) to execute. All API calls leverage the services and helpers classes detailed above.


You can find more details about the API documentation.

JSON configuration files

The ANT was designed to be completely stand-alone, meaning there is no backend database requirement. To store persistent data, the tool uses several JSON configuration files on the files system. The files include

  • appsettings.json
  • Component configurations
  • Log files
  • File version configurations

The site requires all configuration files to be stored in a persistent location. When running as a container, a volume must be mounted to ensure configuration are not lost if the container is deleted/restored.

Docker file (for container support)

The ANT was designed to be hosted in any environment, depending on the user’s needs. The included Docker file allows the tool to be run as a container in Docker Desktop, AKS, or an Azure Container App service. 


You can find more details about running the tool as a container in the Installation documentation.

Configuration Files

The ANT uses several configuration files to function. Many of these files are customizable by the user, while some are controlled by the ANT repository. All default configuration files are stored in the /repository folder. All customizable files are stored in the /settings folder. When the site is first launched, all files in /repository folder are copied to the /settings folder. All changes are then recorded in the /settings folder. 

Here is the process:

  • Site is launched.
  • Site checks for/adds a /settings folder. 
  • The site loops through all files in the /repository folder and copies the file to the /settings file if it does not exist. Any existing files in the /settings are skipped. This ensures the site configuration is retained. 
  • All future configuration updates are stored in the /settings version of the files.
  • Selecting Reset for a component will copy the /repository version of the file to the /settings folder. 
  • Selecting Refresh for a component will download the latest version of the file from the Azure Naming Tool GitHub repository. This will update the /repository and /setting versions of the file. 

Load Process

The ANT’s load process will confirm all configuration and security files are present. This ensures the site has all required components to function.

Here is the process:

  • Site is launched
  • Configuration files are checked. This ensures the /settings files are set.
  • Security is checked. This ensures SALT and API Keys are set.
  • Admin Password is checked. This ensures the admin password is set.

Security & Settings

The ANT has very specific security aspects that allow the tool to be run in any environment, while providing as much security as possible. Because of the lack of dependencies on 3rd party systems, all security must be contained within the app. With the project being open-source, this presents a unique challenge for keeping it secure. To get around this issue, the following process/concepts have been implemented.

Require Admin Password on launch

When first installed, the ANT will require an Admin password be set before any action can occur. This value is stored in the configuration files. The Admin utility allows for the password to be updated at any time. 

Encryption of passwords/keys

When installed, the ANT will generate a random SALT key that is stored in the appsettings.json file. After the password is set (or changed later), the entered value is encrypted using the SALT key. The same process is applied to the API Key. 

Admin utility

The ANT has a built-in Admin section for configuring the site and managing log files. In the current version, there is a single Admin password that enables this functionality. All other site activity does not require credentials and activity is logged anonymously.

Name Generation

The ANT uses resource type-specific configurations during the name generation process. This configuration includes invalid characters, length requirements, special character requirements, as well as a regular expression. The ANT component configuration is used to determine if the required components are present. This process applies to names generated via the UI, as well as the API.

When using the tool UI, a name is created using the user’s selected values on the Generate page. 

When using the API, the components are supplied in the JSON payload call to the /api/ResourceNamingRequests/RequestName endpoint.

The following details the process for when a generate name request is received:

  • Generate name request received.
  • Resource Type is checked. This ensures the correct resource type can be identified and the validation configuration data is found.
  • Delimiter is checked. This ensures the tool configuration is properly loaded.
  • Many resource types do not require a name to be generated. For these resources, a static value is returned.
  • All required components (based on the tool configuration) are checked. “Excluded” and “Optional” components are allowed.
  • The submitted name is validated using the selected resource type’s regex.
  • If the regex fails, the delimiter is removed, and the regex is validated again.
  • The min/max length of the name is validated.
  • Any invalid characters are checked.

Versions & Updates

The ANT uses semantic versioning to track updates to the tool. When the site is launched and the user is authenticated as the Admin, the tool will check the installed version number against the current version in the GitHub repo. If the version is out of date, a modal will be displayed to inform the user that an upgrade is available.


You can read more about the process in the Updating documentation.

Similarly, the resourcetypes.json and resourcelocations.json files are frequently updated with new types and Azure data centers. The Configuration page will display a message if the installed version of the files of the file is out of date with the current version hosted in GitHub. This process allows the ANT team to publish new resource type configurations without requiring the tool to be re-installed. 

Moving Forward

The Azure Naming Tool was designed to be as extendable and functional as possible. In order to accommodate that flexibility, several architecture aspects were implemented. I hope this article helps answer some of your technical questions regarding the architecture. The ANT team will continue to improve the tool and publish updates to the GitHub repository. All feedback is welcome, and feel free to submit a code change if you have a better idea for any part of the tool. Good luck!

Helpful Links