Planning Vnet naming

All Azure resources have a name that must be unique within a scope. The scope is different for each resource type. When creating a Vnet, its name must be unique within the scope of the resource group. This means that it is possible to have two Vnets in your Azure subscription with the same name as long as they don’t belong to the same resource group! This can be useful in a design that involves having the same Vnet resource name for both development and production environments, as shown in Figure 1.2.

Figure 1.2 – Vnet names must be unique for the resource group scope

Even though it is possible to have duplicate names within a subscription, it is not a recommended practice as it could later lead to confusion when investigating security incidents using logging information (we will cover network logging and monitoring later in this book). When investigating security incidents, it helps to be able to quickly identify affected resources and having a unique resource naming strategy for your Vnets helps with this.

Regarding naming best practices, it is best to define a naming convention as early as possible. This convention should be communicated to the teams with permission to create network resources in Azure, and preferably, the naming convention should be enforced using tools such as Azure Policy. To define a good naming strategy, consider these recommendations:

• Review resource name restrictions for the Vnet and other network resources in Azure. For example, a Vnet name can have up to 64 characters made up of alphanumerics, underscores, periods, and hyphens. Your naming convention should take this into consideration. Information on Vnet naming restrictions can be found at https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/resource-name-rules#microsoftnetwork.
• Consider including information about the following – resource type, resource location, deployment environment, and workload type in your naming convention. For example, a Vnet for production web services workloads in the East US region might be named prod-eastus-webservices-Vnet (Figure 1.3).

Figure 1.3 – Sample Vnet naming convention

For more thoughts on naming conventions, please refer to this document: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-naming.