Azure Virtual Network Design Explained for AZ-104

A Virtual Network is defined by one or more address spaces expressed in CIDR notation. Resources within a VNet communicate privately using addresses from this space. Subnets divide the VNet address space into smaller segments, allowing you to group resources logically and apply different security policies to different groups. A web tier subnet, an application tier subnet, and a database subnet each get their own network controls even though they all live within the same VNet.

Azure reserves five IP addresses in every subnet: the network address, the default gateway, two Azure DNS addresses, and the broadcast address. Plan subnet sizes to account for these reservations and for future growth. CIDR /29 gives you only 3 usable addresses. A /24 gives 251. The rule is to plan more space than you think you need: re-addressing a subnet later requires migrating resources, which can be disruptive.

Some Azure services require dedicated subnets: Azure Bastion needs its own AzureBastionSubnet, VPN Gateway needs GatewaySubnet, Azure Firewall needs AzureFirewallSubnet, and Azure Application Gateway needs its own subnet as well. Reserve these subnets during initial VNet design even if you are not deploying those services immediately.

VNet peering connects two VNets so that resources in each can communicate using private IP addresses. Peering can be regional (within the same region) or global (across regions). Peered VNets must not have overlapping address spaces. Peering is non-transitive: if VNet A is peered with VNet B, and VNet B is peered with VNet C, VNet A cannot communicate with VNet C unless you add a direct A-to-C peering or configure a hub VNet with route tables to forward traffic. Traffic in global peering traverses the Microsoft backbone, not the public internet.

Service endpoints extend a VNet's private address space to Azure service resources like Storage and SQL Database, so traffic from your VNet to those services routes over the Azure backbone rather than the public internet. Private endpoints go further: they place a private IP address from your VNet directly on an Azure PaaS resource, making it accessible by private IP and allowing you to block all public access to the service.

VPN Gateway provides encrypted connectivity between your VNet and on-premises networks. Site-to-Site VPN creates an IPsec tunnel over the public internet between your on-premises VPN device and an Azure VPN Gateway. Point-to-Site VPN connects individual client devices to the VNet. ExpressRoute provides a dedicated private circuit from your on-premises location to an Azure datacenter through a connectivity provider. ExpressRoute does not traverse the public internet, offers consistent bandwidth (50 Mbps to 100 Gbps), and lower latency than VPN, at higher cost and longer provisioning time.

Subnet sizing: Azure reserves 5 IPs per subnet. A /29 gives 3 usable, a /28 gives 11, a /24 gives 251.

VNet peering: non-transitive, no overlapping CIDR, works across regions and subscriptions.

Service endpoint: routes traffic to PaaS services over Azure backbone, resource still has public endpoint.

Private endpoint: gives PaaS resource a private IP in your VNet, enables disabling public access entirely.

VPN Gateway: IPsec over internet, active-active for redundancy. Fast to set up, variable performance.

ExpressRoute: private dedicated circuit, consistent SLA-backed bandwidth. Weeks to provision, higher cost.

Azure DNS: private zones for name resolution within VNets, public zones for internet-facing domains.

GatewaySubnet: required for VPN Gateway and ExpressRoute Gateway. Must be named exactly GatewaySubnet.