> ## 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. # 03b. Hybrid & Enterprise > Master ExpressRoute, VPN, Virtual WAN, and Routing # 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/month savings cost them $2.3M **The ROI Math:** * 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 *** 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**: | SKU | Bandwidth | Tunnels | Zone Redundant? | Cost/Month | Use Case | | ------------ | --------- | ------- | --------------- | ---------- | ---------------------- | | **Basic** | 100 Mbps | 10 | No | \$27 | Dev/Test only (No BGP) | | **VpnGw1** | 650 Mbps | 30 | No | \$140 | Production Entry | | **VpnGw2AZ** | 1 Gbps | 30 | **Yes** | \$361 | Mission Critical | | **VpnGw5AZ** | 10 Gbps | 100 | **Yes** | \$1,445 | High 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/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/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 Speed | Monthly Cost | Outbound Data | Total Cost/Month | | ------------- | ------------ | ------------- | ---------------- | | 50 Mbps | \$56 | Unlimited | \$56 | | 100 Mbps | \$100 | Unlimited | \$100 | | 500 Mbps | \$635 | Unlimited | \$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-$3,105/month) * Outbound data (if not unlimited plan) * Partner setup fees ($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:** | Factor | VPN (VpnGw1) | ExpressRoute (1 Gbps) | | ------------------- | ----------------- | --------------------------- | | Cost | \$140/month | \$1,875/month | | Setup Time | 30 minutes | 4-12 weeks | | Bandwidth | 650 Mbps | 1 Gbps-100 Gbps | | Latency | Varies (20-100ms) | Consistent (\<10ms) | | SLA | 99.9% | 99.95% | | Internet Dependency | Yes | No | | Compliance | Basic | HIPAA, PCI-DSS, FedRAMP | | Best For | Small/Medium | Enterprise/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/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 = $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 | Approach | Components | Monthly Cost | Setup Time | | --------------- | ----------------------------------------------------------------------------- | --------------------------- | ---------- | | **Manual** | 3 VPN Gateways
45 VNet Peerings
50 Route Tables
Azure Firewall | \$1,450/month | 80 hours | | **Virtual WAN** | 1 Virtual WAN
1 Virtual Hub
Auto-everything | \$870/month | 2 hours | | **Savings** | - | $580/month
$6,960/year | 78 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 = $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 Type | Destination | Next Hop | Specificity | | ------------ | ----------- | ------------ | ------------------- | | System Route | 0.0.0.0/0 | Internet | /0 (least specific) | | UDR | 10.0.0.0/8 | Firewall | /8 | | BGP | 10.5.0.0/16 | ExpressRoute | /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** ```bash theme={null} az network route-table create \ --name RT-Internet-Via-Firewall \ --resource-group MyRG ``` **2. Add Rule: Send All Internet Traffic to Firewall** ```bash theme={null} 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** ```bash theme={null} 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/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:** | Approach | Setup | Monthly Cost | Security Risk | | ------------------------ | ------- | ------------ | ------------------------------- | | **Public IP + Open RDP** | Free | \$4/month | EXTREME (targeted daily) | | **VPN Gateway** | Complex | \$140/month | Low (but requires VPN client) | | **Azure Bastion** | Simple | \$140/month | Very 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:** ```bash theme={null} # 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 (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):** ```bash theme={null} # 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 = $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) 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 + $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-$50,000 per violation). One 4-hour outage affecting 50 doctors is 200 person-hours of lost productivity at $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/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/month for the hub + $140/month for the integrated VPN gateway + peering costs. Total around $400/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.