The Complete Guide to Networking Design from VNet to Front Door

Master the Azure networking services that always appear on the AZ-305 exam. Deep-dive into VNet design, ExpressRoute, and Front Door vs. Application Gateway based on real exam patterns.

Networking is one of the most challenging domains on the AZ-305 exam. You need a precise understanding of service boundaries: the difference between Front Door and Traffic Manager, the limitations of Application Gateway, and why BGP is mandatory with ExpressRoute. This article focuses on the core patterns extracted from analyzing 42 real exam questions.

---

 

VNet and Subnet Design

A VNet belongs to a single Azure region. If you deploy infrastructure across 3 regions, the minimum number of VNets is 3, and tier separation (frontend/backend/DB) is handled at the subnet level. A common exam trap is calculating region count × tier count when asked for the "minimum number of VNets."

In hybrid environments, IP address space conflicts are fatal. Overlapping addresses make routing impossible with no workaround. Azure reserves 5 IP addresses per subnet (network address, gateway, two DNS, and broadcast). A /24 subnet provides 251 usable addresses, which is more than enough for 150 VMs.

GatewaySubnet Design Principles

The subnet for a VPN Gateway or ExpressRoute Gateway must be named exactly . Three strict rules apply.

Dedicated subnet required: you cannot place workloads like VMs in this subnet alongside the gateway. NSG must not be applied: applying an NSG blocks control-plane traffic and causes tunnel failures. Recommended size: /27 or larger. A /27 is the safe choice when planning for an ExpressRoute migration or co-existence of two gateways.

The fundamental prerequisite for VNet Peering is that the address spaces of the two VNets must not overlap. If they do overlap, you must redesign the IP space — there is no workaround using NAT Gateway or VPN Gateway.

---

 

Hybrid Connectivity: VPN Gateway and ExpressRoute

ExpressRoute uses BGP (Border Gateway Protocol) as its sole routing protocol. If you see a static routing option in an exam question, eliminate it immediately. When site A fails, the BGP session terminates and traffic automatically fails over to site B within seconds. To distinguish primary from backup paths in a redundant setup, use AS Path Prepending: keep the AS Path short for the primary path (site A) and long for the backup (site B).

When the keywords "automatic failover + dynamic routing" appear, choose BGP. When the requirement is to "pin routes manually," choose UDR.

Azure Virtual WAN SKU Selection

Virtual WAN comes into play when you need to manage multiple sites from a central hub.

Basic SKU: supports Site-to-Site VPN only. ExpressRoute and cross-region transitive routing are not supported. Standard SKU: supports ExpressRoute, S2S VPN, P2S VPN, and cross-region transitive routing.

Whenever the exam mentions ExpressRoute or cross-region transitive routing, the answer is always Standard SKU. For hub placement, if the requirement is "nearest-region routing across N continents," you need a minimum of N hubs. A Secured Virtual Hub integrates Azure Firewall into the hub. When the three keywords P2S + transitive routing + FQDN filtering appear together, select Virtual WAN Standard + Secured Virtual Hub.

---

 

Global Traffic Routing: Front Door, Traffic Manager, CDN

Front Door is a Layer 7 proxy that operates via Anycast across Microsoft's global edge network. It accepts traffic at the PoP closest to the user and enforces WAF policies at the edge. It delivers cross-region automatic failover (within seconds), built-in WAF (SQL Injection, XSS, bots, rate limiting), SSL offloading, URL path-based routing, and cookie-based session affinity — all as a single service.

Front Door Premium supports Private Link origins. Backend VMs are never exposed to the internet; Front Door connects via a private path instead. To allow only Front Door traffic in an NSG, use the service tag. Microsoft maintains it automatically, so you never need to manage IP lists.

Traffic Manager is a DNS-based traffic delivery service. It simply returns the optimal endpoint IP to the client as a DNS response — no traffic packets pass through it. Because of this non-intercepting architecture, it cannot perform HTTP header manipulation, rate limiting, or SSL offloading. Layering it with per-region Application Gateway WAF is a powerful pattern: Traffic Manager selects the region at the DNS level, while Application Gateway handles HTTP header routing and WAF.

---

 

Load Balancing: Application Gateway and Azure Load Balancer

Application Gateway is a single-region Layer 7 load balancing service. It has no cross-region routing or automatic failover capability. To serve multiple regions, you deploy separate instances in each region and place Traffic Manager or Front Door above them. The WAF SKU provides OWASP CRS-based SQL Injection and XSS protection, cookie-based session affinity, URL path-based routing, and autoscaling. When the requirement is "WAF + session affinity + load balancing as a single service," Application Gateway WAF is the answer.

The pattern of combining API Management (APIM) with Application Gateway is also tested. External traffic enters through Application Gateway (WAF) and is forwarded to APIM inside the VNet. APIM in Internal mode receives only a private IP and cannot be accessed directly from the internet, making it suitable for internal-team-only scenarios.

Azure Load Balancer is a single-region OSI Layer 4 (TCP/UDP) service. It has no HTTP header routing, no WAF, and no cross-region failover. Gateway Load Balancer transparently inserts third-party NVAs into an existing load balancer using VXLAN tunneling. Select it when you see the keyword combination "third-party NVA + transparent L4 insertion + minimize changes to existing configuration."

!Application Gateway versus Azure Load Balancer

Service Comparison Table

| Feature | Front Door | Traffic Manager | Application Gateway | Azure Load Balancer | |---------|-----------|----------------|---------------------|--------------------| | Layer | L7 (HTTP/HTTPS) | DNS-based | L7 (HTTP/HTTPS) | L4 (TCP/UDP) | | Scope | Global | Global | Single region | Single region | | Built-in WAF | Yes | No | Yes (WAF SKU) | No | | Session affinity | Yes | No | Yes (cookie) | No | | Regional failover | Automatic (seconds) | DNS TTL-based | None | None | | Primary use case | Global L7 app delivery | DNS geo-routing | Regional L7 + WAF | Regional L4 balancing |

---

 

Decision Criteria That Commonly Trip Up Exam Candidates

When a single service needs to cover global HTTP/HTTPS + SSL termination + automatic failover, choose Front Door. Traffic Manager cannot terminate SSL, and Application Gateway is limited to a single region.

When the requirement is geographic nearest-routing + per-region HTTP header routing + WAF, choose the layered pattern of Traffic Manager + Application Gateway WAF. Azure Load Balancer does not support HTTP headers or WAF, so a Front Door + Load Balancer combination falls short.

When an on-premises app must be exposed externally, servers must not be directly exposed, and Entra ID authentication is required simultaneously, choose Microsoft Entra Application Proxy. Installing only a connector agent on-premises allows external access without changing any inbound firewall rules, and Conditional Access with MFA is supported natively.

When you need to resolve Private Endpoint FQDNs from on-premises DNS over ExpressRoute, combine Azure Private DNS Zone with a DNS Private Resolver inbound endpoint. Configure conditional forwarding on the on-premises DNS server for the domain to point to the inbound endpoint IP, and you will receive private IP responses.

When you need to immediately verify whether an NSG is blocking traffic, choose Network Watcher IP Flow Verify. Enter the 5-tuple and it returns the NSG allow/deny result and the matching rule name within seconds. NSG Flow Logs are a post-hoc aggregation tool and are not suitable for immediate diagnosis.

---

 

Practical Implementation Tips

In every scenario involving Private Endpoint, you must think through the DNS design as well. Create an Azure Private DNS Zone and link it to the VNet so that FQDNs resolve automatically to private IPs. When connecting App Service and SQL Database privately, you need at least two separate subnets. The App Service VNet Integration subnet (minimum /28) and the Private Endpoint subnet serve different roles and cannot be shared.

To centrally validate JWT tokens in API Management, configure the policy at the gateway level. This lets you enforce token validation across all APIs without modifying any backend API code. To configure private connectivity to PaaS services in Synapse Analytics, you must enable Managed Virtual Network when creating the workspace. This setting cannot be changed after creation, so it must be decided at the design stage.

---

 

Summary

Here are the decision criteria that appear repeatedly in AZ-305 networking questions.

Global L7 + WAF + automatic failover as a single service → Front Door DNS geo-routing + per-region L7 WAF → Traffic Manager + Application Gateway layered L4 load balancing between VMs in a single region → Azure Load Balancer ExpressRoute automatic failover → BGP + AS Path Prepending Virtual WAN + ExpressRoute or cross-region transitive routing → Standard SKU required GatewaySubnet: no NSG, /27 or larger, dedicated subnet VNet Peering: overlapping IP address spaces cannot be worked around — redesign is mandatory Immediate NSG diagnosis → Network Watcher IP Flow Verify

If you categorize each service by its operating layer (L4 vs L7), scope (single region vs global), and packet-interception model (proxy vs DNS), you will be able to answer most selection questions with confidence.

Back to blog list