Load Balancing
Advanced 12 min read Load Balancing

Global and DNS Load Balancing

Picking the right region before the LB routes within it

Global load balancing (Route 53, Azure Traffic Manager, GCP Cloud DNS + CDN) routes users to the best region by latency, health or geography — an edge layer above the regional load balancers.

global load balancingRoute 53Traffic Managerlatency routinggeolocationhealth-based
Prerequisites: DNS
Before we start

What you will learn

  • Explain DNS-resolved global load balancing
  • Compare latency, geolocation and health-based policies
  • Chain global → regional → fleet layers
In 60 seconds

Before a request reaches a regional LB, DNS-level global balancing answers 'which region's LB?' via health checks and routing policies (latency, geolocation, weighted, failover). It's the outer frontier of a multi-region design.

Introduction

What is this?

AWS Route 53 routing policies: weighted, latency, geolocation, geoproximity, failover, multi-value — health checks attached to records. Azure Traffic Manager: performance, geographic, priority, weighted, multivalue profiles. GCP: Cloud DNS geo/latency-ish policies + GCLB global baking (Google's LB is intrinsically global with anycast). The chain: DNS → global policy → regional LB → fleet. Global LB caches health and TTLs; poor TTL = slow failover.

Motivation

Why do you need it?

  • Send EU users to EU LBs (latency win) and AU users to Sydney.
  • Failover at the edge: if a region is down, DNS serves the healthy next region.
  • Canary/blue-green across regions via weighted DNS.
  • Compliance: geolocation-routing keeps data close to origin for residency.
Think about it

Mental model

Imagine

Airline rebooking desk that chooses the airport by your destination and delays

Think of

Global DNS load balancing

The desk (DNS policy) checks which airports (regions) have open gates (healthy) and flights that leave soonest or nearest (latency/geo) — then forwards you to the regional gate (regional LB).

Mechanics

How it works

  • A health check sits on each region's endpoint; Route53/TM probes it (path, interval, failure threshold).
  • Policy (latency/geolocation/weight) selects the best healthy record for the resolving client.
  • TTL bounds how long resolvers cache: lower TTL (e.g. 60s) makes failover faster but adds DNS chattiness.
  • Client IP geolocation: based on the resolver's location (approximate; users on indirect DNS may skew).
  • Combining with CDN: the edge CDN absorbs static, global L4/L7 handles dynamic routing.

Global routing chain.

Client
Global policy
Region A LB
Regional fleet
Response
Hands-on

Examples

Latency + failover DNS policy

Latency + failover DNS policy
# Route 53: latency records for two regions + health checks
aws route53 create-health-check --caller-reference 'eu' \
  --health-check-config '{"Type":"HTTPS","ResourcePath":"/healthz","Port":443}'
aws route53 change-resource-record-sets --hosted-zone-id ZONE \
  --change-batch '{"Changes":[{
    "Action":"CREATE","ResourceRecordSet":{
      "Name":"app.example.com","Type":"A",
      "SetIdentifier":"eu-west-1","Region":"eu-west-1",
      "HealthCheckId":"hc-111", "TTL":60,
      "AliasTarget":"<eu-lb>"}}]}'

Two latency records with health checks fail over automatically and route EU users regionally.

Real world

In production

  • A SaaS routes EU+US via Route 53 latency records where each region runs an ALB + ASG.
  • Azure Traffic Manager priority profile keeps DR region on hot standby (lower cost).
  • GCP HTTP(S) LB's anycast edge plus Cloud DNS provides global health-aware routing.
Guidelines

Best practices

  • Keep DNS TTL short (30-60s) on global records to speed failover.
  • Attach health checks to every active record; never route to a dead region.
  • Model geo/latency by testing from real regions — resolver location ≠ client location sometimes.
  • Combine with regional LBs: global selects region, regional balances within it.
Watch out

Common mistakes

  • 60s TTL with long-time health checks → slow failover despite 'global' claims.
  • Latency routing confusing resolver IP with client IP (users on roaming/VPN skew).
  • Region health checks false-triggering on a dependency that lives in another region.
  • Weighed geo with a canary region that has no capacity during a spike.
Root cause analysis

Common issues

Error
EU clients hit US region
Root cause

Resolvers/user DNS pattern or geo-granularity

Fix

Inspect resolver IP; refine geolocation entries or guidance to trusted DNS for the region.

Error
Failover not engaging
Root cause

Health check marks region healthy or TTL cached

Fix

Verify the health path and probe interval; temporarily lower TTL and wait out cache.

When things break

Debugging tips

  • dig the record set: which record does your resolver get, and why?
  • Check the health check status before claiming 'we're up globally'.
  • Log 'region A vs B' splits on the backend to verify DNS routing actually works.
  • TTL slow to propagate: plan for edge-cached records in observability, not blame.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/1
1

What mainly controls how fast a global DNS failover takes effect?

Go deeper

Official documentation

AWS — Route 53 routing policies
docs
Azure — Traffic Manager
docs
GCP — External HTTP(S) LB
docs