Virtual Network

A Virtual Network is your own private slice of Azure's datacentre network: you choose a private IP address range, carve it into subnets, and every resource you place inside gets an address from that range and can talk to its neighbours. Everything else in Azure networking — firewalls, gateways, load balancers, private endpoints — is a thing you plug into a VNet.

Names: the service is Azure Virtual Network, universally abbreviated VNet (Microsoft writes it "VNet"; the ARM type is Microsoft.Network/virtualNetworks). You will still meet the retired classic (ASM) virtual network in old blog posts — ignore it; this topic is Resource Manager throughout. Its close relatives have kept their names: Network Security Group (NSG), Application Security Group (ASG), User-Defined Route (UDR), Azure Virtual WAN.

What it is and where it fits

A VNet is a software-defined Layer 3 network. You declare a private address space in CIDR notation — say 10.20.0.0/16 — split it into subnets, and Azure's host-level SDN stack makes every NIC in those subnets behave as though they were plugged into the same switched network. Within a VNet, everything can reach everything by default, across subnets, with no routing configuration and no performance penalty for crossing a subnet boundary.

The problem it kills is the one that made pre-cloud networking slow: a network used to be physical. Adding a VLAN meant a change window and a network engineer; segmenting two applications meant a firewall appliance and a cable. A VNet turns all of that into ARM resources you can create, version, review, and destroy — and, critically, it turns isolation into the default rather than something you bolt on. Two VNets that you haven't explicitly connected cannot reach each other at all, even in the same subscription.

The thing to internalise early: the VNet is a boundary, not a device. There is no virtual router you can log into, no switch, no appliance. The enforcement happens in the hypervisor host on every machine, in a component called the Virtual Filtering Platform, before a packet ever reaches a physical wire. That's why NSG rules don't consume bandwidth, why there is no "network appliance" to size or scale, and also why some familiar on-premises tricks — broadcast, multicast, GRE, IP-in-IP, promiscuous mode — simply don't work here.

Azure's networking catalogue overlaps itself, and the neighbours are worth separating in a line each:

• VNet peering — glue two VNets into one flat routing domain. Cheap, low-latency, and non-transitive: A↔B and B↔C does not give you A↔C.
• Azure Virtual WAN — Microsoft-managed hub-and-spoke at global scale, with transitive routing built in. Choose it when you'd otherwise be hand-building a hub VNet with a firewall, route tables, and a dozen peerings across regions.
• Azure Private Link / private endpoints — bring a PaaS service into your VNet as a private IP. This is a feature you use inside a VNet, not an alternative to one.
• Service endpoints — the older, cheaper, weaker way to reach PaaS: traffic stays on Azure's backbone but still targets the service's public IP. Free, but no on-premises reach and no per-resource granularity.
• ExpressRoute / VPN Gateway — the two ways to attach a VNet to your own datacentre. Both are separate, expensive resources that live in a dedicated subnet.
• Azure Firewall / Network Virtual Appliance — the thing that inspects traffic between subnets or VNets. An NSG filters; a firewall inspects, logs, and does FQDN and threat-intelligence rules.

If you're coming from AWS: a VNet is a VPC, and the mental model transfers further than most Azure↔AWS pairs. Subnet ≈ subnet, security group ≈ NSG, route table ≈ route table, VPC peering ≈ VNet peering, PrivateLink ≈ Private Link. Where it breaks, and it breaks in ways that matter:

• Azure subnets are not zonal. An AWS subnet lives in exactly one Availability Zone; an Azure subnet spans all zones in the region. Zone placement is a property of the resource (the VM, the load balancer), never of the subnet. Half of all AWS-shaped Azure network designs are wrong because of this one difference.
• NSGs are stateful like security groups, but they are ordered, numbered, and have explicit Deny rules — closer to a NACL in expressiveness, closer to a security group in statefulness. They also attach to a subnet or a NIC, not to an instance.
• There is no Internet Gateway or NAT Gateway to attach for basic function. Routing to the internet exists by default as a system route; what you do need to add explicitly is an outbound SNAT source (see Architecture).
• The VNet itself is free and has no SKU. Every cost in Azure networking lives in the things you attach to it — which is exactly why the bill surprises people.

Key facts at a glance

Category	Networking — the foundation layer everything else attaches to
Resource provider	Microsoft.Network/virtualNetworks, with subnets as child resources (Microsoft.Network/virtualNetworks/subnets)
Companion providers	Microsoft.Network/networkSecurityGroups, .../routeTables, .../natGateways, .../privateEndpoints, .../publicIPAddresses, .../networkInterfaces, Microsoft.Network/privateDnsZones
Scope	Regional, and implicitly zone-spanning — one VNet covers every availability zone in its region. It cannot span regions; connect regions with peering or Virtual WAN
The SKU axis	The VNet has no SKU — and that is the single most important structural fact about this topic. The tiering that decides features and cost lives in the attached resources: Public IP (Standard only, since Basic retired), Load Balancer (Standard / Gateway), Azure Firewall (Basic / Standard / Premium), VPN Gateway (VpnGw1–5, with AZ zone-redundant variants), DDoS Protection (IP Protection vs. Network Protection), Bastion (Developer / Basic / Standard / Premium) ⚠️ verify current SKU names against current Azure docs
The trap in that axis	Choosing Azure Firewall Premium when you only needed NSGs and a NAT Gateway. Firewall is billed per deployment-hour plus per GB processed and is the largest single line on most Azure network bills
Unit of billing	The VNet, its subnets, NSGs, ASGs, and route tables are free. You pay for: peering data transfer (charged on both sides), NAT Gateway (hour + GB), public IPs (hour, even when idle), gateways and firewalls (hour + GB), private endpoints (hour + GB), Bastion (hour), and cross-region egress
SLA posture	The VNet as a construct is part of the platform fabric and has no standalone SLA line; the attached resources each carry their own, and the zone-redundant SKU is usually what buys the higher number ⚠️ verify against current Azure docs
Usual companions	NSG + ASG, route table, NAT Gateway, Private DNS zone + private endpoints, Azure Firewall or an NVA, Load Balancer / Application Gateway, Bastion, Network Watcher
Primary alternative	None, for IaaS. For "I just want my PaaS services to talk privately", private endpoints inside a small VNet are the answer rather than a full hub-and-spoke
AWS rough analogue	VPC (+ security groups ≈ NSGs, route tables ≈ route tables, Transit Gateway ≈ Virtual WAN)

When to use a Virtual Network

• Any IaaS at all. A VM, a VM Scale Set, an AKS node pool, and a Container Apps environment all require a subnet. There is no VM without a VNet.
• Private connectivity to PaaS. The moment you want Blob Storage, Key Vault, or Azure SQL to be unreachable from the public internet, you need a VNet to host the private endpoints.
• Segmentation you can prove to an auditor. Subnets plus NSGs plus flow logs give you a defensible, queryable answer to "what can reach the database tier".
• Hybrid connectivity. ExpressRoute or a VPN gateway terminates in a VNet; on-premises routes are advertised into it.
• Controlling egress. If you must know and constrain every destination your workloads reach — common in regulated environments — a VNet with a UDR pointing at a firewall is the mechanism.
• Predictable, private, low-latency service-to-service traffic that never touches a public endpoint.

When not to use one

• A pure PaaS application with no privacy requirement. App Service, Functions on Consumption, and Static Web Apps work fine over public endpoints with Entra ID auth. Adding a VNet adds private DNS, a NAT Gateway, and a class of debugging you didn't previously own.
• As a substitute for identity. Network reach is not authorisation. A private endpoint does not authenticate anyone; you still need Azure RBAC on the data plane. "It's on the private network" has never been a security model.
• One VNet per application, sprayed across a subscription. Non-transitive peering means n VNets need n² peerings to be fully meshed. Either adopt hub-and-spoke or adopt Virtual WAN, but don't let VNets accrete.
• A tiny address space to "keep it tidy". A /24 VNet looks neat right up to the day someone adds AKS with Azure CNI, and then you cannot grow into a peered neighbour without a renumber. Address space is the one decision here that is genuinely hard to undo.
• Copying an AWS design subnet-for-subnet. Per-AZ subnets are meaningless in Azure and will leave you with three redundant subnets and a zone story you haven't actually implemented.

What this topic covers

Sub-topic	What it covers
What & Why	The problem VNets solve, the isolation-by-default model, the AWS analogue and its three sharp edges, and the anti-patterns
Core Concepts	Address space and CIDR, subnets and reserved addresses, NICs and IP configurations, NSGs, ASGs, service tags, route tables, peering, service endpoints vs. private endpoints, delegation, and the reserved subnet names
Architecture	How a packet actually travels, the host SDN and VFP, route selection order, NSG evaluation order, the control-plane / data-plane split, SNAT and port exhaustion, DNS at 168.63.129.16, and the failure modes
Getting Started	One VNet, two subnets, an NSG and a NAT Gateway — three ways: portal, az CLI, and a minimal Terraform snippet — plus teardown
Deployment	A parameterised Terraform module with IPAM-style subnet maths, remote state, an Ansible playbook, the Bicep equivalent, OIDC-based CI/CD, hub-and-spoke environments, rollback, and drift
Integrations	Private Link and Private DNS, Azure Firewall, load balancers, AKS and App Service integration, Bastion, gateways, and Network Watcher
Production	Security, cost, scaling and quota scopes, observability with VNet flow logs and KQL, and reliability across zones and regions
Interview Questions	Three tiers with answer keys, from "what is a VNet" to "someone added a UDR by hand and half the traffic vanished"
Glossary & Cheatsheet	Every term in one line, the commands you'll actually type, the resource ID shape, and the limits worth memorising

Three ideas worth carrying into every other page

Address space is the one irreversible decision. You can add address ranges to a VNet later and you can now remove them, but you cannot overlap with a network you want to peer with — ever. Two VNets with overlapping CIDRs can never be peered, and no amount of NAT makes that pleasant. Before you create your first VNet, decide the range the whole organisation will draw from, write it down, and give each region and environment a non-overlapping block with room to double. This costs you twenty minutes now and a migration project later.

Peering is not transitive, and that shapes every topology. If spoke A and spoke B are both peered to hub H, A cannot reach B by default — the hub has no automatic transit. Making it work requires an actual routing device in the hub (Azure Firewall, an NVA, or Route Server) plus UDRs in each spoke pointing at it. Virtual WAN exists because enough people got this wrong enough times. The corollary: a peering that looks connected in the portal and still doesn't pass traffic is almost always a missing route or a missing Allow forwarded traffic flag, not a broken peering.

The subnet is a security boundary; the VNet mostly isn't. Inside a VNet, the default NSG rule AllowVnetInBound permits everything from everything, across all subnets, in both directions. Flat is the default. Segmentation is something you deliberately build with NSGs and, where inspection matters, a firewall in the path. If nobody has written a deny rule, your database subnet is reachable from your build agent subnet.

Reading paths

New to Azure networking — What & Why → Core Concepts → Getting Started. Build one, break it, delete it, then come back for Architecture.

Coming from a VPC — skim What & Why for the three sharp edges, then go straight to Core Concepts for the NSG/ASG model and Architecture for route selection and SNAT, neither of which behaves quite like its AWS counterpart.

Need to ship this week — Deployment first, then the security and observability sections of Production. Getting Started is deliberately throwaway; don't build on it.

Debugging "it can't reach it" — the route-selection and NSG-evaluation sections of Architecture, then the Network Watcher tools in Integrations. IP flow verify and next hop answer most of these in a minute.

Interview or certification prep — Core Concepts, Architecture, and Interview Questions. The non-transitive-peering question, the service-endpoint-vs-private-endpoint question, and the reserved five addresses per subnet come up constantly.

Chasing a networking bill — the cost section of Production. It is almost always Azure Firewall, an idle gateway, cross-region peering data, or a hundred forgotten public IPs.

---

Next: What & Why →

← Back to the article