​

Hybrid Networking & Enterprise Connectivity

​

What You’ll Learn

• 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

• An office building with servers, databases, and employee computers
• Azure cloud where you’re building new applications

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)

• 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)

• 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

• 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/month savings cost them$2.3M

• Cost to do it right: $1,627/month × 12 = **$19,524/year**
• Cost of doing it wrong: $2.3M in one incident
• ROI: 117x return on investment

​

1. Connecting to On-Premises

​

Understanding the Two Connection Types (From Absolute Zero)

1. A corporate office with servers and databases
2. Azure cloud with applications and data
3. Developers working remotely who need access to both

​

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

Your Laptop (Home) --[VPN Tunnel]--> Azure VNet

• Developer working from home needs to access Azure resources
• IT admin connecting to troubleshoot
• Remote employee accessing internal systems

• 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

Your Office (100+ employees) --[VPN Tunnel]--> Azure VNet

• Entire corporate office needs access to Azure
• On-premises servers need to sync with Azure databases
• Hybrid applications spanning both environments

• 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)

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

• ✅ 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)

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.

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

• Developer creates VPN Gateway
• Chooses “Basic” to save money ($27/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

• 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/month savings cost them$450K

​

ExpressRoute (The Premium Option)

• Anyone can see the truck (even if they can’t open it)
• Depends on traffic conditions
• Slower, less predictable

• Nobody knows you’re moving gold
• Dedicated path, no traffic
• Faster, more predictable

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)

• Circuit fee (above)
• ExpressRoute Gateway ($213-$3,105/month)
• Outbound data (if not unlimited plan)
• Partner setup fees ($1,000-$5,000 one-time)

Circuit: $1,627/month
Gateway (Standard): $213/month
Outbound data (1 TB): $35/month
──────────────────────
Total: $1,875/month ($22,500/year)

• 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)

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

[!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/month instead of expected$1,627/month

• Team reads “ExpressRoute is better than VPN”
• Deploys ExpressRoute for dev environment
• Cost: $1,875/month for rarely-used connection

• VPN for Dev/Test ($140/month)
• ExpressRoute only for Production ($1,875/month)
• Savings: $1,735/month =$20,820/year

​

2. Azure Virtual WAN (vWAN)

​

Understanding Virtual WAN (From Absolute Zero)

• 5 offices around the world (New York, London, Tokyo, Sydney, Mumbai)
• 10 Azure VNets (Production, Dev, Test, etc.)
• Remote workers connecting from home

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

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

• You build runways (VPN gateways)
• You create flight paths (routing tables)
• You manage air traffic control (routing)
• Result: Complex, expensive, error-prone

• Microsoft builds the runways
• Microsoft manages flight paths
• Microsoft handles air traffic control
• Result: Simple, automated, reliable

​

Virtual WAN Components (Simplified)

• Location: One per Azure region
• Connects: Offices, VNets, remote users
• Routing: Automatic

• Connects your VNets to the hub
• Automatic routing between VNets

• Connects offices to Azure
• Up to 20 Gbps aggregate throughput

• Connects remote workers
• Up to 100,000 concurrent users

• Dedicated connections for high-traffic routes

​

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

• 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)

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

• Single office connecting to single VNet
• Developer reads “Virtual WAN is best practice”
• Deploys Virtual WAN
• Cost: $870/month

• Simple VPN Gateway would cost $140/month
• Waste: $730/month =$8,760/year

• < 3 connections = Use standard VPN
• ≥ 4 connections = Use Virtual WAN

​

3. User Defined Routes (UDR)

​

Understanding Routing (From Absolute Zero)

• Your house (VM in Subnet A)
• Friend’s house (VM in Subnet B)
• Grocery store (Internet)
• Security checkpoint (Azure Firewall)

You → Direct path → Friend's house ✅
You → Direct path → Grocery store ✅

You → MUST go through → Security checkpoint → Grocery store ✅
You → Direct path (unchanged) → Friend's house ✅

​

How UDR Works (Step-by-Step)

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 ✅

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)

1. User Defined Route (UDR) - You create these manually
2. BGP Route - Learned from ExpressRoute/VPN
3. System Route - Azure’s default routing

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 ✅

• /32 beats /24 beats /16 beats /8 beats /0

​

Common UDR Scenario: Force All Internet Traffic Through Firewall

az network route-table create \
  --name RT-Internet-Via-Firewall \
  --resource-group MyRG

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

• 0.0.0.0/0 = All internet traffic
• VirtualAppliance = Azure Firewall
• 10.0.1.4 = IP address of your firewall

az network vnet subnet update \
  --vnet-name MyVNet \
  --name SubnetA \
  --resource-group MyRG \
  --route-table RT-Internet-Via-Firewall

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 ✅

• Deploy new subnet
• Forget to associate route table
• Internet traffic bypasses firewall
• Security Risk: Unmonitored traffic

• 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)

• 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)

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

• 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

​

How Azure Bastion Works (Simplified)

• Anyone can walk up and try to break in
• 24/7 exposure to criminals

• Must go through security checkpoint first
• Security guards (Azure) verify identity
• Then you get access to your house

​

Azure Bastion: The Secure Solution

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!

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?

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

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

# 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

​

Using Azure Bastion (Step-by-Step)

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 ✅

# 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

• Create subnet named “BastionSubnet” (logical, right?)
• Try to deploy Bastion
• Error: “Subnet must be named AzureBastionSubnet”

• MUST be exactly AzureBastionSubnet (case-sensitive)
• Azure enforces this strictly

​

Common Mistake #6: Bastion for Every VNet

• Deploy Bastion in every VNet ($140/month each)
• 10 VNets = $1,400/month
• Waste: $1,260/month

• Deploy Bastion in Hub VNet ($140/month)
• Peer all Spoke VNets to Hub
• Use single Bastion for all VMs
• Savings: $1,260/month =$15,120/year

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