Global Traffic Management
Global traffic management decides which healthy application location should receive a user’s connection. It combines traffic-steering policy, health signals, and global delivery mechanisms such as DNS, anycast, and proxies.
itWeb servers, proxies, and traffic management | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic — Global Traffic Management
Global traffic management decides which application location receives a new connection. It exists because putting a service in several regions does not make the internet pick the healthy, permitted, or adequately provisioned one by telepathy. Before this control layer, each client reached whatever address it had, and the application discovered the consequences later, usually at an inconvenient volume.
The useful shape is a small control loop: signals establish eligibility, a steering policy chooses among eligible destinations, and a steering plane applies that decision. The three common planes are DNS, anycast, and a global proxy. DNS changes an authoritative answer; anycast lets routing choose one location for a shared address; a proxy receives the connection and selects an origin pool. They can work together, because apparently the internet enjoys giving the same job several hats.
DNS has the first surprise. A DNS traffic manager does not handle the connection it influences. A recursive resolver, the DNS server that retrieves and caches answers for clients, can retain an answer for its time to live. A lower TTL shortens the intended cache period, but it does not recall answers already cached or turn DNS into a per-request switch. Keep an old destination available while safe cache overlap passes.
Health is evidence, not truth. A TCP check says a port accepted a connection. An HTTP check can test a path and response. Neither proves that every dependency or critical user journey works. Probe from relevant locations, use failure and recovery thresholds, and avoid a check that either misses the request path or removes every location because one shared dependency failed.
Failover is also a capacity event. In active-active placement, several locations serve traffic and must handle data and session behavior across locations. In active-passive placement, the recovery location waits and can drift. Neither arrangement manufactures spare capacity, moves sessions, or replicates data. The surviving location must already be able to accept the transfer.
Read the Course tab for the full control loop and failure behavior. Use Slides to compare the three steering planes and their timelines. Keep Cheatsheet nearby when choosing health signals, rollout weights, and the manual override that will seem unnecessary right up until it becomes the most interesting control in the room.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://www.rfc-editor.org/rfc/rfc9499.html
Supports
- Authoritative server and recursive resolver roles
- DNS caching, record sets, and TTL terminology
- Separation between DNS resolution and later application connections
- https://www.rfc-editor.org/rfc/rfc4786.html
Supports
- Anycast service addresses, nodes, catchments, and route-based selection
- Coarse and potentially uneven load distribution
- Location-dependent monitoring and routing changes
- Transaction duration, node autonomy, and data synchronization limits
- Publication of operational anycast guidance in December 2006
- https://www.rfc-editor.org/rfc/rfc8767.html
Supports
- Resolver use of stale cached data when authoritative refresh fails
- TTL as the duration before the source must again be consulted
- Resiliency and freshness tradeoffs during DNS failure
- https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html
Supports
- Failover, weighted, latency, geolocation, geoproximity, IP-based, and multivalue DNS policies
- Different policies serving different placement intents
- https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/route-53-concepts.html
Supports
- Recursive resolver reuse of cached values before TTL expiry
- TTL expressed as a DNS cache duration
- https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html
Supports
- Endpoint, calculated, and alarm-based health checks
- DNS failover from an unhealthy resource to a healthy resource
- https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-simple-configs.html
Supports
- Health checks running periodically rather than in response to each DNS query
- Routing-policy selection combined with record health
- https://developers.cloudflare.com/load-balancing/monitors/
Supports
- Regular health probes, endpoint status, and pool removal
- Multi-region health vantage points and majority evaluation
- HTTP, HTTPS, TCP, and other monitor behavior
- https://developers.cloudflare.com/reference-architecture/architectures/load-balancing/
Supports
- Priority, weighted, geographic, dynamic, proximity, and request-aware steering
- Endpoint pools, health thresholds, and probe path design
- DNS and layer seven proxy traffic management distinctions
- Active destination selection and fallback behavior
- https://developers.cloudflare.com/load-balancing/load-balancers/common-configurations/
Supports
- Active-passive and active-active pool arrangements
- Failure thresholds, fallback pools, and traffic transfer
- https://developers.cloudflare.com/load-balancing/reference/load-balancing-analytics/
Supports
- Traffic flow, endpoint health, and pool health analysis
- Filtering by pools, regions, and endpoints
- https://github.com/sindresorhus/awesome
Supports
- Discovery of the Awesome SDN list from the canonical awesome index
- https://github.com/sdnds-tw/awesome-sdn
Supports
- Discovery of FRRouting and BIRD as BGP routing projects
- https://docs.frrouting.org/en/latest/
Supports
- FRRouting as an IP routing suite with BGP
- User guidance for routing policy, route state, configuration, and operations
- https://bird.network.cz/doc/bird.html
Supports
- BIRD user documentation for BGP, routing tables, filters, and diagnostics
- https://www.rfc-editor.org/info/rfc1034/
Supports
- Publication of Domain Names - Concepts and Facilities in November 1987
- DNS authoritative-server and resolver architecture
- https://www.rfc-editor.org/rfc/rfc1105.html
Supports
- Publication of the Border Gateway Protocol in June 1989
- Exchange of inter-autonomous-system reachability information
- https://www.rfc-editor.org/info/rfc1546/
Supports
- Publication of Host Anycasting Service in November 1993
- Delivery to one server accepting traffic for an anycast address
- https://www.rfc-editor.org/info/rfc1771/
Supports
- Publication of BGP-4 in March 1995
- BGP route advertisement and interdomain routing context
- https://aws.amazon.com/about-aws/whats-new/2010/12/06/announcing-amazon-route-53-dns-service/
Supports
- Amazon Route 53 launch in December 2010
- Managed DNS routing to AWS and external Internet applications
- https://blog.cloudflare.com/introducing-load-balancing-intelligent-failover-with-cloudflare/
Supports
- Cloudflare Load Balancing availability announcement in May 2017
- Health monitoring, failover, and geographic origin selection
- https://cloud.google.com/blog/products/gcp/announcing-ipv6-global-load-balancing-ga
Supports
- IPv6 global load balancing general availability in September 2017
- Single anycast virtual IP with health and capacity-aware backend selection
- https://blog.cloudflare.com/i-wanna-go-fast-load-balancing-dynamic-steering/
Supports
- Dynamic Steering release in July 2018
- Latency-informed origin-pool selection
- https://www.cloudflare.com/products/load-balancing/
Supports
- Cloudflare Load Balancing across servers, data centers, and cloud environments
- Health and latency-based traffic routing
- https://www.akamai.com/products/global-traffic-management
Supports
- Akamai Global Traffic Management DNS-based policy and load-feedback routing
- Health, geographic, weighted, and real-time condition inputs
- https://learn.microsoft.com/en-us/azure/traffic-manager/traffic-manager-how-it-works
Supports
- Azure Traffic Manager DNS-level endpoint selection and health-based failover
- Traffic routing across Azure and external endpoints
- https://cloud.google.com/load-balancing
Supports
- Google Cloud global anycast front ends and multi-region backend selection
- Health, proximity, and capacity inputs for global load balancing
