Choosing proper names for Azure resources is a crucial aspect of maintaining an organized and manageable cloud environment. A well-thought-out naming convention simplifies resource identification, reduces confusion, and enhances collaboration among teams. In this post I’m going to share 5 tips for good resource naming.
1. Defining Your Naming Strategy
Defining a solid naming strategy is a crucial step in creating an organized and manageable Azure environment. A well-defined naming strategy provides structure, consistency, and clarity to your resource names, making it easier for teams to identify, understand, and work with different resources. Usually the naming strategy contains rules for naming resources, but there are other aspects that you should consider also.
- Onboarding. How new comers are aware of naming convention and how they find it.
- Scope. Do we have naming convention for subscriptions, resource groups, resources, configuration settings etc.
- Security. Are you allowed to use client names or app names in naming? Is ubuntu2104build1234 a good name for server?
- Separator. Some Azure resources do not allow hyphens in their name, so be prepared for that also.
2. Components of an Effective Naming Convention
A good naming convention ensures consistency, clarity, and manageability across your resources, making it easier to identify and understand the purpose of each resource. Hyphens and separators makes the name easier to read to reduces possibility of misreading the resource name.
- Prefix: Start with a clear and meaningful prefix that represents the application, project, department, or environment the resource belongs to. This helps group related resources together and provides context. For example:
- MyCoolCrm-
- CustomerNotification-
- Separator: Use a consistent separator to distinguish between the prefix and the descriptive part of the name. Common separators include hyphens (-) and underscores (_). Keep in mind that not all resouces support the separator.
- Resource Type: Include an abbreviation or indicative term that identifies the type of resource. This makes it easy to understand the purpose of the resource at a glance. Keep list of used abbreviation, so that everyone uses same terms (sql, not sqldb or sqldatabase etc.) For example:
- MyCoolCrm-vm: Virtual Machine
- CustomerNotification-sql: SQL Database
- CustomerNotification-vnet: Virtual Network
- Environment: Indicate the environment the resource is intended for. This could be “dev” for development, “prod” for production, “test” for testing, etc. This prevents confusion when working with multiple environments.
- Instance Number: For resources that can have multiple instances, like virtual machines or application instances, include a numerical identifier or even better add role description in the name. This helps distinguish between different instances of the same resource type. For example:
- MyCoolCrm-vm1
- MyCoolCrm-vm-LoadBalancer
- CustomerNotification-app1
- CustomerNotification-app-WebServer
- Region: If your resources are spread across different regions, you might consider adding a region identifier to your naming convention. This is particularly useful in multi-region deployments.
- Special Characters and Capitalization: Keep the naming convention consistent with regards to the use of capital letters, numbers, and special characters. Stick to a predictable pattern that is easy to read and remember. I prefer separating multiple words by capitalized casing and otherwise use lowercase names.
- Length: Keep names reasonably short while providing enough information to understand the resource’s purpose.
So the final name can be something like MyCoolCrm-vm-prod or vm-MyCoolCrm-prod-westeu. If all your resources are in the same region, then adding the westeu does not make any sense. If you work in a multi-customer environment, then you might want to consider adding customer name/tag into the name. If you prefer all lowercase naming, then the full name could be something like contoso-mycoolcrm-vm-prod-westeu. The order of the component is not that crucial, but of course it affects in which order the Azure Portal is showing the resources by default.
3. Common Naming Mistakes
Most common naming mistake is of course, that naming convention has been ignored or there is a typo in the resource name. Some resources supports renaming, but not all. If you want to keep your environment perfectly clean, then you might need to recreate the wrongly named resources.
Another common mistake is to use company name in naming. I have seen multiple companies which has been acquired by other company and then the new management is not happy about having the old name everywhere in Azure. So my advice here is to NOT use company name in resource names.
4. Review and Maintenance
Don’t let your cool naming strategy rotten over time. You need to maintain it like everything else. Review the rules over time, add new resource type names and keep your documentation up-to-date. Usually the naming strategy does not need intense maintenance like monthly meetings, but I recommend that you spent at least one hour in half a year to check how the naming convention is keeping up.
5. Enforce Naming Conventions
If you work in a bigger Azure environment, you might want to setup naming policies. When user creates a new resource, the naming policy will automatically check, that naming follows the defined naming strategy. If it detects any violations it will prevent the resource creation. Microsoft has a good documentation about this feature and I recommend you to check it out.
Only problem with policies is that they require more work to upkeep (than just a wikipage) and you always need to define them, when a new resource type comes available.
Summary
Having a good naming convention is a must in bigger Azure environments. It makes easier to find correct resources and reduces the possibility of misreading and misunderstanding of resources. You don’t want that summer trainee to delete your production database, because it is not wisely named. So have a clear naming convention and remember to tell it for new employees.
If you work in a bigger Azure environment (lets say over 500 resources), then you might want to consider adding the naming policy to ensure that resource names follows the naming convention.
If you don’t have naming convention yet, you can start by looking the Microsoft documentation of defining your naming convention.