What is a Virtual Network (VNet)?

A Virtual Network (VNet) is Azure’s construct for logical isolation of cloud resources, similar to a traditional on-premises network. Resources placed in a VNet – virtual machines, gateways, and network appliances – communicate securely with each other, with on-premises networks, and with the internet, under subnets and security rules the customer controls.

Key takeaways

• A VNet is Azure’s logically isolated network for cloud resources.
• Subnets divide a VNet into segments such as management, WAN, and LAN.
• VNets reach on-premises networks via VPN Gateway, Virtual WAN, or an NVA.
• Azure Route Server exchanges BGP routes without manual route-table updates.
• Versa SASE Gateways and VOS instances connect to VNets over IPsec and BGP.

On this page: Why it matters · How it works · Types · VNet & Versa · FAQ

Why are VNets important?

Every workload an enterprise runs in Azure – application servers, databases, SD-WAN edge appliances – lives inside a VNet, so the VNet is the boundary that determines what can reach what. Without it, cloud resources have no consistent way to isolate workloads or apply security policy.

VNets matter operationally because most cloud growth now touches hybrid connectivity: branch offices, remote users, and other clouds all need a defined, policy-controlled path into Azure-hosted resources. A VNet gives network and security teams a single boundary to enforce consistent rules across on-premises and cloud environments – something regulatory compliance and a coherent security posture both depend on. Getting VNet design right is foundational to everything built on top of it.

What is a VNet?

A VNet is defined by an IP address space and lives inside an Azure resource group, the logical container Azure uses to manage related resources as a single unit. Within a VNet, subnets carve out smaller address ranges for specific purposes: management, WAN, LAN, and, where dynamic routing is needed, a dedicated RouteServerSubnet.

Two building blocks extend a VNet’s reach. A Virtual Network Gateway is the VPN or ExpressRoute endpoint connecting the VNet to on-premises networks or other VNets, paired with a Local Network Gateway representing the remote device. A Network Security Group (NSG) acts as a virtual firewall on subnets or interfaces, filtering traffic by IP, port, and protocol. Larger designs use Azure Virtual WAN, a Microsoft-managed hub connecting many VNets and branch sites.

Types of VNet connectivity

Connecting an external network to a VNet follows one of three patterns. Site-to-site VPN Gateway builds a direct IPsec tunnel, with dynamic routes over eBGP, between a single VNet’s Virtual Network Gateway and the remote device – simple and cost-effective for one VNet. Virtual WAN hub connects the remote device to a Microsoft-managed hub fanning out to many VNets and regions through centralized routing. Network virtual appliance (NVA) places a virtual instance of the remote device’s own software inside the VNet, terminating dynamic tunnels locally – useful when an existing SD-WAN fabric should extend natively into Azure.

A fourth pattern, Azure Route Server, is a routing layer rather than a connectivity method: it exchanges BGP routes between a VNet and an NVA in active-active or active-passive mode, removing the need to hand-maintain route tables.

VNet & Versa

Versa SASE Gateways and VOS devices connect to Azure VNets through the same patterns Azure exposes. A SASE Gateway can peer directly with a VNet’s Virtual Network Gateway over a site-to-site IPsec tunnel with eBGP, or peer with an Azure Virtual WAN hub for centralized, multi-VNet connectivity. Where an enterprise already runs Versa Secure SD-WAN, a VOS instance deployed as an NVA inside the VNet extends that fabric into Azure, managed from Versa Concerto.

For highly available designs, a VOS device can peer with Azure Route Server over BGP, so routes to every attached VNet stay current on failover – no manual route-table maintenance. Director’s Monitor view exposes the resulting BGP neighbors and prefixes for verification.

Frequently asked questions

What is the difference between a VNet and a subnet?

A VNet is the overall address space and isolation boundary in Azure; a subnet is a smaller range of IP addresses carved out of that VNet to segment resources – for example, separate management, WAN, and LAN subnets within one VNet.

What is the difference between a VNet and a VPC?

They are the same pattern under different vendor names: a VNet is Azure’s logically isolated virtual network, and a VPC is the equivalent construct on AWS. Both let a customer control address ranges, subnets, and routing.

Can two VNets communicate with each other?

Yes, through VNet peering or by attaching both to a shared Azure Virtual WAN hub. Neither approach requires traffic to leave Microsoft’s backbone, and both can carry BGP routes when a route server or NVA is involved.

Does a VNet need a gateway to reach on-premises networks?

In most designs, yes – a Virtual Network Gateway or a network virtual appliance inside the VNet terminates the connection to the remote site. Azure Route Server then optionally handles the BGP route exchange without a manual route table.

How does Azure Route Server help with VNet routing?

It lets a VNet and a network virtual appliance, such as a VOS instance, exchange routes directly over BGP in an active-active or active-passive design. Routes update automatically on failover, removing the need for user-defined route tables.

More on VNets

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about VNets, these are worth looking at next.