Skip to main content

Documentation Index

Fetch the complete documentation index at: https://resources.devweekends.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Hybrid Networking & Enterprise Connectivity

​
What You’ll Learn

By the end of this chapter, you’ll understand:
  • What hybrid networking actually is (connecting your office to Azure)
  • The difference between VPN and ExpressRoute (and when to use each)
  • How Virtual WAN simplifies complex network architectures
  • How to control traffic flow with routing and secure access with Bastion
  • Real costs and common mistakes that can cost you thousands

​
Introduction: What is Hybrid Networking?

​
Start Here if You’re Completely New

Imagine you run a company with:
  • An office building with servers, databases, and employee computers
  • Azure cloud where you’re building new applications
The Problem: How do these two worlds talk to each other securely? Real-World Analogy: Think of it like building a bridge between two islands:
  1. Island A = Your office (on-premises datacenter)
  2. Island B = Azure cloud
  3. The Ocean = The public internet (dangerous, anyone can intercept your traffic)
You have two options for the bridge: Option 1: VPN (Virtual Private Network) = Build a bridge OVER the ocean
  • Uses the public internet (the ocean)
  • Encrypts your traffic (armored truck on the bridge)
  • Cheaper ($140/month for 650 Mbps)
  • Less reliable (depends on internet quality)
Option 2: ExpressRoute = Build a private TUNNEL under the ocean
  • Bypasses the public internet entirely
  • Dedicated fiber cable just for you
  • More expensive ($1,627/month for 1 Gbps)
  • More reliable (99.95% SLA)

​
Why This Matters: Real Cost of Getting It Wrong

Case Study: Healthcare Company VPN Incident (2021) A healthcare company chose VPN for production workloads to save money:
  • The Setup: Site-to-Site VPN ($140/month)
  • The Problem: VPN bandwidth maxed out at 650 Mbps
  • The Incident: During peak hours, doctors couldn’t access patient records in Azure
  • The Cost: 4-hour outage, $2.3M in delayed procedures
  • The Fix: Migrated to ExpressRoute ($1,627/month)
  • The Lesson: 1,487/monthsavingscostthem1,487/month savings cost them 2.3M
The ROI Math:
  • Cost to do it right: 1,627/month×12=∗∗1,627/month × 12 = **19,524/year**
  • Cost of doing it wrong: $2.3M in one incident
  • ROI: 117x return on investment
For most enterprises, the cloud isn’t an island—it’s an extension of their on-premises datacenter.

​
1. Connecting to On-Premises

​
Understanding the Two Connection Types (From Absolute Zero)

Before we dive into the technical details, let’s understand what problem we’re solving: The Scenario: You’re a developer working from home, and your company has:
  1. A corporate office with servers and databases
  2. Azure cloud with applications and data
  3. Developers working remotely who need access to both
How do you connect all these pieces securely? Two Different Connection Types:

​
Point-to-Site (P2S): Individual Remote Access

The Analogy: Like a personal security escort for one person. Example: 
Your Laptop (Home) --[VPN Tunnel]--> Azure VNet
Use Cases:
  • Developer working from home needs to access Azure resources
  • IT admin connecting to troubleshoot
  • Remote employee accessing internal systems
Real Numbers:
  • Cost: ~$140/month (VpnGw1 SKU)
  • Supports: Up to 10,000 concurrent connections
  • Speed: Up to 650 Mbps per gateway

​
Site-to-Site (S2S): Office-to-Cloud Connection

The Analogy: Like a private highway between two buildings. Example: 
Your Office (100+ employees) --[VPN Tunnel]--> Azure VNet
Use Cases:
  • Entire corporate office needs access to Azure
  • On-premises servers need to sync with Azure databases
  • Hybrid applications spanning both environments
Real Numbers:
  • Cost: ~$140/month (VpnGw1 SKU) + your office VPN device
  • Always-on connection
  • Speed: Up to 650 Mbps-10 Gbps (depending on SKU)

​
VPN Gateway (Deep Dive)

What It Is: Encrypted tunnel over the public internet. How It Works (Simplified):
  1. Your office sends data to Azure
  2. VPN Gateway encrypts it (like putting it in a locked box)
  3. Data travels over the public internet (but encrypted)
  4. Azure VPN Gateway decrypts it (unlocks the box)
  5. Data reaches your Azure resources
The Trade-Off:
  • ✅ Cheaper ($140/month)
  • ✅ Easy to set up (takes 30 minutes)
  • ❌ Slower (depends on your internet speed)
  • ❌ Less reliable (if your internet goes down, VPN goes down)
Types:
  1. Point-to-Site (P2S): For individual developers working remotely. Connects your laptop to Azure.
  2. Site-to-Site (S2S): Connects an entire office to Azure. Uses an IPsec/IKE VPN tunnel.
SKU Selection:
SKUBandwidthTunnelsZone Redundant?Cost/MonthUse Case
Basic100 Mbps10No$27Dev/Test only (No BGP)
VpnGw1650 Mbps30No$140Production Entry
VpnGw2AZ1 Gbps30Yes$361Mission Critical
VpnGw5AZ10 Gbps100Yes$1,445High scale
Decision Tree: Which VPN SKU Do I Need? 
START: What's your use case?

├─ Dev/Test environment?
│  └─ Basic ($27/month) ✅
│     Warning: No BGP support, no production use!
│
├─ Production with <500 Mbps traffic?
│  └─ VpnGw1 ($140/month) ✅
│     Good for: Small office, light workloads
│
├─ Mission-critical production?
│  └─ VpnGw2AZ ($361/month) ✅
│     Why AZ? Survives datacenter failures
│
└─ High traffic or many tunnels?
   └─ VpnGw5AZ ($1,445/month) ✅
      Supports: 10 Gbps, 100 tunnels
Common Mistake #1: Using Basic SKU for Production The Trap:
  • Developer creates VPN Gateway
  • Chooses “Basic” to save money (27/monthvs27/month vs 140/month)
  • Works fine in testing
  • Problem: Basic SKU doesn’t support BGP (Border Gateway Protocol)
  • Impact: Can’t automatically failover when connection drops
Real Example:
  • Company saved $113/month using Basic SKU
  • VPN connection failed during business hours
  • No automatic failover (BGP missing)
  • 6-hour manual recovery
  • Cost: $450K in lost productivity
  • Lesson: 113/monthsavingscostthem113/month savings cost them 450K

​
ExpressRoute (The Premium Option)

What It Is: Private, dedicated fiber connection. Traffic never touches the public internet. The Analogy: Imagine you’re moving gold bars between buildings: VPN = Armored truck driving on public roads
  • Anyone can see the truck (even if they can’t open it)
  • Depends on traffic conditions
  • Slower, less predictable
ExpressRoute = Private underground tunnel
  • Nobody knows you’re moving gold
  • Dedicated path, no traffic
  • Faster, more predictable
How It Works (Simplified):
  1. Microsoft partners (like AT&T, Verizon, Equinix) install a dedicated fiber cable
  2. One end connects to your office
  3. Other end connects to Azure datacenter
  4. Your data travels on this private cable (never touches public internet)
The Numbers:
Circuit SpeedMonthly CostOutbound DataTotal Cost/Month
50 Mbps$56Unlimited$56
100 Mbps$100Unlimited$100
500 Mbps$635Unlimited$635
1 Gbps$1,627$0.035/GB$1,627+
10 Gbps$8,760$0.025/GB$8,760+
Hidden Costs:
  • Circuit fee (above)
  • ExpressRoute Gateway (213−213-3,105/month)
  • Outbound data (if not unlimited plan)
  • Partner setup fees (1,000−1,000-5,000 one-time)
Total Cost Example (1 Gbps): 
Circuit: $1,627/month
Gateway (Standard): $213/month
Outbound data (1 TB): $35/month
──────────────────────
Total: $1,875/month ($22,500/year)
Benefits:
  • Security: Private link, never touches public internet
  • Reliability: SLA up to 99.95% (without internet fluctuations)
  • Speed: Up to 100 Gbps (Direct)
  • Predictable Latency: Consistent performance (no “internet weather”)
  • Compliance: Meets strict regulatory requirements (HIPAA, PCI-DSS, FedRAMP)
Decision Tree: VPN or ExpressRoute? 
START: Which connection do I need?

├─ Dev/Test environment?
│  └─ VPN ($140/month) ✅
│     Reason: ExpressRoute overkill for non-production
│
├─ Production workload with <500 Mbps traffic?
│  └─ VPN ($140/month) ✅
│     Reason: Cost-effective, meets most needs
│
├─ Production workload with >1 Gbps traffic?
│  └─ ExpressRoute ($1,875/month) ✅
│     Reason: VPN can't handle the bandwidth
│
├─ Compliance requirements (HIPAA, PCI-DSS)?
│  └─ ExpressRoute ($1,875/month) ✅
│     Reason: Some regulations require private connectivity
│
├─ Mission-critical production (99.95% SLA)?
│  └─ ExpressRoute ($1,875/month) ✅
│     Reason: VPN depends on public internet (unreliable)
│
└─ Budget < $500/month?
   └─ VPN ($140/month) ✅
      Reason: ExpressRoute too expensive
Real-World Comparison:
FactorVPN (VpnGw1)ExpressRoute (1 Gbps)
Cost$140/month$1,875/month
Setup Time30 minutes4-12 weeks
Bandwidth650 Mbps1 Gbps-100 Gbps
LatencyVaries (20-100ms)Consistent (<10ms)
SLA99.9%99.95%
Internet DependencyYesNo
ComplianceBasicHIPAA, PCI-DSS, FedRAMP
Best ForSmall/MediumEnterprise/Mission-Critical
[!WARNING] Gotcha: ExpressRoute Cost You pay for the Circuit (monthly flat fee) AND the Gateway (hourly fee) AND Outbound Data (unless you have an Unlimited plan). It is significantly more expensive than VPN. Example Surprise Bill:
  • Circuit: $1,627/month (expected)
  • Gateway: $213/month (forgot about this!)
  • Outbound data: $350/month (forgot about this too!)
  • Total: 2,190/monthinsteadofexpected2,190/month instead of expected 1,627/month
Common Mistake #2: ExpressRoute for Dev/Test The Trap:
  • Team reads “ExpressRoute is better than VPN”
  • Deploys ExpressRoute for dev environment
  • Cost: $1,875/month for rarely-used connection
Better Approach:
  • VPN for Dev/Test ($140/month)
  • ExpressRoute only for Production ($1,875/month)
  • Savings: 1,735/month=1,735/month = 20,820/year
Hybrid Connectivity

​
2. Azure Virtual WAN (vWAN)

​
Understanding Virtual WAN (From Absolute Zero)

The Problem It Solves: Imagine you have:
  • 5 offices around the world (New York, London, Tokyo, Sydney, Mumbai)
  • 10 Azure VNets (Production, Dev, Test, etc.)
  • Remote workers connecting from home
Without Virtual WAN: 
You need to manually create:
- 5 Site-to-Site VPNs (offices to Azure)
- 1 Point-to-Site VPN (remote workers)
- 45 VNet peerings (to connect all 10 VNets to each other)
- 50+ routing tables (to control traffic flow)
- 5 Firewalls (one per office connection)
────────────────────────────────
Total: 100+ manual configurations
Time: ~80 hours of work
Maintenance: Ongoing nightmare
With Virtual WAN: 
Microsoft creates and manages:
- Hub that auto-connects everything
- Automatic routing
- Built-in firewall
- One central management point
────────────────────────────────
Total: 1 Virtual WAN deployment
Time: ~2 hours of work
Maintenance: Microsoft handles it
The Analogy: Without Virtual WAN = Managing your own airport
  • You build runways (VPN gateways)
  • You create flight paths (routing tables)
  • You manage air traffic control (routing)
  • Result: Complex, expensive, error-prone
With Virtual WAN = Using a managed airport service
  • Microsoft builds the runways
  • Microsoft manages flight paths
  • Microsoft handles air traffic control
  • Result: Simple, automated, reliable

​
Virtual WAN Components (Simplified)

1. Virtual Hub = The central airport
  • Location: One per Azure region
  • Connects: Offices, VNets, remote users
  • Routing: Automatic
2. Hub VNet Connections = Airplane gates
  • Connects your VNets to the hub
  • Automatic routing between VNets
3. Site-to-Site VPN = International flights
  • Connects offices to Azure
  • Up to 20 Gbps aggregate throughput
4. Point-to-Site VPN = Private jets
  • Connects remote workers
  • Up to 100,000 concurrent users
5. ExpressRoute = Private runways
  • Dedicated connections for high-traffic routes

​
Virtual WAN: “Hub-and-Spoke as a Service”

Instead of managing your own Hub VNet with complex peering and routing tables, Microsoft manages the Hub for you. Capabilities:
  • Automated Site-to-Site VPN
  • Automated P2S User VPN
  • ExpressRoute integration
  • Transit Routing (Spoke-to-Spoke, Spoke-to-Branch)
  • Integrated Azure Firewall
[!TIP] Jargon Alert: Transit Routing In standard peering, Spoke A cannot talk to Spoke B directly. In Virtual WAN, all spokes can talk to everything (if you allow it) because the vHub acts as a super-router. Visual Example: 
Standard Peering:
Spoke A ──X──> Spoke B (blocked, need to route through hub manually)

Virtual WAN:
Spoke A ──✓──> Spoke B (works automatically, vHub routes it)
Real Cost Comparison: Scenario: 3 offices + 10 VNets + 500 remote workers
ApproachComponentsMonthly CostSetup Time
Manual3 VPN Gateways
45 VNet Peerings
50 Route Tables
Azure Firewall		$1,450/month80 hours
Virtual WAN1 Virtual WAN
1 Virtual Hub
Auto-everything		$870/month2 hours
Savings-580/month<br/>580/month<br />6,960/year78 hours
Decision Tree: Do I Need Virtual WAN? 
START: Should I use Virtual WAN?

├─ Single office + single VNet?
│  └─ NO, use standard VPN ✅
│     Reason: Virtual WAN overkill
│
├─ 2-3 locations + 2-3 VNets?
│  └─ MAYBE, compare costs ⚠️
│     Calculate: Manual vs vWAN pricing
│
├─ 4+ offices OR 4+ VNets?
│  └─ YES, use Virtual WAN ✅
│     Reason: Complexity justifies automation
│
├─ Need branch-to-branch connectivity?
│  └─ YES, use Virtual WAN ✅
│     Reason: Manual routing nightmare
│
└─ Global presence (multi-region)?
   └─ YES, use Virtual WAN ✅
      Reason: Built for global scale
Common Mistake #3: Virtual WAN for Simple Setups The Trap:
  • Single office connecting to single VNet
  • Developer reads “Virtual WAN is best practice”
  • Deploys Virtual WAN
  • Cost: $870/month
Reality:
  • Simple VPN Gateway would cost $140/month
  • Waste: 730/month=730/month = 8,760/year
The Rule:
  • < 3 connections = Use standard VPN
  • ≥ 4 connections = Use Virtual WAN
Virtual WAN Architecture

​
3. User Defined Routes (UDR)

​
Understanding Routing (From Absolute Zero)

The Analogy: Imagine you live in a neighborhood with:
  • Your house (VM in Subnet A)
  • Friend’s house (VM in Subnet B)
  • Grocery store (Internet)
  • Security checkpoint (Azure Firewall)
Default Routing (System Route): 
You → Direct path → Friend's house ✅
You → Direct path → Grocery store ✅
Azure automatically knows how to route traffic. Everything works. Problem: Your company wants all internet traffic inspected by the firewall (for security). Solution: User Defined Route (UDR) 
You → MUST go through → Security checkpoint → Grocery store ✅
You → Direct path (unchanged) → Friend's house ✅
You’re overriding the default route to force traffic through the firewall.

​
How UDR Works (Step-by-Step)

Before UDR: 
VM in Subnet A wants to access google.com:
1. VM sends packet
2. Azure sees destination: 142.250.80.46 (google.com)
3. Azure uses SYSTEM ROUTE: "Send to internet gateway"
4. Packet goes directly to internet ✅
After UDR: 
VM in Subnet A wants to access google.com:
1. VM sends packet
2. Azure sees destination: 142.250.80.46 (google.com)
3. Azure checks UDR: "0.0.0.0/0 → Send to Firewall at 10.0.1.4"
4. Packet goes to Firewall FIRST
5. Firewall inspects packet (blocks malware, logs traffic)
6. Firewall forwards to internet ✅

​
Routing Table Priority (Most Specific Wins)

Azure checks routes in this order: Priority Ranking:
  1. User Defined Route (UDR) - You create these manually
  2. BGP Route - Learned from ExpressRoute/VPN
  3. System Route - Azure’s default routing
Example: You have these routes:
Route TypeDestinationNext HopSpecificity
System Route0.0.0.0/0Internet/0 (least specific)
UDR10.0.0.0/8Firewall/8
BGP10.5.0.0/16ExpressRoute/16 (most specific)
Traffic to 10.5.20.5: 
1. Check UDR: 10.0.0.0/8 matches ✓
2. Check BGP: 10.5.0.0/16 matches ✓ (more specific, /16 > /8)
3. Winner: BGP route (10.5.0.0/16)
4. Send via ExpressRoute ✅
The Rule: Most specific prefix wins (bigger number after / = more specific)
  • /32 beats /24 beats /16 beats /8 beats /0

​
Common UDR Scenario: Force All Internet Traffic Through Firewall

Goal: Inspect all outbound internet traffic for security. Step-by-Step: 1. Create Route Table 
az network route-table create \
  --name RT-Internet-Via-Firewall \
  --resource-group MyRG
2. Add Rule: Send All Internet Traffic to Firewall 
az network route-table route create \
  --route-table-name RT-Internet-Via-Firewall \
  --resource-group MyRG \
  --name Route-Internet-Via-Firewall \
  --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address 10.0.1.4
Translation:
  • 0.0.0.0/0 = All internet traffic
  • VirtualAppliance = Azure Firewall
  • 10.0.1.4 = IP address of your firewall
3. Associate Route Table with Your Subnets 
az network vnet subnet update \
  --vnet-name MyVNet \
  --name SubnetA \
  --resource-group MyRG \
  --route-table RT-Internet-Via-Firewall
Result: 
Before UDR:
VM → Direct → Internet (no inspection)

After UDR:
VM → Firewall (10.0.1.4) → Internet (inspected!)
[!WARNING] Gotcha: Asymmetric Routing If your request goes out via Azure Firewall but the return traffic comes back via ExpressRoute bypass, the firewall will drop the packet (it didn’t see the SYN). Ensure traffic flows symmetrically! Visual Example of the Problem: 
Outbound (Request):
Your VM → Azure Firewall → Internet ✅

Inbound (Response):
Internet → ExpressRoute (bypasses firewall) → Your VM ❌

Result: Firewall never saw the initial SYN packet,
        so it drops the returning ACK packet
The Fix: Ensure BOTH directions use the same path: 
Outbound: VM → Firewall → Internet ✅
Inbound:  Internet → Firewall → VM ✅
Common Mistake #4: Forgetting to Update Route Tables The Trap:
  • Deploy new subnet
  • Forget to associate route table
  • Internet traffic bypasses firewall
  • Security Risk: Unmonitored traffic
Real Example:
  • Company had UDR forcing traffic through firewall
  • Developer created new subnet for testing
  • Forgot to associate route table
  • Malware infected test VM, spread to production
  • Cost: $1.2M breach (could have been prevented with proper routing)
The Fix:
  • Use Azure Policy to auto-associate route tables with new subnets
  • Regular audits of subnet configurations

​
4. Azure Bastion

​
Understanding Azure Bastion (From Absolute Zero)

The Problem: You have a VM in Azure that you need to access (RDP for Windows, SSH for Linux). Traditional Approach (DANGEROUS): 
1. Give VM a public IP address
2. Open port 3389 (RDP) or port 22 (SSH) to the internet
3. Connect directly from your laptop

Problem:
- Public IP = Target for hackers
- Open ports = Attack surface
- Billions of automated attacks per day
Real Incident: Open RDP Port (2022) A company left RDP port open to the internet:
  • Day 1: VM deployed with public IP
  • Day 2: 47,000 brute-force login attempts
  • Day 3: Attackers gained access (weak password)
  • Day 7: Ransomware encrypted entire network
  • Cost: $4.2M in ransom + recovery
  • Prevention Cost: $140/month for Azure Bastion
ROI: Spending 140/monthcouldhavesaved140/month could have saved 4.2M (30,000x return)

​
How Azure Bastion Works (Simplified)

The Analogy: Without Bastion = Your house has a door facing the street
  • Anyone can walk up and try to break in
  • 24/7 exposure to criminals
With Bastion = Your house is inside a gated community
  • Must go through security checkpoint first
  • Security guards (Azure) verify identity
  • Then you get access to your house

​
Azure Bastion: The Secure Solution

What It Is: A secure jump box managed by Microsoft. How It Works: 
Traditional (Insecure):
Your Laptop → Public Internet → VM Public IP (port 22/3389) ❌
                                  ↑
                            Attack surface

Azure Bastion (Secure):
Your Laptop → Azure Portal (HTTPS port 443) → Bastion → VM (private IP) ✅
                                                ↑
                                          No public IP on VM!
Step-by-Step:
  1. You open Azure Portal in browser (HTTPS, port 443)
  2. Click “Connect” → “Bastion” on your VM
  3. Bastion creates secure tunnel
  4. VM has NO public IP, NO open ports
  5. You access VM via browser (no RDP client needed!)

​
Why Use Azure Bastion?

Benefits: ✅ No Public IPs needed on your VMs (hackers can’t find them) ✅ No TCP 3389/22 open to the internet (no attack surface) ✅ TLS 443: Access via your web browser (Portal) ✅ No VPN needed: Works from anywhere ✅ Centralized access: All connections logged and audited ✅ No software: No need to install RDP/SSH clients Cost Comparison:
ApproachSetupMonthly CostSecurity Risk
Public IP + Open RDPFree$4/monthEXTREME (targeted daily)
VPN GatewayComplex$140/monthLow (but requires VPN client)
Azure BastionSimple$140/monthVery Low (managed by Microsoft)
Decision Tree: How Should I Access My VMs? 
START: How do I securely access VMs?

├─ Dev/Test, low-value data?
│  ├─ Just-in-Time (JIT) Access (free with Defender)
│  └─ Temporarily opens port, auto-closes after 3 hours
│
├─ Production, need frequent access?
│  └─ Azure Bastion ($140/month) ✅
│     Best for: Regular admin access, compliance
│
├─ Multi-region, many VMs?
│  └─ Azure Bastion + Hub-Spoke ($280/month)
│     One Bastion in hub, access all spokes
│
└─ Already have VPN?
   └─ Use existing VPN ✅
      No need for Bastion if VPN already there

​
Azure Bastion Requirements

Technical Requirements:
  1. Dedicated subnet named AzureBastionSubnet
    • Must be exactly this name (Azure enforces it)
    • Minimum size: /27 (32 IP addresses)
    • Recommended: /26 (64 IP addresses) for scalability
  2. Public IP (Standard SKU) for the Bastion host itself
    • Note: Bastion has public IP, NOT your VMs
    • This is the entry point (hardened by Microsoft)
  3. VNet where your VMs live
Setup Example: 
# 1. Create dedicated subnet for Bastion
az network vnet subnet create \
  --name AzureBastionSubnet \
  --vnet-name MyVNet \
  --resource-group MyRG \
  --address-prefixes 10.0.255.0/27

# 2. Create public IP for Bastion
az network public-ip create \
  --name Bastion-PIP \
  --resource-group MyRG \
  --sku Standard \
  --location eastus

# 3. Create Bastion host
az network bastion create \
  --name MyBastion \
  --public-ip-address Bastion-PIP \
  --vnet-name MyVNet \
  --resource-group MyRG \
  --location eastus
Cost: 140/month(720hours×140/month (720 hours × 0.19/hour)

​
Using Azure Bastion (Step-by-Step)

Via Azure Portal (Easy):
  1. Navigate to your VM in Azure Portal
  2. Click “Connect” → “Bastion”
  3. Enter VM username and password
  4. Click “Connect”
  5. Browser opens with RDP/SSH session ✅
Via Native Client (Advanced): 
# SSH via Bastion
az network bastion ssh \
  --name MyBastion \
  --resource-group MyRG \
  --target-resource-id /subscriptions/.../MyVM \
  --auth-type password \
  --username azureuser

# RDP via Bastion
az network bastion rdp \
  --name MyBastion \
  --resource-group MyRG \
  --target-resource-id /subscriptions/.../MyVM
[!NOTE] Deep Dive: Bastion Native Client You can now use your local native SSH/RDP client (terminal/mstsc) to tunnel through Bastion using the Azure CLI: az network bastion tunnel Benefits:
  • Use your favorite SSH/RDP client
  • Copy/paste works better
  • Better performance than browser

​
Common Mistake #5: Wrong Subnet Name

The Trap:
  • Create subnet named “BastionSubnet” (logical, right?)
  • Try to deploy Bastion
  • Error: “Subnet must be named AzureBastionSubnet”
The Rule:
  • MUST be exactly AzureBastionSubnet (case-sensitive)
  • Azure enforces this strictly

​
Common Mistake #6: Bastion for Every VNet

The Trap:
  • Deploy Bastion in every VNet ($140/month each)
  • 10 VNets = $1,400/month
  • Waste: $1,260/month
Better Approach:
  • Deploy Bastion in Hub VNet ($140/month)
  • Peer all Spoke VNets to Hub
  • Use single Bastion for all VMs
  • Savings: 1,260/month=1,260/month = 15,120/year
The Architecture: 
Hub VNet:
├─ AzureBastionSubnet (Bastion here)
├─ Spoke 1 VNet (peered to hub)
├─ Spoke 2 VNet (peered to hub)
└─ Spoke 3 VNet (peered to hub)

Result: One Bastion accesses VMs in all VNets ✅
Cost: $140/month total (not $560/month)

​
Interview Deep-Dive

Strong Candidate Answer:
  • Immediate diagnosis: First, I would check the VPN Gateway metrics in Azure Monitor — specifically “Gateway S2S Bandwidth” and “Tunnel Egress/Ingress Bytes.” If the VpnGw1 SKU is deployed, the maximum bandwidth is 650 Mbps. At 95% utilization, that is 617 Mbps, and packet drops begin at around 90% due to TCP congestion control backing off. The gateway does not fail gracefully — it degrades silently.
  • Short-term fix (same day): Resize the VPN Gateway from VpnGw1 (140/month)toVpnGw2AZ(140/month) to VpnGw2AZ (361/month) which doubles bandwidth to 1 Gbps and adds zone redundancy. Gateway resizing takes 20-45 minutes and causes a brief disconnection, so schedule it during a maintenance window. This buys time while planning the long-term fix.
  • Long-term assessment: 95% utilization on a VPN suggests the workload has outgrown VPN entirely. For healthcare with HIPAA requirements, I would recommend ExpressRoute with a 1 Gbps circuit ($1,627/month). The arguments: predictable sub-10ms latency (VPN latency varies 20-100ms depending on internet conditions), 99.95% SLA (vs 99.9% for VPN), and compliance teams prefer private connectivity for PHI (Protected Health Information).
  • The hybrid approach if budget is tight: Keep the VPN as a backup failover path and deploy ExpressRoute as the primary. This gives you redundancy — if ExpressRoute goes down (rare but it happens during provider maintenance), traffic fails over to VPN automatically via BGP route preference. Total cost: 1,627+1,627 + 361 = $1,988/month for production-grade hybrid connectivity.
  • What most people miss: Before spending on ExpressRoute, analyze what traffic is crossing the VPN. If 70% of the bandwidth is backup traffic or large file transfers, move those to Azure Site Recovery or Azure Data Box instead of pushing them over the VPN. This might reduce VPN utilization to 30% without any gateway changes.
Follow-up: The CFO says ExpressRoute is too expensive at $19,524/year. How do you justify it?I would calculate the cost of the incident they already experienced. If doctors could not access patient records for 4 hours during peak, that translates to delayed procedures, potential patient safety risk, and HIPAA violation exposure (fines of 100−100-50,000 per violation). One 4-hour outage affecting 50 doctors is 200 person-hours of lost productivity at 300/hourloadedcost=300/hour loaded cost = 60,000 in a single incident. ExpressRoute at $19,524/year is a 3x return on a single incident prevention. For healthcare, I would also add the reputational and regulatory risk: a HIPAA audit finding of “inadequate network controls for PHI transmission” carries fines that dwarf the ExpressRoute cost.
Strong Candidate Answer:
  • What asymmetric routing is: The outbound request takes Path A (through Azure Firewall) but the inbound response takes Path B (bypassing the Firewall). The Firewall sees a response packet (TCP ACK) for a connection it never saw the initial SYN for, so it drops the packet as suspicious.
  • The classic scenario: You have a UDR on your application subnet that sends 0.0.0.0/0 (all internet traffic) through Azure Firewall. The outbound path works: VM sends request to API on the internet, Firewall inspects and forwards it. But the response comes back via ExpressRoute (because BGP advertises a more specific route for your IP range), bypassing the Firewall entirely. The Firewall drops the unsolicited return packet.
  • Why it fails technically: Azure Firewall is stateful. It maintains a connection table (5-tuple: source IP, source port, dest IP, dest port, protocol). When the SYN goes through the Firewall, it creates a table entry. When the ACK comes back through a different path, the Firewall has no matching entry and drops it. The client sees a connection timeout.
  • Prevention patterns: (1) Ensure UDRs are applied symmetrically — if outbound goes through Firewall, force inbound return traffic through Firewall too by applying UDRs on the GatewaySubnet. (2) For ExpressRoute scenarios, use route tables on the GatewaySubnet that point internal Azure subnets back through the Firewall. (3) Use Azure Firewall’s forced tunneling mode if all internet-bound traffic must go through an on-premises firewall first. (4) Enable Azure Firewall SNAT for all traffic so the source IP is the Firewall’s IP, ensuring responses naturally return to the Firewall.
  • Debugging approach: Use Network Watcher Connection Troubleshoot and Packet Capture. The telltale sign is that the TCP handshake (SYN) completes one way but the ACK never arrives. NSG flow logs will show the outbound SYN allowed but no corresponding inbound ACK.
Follow-up: How would you detect asymmetric routing before it causes production issues?I would add a smoke test in the CI/CD pipeline that deploys a test VM in each subnet, makes outbound HTTPS calls to known endpoints, and verifies the response. Run traceroute from the VM to confirm the path goes through the Firewall (you should see the Firewall’s private IP as a hop). In Azure Monitor, set up an alert on Azure Firewall’s “SNAT port utilization” and “Application rules hit count” — if the hit count drops to zero while traffic should be flowing, something is bypassing the Firewall.
Strong Candidate Answer:
  • What is wrong: A separate VPN Gateway per office means 10 VPN Gateways at 140/montheach=140/month each = 1,400/month. But worse, you also need VNet peering between all these VNets for inter-office communication, which creates a mesh of 45 peering connections (n*(n-1)/2). Each peering adds routing complexity, and spoke-to-spoke traffic does not work through peering by default, so you need UDRs on every subnet. This is a management nightmare that will break during the first network change.
  • The correct approach for 10+ branches: Azure Virtual WAN with a single Virtual Hub. Deploy one vWAN hub per region. Each branch office creates a single S2S VPN tunnel to the hub. The hub automatically routes traffic between all branches and all connected VNets. Cost: approximately 180/monthforthehub+180/month for the hub + 140/month for the integrated VPN gateway + peering costs. Total around 400/monthvs400/month vs 1,400/month for separate gateways, with massively reduced operational complexity.
  • If the company already has SD-WAN appliances: vWAN integrates natively with major SD-WAN vendors (Cisco Viptela, VMware, Barracuda). The branch offices’ existing SD-WAN appliances can auto-discover and connect to the vWAN hub without manual IPsec tunnel configuration.
  • The scaling advantage: Adding branch #11 with vWAN takes 15 minutes (configure the VPN device, point it at the hub). Adding branch #11 with the separate-gateway approach requires a new VNet, new gateway, 10 new peering connections, and route table updates across all existing VNets.
Follow-up: Three of the 10 offices are in regions where Azure Virtual WAN is not available. How do you handle this?For offices in regions without vWAN support, I would deploy a standard VPN Gateway in the nearest supported region and use the branch office’s internet connection to reach it. The latency increase from routing to a nearby region (typically 10-30ms extra) is acceptable for most workloads. Alternatively, if those offices have ExpressRoute-capable ISPs, use an ExpressRoute circuit to the nearest Azure region with vWAN support and connect the circuit to the vWAN hub. The key principle is to maintain vWAN as the central routing fabric and treat the non-supported regions as edge cases, not exceptions that justify abandoning the architecture.