Load Balancing & Virtual Machine Scale Sets

Azure Fundamentals

Chapter 8 · Load Balancing & Virtual Machine Scale Sets

AWS Fundamentals Chapter 8 covered three real load balancer types (Classic, ALB, NLB) plus Auto Scaling Groups. Azure genuinely splits this into more, more specialized real services — four distinct load balancing options, each solving a different real problem, plus Virtual Machine Scale Sets for the compute side.

Four Real Azure Load Balancing Services

Service	Layer	Scope	Real Use Case
Load Balancer	4 (TCP/UDP)	Regional (or cross-region)	High-performance, ultra-low-latency non-HTTP(S) traffic; zone redundant
Application Gateway	7 (primarily)	Regional	Path-based routing, TLS offload, WAF, for public traffic entering one region's own private network
Azure Front Door	7	Global	Global HTTP(S) load balancing, CDN, fast failover across regions
Traffic Manager	DNS-based	Global	Any traffic type via DNS routing, but real, genuinely slower failover (DNS caching/TTL delays)

A Real, Useful Technical Distinction: Passthrough vs. Terminating

Two Genuinely Different Connection Models

Azure's own documentation draws a real, useful distinction: a passthrough load balancer (like Load Balancer) lets a client establish a connection directly with the specific backend server the load balancer's own algorithm selected. A terminating load balancer (like Application Gateway) has the client connect to the load balancer itself, which then initiates a genuinely separate connection to the backend on the client's behalf. This maps conceptually onto AWS Fundamentals Chapter 8's own NLB (passthrough-like) vs. ALB (proxy-based, terminating) distinction — the same underlying real trade-off, just named more explicitly in Azure's own documentation.

Regional vs. Global — A Real, Explicit Decision

Every one of the four services above is real, explicitly categorized along two dimensions: global vs. regional, and HTTP(S) vs. non-HTTP(S). A regional service (Load Balancer, Application Gateway) distributes traffic within one virtual network. A global service (Front Door, Traffic Manager) distributes traffic across multiple regions, clouds, or hybrid on-premises services through one real, unified control plane — genuinely closer to what a multi-Region AWS architecture would need to build manually on top of Route 53 and cross-region infrastructure.

Virtual Machine Scale Sets

Azure's own real equivalent of an Auto Scaling Group is the Virtual Machine Scale Set (VMSS) — a group of load-balanced, identically configured VM instances that automatically grows or shrinks in response to real demand or a defined schedule. Every instance is created from the same base OS image and configuration, exactly as an AWS ASG's own launch template ensures.

Free, Again

Continuing this course's own recurring real pattern (VNets in Chapters 1 and 5), there's genuinely no extra charge for the scale set service itself — you're billed only for the real compute, network, and storage resources it actually uses.

A real scale set supports up to 1,000 VM instances when using standard marketplace or custom images through Azure Compute Gallery — that real limit drops to 600 instances if you instead use a managed image directly.

A Real, One-Time Decision

VMSS offers two real orchestration modes — Uniform and Flexible — and the mode is set when the scale set is created and genuinely cannot be changed afterward. Flexible mode offers higher availability guarantees by spreading instances across fault domains, and supports mixing VM types or Spot and on-demand instances together within the same scale set; Uniform mode is the older, simpler model. Choosing wrong at creation time means recreating the scale set entirely to switch.

A Scale Set Alone Isn't Zone Protection

Microsoft's own real documentation states this plainly: "a scale set alone can't protect you against data center failures." Real Availability Zone distribution has to be explicitly configured on top of the scale set — and, per Chapter 1's own gotcha, this real protection is only available at all in regions that actually support Availability Zones in the first place.

Autoscale Rules

VMSS autoscale rules work the same real way as an AWS Auto Scaling Group's own target tracking policy (AWS Fundamentals Chapter 8) — a real, defined metric (commonly CPU utilization) drives capacity up or down automatically to hold a target range, adding instances as demand rises and removing them as it falls, to avoid paying for unnecessary capacity during quiet periods.

ALB/NLB vs. Azure's Four Services

Property	AWS	Azure
Regional Layer 4	NLB	Load Balancer
Regional Layer 7	ALB	Application Gateway
Global HTTP(S) + CDN	CloudFront + Route 53, combined manually	Azure Front Door, one real integrated service
DNS-based global routing	Route 53 routing policies	Traffic Manager
Auto-scaling compute group	Auto Scaling Group	Virtual Machine Scale Set (free of extra charge)

Hands-On Exercises

Exercise 1

A public web application needs path-based routing (/api vs /web), TLS offload, and a web application firewall - but is deployed in only a single Azure region. Recommend a real service from this chapter, and explain why Azure Front Door alone would be a genuinely poor fit despite also supporting Layer 7 features.

📄 View solution

Exercise 2

A team creates a VM Scale Set using Uniform orchestration mode, and six months later decides they need Flexible mode's own ability to mix Spot and on-demand instances. Explain, in your own words, what real, concrete step this actually requires.

📄 View solution

Exercise 3

A team deploys a Virtual Machine Scale Set in a region and assumes this alone genuinely protects them against an entire datacenter outage. Explain, in your own words, why this assumption is incorrect, and what real, additional step from this chapter and Chapter 1 is needed.

📄 View solution

Chapter 8 Quick Reference

Load Balancer (L4, regional, passthrough), Application Gateway (L7, regional, terminating/WAF), Front Door (L7, global, CDN), Traffic Manager (DNS-based, global)
Real distinction: passthrough (client connects directly to the chosen backend) vs. terminating (client connects to the load balancer itself)
VMSS — free of extra charge, up to 1,000 instances (600 with a managed image), auto-scales via real metric-based rules
Real gotcha: orchestration mode (Uniform vs. Flexible) is set at creation and cannot be changed afterward
Real gotcha: a scale set alone doesn't protect against a datacenter failure — explicit AZ configuration is still required (and only available in AZ-supporting regions, per Chapter 1)