Virtual Networks and Subnets

An Azure Virtual Network (VNet) is a logically isolated network in the Azure cloud that you define and control. It is the fundamental building block of Azure networking, enabling Azure resources such as virtual machines, databases, and app services to communicate securely with each other, the internet, and on-premises networks. A VNet is scoped to a single Azure region and a specific IPv4 (and optionally IPv6) CIDR address space that you define when creating it.

When creating a VNet, you assign an address space using CIDR notation. CIDR (Classless Inter-Domain Routing) notation specifies both the network address and the number of bits used for the network prefix. For example, 10.0.0.0/16 gives you 65,536 IP addresses (10.0.0.0 through 10.0.255.255). The address space must be a private IP range (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 per RFC 1918). Choose an address space large enough to accommodate all planned subnets with room to grow, but avoid overlapping with on-premises networks if you plan a hybrid connection.

A subnet divides the VNet address space into smaller network segments. Each subnet has its own IP range (a subset of the VNet's address space) and can contain resources of different types. Subnets serve two purposes: organisation (grouping related resources) and isolation (applying different security rules to different resource groups). For example, you might have a web-tier subnet (10.0.1.0/24) for web servers, a app-tier subnet (10.0.2.0/24) for application servers, and a data-tier subnet (10.0.3.0/24) for databases.

Within each subnet, Azure reserves the first four IP addresses and the last IP address for its own use. For a 10.0.1.0/24 subnet: 10.0.1.0 (network address), 10.0.1.1 (default gateway), 10.0.1.2 and 10.0.1.3 (reserved for Azure DNS), and 10.0.1.255 (broadcast address). This leaves 251 usable IPs in a /24 subnet. Account for this reservation when sizing subnets — a /28 subnet has only 11 usable addresses (16 minus 5 reserved).

By default, resources within the same VNet can communicate with each other using their private IP addresses, even if they are in different subnets. No additional configuration is needed for intra-VNet communication. Resources in different VNets cannot communicate by default — you must explicitly connect them using VNet Peering. Resources in the same subnet share the same network segment, making communication between them the most direct possible path within Azure's software-defined networking layer.

VMs in a VNet can initiate outbound connections to the internet by default — Azure automatically provides outbound internet access through a managed NAT service. For inbound internet access, a resource needs a Public IP address assigned to its network interface or load balancer. You then control inbound access using Network Security Group (NSG) rules to specify exactly which ports and protocols are permitted. A common architecture places web servers in a public subnet with public IPs and application servers in a private subnet accessible only from the web tier.

By default, Azure handles routing automatically — traffic between subnets stays within the VNet, outbound internet traffic is NATted, and traffic to Azure services uses Azure's backbone. You can override this with User-Defined Routes (UDRs) in a Route Table. A common use is to force all outbound internet traffic through a Network Virtual Appliance (NVA) or Azure Firewall in a hub VNet for centralised inspection. You create a route table, add route entries, and associate the table with one or more subnets to apply it.

Some Azure services — like Azure App Service (VNet Integration), Azure Kubernetes Service, Azure SQL Managed Instance, and Azure Databricks — require a dedicated subnet delegated to that service. A delegated subnet means Azure can inject service-specific resources (network interfaces, internal IP addresses) into that subnet on your behalf. You cannot deploy other types of resources into a delegated subnet — it is reserved for that Azure service exclusively. Always allocate a dedicated subnet with sufficient IP space when planning to use services that require delegation.

Key best practices for VNet design: Plan your address space before creating the VNet — you cannot change it without recreating resources. Use separate subnets for each application tier to apply distinct security policies. Avoid overlapping address spaces with on-premises networks if you plan to connect via VPN or ExpressRoute. Reserve larger subnets for services that need scaling (e.g., AKS node pools). Name resources clearly (e.g., vnet-prod-eastus-001) to aid in large-scale management. A well-designed VNet is far easier to secure and troubleshoot than one that was built ad-hoc.

Azure VNets can be connected to on-premises networks through two mechanisms: VPN Gateway — an encrypted IPsec/IKE tunnel over the public internet; cost-effective for moderate bandwidth needs. Azure ExpressRoute — a private, dedicated fibre connection through a network provider partner; delivers higher bandwidth, lower latency, and more predictable performance than VPN. For sensitive workloads or scenarios requiring guaranteed bandwidth, ExpressRoute is the preferred option, though it comes at significantly higher cost and longer provisioning lead times.

Sizing a VNet's address space requires planning for current and future needs. A common enterprise pattern is: VNet address space: /16 (65,536 addresses). Subnets: /24 per workload tier (251 usable addresses each). A /16 VNet can contain 256 /24 subnets — more than enough for most environments. For very large environments, use a /8 or request multiple non-overlapping ranges. Always leave growth room: allocating a /24 today when you might need a /22 next year leads to painful re-addressing work later.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: an Azure VNet is a logically isolated network with a defined CIDR address space, scoped to a single region, subnets divide the VNet into segments for organisation and security policy isolation, and Azure reserves 5 IP addresses per subnet, and resources within the same VNet communicate privately by default without additional configuration. Next up we explore Network Security Groups and Application Security Groups for traffic filtering.