Default vs Custom VNets in Azure

What the default VNet looks like

When you create a resource like a virtual machine through the Azure portal and you don’t select an existing VNet, Azure creates one for you automatically. This is called the default VNet.

The default VNet typically uses the address space 10.0.0.0/16 and contains a single subnet called default with the range 10.0.0.0/24. Azure assigns it a generic name like myVNet or derives it from the VM name.

The default VNet is functional. Resources inside it can communicate with each other and reach the internet. For learning and quick experiments, it works fine. The problems start when you try to build something real on top of it.

Why the default VNet causes problems

The default VNet is built for convenience, not design. Several characteristics make it unsuitable for production:

Naming is inconsistent. Azure names the VNet after whatever you were creating when it got generated. You can end up with VNets named after VMs, which tells you nothing about the network’s purpose or region.

Address space conflicts. The default 10.0.0.0/16 is the most common choice everyone makes. If you later want to peer this VNet with another — or connect it to your on-premises network — there is a high chance of address overlap. Overlapping addresses cannot be peered.

No subnet segmentation. Everything lands in one default subnet. Web servers, databases, and management tools all share the same network segment. You cannot apply different security rules to different tiers without creating additional subnets.

No custom DNS. The default VNet uses Azure’s default DNS (168.63.129.16). If you have on-premises DNS servers or need split-horizon DNS, you need to configure that on a custom VNet.

Inspecting the default VNet with CLI

You can list all VNets in your subscription to see what has been auto-created:

az network vnet list --output table

This shows every VNet across all resource groups. Look for ones with generic names and a single default subnet. Show details on a specific one:

az network vnet show \
  --name myVNet \
  --resource-group myResourceGroup \
  --output json

List the subnets inside it:

az network vnet subnet list \
  --vnet-name myVNet \
  --resource-group myResourceGroup \
  --output table

Check if any resources are connected to the default subnet before you decide whether to keep or replace it:

az network vnet subnet show \
  --vnet-name myVNet \
  --resource-group myResourceGroup \
  --name default \
  --query "ipConfigurations" \
  --output table

Designing a custom VNet

A custom VNet starts with a deliberate plan. Before you run a single CLI command, answer these questions:

What environment is this for? Production, staging, and development should each have their own VNet. This ensures complete isolation.

What region? VNets are regional. Place the VNet in the same region as the resources that will use it.

What address space? Pick a range that does not conflict with other VNets you own or your on-premises network. If your on-premises uses 10.1.0.0/16, don’t use that range in Azure.

What subnets do you need? At minimum, consider a web tier subnet, an application tier subnet, a data tier subnet, and a management subnet.

Building a custom VNet step by step

Here is a complete example that creates a well-structured VNet for a three-tier application:

# Create a dedicated resource group
az group create \
  --name rg-prod-networking \
  --location eastus

# Create the VNet with a unique address space
az network vnet create \
  --name vnet-prod-eastus-001 \
  --resource-group rg-prod-networking \
  --location eastus \
  --address-prefixes 10.10.0.0/16

# Web tier subnet
az network vnet subnet create \
  --name snet-web \
  --resource-group rg-prod-networking \
  --vnet-name vnet-prod-eastus-001 \
  --address-prefixes 10.10.1.0/24

# Application tier subnet
az network vnet subnet create \
  --name snet-app \
  --resource-group rg-prod-networking \
  --vnet-name vnet-prod-eastus-001 \
  --address-prefixes 10.10.2.0/24

# Data tier subnet
az network vnet subnet create \
  --name snet-data \
  --resource-group rg-prod-networking \
  --vnet-name vnet-prod-eastus-001 \
  --address-prefixes 10.10.3.0/24

# Management subnet for jump servers and tools
az network vnet subnet create \
  --name snet-mgmt \
  --resource-group rg-prod-networking \
  --vnet-name vnet-prod-eastus-001 \
  --address-prefixes 10.10.4.0/24

Update the VNet to use a custom DNS server (for example, an on-premises DNS at 192.168.1.10):

az network vnet update \
  --name vnet-prod-eastus-001 \
  --resource-group rg-prod-networking \
  --dns-servers 192.168.1.10

Default vs custom: side by side

Moving from default to custom

If you already have resources running in a default VNet and you want to migrate them to a properly designed custom VNet, the process takes planning. Azure does not let you move a VM’s network interface from one VNet to another directly.

The standard approach is to deallocate the VM, capture its disk as a managed disk snapshot, create a new VM in the custom VNet using that snapshot, and then delete the old VM. For production workloads, plan for a maintenance window.

The sooner you move to a custom VNet design, the less painful the migration will be. Doing this with one VM is straightforward. Doing it with 40 VMs and three load balancers is a project.