Anycast vs Unicast in CDN: Routing Strategies Compared

Anycast and unicast are the two fundamental IP routing strategies that CDN providers use to direct user requests to the right edge server. Anycast assigns a single IP address to multiple servers across the globe and relies on BGP routing to deliver traffic to the nearest one. Unicast assigns each server a unique IP address and uses DNS or application-layer logic to steer users. The choice between them shapes every aspect of a CDN architecture: latency, failover speed, DDoS resilience, and operational complexity.

How Does Unicast Routing Work in Traditional CDN Deployments?

In a unicast CDN, every edge server or Point of Presence has its own unique IP address. A user in Tokyo and a user in London both type the same domain name, but the CDN DNS resolver returns different IP addresses to each based on their location. The routing decision happens at the DNS layer, making the DNS resolver the traffic director for the entire network.

The process works as follows:

1. The user DNS request arrives at the CDN authoritative DNS server.
2. The DNS server identifies the user approximate location using the EDNS Client Subnet (ECS) extension or the resolver IP address.
3. Based on location, server health, and current load, the DNS server returns the IP address of the optimal edge server.
4. The user connects directly to that specific server using its unique IP address.
5. If the server goes down, the DNS server must detect the failure and update its responses to point users elsewhere.

This approach gives operators fine-grained control. They can route specific users to specific servers, implement weighted traffic distribution, pin certain regions to certain PoPs for data sovereignty compliance, and gradually shift traffic during deployments. However, it comes with a critical limitation: failover speed is bounded by DNS TTL values.

How Does Anycast Routing Work for CDN Networks?

Anycast fundamentally changes where the routing decision is made. Instead of the CDN DNS resolver choosing a server, the internet routing infrastructure itself makes the decision at the BGP (Border Gateway Protocol) level.

In an anycast CDN, every PoP announces the same IP address prefix to its upstream network peers. When a user sends a packet to that IP address, it travels through the internet following the shortest BGP path, which is determined by AS path length, local preference, and other BGP attributes. The packet arrives at whichever PoP is topologically closest to the user, without any application-layer involvement.

BGP Path Selection in Practice

When multiple locations announce the same prefix, routers along the path choose based on the standard BGP decision process:

• Shortest AS path — Fewer autonomous system hops generally means closer proximity
• Local preference — ISPs may prefer certain paths based on peering agreements
• Multi-exit discriminator (MED) — Used when multiple peering points exist between the same two networks
• IGP metric — Internal routing cost within an autonomous system

The result is that each user naturally gravitates toward the nearest PoP without the CDN needing to know where users are or maintain geolocation databases. The network handles it automatically through content routing mechanisms that have been refined over decades of internet operation.

What Are the Key Differences Between Anycast and Unicast?

The distinction between these routing strategies has practical consequences across every dimension of CDN operation:

How Does Failover Differ Between the Two Approaches?

Failover behavior is where the practical difference between anycast and unicast becomes most visible to end users.

Anycast Failover

When an anycast PoP goes offline, it stops announcing its BGP routes. Upstream routers detect the withdrawal and remove the path from their routing tables. Traffic automatically flows to the next nearest PoP that is still announcing the same prefix. The entire process takes 5-15 seconds for most of the internet to converge, though some paths may update faster. No DNS changes are needed, no TTLs need to expire, and no client-side retry logic is required.

The limitation is granularity. BGP does not distinguish between a server that is crashed and one that is merely overloaded. Anycast failover is all-or-nothing at the PoP level: either the routes are announced or they are not. Health-based load balancing within a PoP requires additional layers. Health check integration with BGP announcement logic adds this capability but increases operational complexity.

Unicast Failover

When a unicast PoP goes offline, the CDN DNS system must detect the failure through health checks (typically every 10-30 seconds), update its resolution logic to exclude the failed PoP, and wait for existing DNS cache entries to expire based on TTL. With a 60-second DNS TTL, failover takes at minimum the health check interval plus the TTL duration: potentially 90-120 seconds. Lower TTLs improve failover speed but increase DNS query volume and add latency to initial connections.

Why Is Anycast Superior for DDoS Protection?

Anycast is the dominant choice for DDoS mitigation because of a fundamental property: attack traffic is automatically distributed across every PoP in the network. An attacker targeting an anycast IP address with a 500 Gbps volumetric attack does not overwhelm a single location. Instead, the attack traffic spreads across all announcing PoPs proportionally to their BGP proximity to the attack sources. If the CDN has 300 PoPs, each PoP absorbs roughly 1.5-2 Gbps, which is easily handled by any modern PoP.

With unicast, a DDoS attack targets the specific IP address returned by DNS for the victim domain. All attack traffic concentrates on one PoP or a small group of PoPs, requiring those locations to absorb the full attack volume. While CDN operators can mitigate by changing DNS responses to distribute attack traffic, this introduces the DNS TTL delay, giving attackers a window of concentrated impact.

Does Anycast Work Reliably with TCP Connections?

A common concern with anycast is TCP connection stability. TCP is a stateful protocol: a connection is established with a specific server, and if BGP routing changes cause subsequent packets to arrive at a different server, the connection breaks because the new server has no knowledge of the existing TCP state.

In practice, this is rarely a problem for HTTP workloads. BGP routes change infrequently during normal operation, most HTTP transactions complete within seconds, and modern HTTP clients automatically retry failed connections transparently. The scenarios where anycast TCP disruption matters are:

• Long-lived connections — WebSocket connections lasting minutes or hours are more exposed to BGP route changes. CDN operators mitigate this with BGP dampening and route stabilization.
• BGP maintenance windows — Planned PoP maintenance that withdraws routes causes a brief disruption for active connections. Graceful connection draining (stopping new connections while existing ones complete) minimizes impact.
• Network instability — BGP route flapping can cause repeated connection drops. This is addressed through route dampening and minimum hold times.

For HTTP/3 over QUIC, anycast is even more natural. QUIC includes connection migration as a core feature: if a packet arrives at a different server, the connection ID allows the new server to identify and resume the session (when servers share state) or the client to seamlessly reconnect.

Which CDN Providers Use Anycast vs Unicast?

The industry trend has shifted strongly toward anycast, but many providers use hybrid approaches:

The hybrid approach is worth noting. Akamai and CloudFront use DNS-based routing for content delivery because it provides load-aware traffic distribution and precise geographic control, while using anycast for their authoritative DNS infrastructure where fast failover and DDoS resilience are paramount. This gives them the granularity benefits of unicast for content and the resilience benefits of anycast for DNS.

How Do You Choose Between Anycast and Unicast?

For most organizations evaluating CDN providers, the choice between anycast and unicast is made implicitly by choosing a provider. However, if you are building your own CDN or evaluating providers for specific requirements, here are the decision factors:

Choose anycast-primary when:

• DDoS protection is a critical requirement
• Fast failover (sub-15-second) is essential for your SLA
• Your workload is primarily short-lived HTTP requests
• Simplicity of operation is valued over routing precision

Choose unicast/DNS-primary when:

• You need fine-grained control over which PoP serves which users
• Data sovereignty requires pinning specific regions to specific locations
• Your workload includes long-lived connections (WebSockets, streaming)
• You need load-aware routing that considers real-time server utilization

The modern trend is clear: anycast has become the default for new CDN architectures, with application-layer intelligence layered on top for cases requiring finer control. Understanding both approaches and their tradeoffs is essential for evaluating how a CDN will perform under normal conditions and, more importantly, under stress. The routing strategy also directly influences your network topology decisions and geographic routing strategy.