Azure Virtual Network: Private Networking, Peering, and Hybrid Connectivity on Azure
An Azure Virtual Network (VNet) is a logically isolated network space in which your Azure resources communicate with each other, with the internet, and with your on-premises infrastructure. It is the fundamental networking building block in Azure — everything from a single VM to a Kubernetes cluster to a Private Endpoint lives inside a VNet.
Unlike traditional networking where physical topology matters, VNet boundaries are purely software-defined. You choose an IP address space (CIDR block), divide it into subnets, apply security rules, and define routes — all without touching physical switches or routers.
Real-World Scenario
A bank deploys a three-tier application: a public-facing web tier in one subnet, an application tier in a second subnet, and a database tier in a third subnet. NSG rules restrict the web subnet to receive traffic only on ports 443 and 80 from the internet. The application subnet only accepts traffic from the web subnet on port 8080. The database subnet only accepts traffic from the application subnet on port 1433. No traffic can flow between non-adjacent tiers. This network segmentation limits lateral movement if any tier is compromised.
VNet Structure
VNet: 10.0.0.0/16 (East US)├── Subnet: web-subnet 10.0.1.0/24│ NSG: Allow 443/80 from Internet│ Allow 8080 to app-subnet│ Resources: Load Balancer, Web VMs│├── Subnet: app-subnet 10.0.2.0/24│ NSG: Allow 8080 from web-subnet only│ Allow 1433 to db-subnet│ Resources: Application VMs, AKS nodes│├── Subnet: db-subnet 10.0.3.0/24│ NSG: Allow 1433 from app-subnet only│ Resources: SQL VM, Private Endpoint│├── Subnet: GatewaySubnet 10.0.4.0/27│ Reserved for VPN Gateway / ExpressRoute GW│└── Subnet: AzureFirewallSubnet 10.0.5.0/26 Reserved for Azure FirewallAzure reserves five IP addresses in each subnet (first four and last). A /24 subnet has 251 usable addresses, not 256.
Network Security Groups (NSGs)
An NSG is a stateful firewall applied to a subnet or a NIC. Rules have a priority (lower number = higher priority, evaluated first), source/destination (IP, CIDR, or service tag), port, protocol, and allow/deny action.
NSG Rule Processing--------------------Traffic arrives |Evaluate rules in priority order (100, 200, 300...) |First matching rule applies (allow or deny) |If no match: default deny (inbound) or allow (outbound) |Response traffic automatically allowed (stateful)
Example NSG for web-subnet:Priority | Name | Source | Port | Action---------|--------------------|-----------------|----- |--------100 | AllowHTTPS | Internet | 443 | Allow110 | AllowHTTP | Internet | 80 | Allow200 | AllowSSHFromBastion| AzureBastionSub | 22 | Allow65000 | AllowVnetInBound | VirtualNetwork | Any | Allow (default)65500 | DenyAllInBound | Any | Any | Deny (default)NSGs use service tags (like Internet, VirtualNetwork, AzureLoadBalancer, Storage) to avoid listing individual IP ranges that change over time.
User-Defined Routes (UDRs)
Azure has implicit system routes (within VNet, to internet, to on-premises via gateway). UDRs override them. The most common use is forcing traffic through a network appliance:
Hub-and-Spoke with Azure Firewall (forced tunnelling)------------------------------------------------------Spoke VNet -> Subnet -> Route Table 0.0.0.0/0 -> Next hop: Azure Firewall (10.0.5.4) 10.1.0.0/16 -> Next hop: Azure Firewall (east spoke) 10.2.0.0/16 -> Next hop: Azure Firewall (west spoke)
All traffic between spokes and from spokes to internetpasses through the firewall for inspection and logging.Without UDR, spoke-to-spoke traffic via VNet peeringbypasses the firewall.UDRs are associated with subnets, not individual resources. Every resource in the subnet follows the same routing rules.
VNet Peering
VNet peering connects two VNets so their resources communicate over the Microsoft backbone network without encryption overhead and without traversing the public internet. Peering is non-transitive — if VNet A peers with B and B peers with C, traffic from A cannot reach C unless you add direct peering or route through a hub.
VNet Peering Topology----------------------Global Hub VNet (10.0.0.0/8) Firewall, Bastion, DNS, VPN/ExpressRoute Gateway | | Peering A Peering B | |Spoke VNet A Spoke VNet B(10.1.0.0/16) (10.2.0.0/16)
A->B traffic path: Spoke A -> Hub Firewall -> Spoke B(transitivity via UDR + firewall, not peering)Global VNet peering connects VNets across Azure regions with the same low-latency Microsoft backbone. Bandwidth is not metered within a region (free); global peering is charged per GB transferred.
Private Endpoints
A Private Endpoint gives a PaaS service (Blob Storage, SQL Database, Key Vault, etc.) a private IP address in your VNet. Traffic to the service stays on the Microsoft network and never traverses the public internet.
Private Endpoint Flow----------------------VM in subnet (10.0.2.5) |DNS resolution: mystorageacct.blob.core.windows.net |Private DNS Zone: mystorageacct.blob.core.windows.net -> 10.0.2.100 |Traffic flows to Private Endpoint NIC (10.0.2.100) in your subnet |Microsoft backbone carries traffic to Azure Storage (public endpoint of storage account can be disabled)Private DNS zones are linked to the VNet so resolution returns the private IP. Without the DNS zone link, clients resolve the public IP even if a Private Endpoint exists.
VNet Integration for PaaS Services
Some PaaS services (App Service, Azure Functions on Premium plan, API Management) need outbound connectivity to private VNet resources. VNet Integration is different from a Private Endpoint:
VNet Integration vs. Private Endpoint---------------------------------------Private Endpoint: inbound into PaaS service from your VNetVNet Integration: outbound FROM PaaS service INTO your VNet
Example: App Service App -> VNet Integration subnet (delegated) -> Routes to 10.0.3.0/24 (db-subnet) -> Reaches SQL Server on Private Endpoint (10.0.3.50)
Public internet -> Private Endpoint for App Service -> Reaches App Service without public IP exposure (inbound)Combine both for a fully private PaaS deployment: Private Endpoint for inbound (clients inside VNet reach the app), VNet Integration for outbound (app reaches private back-end services).
Key Interview Points
- VNet is regional: A VNet lives in one region. Resources in multiple regions need separate VNets connected by peering or VPN.
- Peering non-transitivity: This is the most common interview question on VNet peering. Traffic is not forwarded through a peered VNet to a third VNet without explicit routes or a hub appliance.
- NSG vs. Azure Firewall: NSGs work on layers 3 and 4 (IP and port). Azure Firewall adds layer 7 (FQDN filtering, TLS inspection, IDPS in Premium). For simple subnet isolation, NSGs are sufficient. For internet egress inspection and threat detection, add Azure Firewall.
- Service Endpoint vs. Private Endpoint: Service Endpoints route traffic over the Azure backbone but the PaaS service still has a public IP (traffic stays off-internet but the service endpoint is a public address). Private Endpoints give the service a private IP in your VNet — stronger isolation and enables firewalling the public endpoint entirely.
- Address space cannot overlap: Peered VNets must have non-overlapping CIDR ranges. Plan IP addressing before deploying — changing address space after resources are running requires stopping or deleting them.
Best Practices
- Plan your CIDR range at the organisation level before deploying any VNets — overlapping ranges prevent peering and cause routing problems that are expensive to fix.
- Apply NSGs to subnets, not individual NICs, for consistent security posture; use NIC-level NSGs only for exception cases.
- Enable VNet flow logs (NSG flow logs or VNet flow logs) and send to Log Analytics for traffic analysis and security investigations.
- Use Azure Policy to enforce that all subnets have an NSG attached and that no subnet allows unrestricted inbound from the internet.
- Delegate the GatewaySubnet solely to the gateway — do not place other resources in it, and size it at least /27 (ideally /26) to accommodate future gateway SKU requirements.