7. Geographic Distribution and Fault Tolerance
Chapter 7: Geographic Distribution and Fault Tolerance¶
📚 What You'll Learn in This Chapter¶
By the end of this chapter, you'll understand:
- ✓ Azure Regions (60+ locations worldwide)
- ✓ Availability Zones (3 per region)
- ✓ Region Pairs for disaster recovery
- ✓ Why geography matters for performance
- ✓ Data residency and compliance
- ✓ How to design for global applications
Time needed: 20-25 minutes
Difficulty: Moderate 🟡 (important for exam!)
Why this matters: Geography determines where your data lives, how fast your app runs, and whether you can meet legal requirements. Heavily tested on AZ-900!
The Geography Problem¶
Why does location matter in cloud computing?
┌──────────────────────────────────────────────────────────────┐
│ THE TWO CORE PROBLEMS: │
│ │
│ PROBLEM 1: DISTANCE = SLOW │
│ │
│ User in Tokyo → Server in London │
│ ↓ │
│ 9,000 km distance = 150ms latency │
│ ↓ │
│ Website feels SLOW! 🐌 │
│ │
│ PROBLEM 2: SINGLE LOCATION = RISKY │
│ │
│ All servers in one city │
│ ↓ │
│ Earthquake hits that city │
│ ↓ │
│ EVERYTHING goes down! 💥 │
│ │
│ ─────────────────────────────────────────────────────────────│
│ │
│ SOLUTION: GEOGRAPHIC DISTRIBUTION │
│ │
│ Deploy to multiple locations worldwide │
│ ↓ │
│ Users connect to nearest location (FAST! ⚡) │
│ ↓ │
│ If one location fails, others keep working (SAFE! ✓) │
│ │
└──────────────────────────────────────────────────────────────┘
Let's see how Azure solves this!
Azure's Geographic Structure¶
The Three Levels¶
┌──────────────────────────────────────────────────────────────┐
│ AZURE GEOGRAPHY HIERARCHY │
│ │
│ LEVEL 1: GEOGRAPHY (Largest) │
│ Large area (e.g., "United States", "Europe", "Asia") │
│ Contains multiple regions │
│ ↓ │
│ LEVEL 2: REGION (Medium) │
│ Specific location (e.g., "East US", "West Europe") │
│ Contains 3+ availability zones │
│ ↓ │
│ LEVEL 3: AVAILABILITY ZONE (Smallest) │
│ Individual datacenter building │
│ Physically separate location │
│ │
│ Think: Country → State → City │
│ │
└──────────────────────────────────────────────────────────────┘
Let's explore each level!
LEVEL 1: Geographies¶
┌─────────────────────────────────────────────────────────────────┐ │ 📖 SIMPLE TERMS │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ GEOGRAPHY: │ │ A large area defined by legal/compliance boundaries │ │ │ │ Think: Countries or continents with similar laws │ │ │ │ Example: "Europe" geography keeps data within EU for GDPR │ │ │ └─────────────────────────────────────────────────────────────────┘
Why Geographies Matter:
EXAMPLE: European Company with GDPR Requirements
┌──────────────────────────────────────────────────────────────┐
│ PROBLEM: │
│ EU law says customer data MUST stay in Europe │
│ │
│ SOLUTION: │
│ Deploy to "Europe" geography │
│ ↓ │
│ Azure guarantees data stays within EU borders ✓ │
│ │
│ AZURE GEOGRAPHIES: │
│ • Americas │
│ • Europe │
│ • Asia Pacific │
│ • Middle East and Africa │
│ • China (special, operated by 21Vianet) │
│ │
│ Each geography = Legal compliance boundary │
│ │
└──────────────────────────────────────────────────────────────┘
LEVEL 2: Regions¶
What is an Azure Region?¶
A region is a specific geographic location with one or more datacenters.
┌──────────────────────────────────────────────────────────────┐
│ AZURE HAS 60+ REGIONS WORLDWIDE! │
│ │
│ EXAMPLES: │
│ │
│ UNITED STATES: │
│ • East US (Virginia) │
│ • West US (California) │
│ • Central US (Iowa) │
│ • South Central US (Texas) │
│ │
│ EUROPE: │
│ • North Europe (Ireland) │
│ • West Europe (Netherlands) │
│ • UK South (London) │
│ • France Central (Paris) │
│ │
│ ASIA: │
│ • Southeast Asia (Singapore) │
│ • East Asia (Hong Kong) │
│ • Japan East (Tokyo) │
│ • Australia East (Sydney) │
│ │
│ And many more! New regions added regularly. │
│ │
└──────────────────────────────────────────────────────────────┘
Why Multiple Regions?¶
REASON 1: PERFORMANCE (Low Latency)
┌──────────────────────────────────────────────────────────────┐
│ GLOBAL E-COMMERCE WEBSITE │
│ │
│ SINGLE REGION (Bad): │
│ │
│ All servers in East US (Virginia) │
│ │
│ User in Virginia: 5ms latency ✓ Fast! │
│ User in California: 80ms latency ⚠️ Okay │
│ User in London: 100ms latency 🐌 Slow │
│ User in Tokyo: 150ms latency 🐌🐌 Very slow │
│ │
│ ─────────────────────────────────────────────────────────────│
│ │
│ MULTI-REGION (Good): │
│ │
│ Servers in: East US, West US, UK South, Japan East │
│ │
│ User in Virginia → East US: 5ms ⚡ │
│ User in California→ West US: 8ms ⚡ │
│ User in London → UK South: 10ms ⚡ │
│ User in Tokyo → Japan East: 6ms ⚡ │
│ │
│ Everyone gets FAST experience! 🎉 │
│ │
└──────────────────────────────────────────────────────────────┘
REASON 2: DISASTER RECOVERY
┌──────────────────────────────────────────────────────────────┐
│ BANKING APPLICATION │
│ │
│ SINGLE REGION (Risky): │
│ │
│ All servers in East US │
│ ↓ │
│ Hurricane hits Virginia │
│ ↓ │
│ Power out for 3 days │
│ ↓ │
│ Bank offline for 3 days! ❌ │
│ Customers angry, money lost │
│ │
│ ─────────────────────────────────────────────────────────────│
│ │
│ MULTI-REGION (Safe): │
│ │
│ Primary: East US │
│ Backup: West US │
│ ↓ │
│ Hurricane hits Virginia │
│ ↓ │
│ Auto-failover to West US (2 minutes) │
│ ↓ │
│ Bank stays online! ✓ │
│ Customers don't even notice │
│ │
└──────────────────────────────────────────────────────────────┘
LEVEL 3: Availability Zones¶
What is an Availability Zone?¶
┌─────────────────────────────────────────────────────────────────┐ │ 📖 SIMPLE TERMS │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ AVAILABILITY ZONE: │ │ A physically separate datacenter WITHIN a region │ │ │ │ Each zone has: │ │ • Its own building │ │ • Its own power supply │ │ • Its own cooling system │ │ • Its own network connection │ │ │ │ Think: 3 separate buildings in the same city │ │ │ └─────────────────────────────────────────────────────────────────┘
How Availability Zones Work¶
┌──────────────────────────────────────────────────────────────┐
│ EAST US REGION (Example) │
│ │
│ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ │
│ │ ZONE 1 │ │ ZONE 2 │ │ ZONE 3 │ │
│ │ │ │ │ │ │ │
│ │ Building A │ │ Building B │ │ Building C │ │
│ │ (10 miles away)│ │ (15 miles away)│ │ (12 miles away)│ │
│ │ │ │ │ │ │ │
│ │ • Own power │ │ • Own power │ │ • Own power │ │
│ │ • Own cooling │ │ • Own cooling │ │ • Own cooling │ │
│ │ • Own network │ │ • Own network │ │ • Own network │ │
│ │ │ │ │ │ │ │
│ │ Your VM #1 │ │ Your VM #2 │ │ Your VM #3 │ │
│ │ Your Database │ │ Your Database │ │ Your Database │ │
│ │ (copy 1) │ │ (copy 2) │ │ (copy 3) │ │
│ └────────────────┘ └────────────────┘ └────────────────┘ │
│ ↑ ↑ ↑ │
│ └──────────────────┴──────────────────┘ │
│ Connected by fast network │
│ (<2 milliseconds latency) │
│ │
│ WHY 3 ZONES? │
│ • Lightning hits Zone 1 → Zones 2&3 still work ✓ │
│ • Power outage Zone 2 → Zones 1&3 still work ✓ │
│ • Cooling fails Zone 3 → Zones 1&2 still work ✓ │
│ │
│ Your app stays online even if entire datacenter fails! 🎉 │
│ │
└──────────────────────────────────────────────────────────────┘
Real-World Zone Example¶
SCENARIO: E-Commerce Website During Black Friday
┌──────────────────────────────────────────────────────────────┐
│ DEPLOYMENT ACROSS 3 ZONES: │
│ │
│ Zone 1: 5 Web Servers + Database Replica │
│ Zone 2: 5 Web Servers + Database Replica │
│ Zone 3: 5 Web Servers + Database Replica │
│ │
│ Total: 15 servers across 3 physical buildings │
│ │
│ WHAT HAPPENS: │
│ │
│ 10:00 AM - Normal Operation: │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ Load Balancer distributes traffic evenly: │ │
│ │ Zone 1: 33% traffic (1,000 requests/sec) │ │
│ │ Zone 2: 33% traffic (1,000 requests/sec) │ │
│ │ Zone 3: 34% traffic (1,020 requests/sec) │ │
│ │ All zones healthy ✓ │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │
│ 11:30 AM - Zone 2 Power Failure! │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ Load Balancer detects Zone 2 is down (1 second) │ │
│ │ Automatically redistributes traffic: │ │
│ │ Zone 1: 50% traffic (1,500 requests/sec) ✓ │ │
│ │ Zone 2: 0% traffic (OFFLINE) ❌ │ │
│ │ Zone 3: 50% traffic (1,500 requests/sec) ✓ │ │
│ │ │ │
│ │ Customers don't notice anything! │ │
│ │ Sales continue, Black Friday saved! 🎉 │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │
│ 2:00 PM - Zone 2 Back Online: │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ Load Balancer detects Zone 2 is healthy │ │
│ │ Gradually shifts traffic back to 3-zone distribution │ │
│ │ All zones handling traffic again ✓ │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │
│ RESULT: │
│ • Total downtime: 0 seconds │
│ • Customer impact: None │
│ • Revenue lost: $0 │
│ │
└──────────────────────────────────────────────────────────────┘
Zone SLA Benefits¶
KEY EXAM FACT!
┌──────────────────────────────────────────────────────────────┐
│ SLA (SERVICE LEVEL AGREEMENT) BASED ON ZONES │
│ │
│ SINGLE ZONE (Single VM): │
│ SLA: 95% │
│ Downtime allowed: ~36 hours/year ❌ │
│ Not good for production! │
│ │
│ TWO ZONES (VMs in 2 different zones): │
│ SLA: 99.99% │
│ Downtime allowed: ~52 minutes/year ✓ │
│ Good for most applications │
│ │
│ THREE+ ZONES (VMs across 3 zones): │
│ SLA: 99.99% │
│ Downtime allowed: ~52 minutes/year ✓✓ │
│ Best practice for critical apps │
│ │
│ REMEMBER: │
│ Deploy across 2+ zones = 99.99% SLA guarantee! ⭐ │
│ │
└──────────────────────────────────────────────────────────────┘
Region Pairs¶
What are Region Pairs?¶
┌─────────────────────────────────────────────────────────────────┐ │ 📖 SIMPLE TERMS │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ REGION PAIR: │ │ Two regions that are permanently linked for disaster recovery │ │ │ │ Requirements: │ │ • At least 300 miles apart (different disaster zones) │ │ • In same geography (same legal jurisdiction) │ │ • Updates roll out to only one region at a time │ │ │ │ Think: Backup buddy in a different city │ │ │ └─────────────────────────────────────────────────────────────────┘
How Region Pairs Work¶
┌──────────────────────────────────────────────────────────────┐
│ REGION PAIRING EXAMPLE │
│ │
│ PRIMARY REGION PAIRED REGION │
│ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ East US │◄───────►│ West US │ │
│ │ (Virginia) │ Paired │(California) │ │
│ │ │ │ │ │
│ │ 300+ miles apart (earthquake-safe!) │
│ │ │ │ │ │
│ │ Production │ │ Backup │ │
│ │ Active │ Auto │ Standby │ │
│ │ │ Sync→ │ │ │
│ └─────────────┘ └─────────────┘ │
│ │
│ HOW IT WORKS: │
│ │
│ NORMAL OPERATION: │
│ • East US: Runs your application │
│ • West US: Receives continuous backup of data │
│ │
│ DISASTER SCENARIO: │
│ • Earthquake destroys East US datacenters │
│ • Azure automatically fails over to West US │
│ • West US becomes primary (2-5 minutes) │
│ • Users redirected to West US │
│ • Application continues running ✓ │
│ │
└──────────────────────────────────────────────────────────────┘
Common Region Pairs¶
┌──────────────────────────────────────────────────────────────┐
│ MAJOR AZURE REGION PAIRS │
├──────────────────────────────────────────────────────────────┤
│ │
│ UNITED STATES: │
│ • East US ↔ West US │
│ • East US 2 ↔ Central US │
│ • North Central US ↔ South Central US │
│ │
│ EUROPE: │
│ • North Europe (Ireland) ↔ West Europe (Netherlands) │
│ • UK South ↔ UK West │
│ • France Central ↔ France South │
│ │
│ ASIA: │
│ • Southeast Asia (Singapore) ↔ East Asia (Hong Kong) │
│ • Japan East ↔ Japan West │
│ • Australia East ↔ Australia Southeast │
│ │
│ All pairs are 300+ miles apart for safety! ✓ │
│ │
└──────────────────────────────────────────────────────────────┘
Benefits of Region Pairs¶
BENEFIT 1: PLANNED UPDATES (No downtime!)
┌──────────────────────────────────────────────────────────────┐
│ Microsoft needs to update Azure software │
│ │
│ WITHOUT REGION PAIRS: │
│ Update all regions at once → Everything down! ❌ │
│ │
│ WITH REGION PAIRS: │
│ │
│ Week 1: Update East US only │
│ ↓ │
│ West US still running (your backup!) ✓ │
│ ↓ │
│ Week 2: Update West US │
│ ↓ │
│ East US back and running ✓ │
│ │
│ Result: Always one region available! 🎉 │
│ │
└──────────────────────────────────────────────────────────────┘
BENEFIT 2: DATA RESIDENCY (Legal compliance)
┌──────────────────────────────────────────────────────────────┐
│ EU Law: Customer data must stay in EU │
│ │
│ Your Setup: │
│ Primary: North Europe (Ireland) │
│ Paired: West Europe (Netherlands) │
│ │
│ Both in EU! ✓ │
│ Data never leaves EU even during disaster recovery │
│ Compliant with GDPR ✓ │
│ │
└──────────────────────────────────────────────────────────────┘
Latency and Performance¶
Understanding Network Latency¶
┌──────────────────────────────────────────────────────────────┐
│ WHAT IS LATENCY? │
│ │
│ Latency = Time for data to travel from user to server │
│ │
│ Measured in milliseconds (ms) │
│ │
│ HUMAN PERCEPTION: │
│ • 0-50ms: Instant (users don't notice) ✓✓✓ │
│ • 50-100ms: Fast (barely noticeable) ✓✓ │
│ • 100-200ms: Okay (slight delay) ✓ │
│ • 200-500ms: Slow (annoying) ⚠️ │
│ • 500ms+: Very slow (users leave!) ❌ │
│ │
│ DISTANCE AFFECTS LATENCY: │
│ │
│ Same city: 5-10ms ⚡⚡⚡ │
│ Same coast: 30-50ms ⚡⚡ │
│ Coast to coast: 60-80ms ⚡ │
│ US to Europe: 100-120ms 🐌 │
│ US to Asia: 150-200ms 🐌🐌 │
│ Australia: 200-300ms 🐌🐌🐌 │
│ │
│ Physics limits! Light/electricity only travels so fast. │
│ │
└──────────────────────────────────────────────────────────────┘
Real-World Examples by Age Group¶
For Students (16-25):
ONLINE GAMING
┌──────────────────────────────────────────────────────────────┐
│ Fortnite Server Selection │
│ │
│ You're in California playing Fortnite │
│ │
│ OPTION 1: Connect to Asian server │
│ Latency: 150ms │
│ Result: Lag! Enemies shoot you before you see them! ❌ │
│ │
│ OPTION 2: Connect to US West server │
│ Latency: 15ms │
│ Result: Smooth gameplay! You win! ✓ │
│ │
│ This is why games have regional servers! │
│ Azure regions enable this globally. │
│ │
└──────────────────────────────────────────────────────────────┘
For Career Changers (25-45):
VIDEO CONFERENCING
┌──────────────────────────────────────────────────────────────┐
│ Zoom/Teams Meeting Quality │
│ │
│ You're in New York, colleague in London │
│ │
│ BAD SETUP: │
│ Meeting server in Australia │
│ Latency: 250ms │
│ Result: Delayed audio, constant "Can you hear me?" ❌ │
│ │
│ GOOD SETUP: │
│ Meeting server in US East (close to both) │
│ Latency: 50ms │
│ Result: Clear, real-time conversation ✓ │
│ │
│ Azure's global regions enable smooth remote work! │
│ │
└──────────────────────────────────────────────────────────────┘
For Professionals (45-60):
FINANCIAL TRADING PLATFORM
┌──────────────────────────────────────────────────────────────┐
│ Stock Trading Application │
│ │
│ REQUIREMENT: Execute trades in <10ms (regulatory) │
│ │
│ WRONG APPROACH: │
│ Servers in West US, stock exchange in New York │
│ Latency: 60ms (too slow!) │
│ Can't execute trades fast enough ❌ │
│ Could lose millions! │
│ │
│ CORRECT APPROACH: │
│ Deploy to East US (same region as NYSE) │
│ Latency: 2ms │
│ Trades execute instantly ✓ │
│ Regulatory compliance met ✓ │
│ │
│ Geography = Money in finance! │
│ │
└──────────────────────────────────────────────────────────────┘
Data Residency and Compliance¶
What is Data Residency?¶
┌─────────────────────────────────────────────────────────────────┐ │ 📖 SIMPLE TERMS │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ DATA RESIDENCY: │ │ Legal requirement that certain data must stay in specific │ │ geographic locations │ │ │ │ Why it matters: │ │ • Privacy laws (GDPR in EU) │ │ • Government regulations │ │ • Industry compliance (healthcare, finance) │ │ │ │ Azure regions help you meet these requirements │ │ │ └─────────────────────────────────────────────────────────────────┘
Compliance Examples¶
SCENARIO 1: EU HEALTHCARE PROVIDER
┌──────────────────────────────────────────────────────────────┐
│ REQUIREMENT: GDPR │
│ Patient data must stay in European Union │
│ │
│ WRONG: │
│ Store data in US East ❌ │
│ Violates GDPR! Could face €20 million fine! │
│ │
│ CORRECT: │
│ Primary: North Europe (Ireland) ✓ │
│ Backup: West Europe (Netherlands) ✓ │
│ Both in EU → GDPR compliant! │
│ │
└──────────────────────────────────────────────────────────────┘
SCENARIO 2: CHINESE COMPANY
┌──────────────────────────────────────────────────────────────┐
│ REQUIREMENT: Chinese Law │
│ Data about Chinese citizens must stay in China │
│ │
│ SOLUTION: │
│ Use Azure China regions │
│ Operated by 21Vianet (not Microsoft) │
│ Data never leaves China ✓ │
│ │
└──────────────────────────────────────────────────────────────┘
Designing for Global Applications¶
Strategy 1: Single Region (Simple)¶
┌──────────────────────────────────────────────────────────────┐
│ WHEN TO USE: │
│ • Small local business │
│ • All users in same area │
│ • Budget constrained │
│ • Don't need disaster recovery │
│ │
│ EXAMPLE: │
│ Local pizza shop with online ordering │
│ All customers within 10 miles │
│ Deploy to nearest region only │
│ │
│ PROS: │
│ ✓ Cheapest option │
│ ✓ Simplest to manage │
│ │
│ CONS: │
│ ❌ No disaster recovery │
│ ❌ Regional outage = total downtime │
│ │
└──────────────────────────────────────────────────────────────┘
Strategy 2: Region Pair (Safe)¶
┌──────────────────────────────────────────────────────────────┐
│ WHEN TO USE: │
│ • Need disaster recovery │
│ • Users mostly in one area │
│ • Can accept slight failover delay │
│ • Compliance requires data in specific geography │
│ │
│ EXAMPLE: │
│ Regional bank (US only) │
│ Primary: East US (active) │
│ Backup: West US (standby) │
│ │
│ PROS: │
│ ✓ Protected from regional disasters │
│ ✓ Moderate cost │
│ ✓ Compliance friendly │
│ │
│ CONS: │
│ ❌ 2-5 minute failover time │
│ ❌ West Coast users still have higher latency │
│ │
└──────────────────────────────────────────────────────────────┘
Strategy 3: Multi-Region (Global)¶
┌──────────────────────────────────────────────────────────────┐
│ WHEN TO USE: │
│ • Global user base │
│ • Need best performance worldwide │
│ • 24/7 uptime critical │
│ • Budget allows │
│ │
│ EXAMPLE: │
│ Netflix-style streaming service │
│ │
│ Regions: │
│ • East US (Americas) │
│ • West Europe (Europe/Africa) │
│ • Southeast Asia (Asia/Pacific) │
│ • Australia East (Oceania) │
│ │
│ Each region: │
│ • Runs full copy of application │
│ • Has complete data copy │
│ • Serves local users │
│ │
│ PROS: │
│ ✓ Best performance worldwide │
│ ✓ Highest availability │
│ ✓ Regional failure = zero impact │
│ │
│ CONS: │
│ ❌ Most expensive │
│ ❌ Complex to manage │
│ ❌ Data synchronization challenges │
│ │
└──────────────────────────────────────────────────────────────┘
📝 Chapter Summary¶
Key Points to Remember:
✅ Geographic Structure - Geography > Region > Availability Zone - 60+ Azure regions worldwide - Each region has 3+ availability zones
✅ Availability Zones - Physically separate datacenters within a region - Deploy across 2+ zones = 99.99% SLA - Protection against datacenter-level failures
✅ Region Pairs - Two regions permanently linked - 300+ miles apart (different disaster zones) - Updates roll out to one region at a time - Data stays in same geography (compliance)
✅ Latency Matters - Distance = delay - Same region: 5-10ms - Cross-continent: 100-200ms - Deploy close to users for best performance
✅ Data Residency - Legal requirements for data location - Use appropriate geography for compliance - GDPR, Chinese law, healthcare regulations
✅ Design Strategies - Single region: Simple, cheap, risky - Region pair: Safe, moderate cost - Multi-region: Best performance, expensive
✅ Self-Check¶
Before moving on, can you:
□ Explain the difference between regions and availability zones?
□ Know how many zones are in a region? (Typically 3)
□ Understand why region pairs are 300+ miles apart?
□ Calculate SLA benefit of deploying across zones?
□ Explain why latency matters for user experience?
🎯 Practice Questions¶
Question 1: How many availability zones does a region typically have?
A) 1
B) 2
C) 3 or more
D) 10
Question 2: What SLA can you get by deploying VMs across two availability zones?
A) 95%
B) 99%
C) 99.9%
D) 99.99%
Question 3: Why are region pairs at least 300 miles apart?
A) To reduce cost
B) To improve latency
C) To avoid both being affected by same disaster
D) Because of international law
Question 4: User in Tokyo connects to server in Virginia. Approximate latency?
A) 10ms
B) 50ms
C) 100ms
D) 150-200ms
Question 5: EU company must keep customer data in Europe per GDPR. Which regions should they use?
A) East US and West US
B) North Europe and West Europe
C) East Asia and Southeast Asia
D) Any regions (doesn't matter)
✍️ Practice Answers¶
Question 1: C - 3 or more availability zones
Explanation: Azure regions that support availability zones have a minimum of 3 zones. This provides redundancy - if one zone fails, you still have 2 others running. Not all regions have zones, but those that do have at least 3.
Question 2: D - 99.99% SLA
Explanation: Single VM = 95% SLA. Two or more VMs across availability zones = 99.99% SLA. This is a key exam fact! Deploying across zones dramatically improves your SLA guarantee from Azure.
Question 3: C - To avoid both being affected by same disaster
Explanation: The 300-mile minimum ensures that region pairs are in different disaster zones. An earthquake, flood, or hurricane affecting one region won't affect the paired region. This geographic separation is critical for disaster recovery.
Question 4: D - 150-200ms
Explanation: Tokyo to Virginia is approximately 11,000 km. Due to the speed of light limit and network routing, this results in 150-200ms latency. This is why you'd deploy to Japan East region for Japanese users instead!
Question 5: B - North Europe and West Europe
Explanation: GDPR requires EU citizen data to stay within the European Union. North Europe (Ireland) and West Europe (Netherlands) are both in the EU AND they're a region pair, providing both compliance and disaster recovery. Using US or Asian regions would violate GDPR.
🔖 Quick Reference Card¶
┌──────────────────────────────────────────────────────────────┐
│ GEOGRAPHIC DISTRIBUTION CHEAT SHEET │
├──────────────────────────────────────────────────────────────┤
│ │
│ HIERARCHY: │
│ Geography → Region → Availability Zone │
│ │
│ KEY NUMBERS (memorize!): │
│ • 60+ Azure regions worldwide │
│ • 3+ availability zones per region (typically) │
│ • 300+ miles between region pairs │
│ • <2ms latency between zones │
│ │
│ SLA BENEFITS: │
│ • Single zone: 95% SLA │
│ • Two+ zones: 99.99% SLA ⭐ │
│ │
│ LATENCY GUIDELINES: │
│ • Same region: 5-10ms (excellent) │
│ • Same continent: 30-80ms (good) │
│ • Cross-continent: 100-200ms (acceptable) │
│ │
│ REGION PAIRS: │
│ • East US ↔ West US │
│ • North Europe ↔ West Europe │
│ • Southeast Asia ↔ East Asia │
│ • Updates to one region at a time │
│ │
│ COMPLIANCE: │
│ • EU data → EU regions (GDPR) │
│ • China data → China regions │
│ • Use geographies for compliance │
│ │
└──────────────────────────────────────────────────────────────┘
End of Chapter 7 ✓
Reading Time: ~20 minutes
Concepts Covered: Regions, zones, pairs, latency, compliance
Practice Questions: 5
Diagrams: 12+
Ready for Chapter 9: Core Azure Services! This is a big one! 🚀 -e