Global Traffic & Latency Routing
Every user lands in the right kitchen
Sending each user to the best region: latency-based DNS, global load balancers, CDN ingress, and Anycast (for edge). Understand routing policies (geoproximity, latency, weighted), TTL, and traffic steering by context (health, cost, compliance).
What you will learn
- Choose DNS steering policies for multi-region reach
- Layer GSLB/CDN correctly
- Design health + cost + compliance-aware steering
Routing plan: 1) CDN/edge for static + HTTP (Anycast territories), 2) DNS steering (latency-based / geoproximity) to the nearest region for app entry, 3) global LB (AWS GA LB, Azure Front Door, GCP external LB) bridging DNS + frontend. Steering criteria: lowest latency, geo provenance, region health, cost weight.
What is this?
DNS steering: Route 53 latency-based (route to region with best measured latency for the resolver), geoproximity (weight by mile-degree + bias), weighted (A/B), multivalue; Azure Traffic Manager profiles (Performance=latency/nearest, Priority, Geographic, Weighted), GCP Cloud DNS policy / external LB backend selection. Global load balancers: AWS Global Accelerator (Anycast IPs + optimal AWS network path, health + static IPs), Azure Front Door (global HTTP routing + WAF + caching), GCP Global External Load Balancer (anycast VIP, HTTP routing to any backend region). CDN on the front for reads. Health + failover fusion: steering must observe region health (route unhealthy → geo bias to sibling). Contexts: latency precedence, compliance pinning (data residency via geoproximity bias), cost (route reads to cheaper region, writes stay home), canary launches (weighted steering to new region). TTL matters: lower TTL = faster steering change but more DNS load.
Why do you need it?
- Latency routing is the difference between 'the app is quick' and the user feeling distance.
- Steering with health in mind is how a region loss becomes a quiet shift instead of a 500 wall.
- Global LBs give static IPs + WAF/CDN without abandoning DNS steering.
- Compliance-aware steering keeps data in-region without manual IP gymnastics.
Mental model
Airline check-in: passengers routed to the counter whose line is shortest (latency) but flagged if they need the visa desk (compliance)
Traffic steering
The counter knows lines (latency), the region (geo), and the visitor's visa constraints (residency) — route accordingly; when a counter breaks, its passengers flow to the next closest.
How it works
- Edge/CDN fronts static; app entry resolves via DNS steering policy.
- Resolver asks; policy evaluates latency + geo + health + weights and returns best A/AAAA.
- Global LB (GA/Front Door/extLB) owns static IPs and steers internally for resilient paths.
- Region health events update steering (via LB health checks / DNS failover), rebalancing traffic.
- Compliance bias keeps regulated data bound to legal regions at resolve time.
Global traffic layer.
Examples
Route 53 + Global Accelerator layering
# Static: CloudFront (origin-agnostic; S3/GCS bucket or both)# App entry: AWS Global Accelerator (Anycast static IPs)# - listen on the GA IPs; accelerator forwards to the healthiest regional NLB/ALB# Steering inside GA: default traffic dial 100% → A; failover bias shifts to B.# DNS failback record via Route53 latency policy (for regions where you want explicit control)# TTL: records 30s; accelerate steering changes with health checks.CDN for reads, GA for the app entry — static IP + health-aware edge + DNS as the manual override lever.
In production
- Global Accelerator in front of regional ALBs; health check + failover dial.
- Traffic Manager Performance profile for Azure web tiers across paired regions.
- GCP global external LB with backend buckets + regional instance groups.
Best practices
- Steer with health at the global layer, not just DNS — a dead region must drop out, not round-robin.
- Keep TTL low on steering records you expect to move (30-60s).
- Layer CDN before the app so static bypasses origin entirely.
- Test geo/latency routing with probes from multiple continents (not your office).
- Compliance as steering bias: enforce residency before latency via geoproximity bias rules.
Common mistakes
- Steering by latency when the DB is single-region: fast front door, slow writes undermine success.
- No health integration: a dead region still receives the 'nearest' traffic.
- TTL dreams again: long TTLs delay any steering (& failover) change to users.
- Ignoring resolver location: latency-based DNS measures the resolver, not the end user's device.
Debugging tips
- Users route to wrong region → verify resolver-based metrics vs geoproximity; both have quirks.
- Healthy region gets no traffic → steering weights/bias off; check geoproximity bias direction.
- GA IPs unreachable → accelerator endpoint groups + listener port health; check region endpoint health.
- Failover slow after region outage → TTL + health threshold throttle steering; tune lower.
Interview checkpoint
Hands-on lab
- Model 2-3 regional endpoints locally
- Implement latency-based routing (simulated by ping/time)
- Add failover when the nearest region goes dark
Route Users to Their Nearest 'Region'
30 min · intermediate
Quick quiz
A failure you must design around when using latency-based DNS:
The layer that adds static IPs + deep health checks to global routing: