Azure VNet Complete Design Guide: CIDR, Subnet, NSG, Peering Best Practices

Azure Virtual Network (VNet) is a logically isolated virtual network on Azure and the foundation of every workload running on the platform. VNet design is an area where "once built, it is extremely hard to rebuild," so the quality of the initial design affects every subsequent network, security, and operational decision. This article organizes Azure VNet implementation best practices across CIDR design, subnet partitioning, security integration, and operational know-how.

VNet Core Concepts

Azure VNet is a logical network concept equivalent to on-premises VLANs or subnets. A single VNet is tied to one Azure region and defines its IP address space with a CIDR block (e.g., 10.0.0.0/16). Resources inside the VNet (VMs, App Service Environment, Storage Account Private Endpoints, AKS, etc.) can communicate as part of the same network segment, while external communication is allowed only through explicitly permitted paths (Internet Gateway, NAT Gateway, VPN Gateway, ExpressRoute Gateway, Peering) — a design philosophy close to zero trust.

CIDR Design

CIDR design for a VNet is the single most important decision. Shrinking or changing CIDR after the fact is hard (some expansion is possible), and any change typically requires a delete-and-rebuild rehost of the VNet.

Recommended CIDR Sizes

• VNet per environment: allocate /16 (65,536 addresses) to each of Dev / Stage / Prod
• Small projects: single VNet with /20 (4,096 addresses)
• Large enterprises: /14 (262,144 addresses) for the Hub VNet and /16 for each Spoke VNet

CIDR Selection Principles

• Pick from RFC 1918 private IP space (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
• Anticipate peering with other VNets and avoid CIDR overlap (a company-wide IP address management table is essential)
• Also avoid overlap with on-premises networks and other clouds (AWS / GCP)
• Leave room for future expansion — secure a sufficiently large (/16 recommended) address space from the start

Subnet Partitioning Pattern

The standard pattern is to split the VNet into function-specific subnets. Azure's standard 3-tier architecture pattern:

Azure's reserved names (GatewaySubnet, AzureFirewallSubnet, AzureBastionSubnet) must be created with their exact names. Creating them under wrong names causes deployment errors when the corresponding services are deployed.

Azure Reserved IP Addresses

Azure reserves a total of 5 IPs per subnet — the first 4 and the last 1. Example: in 10.0.0.0/24, the following are reserved.

• 10.0.0.0: Network Address
• 10.0.0.1: Default Gateway
• 10.0.0.2: Azure DNS
• 10.0.0.3: Azure DNS
• 10.0.0.255: Broadcast

Usable IPs are 10.0.0.4 to 10.0.0.254 — 251 in total. A /27 (32 IPs) yields only 27 usable, so subnets that host IP-heavy resources like AKS Nodes or App Service Environment should be sized up (/22 or larger).

VNet Peering

VNet Peering is the mechanism that directly connects two VNets.

• Regional Peering: connects two VNets within the same region. Low latency, high bandwidth.
• Global Peering: connects VNets across regions over the Azure backbone, with low latency.

Peering pricing is traffic-only (no hourly charge): Regional Peering is 0.01 USD/GB inbound/outbound, and Global Peering is 0.035-0.06 USD/GB inbound/outbound (varies by region). For interconnecting three or more VNets, a full-mesh peering arrangement becomes operationally complex, so the standard play is to migrate to Hub-Spoke or Virtual WAN. See Hub-Spoke vs Virtual WAN Complete Comparison for details.

Security Layers

Traffic inside a VNet is protected with defense in depth.

The baseline pattern is to always apply NSG, and add Azure Firewall at the Hub as needed. Using both together is standard — they play complementary roles.

DNS Configuration

VNet DNS settings offer three options: 'Azure-provided DNS (Default),' 'Custom DNS (on-prem DC IP),' and 'Private DNS Zone.'

• Azure-provided DNS (168.63.129.16): default setting; resolves Azure resource names only.
• Custom DNS:specify on-prem AD DNS IPs to integrate AD name resolution in hybrid environments.
• Private DNS Zone:DNS zone scoped to a VNet; required for Private Endpoint name resolution.
• Azure DNS Private Resolver:managed service for hybrid DNS resolution (GA 2022).

VNet Design Pitfalls

Common real-world failure patterns:

1. CIDR too small leading to IP exhaustion: starting with /24 often gets exhausted by a single AKS cluster. We recommend /22 minimum.
2. Subnet name differs from Azure's reserved name: GatewaySubnet, AzureFirewallSubnet, and AzureBastionSubnet require exact names.
3. CIDR overlap with on-prem: breaks routing for VPN/ExpressRoute connections. Centrally manage IPs in a company-wide address table beforehand.
4. Cost explosion from overusing Global Peering: consider Virtual WAN for multi-site connectivity.
5. Exposing public-IP VMs without an NSG: a textbook security incident. Apply NSG to subnets by default.
6. Misusing Service Endpoint vs Private Endpoint: see Private Endpoint vs Service Endpoint for details.
7. Leaving DNS at Default so Private DNS Zone stops working: always configure a Private DNS Zone when deploying Private Endpoints.

Related Certifications

Microsoft certifications are the most efficient way to learn VNet topics systematically.

• AZ-104 (Administrator): VNet fundamentals in Domain 4 (Virtual networking, 15-20%).
• AZ-700 (Network Engineer Associate): large-scale VNet design overall.
• AZ-305 (Solutions Architect Expert): network design judgment in Domain 4.

See Azure Network Engineer Career Roadmap for details.

Frequently Asked Questions

Technical information in this article is based on the Azure Virtual Network Documentation. This article is not an official Microsoft Corporation product and has no affiliation or sponsorship. Microsoft and Azure are trademarks of the Microsoft group of companies. Information is based on official public materials as of May 24, 2026. Always consult the official pages for the latest information.