Azure Networking Deep Dive
Advanced networking with Private Link, Application Gateway, and ExpressRoute patterns.
Prerequisites
- VNet architecture fundamentals
- Understanding of TCP/IP, DNS, and routing
- Experience with Azure networking services
Azure Networking Deep Dive
Azure networking extends far beyond basic VNets and subnets. This advanced guide covers the full networking stack: load balancers, application gateways, Azure Front Door, traffic routing, hybrid connectivity with VPN and ExpressRoute, Azure Firewall, Private Link, DNS architecture, and network monitoring. Understanding how these services interact is essential for designing production-grade architectures that are secure, performant, and resilient.
Where the VNet Architecture guide covers foundational network design, this guide focuses on the services and patterns that run on top of that foundation. We will explore how to route traffic globally, inspect it for threats, connect to on-premises datacenters, and troubleshoot connectivity issues when things go wrong.
Start with VNet fundamentals: IP planning, hub-spoke, subnets, and peeringLoad Balancing Options
Azure offers four primary load balancing services. Choosing the right one (or combination) depends on whether traffic is HTTP or non-HTTP, global or regional, and what features you need like WAF, SSL offload, or URL-based routing.
| Service | Layer | Scope | Protocol | Key Features | Best For |
|---|---|---|---|---|---|
| Azure Front Door | L7 | Global | HTTP/HTTPS | CDN, WAF, SSL offload, caching, anycast | Global web apps, APIs, static sites |
| Traffic Manager | DNS | Global | Any | DNS-based routing, health checks | Multi-region failover for any protocol |
| Application Gateway | L7 | Regional | HTTP/HTTPS | WAF, URL routing, SSL termination, rewrites | Regional web apps, path-based routing |
| Azure Load Balancer | L4 | Regional | TCP/UDP | HA ports, floating IP, outbound rules | Non-HTTP workloads, internal services |
Combining Load Balancers
Production architectures often stack load balancers for defense in depth. A common pattern: Azure Front Door for global L7 routing, CDN caching, and WAF protection at the edge, forwarding to Application Gateway per region for path-based routing and additional WAF rules, which distributes traffic to backend pools (App Service, VMs, or AKS). For non-HTTP services (databases, message queues, custom TCP protocols), use Azure Load Balancer internally.
Decision Framework for Load Balancing
Is the traffic HTTP/HTTPS?
YES -> Do you need global distribution?
YES -> Azure Front Door (Premium for WAF + Private Link)
NO -> Application Gateway v2 (with WAF if needed)
NO -> Do you need global distribution?
YES -> Traffic Manager (DNS-based, works with any protocol)
NO -> Azure Load Balancer
Standard SKU: cross-zone, HA ports
Internal: for private backend services
Public: for internet-facing non-HTTP
Common combinations:
Web app: Front Door -> App Gateway -> App Service
API + backend: Front Door -> Load Balancer (internal) -> AKS
Multi-region: Front Door -> App Service (per region)
Non-HTTP: Traffic Manager -> Load Balancer (per region)Azure Front Door and WAF
Azure Front Door Premium is the recommended entry point for global web applications. It combines global load balancing, SSL termination, HTTP/2 and HTTP/3 support, caching, URL-based routing, and Web Application Firewall (WAF) in a single service deployed at Microsoft's edge network with over 200 Points of Presence worldwide.
Front Door Tiers
| Feature | Standard | Premium |
|---|---|---|
| Global load balancing | Yes | Yes |
| SSL termination | Yes | Yes |
| Caching / CDN | Yes | Yes |
| Custom WAF rules | Yes | Yes |
| Managed WAF rule sets | Yes (DRS) | Yes (DRS + Bot Manager) |
| Private Link origins | No | Yes |
| Bot protection | No | Yes |
| DDoS protection | Basic | Enhanced |
resource frontDoorProfile 'Microsoft.Cdn/profiles@2023-05-01' = {
name: 'myapp-fd'
location: 'global'
sku: {
name: 'Premium_AzureFrontDoor'
}
}
resource endpoint 'Microsoft.Cdn/profiles/afdEndpoints@2023-05-01' = {
parent: frontDoorProfile
name: 'myapp-endpoint'
location: 'global'
properties: {
enabledState: 'Enabled'
}
}
resource originGroup 'Microsoft.Cdn/profiles/originGroups@2023-05-01' = {
parent: frontDoorProfile
name: 'backend-origins'
properties: {
loadBalancingSettings: {
sampleSize: 4
successfulSamplesRequired: 3
additionalLatencyInMilliseconds: 50
}
healthProbeSettings: {
probePath: '/health'
probeRequestType: 'HEAD'
probeProtocol: 'Https'
probeIntervalInSeconds: 30
}
}
}
resource originEastUS 'Microsoft.Cdn/profiles/originGroups/origins@2023-05-01' = {
parent: originGroup
name: 'eastus-origin'
properties: {
hostName: 'myapp-eastus.azurewebsites.net'
httpPort: 80
httpsPort: 443
priority: 1
weight: 1000
enforceCertificateNameCheck: true
originHostHeader: 'myapp-eastus.azurewebsites.net'
}
}
resource originWestEurope 'Microsoft.Cdn/profiles/originGroups/origins@2023-05-01' = {
parent: originGroup
name: 'westeurope-origin'
properties: {
hostName: 'myapp-westeurope.azurewebsites.net'
httpPort: 80
httpsPort: 443
priority: 1
weight: 1000
enforceCertificateNameCheck: true
originHostHeader: 'myapp-westeurope.azurewebsites.net'
}
}
resource wafPolicy 'Microsoft.Network/FrontDoorWebApplicationFirewallPolicies@2022-05-01' = {
name: 'myappwaf'
location: 'global'
sku: {
name: 'Premium_AzureFrontDoor'
}
properties: {
policySettings: {
mode: 'Prevention'
requestBodyCheck: 'Enabled'
}
managedRules: {
managedRuleSets: [
{
ruleSetType: 'Microsoft_DefaultRuleSet'
ruleSetVersion: '2.1'
ruleSetAction: 'Block'
}
{
ruleSetType: 'Microsoft_BotManagerRuleSet'
ruleSetVersion: '1.0'
}
]
}
}
}Front Door + Private Link for Zero-Trust
Azure Front Door Premium supports Private Link origins, meaning traffic from Front Door to your backend flows over the Microsoft backbone through a Private Endpoint, never over the public internet. Combined with disabling public access on your App Service or Load Balancer, this creates a zero-trust network path where the only way to reach your backend is through Front Door (with WAF inspection). This is the recommended pattern for production web applications.
Application Gateway v2
Azure Application Gateway is a regional L7 load balancer that provides URL-based routing, SSL termination, cookie-based session affinity, and WAF protection. It operates within a VNet (unlike Front Door which is a global edge service), making it suitable for internal applications and as a regional complement to Front Door.
Key Application Gateway Features
- URL path-based routing: Route /api/* to backend A and /static/* to backend B
- Multi-site hosting: Host multiple domains on a single Application Gateway
- SSL termination and end-to-end SSL: Offload SSL at the gateway or re-encrypt to backends
- Autoscaling: v2 SKU scales automatically from 0 to 125 instances based on traffic
- WAF v2: OWASP Core Rule Set 3.2, custom rules, bot protection, geo-filtering
- HTTP/2 support: Improved performance for modern web applications
- Rewrite rules: Modify request/response headers, URLs, and query strings
# Create a WAF policy
az network application-gateway waf-policy create \
--name myapp-waf \
--resource-group myRG \
--location eastus2
# Enable managed rule set
az network application-gateway waf-policy managed-rule rule-set add \
--policy-name myapp-waf \
--resource-group myRG \
--type OWASP \
--version 3.2
# Create Application Gateway v2 with WAF
az network application-gateway create \
--name myapp-agw \
--resource-group myRG \
--location eastus2 \
--sku WAF_v2 \
--capacity 2 \
--vnet-name prod-spoke-vnet \
--subnet AppGatewaySubnet \
--http-settings-protocol Https \
--http-settings-port 443 \
--frontend-port 443 \
--waf-policy /subscriptions/<sub-id>/resourceGroups/myRG/providers/Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies/myapp-waf
# Enable autoscaling (0-10 instances)
az network application-gateway update \
--name myapp-agw \
--resource-group myRG \
--set sku.name=WAF_v2 sku.capacity=null \
--set autoscaleConfiguration.minCapacity=0 autoscaleConfiguration.maxCapacity=10Hybrid Connectivity: VPN vs ExpressRoute
Connecting on-premises networks to Azure is one of the most critical infrastructure decisions. Azure offers two primary connectivity options, each suited to different requirements for bandwidth, latency, reliability, and security.
| Feature | Site-to-Site VPN | ExpressRoute |
|---|---|---|
| Connection type | IPSec tunnel over public internet | Private MPLS circuit via connectivity provider |
| Max bandwidth | Up to 10 Gbps (VpnGw5) | Up to 100 Gbps (Direct) |
| Latency | Variable (internet-dependent, typically 20-100ms) | Predictable, low latency (5-20ms) |
| Reliability SLA | 99.95% (active-active) | 99.95% (standard), 99.99% (Global Reach) |
| Encryption | IPSec encryption built-in | Not encrypted by default |
| Setup time | Minutes to hours | Weeks to months (provider provisioning) |
| Monthly cost | ~$350-5,000 (gateway SKU) | ~$500-15,000 + circuit provider fees |
| Redundancy | Active-active gateways | Dual circuits to different peering locations |
| Microsoft 365 access | No | Yes (with Microsoft peering) |
| Best for | Dev/test, small offices, VPN backup | Production, large data transfers, compliance |
ExpressRoute Is Not Encrypted by Default
A common misconception is that ExpressRoute traffic is encrypted because it uses a private circuit. It is not. Data traverses the MPLS path unencrypted. For sensitive workloads, layer IPSec VPN over ExpressRoute (VPN Gateway coexistence) or enable MACsec on ExpressRoute Direct ports for line-rate hardware encryption. Microsoft also offers ExpressRoute with encryption through the VPN gateway coexistence feature, which provides IPSec tunnels over the ExpressRoute circuit.
ExpressRoute Resiliency Patterns
Pattern 1: Standard Resiliency (single circuit, two connections)
On-Premises -> Provider -> Primary Connection -> Azure (Zone 1)
On-Premises -> Provider -> Secondary Connection -> Azure (Zone 2)
SLA: 99.95%
Risk: Single provider failure takes down both connections
Pattern 2: Maximum Resiliency (two circuits, different providers)
On-Premises -> Provider A -> Circuit 1 -> Azure Region 1
On-Premises -> Provider B -> Circuit 2 -> Azure Region 1
SLA: 99.99%+
Cost: 2x circuit cost, but eliminates single provider risk
Pattern 3: ExpressRoute + VPN Failover
Primary: On-Premises -> ExpressRoute -> Azure
Backup: On-Premises -> Site-to-Site VPN -> Azure
BGP weight: ExpressRoute preferred, VPN as automatic failover
Cost: ExpressRoute + VPN gateway cost
Pattern 4: ExpressRoute Global Reach (multi-region)
Datacenter A -> ExpressRoute Circuit A -> Azure Region 1
Datacenter B -> ExpressRoute Circuit B -> Azure Region 2
Global Reach: Circuit A <-> Circuit B (cross-region via Microsoft backbone)
Enables: On-premises site-to-site via Azure backboneAzure Firewall
Azure Firewall is a managed, cloud-native network security service that provides stateful packet inspection, application-level filtering, threat intelligence-based filtering, and TLS inspection. It sits in your hub VNet and inspects traffic flowing between spokes, between Azure and the internet, and between Azure and on-premises networks.
Firewall Tiers
| Tier | Key Features | Throughput | Approximate Cost |
|---|---|---|---|
| Basic | L3-L4 filtering, fixed 250 Mbps throughput | 250 Mbps | ~$275/mo + data |
| Standard | L3-L7 filtering, threat intel, FQDN filtering, DNS proxy | 30 Gbps | ~$912/mo + data |
| Premium | Standard + TLS inspection, IDPS, URL filtering, web categories | 100 Gbps | ~$1,825/mo + data |
# Create Firewall Policy
az network firewall policy create \
--name hub-firewall-policy \
--resource-group myRG \
--location eastus2 \
--sku Premium \
--threat-intel-mode Alert
# Create a rule collection group
az network firewall policy rule-collection-group create \
--name DefaultRuleCollectionGroup \
--policy-name hub-firewall-policy \
--resource-group myRG \
--priority 100
# Application rule: Allow outbound HTTPS to specific FQDNs
az network firewall policy rule-collection-group collection add-filter-collection \
--policy-name hub-firewall-policy \
--resource-group myRG \
--rule-collection-group-name DefaultRuleCollectionGroup \
--name AllowWebTraffic \
--collection-priority 100 \
--action Allow \
--rule-type ApplicationRule \
--rule-name AllowAzureServices \
--source-addresses "10.1.0.0/16" \
--protocols Https=443 \
--target-fqdns "*.azure.com" "*.microsoft.com" "*.windows.net"
# Network rule: Allow spoke-to-spoke on specific ports
az network firewall policy rule-collection-group collection add-filter-collection \
--policy-name hub-firewall-policy \
--resource-group myRG \
--rule-collection-group-name DefaultRuleCollectionGroup \
--name AllowSpokeToSpoke \
--collection-priority 200 \
--action Allow \
--rule-type NetworkRule \
--rule-name AllowProdToStaging \
--source-addresses "10.1.0.0/16" \
--destination-addresses "10.2.0.0/16" \
--destination-ports 443 8080 \
--ip-protocols TCP
# Create route table to force traffic through firewall
az network route-table create \
--name spoke-to-firewall-rt \
--resource-group myRG \
--location eastus2 \
--disable-bgp-route-propagation true
# Default route through the firewall
az network route-table route create \
--name to-internet \
--route-table-name spoke-to-firewall-rt \
--resource-group myRG \
--address-prefix 0.0.0.0/0 \
--next-hop-type VirtualAppliance \
--next-hop-ip-address 10.0.1.4Azure Firewall vs Third-Party NVAs
Azure Firewall is a managed service, so Microsoft handles updates, scaling, and availability. Third-party Network Virtual Appliances (Palo Alto, Fortinet, Check Point) offer more advanced features (deep packet inspection, advanced threat prevention, centralized management across on-premises and cloud) but require you to manage the infrastructure including HA, patching, and scaling. Choose Azure Firewall for simplicity and Azure-native integration. Choose a third-party NVA if you have existing security tool investments, need specific compliance certifications, or require features not available in Azure Firewall.
Private Link and Private Endpoints
Azure Private Link enables you to access Azure PaaS services (Storage, SQL, Cosmos DB, Key Vault, and 60+ services) over a private endpoint in your VNet. Traffic between your VNet and the service travels over the Microsoft backbone network, never traversing the public internet. This is the cornerstone of zero-trust networking for PaaS services.
Private Link Architecture Pattern
Application in Spoke VNet (10.1.2.5)
|
| DNS query: mystorageaccount.blob.core.windows.net
| -> CNAME: mystorageaccount.privatelink.blob.core.windows.net
| -> A record: 10.1.4.5 (from Private DNS Zone)
|
v
Private Endpoint (10.1.4.5 in private-endpoints subnet)
|
| Traffic flows over Microsoft backbone
| (never crosses the public internet)
|
v
Azure Storage Account (mystorageaccount)
Public access: DISABLED
Only accessible via Private Endpoint
Required components:
1. Private Endpoint (NIC with private IP in your subnet)
2. Private DNS Zone (privatelink.blob.core.windows.net)
3. VNet Link (connect DNS zone to VNets that need resolution)
4. DNS Zone Group (auto-register PE IP in DNS zone)
5. PaaS service configured with publicNetworkAccess: DisabledCommon Private DNS Zones
| Azure Service | Private DNS Zone |
|---|---|
| Storage (Blob) | privatelink.blob.core.windows.net |
| Storage (File) | privatelink.file.core.windows.net |
| Azure SQL Database | privatelink.database.windows.net |
| Cosmos DB (SQL API) | privatelink.documents.azure.com |
| Key Vault | privatelink.vaultcore.azure.net |
| Azure Container Registry | privatelink.azurecr.io |
| Event Hubs / Service Bus | privatelink.servicebus.windows.net |
| Azure Cache for Redis | privatelink.redis.cache.windows.net |
DNS Architecture for Azure
DNS is the most underestimated component of Azure networking. Poor DNS architecture leads to Private Endpoint resolution failures, hybrid connectivity issues, and operational headaches that are difficult to diagnose. A robust DNS architecture for Azure includes:
- Azure Private DNS Resolver: A managed DNS forwarding service deployed in the hub VNet. It forwards queries from Azure to on-premises DNS servers and from on-premises to Azure Private DNS Zones.
- Centralized Private DNS Zones: One zone per Azure service type using Private Endpoints, all hosted in the hub subscription and linked to all VNets.
- Conditional forwarding: On-premises DNS servers forward Azure private zone queries (*.privatelink.*.azure.com) to the Private DNS Resolver inbound endpoint. The resolver forwards on-premises domain queries to on-premises DNS.
# Create a Private DNS Resolver in the hub VNet
az dns-resolver create \
--name hub-dns-resolver \
--resource-group myRG \
--location eastus2 \
--id /subscriptions/<sub-id>/resourceGroups/myRG/providers/Microsoft.Network/virtualNetworks/hub-vnet
# Create inbound endpoint (on-premises queries Azure)
az dns-resolver inbound-endpoint create \
--name inbound-endpoint \
--dns-resolver-name hub-dns-resolver \
--resource-group myRG \
--location eastus2 \
--ip-configurations '[{"id": "/subscriptions/<sub-id>/resourceGroups/myRG/providers/Microsoft.Network/virtualNetworks/hub-vnet/subnets/DNSResolverInbound", "private-ip-allocation-method": "Dynamic"}]'
# Create outbound endpoint (Azure queries on-premises)
az dns-resolver outbound-endpoint create \
--name outbound-endpoint \
--dns-resolver-name hub-dns-resolver \
--resource-group myRG \
--location eastus2 \
--id /subscriptions/<sub-id>/resourceGroups/myRG/providers/Microsoft.Network/virtualNetworks/hub-vnet/subnets/DNSResolverOutbound
# Create forwarding ruleset for on-premises domains
az dns-resolver forwarding-ruleset create \
--name onprem-forwarding \
--resource-group myRG \
--location eastus2 \
--outbound-endpoints '[{"id": "/subscriptions/<sub-id>/resourceGroups/myRG/providers/Microsoft.Network/dnsResolvers/hub-dns-resolver/outboundEndpoints/outbound-endpoint"}]'
# Forward corp.contoso.com queries to on-premises DNS
az dns-resolver forwarding-rule create \
--name forward-to-onprem \
--ruleset-name onprem-forwarding \
--resource-group myRG \
--domain-name "corp.contoso.com." \
--target-dns-servers '[{"ip-address": "192.168.1.10", "port": 53}, {"ip-address": "192.168.1.11", "port": 53}]'DNS Is a Day-One Decision
Plan your DNS architecture before deploying your first Private Endpoint. Retroactively fixing DNS for dozens of Private Endpoints across multiple VNets is painful and error-prone. Centralize Private DNS Zones in the hub subscription. Automate zone creation and VNet linking using Azure Policy with DeployIfNotExists. Set up conditional forwarding before enabling hybrid connectivity.
Network Monitoring and Troubleshooting
Azure provides several tools for network diagnostics, each designed for different types of connectivity issues. Knowing which tool to reach for first can save hours of troubleshooting time.
Diagnostic Tools
| Tool | What It Does | When to Use |
|---|---|---|
| Network Watcher - IP flow verify | Tests if a packet is allowed or denied by NSG rules | VM cannot reach a destination, suspect NSG blocking |
| Network Watcher - Next hop | Shows the next hop for a packet from a VM | Traffic not reaching the expected destination (routing issue) |
| Network Watcher - Connection troubleshoot | Tests TCP connectivity between source and destination | End-to-end connectivity failure diagnosis |
| Effective routes | Shows all routes applied to a NIC (system + UDR + BGP) | Traffic taking unexpected path, firewall bypass |
| Effective NSG rules | Shows combined effect of subnet and NIC NSGs | Understanding actual security rules applied to a VM |
| NSG flow logs | Logs all traffic evaluated by NSGs (allowed + denied) | Security audit, traffic pattern analysis |
| Connection Monitor | Continuous end-to-end connectivity monitoring | Proactive monitoring, SLA tracking |
| Traffic Analytics | Visual analysis of NSG flow logs | Network traffic visualization, anomaly detection |
# Test connectivity between a VM and a destination
az network watcher test-connectivity \
--resource-group myRG \
--source-resource myVM \
--dest-address 10.1.3.4 \
--dest-port 1433
# Check effective routes for a NIC (shows actual routing table)
az network nic show-effective-route-table \
--resource-group myRG \
--name myVM-nic \
--output table
# Check effective NSG rules (combined subnet + NIC NSGs)
az network nic list-effective-nsg \
--resource-group myRG \
--name myVM-nic
# Verify IP flow (is this traffic allowed or denied by NSG?)
az network watcher test-ip-flow \
--vm myVM \
--resource-group myRG \
--direction Inbound \
--protocol TCP \
--local 10.1.2.5:80 \
--remote 10.1.1.10:*
# Enable NSG flow logs with Traffic Analytics
az network watcher flow-log create \
--name myNSGFlowLog \
--nsg myNSG \
--resource-group myRG \
--storage-account mystorageaccount \
--workspace myLogAnalyticsWorkspace \
--enabled true \
--traffic-analytics true \
--interval 10Systematic Troubleshooting Approach
When debugging connectivity issues, follow this order: (1) Check effective NSG rules to rule out security blocking, (2) Check effective routes to ensure traffic takes the expected path, (3) Use Connection Troubleshoot for end-to-end path analysis, (4) Check DNS resolution if the destination is a hostname, (5) Review Azure Firewall logs if traffic passes through the firewall. Most connectivity issues are caused by NSG rules, missing UDRs, or DNS resolution failures. Check these first before investigating more complex scenarios.
Key Takeaways
- 1Private Link creates private endpoints for Azure PaaS services inside your VNet.
- 2Application Gateway provides L7 load balancing with WAF, SSL termination, and URL routing.
- 3ExpressRoute delivers dedicated private connectivity to on-premises with predictable latency.
- 4Azure Firewall provides centralized, stateful network security with threat intelligence.
- 5Network Watcher tools diagnose connectivity issues, capture packets, and analyze flow logs.
- 6Front Door provides global L7 load balancing with CDN, WAF, and SSL offloading.
Frequently Asked Questions
What is the difference between Private Endpoints and Service Endpoints?
When should I use Application Gateway vs Front Door?
What is the difference between ExpressRoute and VPN Gateway?
How does Azure Firewall differ from NSGs?
What is Azure DDoS Protection?
Written by CloudToolStack Team
Cloud engineers and architects with hands-on experience across AWS, Azure, and GCP. We write guides based on real-world production patterns, not just documentation rewrites.
Disclaimer: This guide is for educational purposes. Cloud services change frequently; always refer to official documentation for the latest information. AWS, Azure, and GCP are trademarks of their respective owners.