This chapter covers designing network solutions in Azure, focusing on virtual network connectivity, hybrid networking, name resolution, and traffic management. For the AZ-305 exam, this domain typically constitutes 15-20% of questions, with a strong emphasis on choosing between VNet peering, VPN gateways, ExpressRoute, and Azure DNS configurations. You will learn the architectural decisions, constraints, and best practices required to design secure, high-performance, and cost-effective network topologies in Azure.
Jump to a section
Think of Azure Virtual Networks (VNets) as individual cities, each with its own internal road network (subnets and IP addressing). VNet peering is like building a direct, limited-access highway between two cities. When you establish a peering, you create two one-way toll roads: one from City A to City B, and another from City B to City A. Each city’s traffic control (route tables) decides which traffic can use the highway. The highway itself has no traffic lights—packets flow at layer 3 with minimal latency. Unlike the public internet (which would be like driving through many small towns with stop signs), a peering highway is non-transitive: a highway from City A to City B and City B to City C does not allow A to reach C directly—you’d need a separate A-to-C connection. Also, the highway does not support overlapping street addresses: if both cities have a “Main Street” (overlapping IP ranges), the highway cannot route correctly. In Azure, you explicitly allow or deny traffic using peering settings, similar to setting up toll booths that only permit certain vehicles (forwarded traffic) or allow all traffic (gateway transit). Just as highways have speed limits and maintenance costs, VNet peering has bandwidth limits (varies by VM size) and incurs data transfer charges (ingress/egress fees).
Azure Virtual Networks (VNets) and Subnets
An Azure Virtual Network (VNet) is a logically isolated network in the Azure cloud. Each VNet has its own IP address space, specified using CIDR notation (e.g., 10.0.0.0/16). You can divide a VNet into subnets to segment traffic and apply network security groups (NSGs) or route tables. Subnets must have at least one address range; Azure reserves the first four and last IP addresses in each subnet for protocol purposes (e.g., network address, broadcast, default gateways). The smallest subnet size is /29 (8 IPs, 3 usable after reservations), but for most workloads you need at least a /24 (256 IPs, 251 usable).
VNet Peering
VNet peering connects two VNets in the same or different regions (global peering) via the Azure backbone. Traffic between peered VNets stays within Microsoft's network, never traversing the public internet. Peering is non-transitive: if VNet A is peered to B, and B to C, A cannot reach C directly. You must explicitly peer A to C. Peering supports gateway transit: one VNet can use the VPN/ExpressRoute gateway of a peered VNet to connect to on-premises networks. When you create a peering, you configure two directions—each side must accept the peering. You can also allow or deny forwarded traffic (traffic from a third VNet passing through) and allow or deny gateway transit. Key constraints: VNet address spaces must not overlap; you cannot peer VNets with overlapping address spaces. Global peering works across Azure regions but does not support virtual machine extension-based load balancers (e.g., Azure Load Balancer with backend VMs in another region via global peering is not supported).
Hybrid Connectivity: VPN Gateway and ExpressRoute
Azure VPN Gateway connects on-premises networks to Azure via site-to-site (S2S) VPN over the internet (IPsec/IKE) or point-to-site (P2S) VPN for individual clients. VPN Gateway is deployed in a dedicated subnet called GatewaySubnet (minimum /27). There are two SKU families: VpnGw1-5 (based on throughput: 100 Mbps to 10 Gbps) and VpnGw1-5AZ (availability zones). For S2S, you need a public IP for the VPN device and must configure a local network gateway representing the on-premises network. The gateway uses active-active or active-passive mode; active-active provides higher availability using two instances.
ExpressRoute provides private, dedicated connectivity to Azure from on-premises via a connectivity provider (e.g., Equinix, Level 3). It offers higher reliability, faster speeds (50 Mbps to 10 Gbps), lower latency, and no internet dependency. ExpressRoute circuits are redundant (two connections to two Microsoft Enterprise Edge routers). You can connect to Azure via peering: Microsoft peering (for public services like Azure PaaS) or private peering (for VNets). For private peering, you must configure a VLAN ID and BGP session. ExpressRoute Global Reach extends connectivity between on-premises sites via Azure backbone. Key exam point: ExpressRoute does not encrypt traffic by default; you can add IPsec over ExpressRoute for encryption.
Azure DNS and Private DNS Zones
Azure DNS hosts your domain records and provides name resolution using Microsoft's global infrastructure. For private DNS in VNets, you use Azure Private DNS Zones, which are authoritative DNS zones that are resolvable only within specified VNets. You can link a private zone to multiple VNets (registration VNets and resolution VNets). Registration VNets automatically register VM DNS records; resolution VNets can query the zone. Private zones support split-horizon DNS: the same name (e.g., contoso.com) can resolve to private IPs in Azure and public IPs on the internet. For custom DNS servers, you can set the VNet’s DNS servers to custom IPs (e.g., on-premises DCs). Azure also provides Azure DNS Private Resolver (a service that allows DNS resolution between on-premises and Azure without a VM).
Traffic Management: Azure Load Balancer, Traffic Manager, and Front Door
Azure Load Balancer (Layer 4) distributes incoming traffic across backend pool instances (VMs or VMSS). It supports inbound NAT rules, health probes (HTTP, TCP, HTTPS), and session persistence (source IP, client IP, protocol). Basic SKU is free but has no SLA; Standard SKU provides SLA, availability zones, and outbound SNAT. For global load balancing, use Traffic Manager (DNS-based) or Azure Front Door (Layer 7 with WAF, SSL termination, URL-based routing). Traffic Manager uses DNS to route traffic based on routing methods: Performance (lowest latency), Geographic, Priority, Weighted, or Multivalue. Front Door is a modern CDN and application firewall with global anycast.
Network Security Groups (NSGs) and Application Security Groups (ASGs)
NSGs filter traffic at the subnet or NIC level with rules (source, destination, port, protocol, priority). Each NSG has default rules (deny all inbound, allow all outbound, allow VNet inbound, allow Azure Load Balancer probe). You cannot delete default rules but can override them with higher-priority custom rules (priority 100-4096). ASGs allow you to group VMs logically (e.g., all web servers) and reference them in NSG rules instead of IP addresses. This simplifies rule management.
Azure Firewall and Azure DDoS Protection
Azure Firewall is a managed, stateful firewall as a service with built-in high availability (auto-scales up to 100 Gbps). It supports application rules (FQDN filtering), network rules (IP/port), threat intelligence, and DNS proxy. You deploy it in a dedicated subnet called AzureFirewallSubnet (minimum /26). For DDoS protection, Azure provides Basic (free, always-on) and Standard (paid, adaptive tuning, mitigation policies). Standard DDoS protection covers public IPs associated with VMs, load balancers, and application gateways.
Service Endpoints and Private Link
Service Endpoints secure Azure service traffic (e.g., Storage, SQL) to your VNet by exposing the service’s public IP to your VNet. They are free but limited to Azure services and do not allow on-premises access. Private Link (Private Endpoint) provides a private IP in your VNet for Azure PaaS services (e.g., Storage, SQL, Cosmos DB) or your own services behind a Standard Load Balancer. Traffic stays within Microsoft backbone. Private Endpoints are supported for many services and allow on-premises access via VPN/ExpressRoute. Key exam point: Private Endpoint uses a NIC with a private IP; you must disable public access to the service if you want to force traffic through the endpoint.
Route Tables and User-Defined Routes (UDRs)
Azure automatically creates system routes for each subnet (local VNet, peered VNets, internet, VPN gateway). You can override these with User-Defined Routes (UDRs) by specifying a next hop type: Virtual appliance, VNet peering, Virtual network gateway, Internet, or None. UDRs are applied at the subnet level. For forced tunneling (all internet traffic to on-premises), you create a default route (0.0.0.0/0) with next hop Virtual network gateway. UDRs are evaluated before NSGs.
Virtual WAN
Azure Virtual WAN is a managed networking service that consolidates connectivity, security, and routing in a single hub-and-spoke topology. It supports site-to-site VPN, ExpressRoute, point-to-site VPN, and Azure Firewall in the hub. VWAN simplifies large-scale branch connectivity and uses BGP for dynamic routing. For the AZ-305, know that VWAN is recommended for organizations with multiple branches and hybrid connectivity needs.
Plan IP Address Space
Determine the required IP address ranges for your Azure VNets and on-premises networks, ensuring no overlap. Use RFC 1918 private addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). For each VNet, allocate a contiguous CIDR block (e.g., /16 or /20) and split into subnets for tiers (web, app, data). Reserve a /27 or /26 subnet for GatewaySubnet if you plan to use VPN/ExpressRoute. Azure reserves the first four and last IP in each subnet, so plan for usable IPs accordingly. For example, a /24 subnet provides 251 usable addresses. Avoid overlapping with on-premises ranges to prevent routing conflicts when peering or connecting via VPN.
Create VNet and Subnets
In the Azure portal or via PowerShell/CLI, create a VNet with the chosen address space. Then create subnets with specific address prefixes. For example, create a subnet named 'web' with 10.0.1.0/24 and 'data' with 10.0.2.0/24. Use Azure CLI: 'az network vnet create -g MyRG -n MyVNet --address-prefix 10.0.0.0/16 --subnet-name web --subnet-prefix 10.0.1.0/24'. Ensure you have a GatewaySubnet if needed (name must be 'GatewaySubnet'). After creation, verify with 'az network vnet subnet list -g MyRG --vnet-name MyVNet'.
Establish VNet Peering
To connect two VNets, create a peering from each side. In the Azure portal, go to VNet A -> Peerings -> Add. Specify the remote VNet (B), name the peering (e.g., A-to-B), and configure settings: Allow virtual network access (Yes), Allow forwarded traffic (typically No unless using a network virtual appliance), Allow gateway transit (optional). Then repeat on VNet B. Once both peerings are accepted, traffic flows. Use CLI: 'az network vnet peering create -g MyRG -n A-to-B --vnet-name VNetA --remote-vnet VNetB --allow-vnet-access'. Verify with 'az network vnet peering list -g MyRG --vnet-name VNetA'.
Configure Hybrid VPN Gateway
To connect on-premises, first create a GatewaySubnet in the VNet (minimum /27). Then create a VPN gateway (VpnGw1 SKU or higher). Use CLI: 'az network vnet-gateway create -g MyRG -n MyGW --public-ip-address MyPIP --vnet MyVNet --gateway-type Vpn --sku VpnGw1 --vpn-type RouteBased'. Next, create a local network gateway representing on-premises: 'az network local-gateway create -g MyRG -n OnPremGW --gateway-ip-address <on-prem-public-IP> --local-address-prefixes 192.168.0.0/16'. Then create the S2S connection: 'az network vpn-connection create -g MyRG -n MyConn --vnet-gateway1 MyGW --local-gateway2 OnPremGW --shared-key MySecret'. Verify with 'az network vpn-connection show -g MyRG -n MyConn'. The gateway takes up to 45 minutes to provision.
Implement Private DNS Resolution
For internal name resolution, create an Azure Private DNS Zone (e.g., contoso.internal). Link it to VNets: registration VNet (auto-register VM DNS) and resolution VNets (query only). Use CLI: 'az network private-dns zone create -g MyRG -n contoso.internal'. Then create a link: 'az network private-dns link vnet create -g MyRG -n MyLink --zone-name contoso.internal --virtual-network MyVNet --registration-enabled true'. For custom DNS, set the VNet's DNS servers to custom IPs (e.g., 10.0.0.4) using 'az network vnet update -g MyRG -n MyVNet --dns-servers 10.0.0.4 10.0.0.5'. Verify DNS resolution by logging into a VM and using nslookup.
Scenario 1: Multi-tier Application with VNet Peering
A financial services company deploys a three-tier application (web, app, database) in separate VNets for security isolation. They use VNet peering to connect the VNets, with NSGs restricting traffic: web tier can talk to app tier on port 443, app tier to database on port 1433. They use global peering between two regions for disaster recovery. In production, they observed that global peering incurs egress charges ($0.02/GB outbound from each region) and has bandwidth limits (up to 10 Gbps per VM series). Misconfiguration often occurs when they forget to allow forwarded traffic for the network virtual appliance (NVA) in the hub VNet. They resolved this by setting 'allowForwardedTraffic: true' on the peering from the spoke to the hub. Also, they ensure no overlapping IPs between VNets; a common mistake is using the same 10.0.0.0/16 across multiple VNets, which breaks peering.
Scenario 2: Hybrid Cloud with ExpressRoute and VPN Failover
A manufacturing company connects its main office to Azure via ExpressRoute (1 Gbps) and uses a site-to-site VPN as backup (200 Mbps). They deploy a VPN gateway in active-active mode and an ExpressRoute gateway in the same VNet. They configure BGP over both connections with appropriate AS numbers and prefer ExpressRoute via local preference. In production, they noticed that failover takes about 30 seconds (BGP convergence). Common pitfall: they initially used overlapping IP ranges between on-premises and Azure, causing asymmetric routing. They resolved by re-IPing on-premises to a non-overlapping range (10.1.0.0/16 vs Azure 10.0.0.0/16). They also enable FastPath for ExpressRoute to reduce latency. For cost optimization, they use ExpressRoute with unlimited data plan (if high usage) and choose the appropriate gateway SKU (ErGw3AZ for 10 Gbps).
Scenario 3: Secure PaaS Access with Private Endpoints
A healthcare startup uses Azure SQL Database and Blob Storage. To avoid public internet exposure, they deploy Private Endpoints in their VNet for both services. They disable public access on the SQL server and storage account. They configure DNS to resolve the private endpoint IPs using Azure Private DNS Zones (privatelink.database.windows.net and privatelink.blob.core.windows.net). They link the private DNS zone to their VNet. In production, they initially forgot to disable public network access on the storage account, causing data exfiltration risk. They also had issues with on-premises access: they needed to configure custom DNS forwarders to resolve the private zone. They set up an Azure DNS Private Resolver for hybrid resolution. Performance is excellent (sub-millisecond latency within region). They monitor via Azure Monitor for Private Endpoint metrics (bytes in/out, packets dropped).
AZ-305 Exam Focus: Designing Network Solutions (Objective 4.2)
The exam tests your ability to recommend an appropriate networking solution based on requirements for connectivity, performance, security, and cost. Specific sub-objectives include: - 4.2.1: Recommend a network architecture (hub-spoke, VNet peering, Virtual WAN) - 4.2.2: Recommend a connectivity solution (VPN, ExpressRoute, or both) - 4.2.3: Recommend a name resolution solution (Azure DNS, custom DNS, private DNS zones) - 4.2.4: Recommend a traffic management solution (Load Balancer, Traffic Manager, Front Door, Application Gateway)
Common Wrong Answers and Why Candidates Choose Them
Choosing VNet peering for transitive routing: Many candidates assume VNet Peering is NOT transitive (like a router). In reality, it is non-transitive. The exam will present a scenario with three VNets (A, B, C) where A is peered to B and B to C, and ask if A can reach C. The correct answer is No unless explicit A-C peering exists. Candidates choose Yes because they think peering works like a physical network switch.
Selecting ExpressRoute without encryption: Candidates often forget that ExpressRoute does not encrypt data by default. The exam may ask: 'You need encrypted traffic between on-premises and Azure over ExpressRoute. What should you do?' The correct answer is to implement IPsec over ExpressRoute (e.g., using a VPN gateway or NVA). Wrong answer: 'ExpressRoute provides encryption' or 'Use Azure Firewall' (which does not encrypt by itself).
Using Service Endpoints instead of Private Endpoints for on-premises access: Service Endpoints only provide access from VNets, not from on-premises. The exam scenario: 'You need to securely access Azure Storage from on-premises via ExpressRoute.' Candidates choose Service Endpoints because they are free and simple, but the correct answer is Private Endpoints (or Private Link). Service Endpoints expose the service's public IP, which is not routable from on-premises via private peering.
Overlooking GatewaySubnet size: The exam may give a scenario where a VPN gateway fails to provision because the GatewaySubnet is too small (e.g., /29). Candidates often think any subnet size works, but the minimum is /27 (or /26 for some SKUs). They also miss that the subnet must be named exactly 'GatewaySubnet'.
Specific Values and Terms That Appear on the Exam
GatewaySubnet minimum size: /27 (or /26 for high-performance SKUs)
AzureFirewallSubnet minimum size: /26
VNet peering: non-transitive, supports gateway transit
ExpressRoute: private peering for VNets, Microsoft peering for PaaS
VPN Gateway: RouteBased (IKEv2) required for S2S; PolicyBased only supports basic SKU
Private DNS zone: registration VNet auto-registers, resolution VNet queries
Load Balancer: Standard SKU required for availability zones and outbound SNAT
Traffic Manager: routing methods include Performance, Geographic, Priority, Weighted, Multivalue
Front Door: Layer 7, supports WAF, URL rewrite, SSL offload
Edge Cases and Exceptions
Global VNet peering does not support virtual machine extension-based load balancers (e.g., you cannot have a load balancer in one region with backend VMs in another region via global peering).
ExpressRoute with Microsoft peering can access Azure public services (e.g., Office 365, Dynamics 365) but requires route filters.
Azure Firewall in Forced Tunneling mode: you must configure a default route to the firewall, but the firewall itself cannot be forced tunneled.
Private Endpoints and Service Endpoints cannot coexist on the same subnet for the same service.
VPN Gateway active-active mode requires two public IPs.
How to Eliminate Wrong Answers Using the Underlying Mechanism
Always map the requirement to the underlying technology's capabilities. For connectivity, ask: Is it within Azure? Use VNet peering. To on-premises? Use VPN or ExpressRoute. Need low latency and high bandwidth? ExpressRoute. Need encryption? Add IPsec. For name resolution: Need private DNS? Azure Private DNS Zone. Need custom DNS? Set VNet DNS servers. For traffic management: Layer 4? Load Balancer. Layer 7? Application Gateway or Front Door. Global? Traffic Manager or Front Door. Security? Azure Firewall or NSGs. By understanding the mechanism (e.g., peering is non-transitive because it's a simple layer 3 connection without routing protocols), you can eliminate options that violate that property.
VNet peering is non-transitive and requires explicit peerings between each pair of VNets.
ExpressRoute does not encrypt traffic by default; use IPsec over ExpressRoute for encryption.
Private Endpoints (Private Link) provide private IP access to PaaS services and support on-premises connectivity via VPN/ExpressRoute.
GatewaySubnet must be at least /27 and named exactly 'GatewaySubnet'.
Azure Firewall requires a dedicated subnet named 'AzureFirewallSubnet' with minimum /26.
VNet peering requires non-overlapping address spaces.
Traffic Manager uses DNS-based routing; Azure Front Door provides Layer 7 global load balancing with WAF.
Service Endpoints are free but only work from VNets, not from on-premises.
For high availability, use active-active VPN gateways (two public IPs) and ExpressRoute circuits with redundant connections.
Azure Virtual WAN simplifies hub-and-spoke networking for large-scale branch connectivity.
These come up on the exam all the time. Here's how to tell them apart.
VNet Peering
Connects VNets within Azure (same or different regions) using Azure backbone
No public internet exposure; traffic stays within Microsoft network
Supports up to 10 Gbps per peering (limited by VM NIC bandwidth)
No encryption overhead; traffic is isolated at layer 3
Cost: data transfer charges (ingress/egress) based on zone/region
VPN Gateway
Connects on-premises networks to Azure over the internet (S2S VPN) or clients (P2S)
Traffic traverses public internet with IPsec encryption
Throughput up to 10 Gbps (VpnGw5) but typically lower due to encryption and internet conditions
Encryption is mandatory (IPsec/IKE); adds latency overhead
Cost: hourly gateway instance fee plus data transfer charges
Mistake
VNet peering is transitive by default.
Correct
VNet peering is strictly non-transitive. Traffic between two peered VNets does not automatically flow to a third peered VNet. You must create explicit peerings between each pair of VNets that need to communicate.
Mistake
ExpressRoute encrypts all traffic by default.
Correct
ExpressRoute provides a private, dedicated connection but does not encrypt data. To encrypt traffic, you must implement IPsec over ExpressRoute (e.g., using a VPN gateway or a network virtual appliance) or use application-level encryption (HTTPS, TLS).
Mistake
Service Endpoints allow on-premises access to Azure PaaS.
Correct
Service Endpoints only extend the service's public IP to your VNet. On-premises traffic cannot use Service Endpoints because on-premises networks are not part of the VNet. For on-premises access, use Private Endpoints (Private Link) which provide a private IP routable from on-premises via VPN/ExpressRoute.
Mistake
You can peer VNets with overlapping IP address ranges.
Correct
VNet peering requires that the address spaces of the VNets do not overlap. Overlapping ranges cause routing conflicts and the peering creation will fail. If overlapping is unavoidable, use NAT or re-IP one VNet.
Mistake
Azure Firewall can be deployed in any subnet.
Correct
Azure Firewall must be deployed in a dedicated subnet named 'AzureFirewallSubnet' with a minimum size of /26. It cannot be placed in a regular subnet or the GatewaySubnet.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
VNet peering connects two Azure VNets directly over Microsoft's backbone with low latency and high throughput (up to 10 Gbps). It is non-transitive and has no encryption overhead. VPN gateway connects on-premises networks to Azure over the internet using IPsec encryption, with throughput up to 10 Gbps (VpnGw5) but typically lower. Use peering for VNet-to-VNet within Azure; use VPN for hybrid connectivity. Exam tip: if the requirement is to connect two VNets in the same region, always prefer peering over VPN for performance and cost.
Use Private Endpoint when you need private IP access from on-premises (via VPN/ExpressRoute) or from other VNets. It also allows you to disable public access to the service. Service Endpoint is simpler and free but only works from VNets (not on-premises) and does not provide a private IP—it still uses the service's public endpoint. Exam tip: if the question mentions 'on-premises' or 'private IP', choose Private Endpoint. If it says 'from VNet only' and cost is a concern, Service Endpoint may be acceptable.
Yes, you can use a VPN gateway in each VNet to create a VNet-to-VNet connection. However, this is less efficient than VNet peering because it adds encryption overhead and incurs gateway costs. VNet peering is the preferred method for VNet-to-VNet connectivity within Azure. The exam will expect you to recommend peering unless there is a specific requirement for encryption (which peering does not provide) or cross-region connectivity with certain limitations.
Azure Load Balancer operates at Layer 4 (TCP/UDP) and distributes traffic within a region to backend pool instances (VMs). It is ideal for internal or external traffic to a single region. Traffic Manager operates at DNS level (Layer 7) and directs traffic to different endpoints (e.g., regional deployments) based on routing methods (performance, priority, etc.). It is used for global load balancing. Exam tip: if the requirement is global traffic distribution, use Traffic Manager or Front Door; if regional, use Load Balancer or Application Gateway.
Configure forced tunneling by adding a User-Defined Route (UDR) on the subnet with destination 0.0.0.0/0 and next hop type 'Virtual network gateway' (VPN gateway). Then set the VPN gateway to route internet traffic to on-premises. Alternatively, use Azure Firewall as the next hop (set next hop to 'Virtual appliance' with the firewall's private IP). Note: forced tunneling with VPN gateway requires the gateway to be configured for forced tunneling (using BGP or custom routes). Exam tip: forced tunneling is a common scenario for compliance and security.
Azure Virtual WAN is a managed networking service that provides a hub-and-spoke topology with integrated connectivity (VPN, ExpressRoute, P2S) and security (Azure Firewall). It is designed for large enterprises with many branches and hybrid connectivity needs. Use it when you have more than 10 branches, need centralized management, or want to simplify routing with BGP. For smaller deployments, traditional hub-spoke with VNet peering and individual gateways may be simpler and cheaper.
Yes, you can use overlapping IP addresses in different VNets as long as they are not connected via peering or VPN. If you need to connect them, the addresses must not overlap. If overlapping is unavoidable, you can use NAT (e.g., Azure Firewall or an NVA) to translate addresses. However, this adds complexity. Best practice is to plan unique IP ranges for each VNet and on-premises network.
You've just covered Designing Azure Network Solutions — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?