CDN Routing Mechanics

CDN routing is the process of directing user requests to the optimal edge server based on geography, network conditions, server health, and content type. CDNs combine DNS-based routing, BGP anycast, real-time performance monitoring, and intelligent load balancing to route each request to the server that delivers the best performance for that specific user at that moment.

CDN routing operates at multiple layers: DNS routing directs users to nearby edge clusters, BGP routing announces IP prefixes from multiple locations, application-layer routing within edge clusters load balances across servers, and origin selection chooses optimal backend for dynamic content. Each layer optimizes different aspects of request delivery.

The routing goal: minimize round-trip time (RTT) between user and edge server, maximize cache hit rate by serving from servers with requested content, maintain availability by avoiding overloaded or failed servers, and optimize cost by routing to efficient locations. Modern CDNs route traffic in real time based on thousands of metrics per second.

Last updated: 2026-04-22

How CDN Routing Works

CDN routing begins when a user requests content from a CDN-backed domain. The routing process involves multiple decision points:

Step 1: DNS Resolution

User’s browser queries www.example.com through DNS:

1. Recursive resolver queries authoritative nameserver for example.com
2. Authoritative nameserver returns CNAME pointing to CDN domain: www.example.com.cdn.example.net
3. Resolver queries CDN’s DNS infrastructure for cdn.example.net
4. CDN DNS returns IP address of optimal edge server for that resolver

The returned IP address is selected based on:

• Geographic location of resolver (geo-DNS)
• IP anycast routing (same IP announced from multiple locations)
• Server health and load
• Content availability (which edge has the content cached)
• Real-time performance metrics

Step 2: BGP Routing at Network Layer

User’s device connects to the IP address returned by DNS:

• For anycast IPs, BGP routes packets to nearest location announcing that prefix
• For unicast IPs, traffic routes to specific edge location selected by DNS
• Network operators tune BGP attributes (AS path, MED, local preference) to influence routing
• BGP convergence takes seconds to minutes; DNS routing adapts in milliseconds

Step 3: Edge Server Selection

At the edge location, load balancers distribute requests across servers:

• Layer 4 load balancers (TCP/UDP) distribute by IP:port
• Layer 7 load balancers (HTTP) route by URL path, headers, cookies
• Health checks remove failed servers from rotation
• Session affinity (sticky sessions) route same user to same server when needed

Step 4: Origin Selection

For cache misses or non-cacheable content, edge server fetches from origin:

• Multiple origin servers for redundancy
• Origin selection based on proximity, health, load
• Shielding: designate specific edge location as “shield” to deduplicate origin requests
• Connection pooling to origins reduces TCP/TLS handshake overhead

DNS-Based Routing

Geo-DNS (Geographic DNS)

Returns different IP addresses based on resolver’s geographic location:

• Database maps resolver IP to geographic region
• Different edge server IPs for different regions (Americas, Europe, Asia-Pacific)
• Reduces latency by routing to nearest edge location
• Limitations: resolver IP may not reflect user location (public resolvers like 8.8.8.8), inaccurate geo-IP databases

Example:

User in Brazil → Resolver in Brazil → CDN DNS returns IP of São Paulo edge server
User in Germany → Resolver in Germany → CDN DNS returns IP of Frankfurt edge server

Anycast DNS

Same IP address announced from multiple locations:

• BGP routes user to topologically nearest anycast location
• Failover automatic: if one location fails, BGP withdraws route, traffic flows to next nearest
• Simplifies DNS management: single IP instead of location-specific IPs
• Works at network layer; no geo-IP database required

How anycast works:

1. CDN assigns same IP address (e.g., 203.0.113.50) to edge servers in 50 locations
2. Each location announces 203.0.113.0/24 prefix via BGP
3. User’s packets route to nearest location via normal BGP path selection
4. If São Paulo location fails, it withdraws BGP announcement; Brazilian users route to next nearest (Miami or Virginia)

Latency-Based Routing

Measures RTT from resolver’s IP to candidate edge locations:

• CDN maintains latency database from real user traffic
• DNS responds with IP of edge location with lowest RTT
• More accurate than geo-DNS (measures actual network performance, not just geography)
• Adapts to network changes: congestion, outages automatically route around

Weighted Round-Robin DNS

Distributes traffic proportionally across locations:

• DNS returns different IPs with different probabilities
• Example: 40% to location A, 35% to location B, 25% to location C
• Used for gradual traffic migration, testing new locations, cost optimization
• Requires clients to query DNS frequently (respect TTL)

BGP Routing in CDNs

Prefix Advertisement

CDN announces IP prefixes (blocks of IP addresses) via BGP:

• Large CDNs own their IP address space (Provider Independent IP space)
• Announce prefixes from multiple locations via BGP to upstream ISPs
• ISPs propagate routes across internet
• Path to CDN IP determined by BGP’s shortest AS-path algorithm

Traffic Engineering

CDNs manipulate BGP attributes to influence routing:

Local Preference: Prefer certain routes internally

route-map PREFER-ISP1 permit 10
  set local-preference 200

Higher local preference = preferred route within CDN’s network.

AS Path Prepending: Make path appear longer, reducing preference

route-map DEPREP-CATE permit 10
  set as-path prepend 64512 64512 64512

Prepending CDN’s AS number multiple times makes path look longer, routing traffic away from this location.

Multi-Exit Discriminator (MED): Suggest preferred entry point to neighboring AS

route-map SET-MED permit 10
  set metric 50

Lower MED = preferred when multiple links to same neighbor AS.

Anycast Routing

Same IP prefix announced from multiple locations:

• Each location advertises prefix with similar BGP attributes
• Internet routers choose “nearest” based on AS-path length, IGP cost
• Automatic failover when location withdraws announcement
• Single IP address simplifies configuration, enables seamless failover

Edge Server Load Balancing

Layer 4 Load Balancing (Transport Layer)

Distributes TCP/UDP connections based on IP and port:

• Round-robin: rotate through servers sequentially
• Least connections: route to server with fewest active connections
• Source IP hash: same client IP always routes to same server (session affinity without state)
• Health checks: TCP SYN to server port, remove unresponsive servers

Advantages: Fast, simple, works for all TCP protocols Limitations: No visibility into HTTP layer, cannot route by URL or headers

Layer 7 Load Balancing (Application Layer)

Routes HTTP requests based on application data:

• URL path routing: /api/* to API servers, /static/* to static file servers
• Header routing: Host header, custom headers
• Cookie-based routing: session cookies for sticky sessions
• Content-based routing: route based on query parameters, request body

Advantages: Intelligent routing, health checks at HTTP level (GET /health returns 200 OK) Limitations: Higher latency (must receive full HTTP request), more resource-intensive

Consistent Hashing

Distributes cacheable content to maximize cache hit rate:

• Hash request URL to determine which edge server should handle it
• Same URL always routes to same server (where content is cached)
• When servers added/removed, only 1/N of URLs remap (minimize cache warming)
• Essential for maximizing cache efficiency in CDN edge clusters

Origin Selection and Shielding

Multi-Origin Load Balancing

Edge servers distribute origin fetches across multiple origins:

• Round-robin: rotate through origin servers
• Least connections: route to origin with fewest active requests
• Geographic proximity: edge in Europe prefers origin in Europe
• Health checks: active probes and passive failure detection

Origin Shielding

Designate specific edge location as shield for origin protection:

• All edges in a region fetch from shield, not directly from origin
• Shield deduplicates requests: 1000 edges requesting same content = 1 request to origin
• Reduces origin load, improves cache hit rate at shield
• Shield typically positioned close to origin

Example: Brazilian edges (São Paulo, Rio) fetch from shield in Virginia; Virginia shield fetches from origin in US East. Origin receives traffic from Virginia shield only, not from all Brazilian edges.

Connection Pooling

Reuse TCP connections between edge and origin:

• Persistent connections avoid TCP/TLS handshake per request
• Pool of idle connections ready for new requests
• Reduces latency and server overhead
• Critical for high-traffic origins

Real-Time Routing Optimization

Performance Monitoring

CDNs continuously measure performance to inform routing:

• Synthetic monitoring: Active probes from edges measure RTT, bandwidth to resolvers
• Real user measurements (RUM): JavaScript beacons report latency from actual users
• Passive monitoring: TCP handshake time, TLS handshake time, first byte time from real traffic
• Health monitoring: HTTP health checks, TCP probes, custom scripts

Data feeds into routing decisions: if latency to location A increases, route more traffic to location B.

Adaptive Routing Algorithms

Machine learning and optimization algorithms improve routing:

• Reinforcement learning: Learn routing policies from outcomes (latency, errors)
• Multi-armed bandit: Explore alternative routes opportunistically, exploit best-known routes
• Constraint optimization: Route under constraints (max latency, min bandwidth, budget)
• Real-time tuning: Adjust routing parameters based on current conditions (traffic spikes, outages)

CDNs update routing tables every few seconds to minutes, responding to network changes faster than BGP convergence (minutes to hours).

Cost-Aware Routing

Optimize routing for cost, not just performance:

• Different origin costs (server A cheaper than server B)
• Different egress costs (transit ISP A more expensive than ISP B at certain location)
• Balance performance and cost by routing traffic efficiently
• Tiered pricing models (first 10TB cheap, overages expensive) influence routing during high-traffic periods

CDN Routing vs Traditional Load Balancing

CDN routing extends load balancing principles to global scale with geographic distribution, anycast, and content awareness.

When CDN Routing Optimization Matters

CDN routing optimization matters when:

• Global user base requires low latency worldwide
• High traffic volumes demand efficient distribution
• Content changes frequently (cache invalidation coordination)
• Origin capacity limited (origin shielding essential)
• Multiple origins available (active-active setups, multi-cloud)
• Real-time performance monitoring needed for QoS

CDN routing less critical when:

• Single-region user base (no geographic distribution)
• Low traffic (origin can handle all requests)
• Content highly cacheable with long TTLs (edges serve majority)
• Simple architecture without origin redundancy

Signals You Need Better CDN Routing

• High latency from certain regions (poor edge placement or routing)
• Origin overloaded (ineffective shielding, cache misses high)
• Uneven load distribution (some edges overloaded, others underutilized)
• Poor cache hit rates (inconsistent routing prevents cache efficiency)
• Increased origin costs (excessive origin fetches, inefficient routing)
• User complaints about performance (incorrect geo-routing, BGP issues)

Metrics and Measurement

Routing Performance Metrics:

• Edge selection accuracy: Percentage of users routed to optimal edge (measure RTT variance)
• DNS resolution time: Time to resolve CDN hostname (target: <50ms)
• First byte time: Time from request to first byte received (target: <100ms from edge)
• Cache hit ratio: Percentage of requests served from cache (target: >90% for static content)
• Origin request rate: Requests from edge to origin (lower = better routing and caching)

Routing Efficiency Metrics:

• Geographic distribution: Traffic across regions matches user distribution
• Load distribution: Standard deviation of request rate across edges (low = balanced)
• Anycast attraction ratio: Traffic to each anycast location vs. expected
• Failover speed: Time to reroute traffic from failed edge (target: <30s for DNS, <5s for anycast)
• Cost efficiency: Egress cost per GB delivered (optimize routing for cost)

According to CDN performance benchmarks (2024), well-tuned CDN routing reduces median latency by 40-60% compared to single-origin architecture. Anycast routing failover time: 10-30 seconds (BGP convergence). DNS-based failover: 1-5 minutes (TTL + retries). Real-time adaptive routing improves latency by 10-20% over static geo-routing.

Real-World Use Cases

Global Media Streaming

• Video segments cached at edges worldwide
• Geography-based routing sends users to nearest edge
• Consistent hashing ensures same video segment served from same edge (maximize cache hits)
• Adaptive bitrate streaming adapts to network conditions
• Origin shield deduplicates requests during popular content releases (premiere events)

E-Commerce Platform

• Static assets (product images, CSS, JS) served from cache
• Dynamic content (pricing, cart) routed to nearest edge with origin fetch
• Session affinity ensures user’s cart consistent across requests
• High availability: automatic failover during origin outages
• Geographic routing: European users route to European origin, US users to US origin

SaaS Application

• API requests routed to nearest edge with origin forward
• WebSocket connections routed to specific edges (stateful)
• Multi-tenant routing: different customers route to different origins
• Cost optimization: route traffic to cheaper origins during low-priority periods
• Real-time health checks prevent routing to degraded origins

Multi-Cloud Architecture

• Origins in AWS, Google Cloud, Azure
• CDN routes based on origin cost, latency, availability
• Automatic failover between cloud providers
• Cost-aware routing during cloud provider outages or price changes
• Intelligent traffic distribution to avoid cloud egress charges

Gaming and Real-Time Applications

• UDP traffic routed via anycast for fastest path
• Game state servers distributed globally
• Players routed to nearest game server (minimize RTT for real-time gameplay)
• Matchmaking routes players in same region to same server
• Failover during server overload: distribute to nearby regions

Common Mistakes and Fixes

Mistake: Over-relying on geo-IP databases for routing Fix: Geo-IP databases have 5-15% error rate at city level, worse for mobile users. Combine geo-DNS with latency measurements (RUM, synthetic probes). Implement feedback loop: measure actual performance, adjust routing accordingly. Consider EDNS Client Subnet (ECS) to pass user IP prefix to authoritative DNS (privacy tradeoff).

Mistake: Setting DNS TTL too high for routing changes Fix: Lower TTL for CDN DNS records (60-300 seconds) enables faster routing updates during outages, load rebalancing, and traffic migrations. Tradeoff: higher DNS query load, slight latency increase (more DNS lookups). Use longer TTL for stable, well-performing routes; shorter TTL for testing, migration, or unstable regions.

Mistake: Not implementing origin shielding Fix: Enable origin shielding to protect origins from thundering herd during cache stampedes (popular content expires, thousands of edges fetch simultaneously). Shield deduplicates requests, reducing origin load by 10-100x for popular content. Position shield close to origin for low latency.

Mistake: Ignoring consistent hashing for cache routing Fix: Use consistent hashing to route same URL to same edge server consistently. Random or round-robin routing distributes same content across multiple servers, wasting cache space and reducing hit rates. Consistent hashing ensures content cached once per cluster, maximizing cache efficiency.

Mistake: Not monitoring anycast attraction Fix: Monitor traffic to each anycast location. Unexpected attraction changes indicate BGP routing shifts, potential outages, or traffic engineering issues. Set alerts for significant traffic deviation (>20% change). Work with ISPs to tune BGP attributes if traffic distribution suboptimal.

Mistake: Routing complexity without observability Fix: Implement comprehensive logging: DNS response (which IP returned, why), edge server handling request, routing decision (geo, latency, load), origin selected. Correlate across layers to troubleshoot routing issues. Without observability, routing problems are nearly impossible to diagnose.

Frequently Asked Questions

How does anycast work for CDN routing? Anycast assigns the same IP address to servers in multiple locations. Each location announces the IP prefix via BGP. Internet routers send traffic to the topologically nearest location based on BGP metrics. If a location fails, it withdraws its BGP announcement, and traffic flows to the next nearest. Provides automatic failover and load distribution without DNS changes.

Why use DNS routing instead of BGP anycast? DNS routing provides more control: route based on geography, latency measurements, server load, content presence. Anycast routes based on BGP metrics (AS-path length), which may not reflect performance (BGP shortest path ≠ lowest latency). Many CDNs combine both: anycast for failover and simplicity, DNS routing for intelligent optimization.

How do CDNs handle DNS resolver location vs. user location? Geo-DNS routes based on resolver IP, which may not reflect user location (especially with public resolvers like 8.8.8.8, 1.1.1.1). EDNS Client Subnet (ECS) passes user’s IP prefix to authoritative DNS, enabling more accurate routing. Privacy tradeoff: ECS reveals user subnet. Some CDNs use real user measurements (RUM) to validate routing effectiveness.

What is the difference between DNS load balancing and CDN routing? DNS load balancing returns different IPs for a domain based on various criteria. CDN routing is DNS load balancing plus a network of edge servers that cache content, terminate connections close to users, and forward to origins. CDN routing includes BGP anycast, edge server selection, origin selection, caching logic—much more than DNS alone.

How fast does CDN routing adapt to failures? DNS TTL + resolver retries: 1-5 minutes (depending on TTL and resolver behavior). Anycast BGP withdrawal: 10-30 seconds (BGP convergence). Health check-based removal: 5-30 seconds (depends on check interval and threshold). Adaptive real-time routing: seconds to minutes (depends on measurement frequency). Multi-layer failover combines these mechanisms.

Can CDN routing optimize for cost instead of performance? Yes. Cost-aware routing considers origin egress costs, transit costs, regional pricing differences. During high-traffic periods, route to cheaper origins or edges. Balance performance (user latency) with cost (infrastructure expense). Multi-cloud setups route between AWS, Google Cloud, Azure based on current pricing and committed use discounts.

How does session affinity work in CDN routing? Session affinity (sticky sessions) routes the same user to the same server for the session duration. Implemented via HTTP cookies (load balancer sets cookie, routes based on cookie), source IP hash (hash client IP to server), or session identifier in URL. Ensures stateful sessions consistent (shopping cart, WebSocket connection). Tradeoff: uneven load distribution if some users generate more traffic.

How This Applies in Practice

CDN routing is the intelligence layer that makes global content delivery possible. Understanding routing mechanisms helps architects design performant, reliable, cost-effective content delivery strategies.

Routing Design Considerations:

• Choose DNS-based routing for control, anycast for simplicity and failover, or combine both
• Implement origin shielding to protect origins from traffic spikes
• Use consistent hashing for cacheable content to maximize cache efficiency
• Monitor routing performance continuously and adapt to network changes
• Plan for failover at each layer: DNS, BGP, edge server, origin

Optimization Strategies:

• Measure real user latency, not just synthetic probes
• Lower DNS TTL during traffic migrations, testing, or unstable periods
• Implement health checks at multiple layers (TCP, HTTP, custom)
• Use cost-aware routing for high-traffic, multi-origin, or multi-cloud architectures
• Tune BGP attributes to control anycast attraction

Troubleshooting Routing Issues:

• Trace DNS resolution: dig, nslookup, DNS troubleshooting tools
• Verify BGP routes: looking glasses, BGP route collectors
• Measure RTT from user to different edge locations
• Check cache hit rates and origin request patterns
• Analyze logs for routing decisions: which edge, why, performance outcome
• Monitor anycast attraction changes indicating routing shifts

CDN Routing on Azion

Azion provides sophisticated routing through its global edge network:

• Anycast IP addresses announced from 100+ edge locations worldwide
• Real-Time Metrics for monitoring routing performance and traffic distribution
• Intelligent DNS with geographic and latency-based routing
• Edge Applications for Layer 7 routing based on URL, headers, geographic context
• Load Balancer for origin selection with active health checks
• Edge Caching with consistent hashing across edge servers
• Origin Shielding to protect backend infrastructure

Azion’s routing adapts in real time to network conditions, server health, and traffic patterns, ensuring optimal performance for users worldwide.

Learn more about Applications, Intelligent DNS, and Load Balancing.

Sources

• Buyya, R., et al. “Content Delivery Networks: Status and Trends.” IEEE Internet Computing, 2008.
• Nygren, E., et al. “The Akamai Network: A Platform for High-Performance Internet Applications.” ACM SIGOPS, 2010.
• Candela, M., et al. “On the Performance of Anycast in DNS-based CDNs.” IMC ‘19.
• BGP Routing Tables. “CIDR Report.” https://www.cidr-report.org/
• RIPE NCC. “DNS Monitoring.” https://dnsmon.ripe.net/