This chapter covers Azure Virtual Networks (VNets), the fundamental building block for private networking in Azure. As part of Domain 2 (Azure Architecture and Services), Objective 2.3 focuses on core networking services, which appear in roughly 15-20% of AZ-900 exam questions. Understanding VNets is critical because they enable secure communication between Azure resources, the internet, and on-premises networks. By the end of this chapter, you will grasp what a VNet is, how it works, its key components, and how it differs from traditional on-premises networking.
Jump to a section
Imagine your company moves into a new office building. The building itself is like an Azure region—a physical location. Inside, you have a dedicated floor (your VNet) that only your team can access. On that floor, you can set up private rooms for different departments (subnets). Each room has a door with a specific lock (network security group) that controls who enters. Some rooms are for servers (like a data center), others for employee desks (web servers). You can also install a secure tunnel to another building across town (VPN gateway) so your branch office can connect privately over the internet. The building has a main reception desk (Azure Firewall) that screens all visitors. If you want to allow public visitors, you install a glass door (public IP and load balancer) that directs them to the right room. Just as you wouldn't let a stranger wander into the server room, Azure VNet uses subnets and NSGs to segment traffic. The building manager (Azure) handles the physical security and maintenance, but you decide the floor plan and locks. This analogy mirrors VNet's mechanism: logical isolation, subnet segmentation, traffic filtering, and hybrid connectivity—all within a shared physical infrastructure managed by Microsoft.
What is Azure Virtual Network (VNet)?
Azure Virtual Network (VNet) is a logically isolated section of the Azure cloud dedicated to your subscription. It allows you to launch Azure resources (like VMs, App Services, databases) in a private network environment that you control. Think of it as your own private data center in the cloud—you can define IP address ranges, subnets, routing tables, and security policies. The business problem VNet solves is simple: without it, your cloud resources would be exposed to the public internet by default, making them vulnerable to attacks. VNet provides isolation, segmentation, and secure connectivity.
How VNet Works: The Mechanism
When you create a VNet, you choose an IP address space (e.g., 10.0.0.0/16) in a private range (RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). This address space is carved into subnets (e.g., 10.0.1.0/24 for web servers, 10.0.2.0/24 for databases). Each subnet is a range of IP addresses within the VNet. Azure automatically handles routing between subnets within the same VNet—you don't need to configure a router. You can also add a gateway subnet for VPN or ExpressRoute connections.
Traffic is controlled by Network Security Groups (NSGs) and Azure Firewall. NSGs are stateful packet filters that allow or deny traffic based on source/destination IP, port, and protocol. They can be associated with subnets or individual network interfaces (NICs). Azure automatically creates default rules (e.g., allow all outbound, deny all inbound from internet) that you can override.
Key Components of VNet
Address Space: A set of private IP ranges assigned to the VNet. You cannot overlap address spaces when peering VNets or connecting to on-premises.
Subnets: Segments within the VNet that group resources logically. Azure reserves the first four and last IP in each subnet for internal use (e.g., 10.0.1.0-3 and 10.0.1.255).
Network Security Groups (NSGs): Filter traffic at the subnet or NIC level. They contain security rules with priority (100-4096), action (Allow/Deny), source, destination, protocol, and port.
Azure Firewall: A managed, cloud-based network security service that protects your VNet resources. It's a stateful firewall with built-in high availability and scalability.
Virtual Network Peering: Connects two VNets in the same or different regions, allowing resources in each to communicate as if they were on the same network. Traffic stays on the Microsoft backbone.
VPN Gateway: A specific type of VNet gateway that sends encrypted traffic between an Azure VNet and an on-premises network over the public internet.
Azure ExpressRoute: A dedicated private connection from on-premises to Azure that does not traverse the internet.
Private IP and Public IP: Resources can have private IPs (within VNet) and optionally public IPs for internet access.
Service Endpoints: Extend your VNet private address space to Azure services (like Storage, SQL Database) over the Microsoft backbone.
Private Link: Expose Azure services privately within your VNet without using public IPs.
VNet vs. On-Premises Network
In an on-premises data center, you buy routers, switches, firewalls, and cables, and you manage physical security. With VNet, the physical infrastructure is Microsoft's responsibility. You define the logical topology in software. On-premises, VLANs segment traffic; in Azure, subnets and NSGs do the same. On-premises, you use BGP for routing; in Azure, system routes handle routing within a VNet, and you can add user-defined routes (UDRs) for custom routing. On-premises, you buy hardware VPNs; in Azure, you deploy a VPN gateway as a managed service.
Pricing and Tiers
VNet itself is free—you only pay for associated resources like VPN gateways (hourly + data transfer), Azure Firewall (hourly + data processing), and public IP addresses (static vs. dynamic). Data transfer within a VNet is free; data transfer between VNets in different regions incurs charges. There is no tier for VNet; it's a standard service. However, VPN gateways have tiers (Basic, VpnGw1-5) with different throughput and features.
Azure Portal and CLI Touchpoints
You can create a VNet via the Azure portal under "Create a resource" > "Networking" > "Virtual network". The wizard asks for subscription, resource group, name, region, address space, and subnets. You can also use Azure CLI:
az network vnet create \
--name MyVNet \
--resource-group MyRG \
--location eastus \
--address-prefix 10.0.0.0/16 \
--subnet-name default \
--subnet-prefix 10.0.1.0/24To create an NSG:
az network nsg create --name MyNSG --resource-group MyRG --location eastus
az network nsg rule create --nsg-name MyNSG --resource-group MyRG --name AllowSSH --priority 100 --source-address-prefixes '*' --destination-port-ranges 22 --access Allow --protocol TcpConcrete Business Scenario
A retail company deploys a three-tier application on Azure: web servers, application servers, and databases. They create a VNet with three subnets: WebSubnet (10.0.1.0/24), AppSubnet (10.0.2.0/24), and DBSubnet (10.0.3.0/24). They attach an NSG to WebSubnet allowing inbound HTTP/HTTPS from the internet. Another NSG on AppSubnet allows inbound only from WebSubnet on port 8080. DBSubnet allows inbound only from AppSubnet on port 1433 (SQL). This ensures defense in depth.
Plan IP Address Space
Before creating a VNet, determine the IP address range(s) you need. Use private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Ensure the range does not overlap with other VNets you plan to peer with or your on-premises network. Consider future growth—leave room for expansion. Azure allows up to 65,536 addresses in a /16 VNet, but you can add multiple address prefixes. For example, a company with a small web app might use 10.0.0.0/24 (256 addresses), while a large enterprise might use 10.0.0.0/16. The address space is a logical construct; Azure does not physically reserve IPs until you create subnets.
Create the VNet and Subnets
In the Azure portal, navigate to 'Virtual networks' and click '+ Create'. Provide a name (e.g., 'MyVNet'), select a region (e.g., 'East US'), and enter the address space (e.g., 10.0.0.0/16). Then add subnets: at least one subnet is required. Name the first subnet 'default' with prefix 10.0.1.0/24. You can add more subnets later (up to 1,000 per VNet). Azure automatically creates system routes for traffic between subnets. Behind the scenes, Azure assigns a routing table and enables communication. Note: The first three IPs in each subnet are reserved for Azure infrastructure (e.g., .1 for gateway, .2 and .3 for DNS).
Configure Network Security Groups
After creating subnets, secure them with NSGs. Create an NSG and define inbound/outbound rules. For a web subnet, add a rule to allow inbound HTTP (TCP 80) and HTTPS (TCP 443) from any source (Internet). For a database subnet, allow inbound only from the app subnet on SQL port (1433). Associate the NSG with the subnet or NIC. Azure evaluates rules in priority order (lowest number first). By default, all inbound traffic from the internet is denied, and all outbound traffic is allowed. NSGs are stateful—if you allow inbound on port 80, the return traffic is automatically allowed. Exam tip: NSGs filter traffic at Layer 3 and 4 (IP and port).
Connect to On-Premises (Optional)
If you need hybrid connectivity, create a gateway subnet (named 'GatewaySubnet' exactly) within the VNet. Then deploy a VPN gateway or ExpressRoute gateway. For a site-to-site VPN, you'll need a VPN device on-premises with a public IP. Create a local network gateway representing your on-premises network. Then create a connection between the VPN gateway and local gateway. The VPN gateway encrypts traffic using IPsec/IKE. This step can take 30-45 minutes to provision. Alternatively, use ExpressRoute for a dedicated private connection. Exam: Know that VPN gateways provide encrypted connectivity over the internet, while ExpressRoute is private and more reliable.
Peer VNets (Optional)
To connect VNets in the same or different regions, use virtual network peering. In the portal, go to your VNet, select 'Peerings' under Settings, and add a peering. You need to create two peerings (one from each VNet). Traffic between peered VNets stays on the Microsoft backbone and is private. You can peer VNets in the same subscription or across subscriptions. There is no downtime during peering creation. Exam: Peering is non-transitive by default—if VNet A peers with B and B peers with C, A does not communicate with C unless you explicitly set up transitive routing via a hub VNet or Azure Firewall.
Scenario 1: E-commerce Website with Multi-Tier Architecture
A startup builds an e-commerce platform on Azure. They create a VNet with three subnets: web, app, and data. The web subnet has a public IP and a load balancer (Azure Load Balancer) distributing traffic to multiple VMs running IIS. An NSG on the web subnet allows inbound HTTP/HTTPS from the internet. The app subnet contains VMs running business logic; its NSG allows inbound only from the web subnet on port 8080. The data subnet hosts SQL Server VMs; its NSG allows inbound only from the app subnet on port 1433. This setup prevents direct database access from the internet. The team uses Azure Bastion to securely RDP into VMs without public IPs. Cost: VNet is free; they pay for VMs, load balancer, and data transfer. If they misconfigure the NSG to allow all inbound from internet to the data subnet, a breach could expose customer data. They also set up a site-to-site VPN to connect to their on-premises inventory system, using a VPN gateway (VpnGw1 tier).
Scenario 2: Hybrid Cloud with ExpressRoute
A financial services company has a strict compliance requirement to keep data private. They use Azure ExpressRoute to connect their on-premises data center to an Azure VNet via a dedicated fiber connection. The VNet is divided into subnets for different environments (dev, test, prod). They use Azure Firewall to inspect all traffic between subnets and to the internet. They also peer the VNet with another VNet in a different region for disaster recovery. The ExpressRoute circuit provides a 99.95% SLA (higher than VPN). Misconfiguration: If they forget to add a route for the on-premises network in the VNet, traffic will not flow. They use user-defined routes (UDRs) to direct traffic to the firewall. Cost: ExpressRoute has monthly port fees and data transfer charges. The company saves on MPLS costs by moving to Azure.
Scenario 3: Microservices with Service Endpoints
A SaaS provider runs microservices on Azure Kubernetes Service (AKS). The AKS cluster is deployed in a VNet. They need secure access to Azure Storage and Azure SQL Database without exposing these services to the internet. They enable service endpoints on the VNet for Storage and SQL. This ensures traffic from the VNet to these services stays on the Microsoft backbone and uses private IPs. They also use Private Link for Azure Cosmos DB to get a private IP in the VNet. Problem: If they don't enable service endpoints, traffic to Storage goes over the internet, even though it's encrypted. The team uses Azure Policy to enforce service endpoints on all VNets. Cost: Service endpoints are free; Private Link charges for the endpoint and data processed.
Objective 2.3: Describe core networking services
This objective covers VNet, VPN Gateway, ExpressRoute, Azure DNS, Azure Firewall, and Azure Front Door. For VNet specifically, expect 2-4 questions on the exam. The exam tests your understanding of: what a VNet is, its purpose (isolation, segmentation, connectivity), key components (subnets, NSGs), and how it differs from on-premises networking.
Common Wrong Answers and Why Candidates Choose Them
'VNets are required for all Azure resources.' Wrong. Some resources (like App Service on multitenant plan) can be accessed via public endpoint without a VNet. However, many resources benefit from VNet integration. Candidates choose this because they think all resources need private networking.
'NSGs can filter traffic at the application layer (Layer 7).' Wrong. NSGs filter at Layers 3 and 4 (IP, port, protocol). Azure Firewall or Application Gateway can do Layer 7 filtering. Candidates confuse NSGs with firewalls.
'VNet peering supports transitive routing automatically.' Wrong. By default, peering is non-transitive. Candidates assume it works like a router.
'A VNet can be moved to another region after creation.' Wrong. VNets are regional resources; you cannot change the region. You must delete and recreate. Candidates think resources can be moved easily.
Specific Terms and Values
Private IP ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.
Subnet limits: 1,000 subnets per VNet.
NSG rule priority: 100 to 4096.
VPN gateway: Basic tier supports up to 100 tunnels; VpnGw1 supports up to 30 tunnels.
ExpressRoute SLA: 99.95% for dedicated circuit.
Edge Cases and Tricky Distinctions
VNet vs. Virtual Network (classic): Classic VNets are legacy; new deployments use Resource Manager VNets. Exam may ask about differences.
Service Endpoints vs. Private Link: Both provide secure access to Azure services. Service Endpoints extend VNet identity to the service; Private Link gives a private IP in the VNet. Private Link is more secure and recommended.
Azure DNS: Not a VNet component but often tested together. Azure DNS provides name resolution; you can use custom DNS servers in a VNet.
Memory Trick: 'VNet = Virtual Isolation'
Remember: VNet gives you a private, isolated network in Azure. Use the acronym 'VIP' for key features: Virtual isolation, IP address control, and Private connectivity. For exam questions, if an answer says 'global' or 'multi-region' for VNet, it's wrong (VNet is regional). If it says 'Layer 7 filtering' for NSG, it's wrong. If it says 'transitive peering' without a hub, it's wrong.
Azure VNet is a logically isolated network in the Azure cloud, confined to a single region.
You define private IP address space (RFC 1918) and divide it into subnets.
Network Security Groups (NSGs) filter traffic at Layers 3 and 4 (IP, port, protocol) with priority rules (100-4096).
VNet peering connects two VNets in the same or different regions; it is non-transitive by default.
VPN Gateway provides encrypted site-to-site or point-to-site connectivity over the internet; ExpressRoute provides private dedicated connectivity.
Azure reserves the first four and last IP address in each subnet for infrastructure use.
Service Endpoints extend VNet identity to Azure PaaS services; Private Link gives a private IP in the VNet.
VNet itself is free; you pay for gateways, public IPs, and data transfer.
A VNet cannot be moved to another region after creation; you must delete and recreate.
Azure automatically provides system routes within a VNet; you can override with user-defined routes (UDRs).
These come up on the exam all the time. Here's how to tell them apart.
Azure VNet
Logical isolation in Microsoft's physical infrastructure
No hardware to purchase; pay only for associated services
Scalable instantly; add subnets without physical changes
Managed by Azure; no rack space, power, or cooling concerns
Global connectivity via peering and VPN/ExpressRoute
On-Premises Network
Physical isolation in your own data center
Requires purchase of routers, switches, cables, firewalls
Scaling requires new hardware and cabling
Full control but full responsibility for maintenance
Limited to your physical premises; WAN connections needed for remote sites
VPN Gateway
Encrypted connectivity over the public internet
Lower cost; pay-as-you-go hourly + data out
Bandwidth up to 1.25 Gbps (VpnGw5)
SLA: 99.9% for gateway; 99.95% with active-active
Setup time: minutes to hours
ExpressRoute
Private, dedicated connection (not over internet)
Higher cost; monthly port fee + data transfer
Bandwidth up to 100 Gbps
SLA: 99.95% for dedicated circuit
Setup time: weeks (requires carrier coordination)
Mistake
A VNet is a physical network that spans multiple regions.
Correct
A VNet is a logical network confined to a single Azure region. You can connect VNets across regions using peering, but each VNet itself is regional.
Mistake
You need a VNet to deploy any Azure resource.
Correct
Many Azure resources (e.g., App Service, Storage, SQL Database) can be accessed via public endpoints without a VNet. However, VNet integration enhances security and is recommended for production workloads.
Mistake
Network Security Groups (NSGs) can inspect and filter application-layer traffic (HTTP, SQL).
Correct
NSGs operate at Layer 3 and 4 (IP, port, protocol). For application-layer filtering, you need Azure Firewall, Application Gateway (WAF), or a network virtual appliance.
Mistake
Azure VNet provides a default route to the internet for all resources.
Correct
By default, Azure creates a system route that enables outbound internet connectivity for resources with public IPs or via default outbound access. However, inbound internet traffic is blocked by default unless you add an NSG rule.
Mistake
VNet peering allows resources in one VNet to directly access resources in another VNet across subscriptions without any configuration.
Correct
Peering requires explicit configuration in both VNets. It is not automatic. Also, peering is non-transitive by default; you cannot go from VNet A to C via B unless you set up a hub-spoke topology.
Yes, you can add or remove address prefixes (e.g., add 10.1.0.0/16 to an existing VNet) as long as there are no conflicting subnets or peered VNets. However, you cannot change the existing prefix; you can only add new ones. Removing a prefix is possible only if no subnets use it. This is useful when you need to expand the VNet.
NSGs are distributed, stateful packet filters that operate at Layers 3 and 4 (IP and port). They are free and associated with subnets or NICs. Azure Firewall is a managed, centralized firewall service that provides Layer 3-7 inspection, threat intelligence, and FQDN filtering. Azure Firewall is a paid service with higher cost but more features. For exam: NSG is for basic traffic filtering; Azure Firewall is for advanced security.
Yes, you can use a single VPN gateway to connect to multiple on-premises networks by creating multiple local network gateways and connections. However, the VPN gateway has a limit on the number of tunnels (e.g., VpnGw1 supports up to 30 tunnels). For large-scale connectivity, consider using ExpressRoute with a hub VNet.
By default, Azure provides outbound connectivity via Source Network Address Translation (SNAT) using a public IP dynamically assigned by Azure. This is called 'default outbound access' and is not recommended for production because the IP can change. For a stable outbound IP, assign a public IP to the VM or use a NAT gateway.
You can use service endpoints to extend your VNet's private address space to Azure Storage, ensuring traffic stays on the Microsoft backbone. Alternatively, use Private Link to assign a private IP to the storage account within your VNet. Service endpoints are free and easier to set up; Private Link provides more granular control and is recommended for compliance.
A VNet is regional, so if the region experiences a full outage, the VNet and its resources become unavailable. To achieve disaster recovery, you should deploy resources in multiple regions and use VNet peering or VPN gateways to connect them. Azure Site Recovery can help replicate VMs across regions.
Yes, you can peer VNets in different subscriptions within the same Azure AD tenant. You need to create a peering from each VNet, and the user must have the necessary permissions (e.g., Network Contributor role). This allows resources in different subscriptions to communicate privately.
You've just covered Azure Virtual Networks (VNet) — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?