Virtual Network (VNet)

What it is

An Azure Virtual Network (VNet) is a private network you define in Azure. It gives Azure resources a shared private address space and the network controls needed to communicate with each other, the internet, connected networks, and supported Azure services. Think of it as the boundary of Northwind’s private office network in Azure, not as a physical switch or a single datacenter.

Why it exists

Physical networks were constrained by hardware and on-premises cabling. A VNet gives you the same segmentation, routing, name resolution, and security primitives as an on-prem LAN, but delivered as an isolated slice of Azure’s shared cloud — provisioned in seconds and fully API-managed.

Key ideas

  • A VNet belongs to one Azure region and subscription. It spans the availability zones in that region; you do not create a separate VNet merely to use different zones.
  • You give the VNet a private address range, such as 10.0.0.0/16, expressed in CIDR notation, then divide it into subnets. Ranges must be planned so they do not overlap with networks you need to connect.
  • Azure supplies system routes. Route tables can direct traffic; network security groups decide whether matching traffic is allowed. A route is a path, not a firewall rule.
  • VNets can connect to other VNets through vnet-peering, and to on-premises networks through VPN Gateway or ExpressRoute.
  • Inbound internet access requires an intentional design such as a public IP or public load balancer. Plan outbound access explicitly as well; do not depend on an accidental default.

Northwind example

Northwind creates one production VNet and divides 10.20.0.0/16 into frontend, app, and private-endpoints subnets. Its public load balancer receives shopper traffic, while application-to-storage traffic uses a private endpoint. An NSG permits only the front-end traffic needed by the app tier. The VNet supplies the private network; the subnets organize it; the NSG filters it; and routes determine where it goes.

Common confusion

  • A VNet is not a VPN. A VPN gateway can connect a VNet to another network, but the VNet is the Azure network itself.
  • A VNet is not automatically isolated from all internet access. Inbound and outbound behavior must be designed and controlled.
  • A VNet does not replace an NSG, firewall, DNS, or load balancer. Those solve different network problems.

How it fits

Internet │  On-premises
   │      │      │
   ▼      ▼      ▼
[ public IP ][ VPN Gateway / ER ]
   ┌────────────── VNet (10.0.0.0/16) ──────────────┐
   │  Subnet A (10.0.1.0/24)    Subnet B (10.0.2.0/24) │
   │  [VM][LB]                   [VM][ASG]            │
   │  NSG / route tables / Azure Firewall             │
   └───────────────────────────────▲──────────────────┘
                                   │ vnet-peering
                          ┌────────┴────────┐
                          │  other VNet     │
                          └─────────────────┘

Practical limits and tradeoffs

  • Choose address ranges before deployment. Overlap can block peering, VPN, and hybrid connectivity later.
  • A VNet can contain resources with different roles, but use subnets and rules to limit unnecessary traffic between them.
  • Moving a VM to another VNet requires recreating the VM in the target VNet. Treat network moves as planned migrations, not a quick toggle.

subnet · cidr-ip-addressing · vnet-peering · route-table · nsg · private-endpoint · azure-dns · northwind-traders-case-study

📘 Source: Microsoft Learn — What is Azure Virtual Network?, checked 2026-09-16.