Anycast

Anycast is a network addressing and routing method. One IP address, the service address, is advertised from many separate locations at once. The routing system delivers each packet to whichever location it computes as closest. The formal definition is “the practice of making a particular Service Address available in multiple, discrete, autonomous locations, such that datagrams sent are routed to one of several available locations” (RFC 4786 §2, published as BCP 126, “Operation of Anycast Services”).

It is not DNS-based server selection such as Geo DNS. It is not one address parked in front of a load balancer either. For an anycast service there is “no inherent requirement for referrals to other servers or name-based service distribution”: BGP itself chooses the node. There is no second lookup and no hostname rewrite (RFC 4786 §3.1). Nor is an anycast address a special kind of address. Anycast addresses are “syntactically indistinguishable from unicast addresses”, so you cannot identify one by looking at it (RFC 7094 §1).

The trade in one line: you give up per-client control over which site serves a request. In return, one address covers a global fleet, failover needs no DNS change, and flood traffic is divided among sites by the network rather than by you. Anycast is also called IP anycast. In DNS work it appeared historically as a “shared unicast address” (RFC 3258; see RFC 7094 §2.1).

How it works

The service is associated with a stable set of IP addresses. Reachability to those addresses is advertised from two or more independent anycast nodes. To the routing system each node “presents a unique path to the Service Address”, so the whole fleet simply looks like several routes to one prefix (RFC 4786 §1–§2). From there ordinary routing does the work.

• Every edge server or router in every point of presence announces the same address, so a user in Tokyo and a user in Amsterdam use that one IP. They are still served by different physical machines.
• Each network along the path applies its own route selection to the candidate paths. Delivery is best effort “to the ‘closest’ instance as determined by unicast routing topology metric(s)” (RFC 7094 §1). Cloudflare describes its own case as routers sending the packet “down the one with the fewest stops along the way (i.e., ‘hops’)” (Cloudflare, 2013).
• The decision is made by every intervening network, not by you. The region of the network whose packets land on one particular node is that node’s catchment. That catchment shifts as other people’s routing changes.
• Several equal-cost routes to the anycast prefix may exist. When they do, routers may additionally apply ECMP-style per-packet or per-microflow load balancing across them (RFC 7094 §1).
• A node may stop advertising the route. Common causes are maintenance, a failed site, or a failing health check. When that happens, routers re-converge and “packets will find their way to the next shortest available route”. No DNS record changes (Cloudflare, 2013).
• Nodes are scoped. A global node’s advertisement is potentially visible to the whole routing system. A local node’s advertisement is deliberately propagated so that only a subset of the routing system can see it. This is how operators keep a small site serving only its own region (RFC 4786 §2).

Anycast applies to services reachable over both IPv4 and IPv6. What CDNs run is off-link anycast. It “takes advantage of routing protocol preferences and the IP hop-by-hop destination-based forwarding paradigm” and works for both address families. IPv6 additionally standardises on-link anycast inside Neighbor Discovery. IPv4 has no standardised equivalent (RFC 7094 §1).

Why it matters for a CDN

One address can front the whole fleet. An operator points a hostname at an anycast address, and the routing system does the placement, so there are no per-region records to maintain and a site can be drained by withdrawing a route. BCP 126 lists the objectives an operator is actually buying (RFC 4786 §3.2):

• Scale through coarse load spreading. “Coarse (‘unbalanced’) distribution of load across nodes, to allow infrastructure to scale to increased numbers of queries and to accommodate transient query peaks”. Note the word unbalanced. This is capacity spreading, not load balancing.
• Damage containment. Anycast localises a non-distributed denial-of-service attack to single nodes. It also constrains a distributed denial-of-service attack or flash crowd “to local regions around Anycast Nodes”, with “traffic to be handled closer to its source, perhaps using high-performance peering links rather than oversubscribed, paid transit circuits”. RFC 7094 puts it as “mitigate or at least localize the effects” (RFC 7094 §4.4). That means localisation, not unlimited absorption.
• Attack attribution. Node selection relates to the topological source of a request. So the node that received spoofed-source traffic is itself evidence about where that traffic entered.
• Shorter network leg, with a caveat. “Improvement of query response time, by reducing the network distance between client and server with the provision of a local Anycast Node”. But the same paragraph immediately qualifies it: how much you gain “depends on the way that nodes are selected for the clients by the routing system”. See latency and the first item under Watch out for.
• Collapsing a server list into one address. A large set of authoritative nameservers can be deployed behind a small set of anycast addresses. This increases reach “without increasing the size of a referral response”.

Resilience is the other half. A partition can happen: a transoceanic fibre cut, a natural disaster. Each surviving node then serves its own catchment (RFC 7094 §4.4). Cloudflare reports that with its anycast WAN it “can lose an entire data center and packets flow to the next closest facility” (Cloudflare, 2013). This is why anycast underpins public DNS. By late 2007, “at least 10 of the 13 root name servers were already using IP anycast” (RFC 7094 §1). Today those 13 addresses are served by 2,004 operational instances run by 12 operators (root-servers.org, 19 August 2026).

It can also measurably win. A 2025 measurement study of content delivery over Starlink found the anycast CDN “consistently achieves the lowest latencies ≈ 18 ms lower than Akamai and ≈ 6 ms lower than CloudFront on average”, with gaps above 100 ms where a client’s resolver was mislocated. This is a result for Starlink clients specifically, not a general CDN ranking (Bose et al., arXiv:2510.13710).

What CDNs do

• Cloudflare runs anycast as the default at the WAN. Cloudflare says “every router in all of CloudFlare’s … data centers announces all of our external-facing IP addresses”. TCP over anycast took “a significant amount of engineering … to allow TCP to run across Anycast without flapping” (Cloudflare, 2013). Inside a data centre, the mechanism has since changed. Cloudflare “relied on ECMP alone to spread load across servers before we deployed Unimog”, its layer 4 load balancer. Unimog “makes every server into a load balancer” rather than a dedicated appliance tier (Cloudflare, Unimog).
• Fastly offers anycast as an option, not the default. “If an anycast A or AAAA record is configured, then the client will receive the anycast IP, which is advertised by multiple Fastly POPs. Standard internet routing will take the user to a nearby POP.” It is mandatory where a CNAME cannot be used: “Anycast is required for apex domains (e.g., example.com) because they do not support CNAMEs in DNS.” Fastly also states the cost of choosing it. With anycast IPs, “connections select a Fastly POP based on routing decisions made outside of Fastly and over which Fastly has less ability to direct traffic for best performance”. A CNAME, by contrast, lets Fastly resolve to the POP its own measurement data says performs best (Fastly docs).
• Akamai uses anycast at the DNS layer rather than for delivery. “Edge DNS relies on IP Anycast technology … organizations can create a logical name server that comprises multiple physical name servers deployed across multiple networks and continents” (Akamai TechDocs). Its content delivery, by contrast, is mapped by DNS-based request redirection (arXiv:2510.13710).
• AWS CloudFront selects an edge location through DNS by default. It “routes traffic based on the distribution’s price class, associated geolocation databases, and EDNS0-Client-Subnet support” (AWS re:Post). Anycast static IPs are an opt-in feature reviewed by CloudFront support before you can allocate a list. AWS says: “if you want to enable routing of apex domains (such as example.com) directly to your CloudFront distributions, you can request 3 Anycast static IP addresses for this use case”. A distribution using such a list must also use the “Use all edge locations” price class (AWS docs).

Watch out for

• “Nearest” is a routing-topology choice, not a latency promise. “Topological nearness within the routing system does not, in general, correlate to round-trip performance across a network; in some cases, response times may see no reduction, and may increase” (RFC 4786 §3.2). Measure per region. Never quote a global latency figure as a property of anycast.
• Transaction time must fit inside routing stability. Because “it is usually a requirement that a single client-server interaction is carried out between a client and the same server node for the duration of the transaction … the routing system’s node selection decision ought to be stable for substantially longer than the expected transaction time”. Single-packet exchanges such as “DNS transactions over UDP transport” fit trivially. Bulk downloads and media streaming do not, and “especially for long running flows, there are potential failure modes using anycast that are more complex than a simple ‘destination unreachable’ failure using unicast” (RFC 4786 §4.1). BCP 126 deliberately does not rule any protocol in or out.
• A mid-flight reroute breaks TCP. Packets “may be delivered to a different anycast instance if (for example) a route has changed. In such a case, the TCP connection will likely elicit a connection reset but will certainly result in the disruption of the connection” (RFC 7094 §4.2).
• Do not withdraw the route to dodge a flood. “Care must be taken not to simply withdraw an anycast route in the presence of a sustained DoS attack, since the result would simply move the attack to another service instance, potentially causing a cascaded failure” (RFC 7094 §4.4).
• The prefix can be stolen. “Adding an anycasted node to the routing system can prevent a previous recipient from continuing to receive traffic because it may now be delivered to the new node instead”. So an unauthorised advertisement of your prefix diverts your traffic. It can even sinkhole that traffic (RFC 7094 §4.4).
• Monitoring and load are position-dependent. “The observed availability changes according to the location of the client within the network, and the population of clients using individual anycast nodes is neither static, nor reliably deterministic” (RFC 4786 §1). Also, “load-balancing between Anycast Nodes is typically difficult to achieve” (RFC 4786 §3.1).
• Flap dampening can suppress a healthy node. “A dampened path will be suppressed by routers for an interval that increases according to the frequency of the observed oscillation; a suppressed path will not propagate”. Where implementations dampen on AS_PATH rather than prefix, “individual nodes’ instability may result in stable nodes becoming unavailable” (RFC 4786 §4.4.4).
• Stateful middleboxes and the anycast-to-unicast handoff. A service may move a client from an anycast source address to a unicast one. That move “may require new or additional session state, and this may not exist in the middlebox” such as a NAT or stateful firewall (RFC 7094 §4.3).
• Other people’s networks move without telling you. Reachability “is dependent on routing policies and topology changes (planned and unplanned), which are unpredictable and sometimes difficult to identify” (RFC 4786 §4.4.7).

Best practice

• Compare the routing system’s stability against the service’s transaction time before choosing anycast. Where transactions are long, consider splitting them: “an initialisation phase that is handled by anycast servers, and a sustained phase that is provided by non-anycast servers, perhaps chosen during the initialisation phase” (RFC 4786 §4.1).
• Advertise a covering route short enough to survive other networks’ filters: “a sufficiently short prefix that it will not be discarded by commonly-deployed import policies. For IPv4 Service Addresses, this is often a 24-bit prefix” (RFC 4786 §4.4.2).
• Drive the advertisement from health. A broken node then stops attracting traffic, while healthy nodes keep theirs: “availability of the service triggers the route advertisement, and non-availability of the service triggers a route withdrawal” (RFC 4786 §4.4.1).
• Damp your own oscillation before the Internet damps it for you: “nodes should be configured such that rapid oscillations are avoided (e.g., by implementing a minimum delay following a withdrawal before the service can be re-advertised)” (RFC 4786 §4.4.1).
• Keep the paths distinct: “arrange that the AS_PATH attributes on routes from different nodes are as diverse as possible”. BCP 126 achieves this by having nodes “use the same origin AS for their advertisements, but … different upstream ASes” (RFC 4786 §4.4.4). Be aware this conflicts with later advice for globally anycasted critical infrastructure. There, per-node unique origin AS numbers are recommended as routing-system discriminators. They also carry an RPKI benefit: “without per-node unique origin ASNs, the cryptographic certificates needed to attest to the Route Origin Authorizations (ROAs) of a multi-administrative deployment of anycast would need to be shared” (RFC 7094 §4.4, citing RFC 6382). Pick deliberately. Do not assume one answer fits both cases. Either way, publish ROAs for the prefix so a hijack of it is invalid by origin.
• Over-provision each node and watch from everywhere: “individual nodes’ internal and external/connecting infrastructure should be scaled to support loads far in excess of the average, and the service should be monitored proactively from many points in order to avoid unpleasant surprises” (RFC 4786 §4.4.7).