What is BGP anycast and why CDNs (Cloudflare, Akamai) use it to make your data center faster
Why your website feels the same from Monterrey as from Madrid
Every time a user in Guadalajara opens Netflix, Cloudflare, Spotify or Mercado Libre, their device asks an apparently simple question: which server do I connect to? The answer, in milliseconds, comes from a routing decision the user never sees: the topologically closest server. The technique that makes that decision possible is called BGP anycast, and it is the reason a data center in Querétaro can feel fast to a user in Tokyo without having a mirror there.
What anycast is and why it matters
On a conventional network, an IP address lives in one place. If a user sends a packet to 1.2.3.4, the routers on the Internet take it, by different paths, to the same destination. That is called unicast. Anycast breaks that rule: the same IP address is announced from multiple physical locations, and the routers along the path choose, for each packet, the topologically closest announcement. The user does not know — nor need to know — which instance served the request.
Anycast routing depends on the BGP protocol, Border Gateway Protocol, which is the inter-autonomous-system routing system of the Internet. Each IP prefix — for example 1.1.1.0/24 — is announced from one or more autonomous systems (AS). When an AS announces the same prefix from two different sites, neighbor routers see two paths to the same destination and choose the one with lower cost. The dominant criterion is AS-path length: the path with the fewest inter-AS hops wins [Source: semicolony.dev, Anycast simulator, 2026].
The result, from the user’s point of view, is transparent. You type 1.1.1.1 in your DNS client and end up at the Cloudflare Point of Presence (PoP) closest to your network — usually the same continent, often the same city. Cloudflare’s internal measurement reports median resolution latency below 15 ms globally [Source: semicolony.dev, citing Cloudflare disclosure].
How CDNs use it: the Cloudflare, Akamai and Fastly case
A Content Delivery Network — CDN — exists to bring content closer to the user. Before anycast, CDNs used GeoDNS: the authoritative DNS server returned a different IP based on the country or region of the client. The method worked, but with three structural problems:
1. The routing decision was made at the DNS resolver, not at the network. A Spanish user behind a corporate resolver in Texas was sent to the Texas PoP, not the Madrid one. Geolocation by resolver IP is approximate, not exact, and many users end up routed to a suboptimal PoP.
2. Failover depended on the DNS TTL. If a PoP went down, users kept pointing to the old IP during the TTL — 60 to 300 seconds in most configurations. Five minutes of degraded service.
3. Managing many different IPs for many PoPs added operational complexity and opened attack vectors.
Cloudflare, Fastly and Google Cloud CDN adopted anycast from the start or migrated to it. Cloudflare operates the largest individual footprint: more than 330 cities in more than 125 countries, all announcing the same 1.1.1.0/24 block from AS 13335 [Source: hld.handbook.academy, CDNs curriculum, 2026]. Akamai operates a different model for historical reasons — it was born as a network of appliances embedded within ISPs — but it also uses anycast for its edges; its combined footprint exceeds 4,200 nodes [Source: crosscheck.cloud, How CDNs work, 2026].
The result for the user: a packet leaving a laptop in São Paulo toward any-cdn.com reaches the Cloudflare or Fastly PoP in São Paulo — probably less than 20 ms RTT. The latency of a transcontinental round-trip, which easily exceeds 100 ms, drops to a fraction. Without the user changing anything. Without the site developer changing anything.
The result for the data center operator: any PoP can handle the request, and if one fails, BGP withdraws it from routing in seconds. Cloudflare’s internal convergence using BGP add-path and BFD is sub-second; convergence between external ASes is in the 5-30 second range depending on the aggressiveness of peer timers [Source: semicolony.dev, Anycast simulator, 2026].
How root DNS servers exploit it — the most extreme version
The 13 root DNS servers — the machines that serve the top of the . hierarchy — are each an anycast cloud of tens to hundreds of physical servers distributed globally. The 13 IP addresses (a.root-servers.net through m.root-servers.net) are anycast announcements. Root K, for example, operates dozens of instances on every continent, and publishes coverage that exceeds 200 points of presence [Source: hld.handbook.academy, 2026].
The root system handles a few hundred billion queries per day [Source: hld.handbook, citing ICANN RSSAC and root server operator disclosures]. Without anycast, that would mean 13 datacenters receiving the entire load of the planet — and melting. With anycast, the load is spread by topology: a query from Berlin lands at the European PoP; a query from Buenos Aires lands at the South American PoP.
Public resolvers — Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9 — are also anycast clouds. The infrastructure is conceptually identical: one IP address announced from N sites, BGP routing choosing the closest. Each one serves hundreds of millions of queries per second collectively.
Why a BGP anycast is not the same as having a CDN
A point that confuses: anycast gets you to the topologically closest PoP; the CDN decides what to do when you get there. The difference matters because any IP can be anycast, but not every IP should be anycast.
The operational restrictions are documented in two canonical RFCs:
- RFC 4786 — Operation of Anycast Services (BCP 126, December 2006): all instances must be functionally identical. If two anycast nodes differ — DNS zone version, TLS certificate, cipher list — users see Heisenbug behavior depending on the routing.
- RFC 7094 — Architectural Considerations of IP Anycast (IAB, January 2014): service delivery must be tightly coupled with route advertisement. If the local service goes down, the route is withdrawn; if the service returns, the route is re-announced.
The practical result: stateful protocols over anycast are problematic. A long-duration TCP connection — a websocket open 20 minutes, a sustained gRPC session — can break if the BGP path changes mid-flow. In practice, RFC 7094 §3 measurements and Verisign show that flow-failure rate from BGP flap is less than 1 in 10,000 connection-hours [Source: hivebook.wiki, Anycast one-IP-many-servers, 2026]. But the defense is architectural: treat anycast as best-effort and reconnect clean, or terminate TLS at the anycast edge and use a unicast backend for long sessions. Most CDNs do the latter.
DDoS absorption: the use case that justifies the investment
The largest DDoS attack publicly recorded to date — 3.8 Tbps, mitigated by Cloudflare in 2024 — was absorbable precisely because the attacked address was announced from hundreds of PoPs [Source: labhub.hopto.org, CDN Edge Computing Deep Dive, 2026]. Each PoP received a fraction of the attack proportional to its BGP announcement. Without anycast, the 3.8 Tbps would have hit a single origin.
The mechanism is mathematically simple. A 10 Gbps attack from a botnet, distributed across 20 PoPs by anycast routing, leaves 500 Mbps per PoP. Each PoP has local scrubbing capacity; no individual PoP gets overwhelmed. If a PoP overloads, BGP withdraws its announcement and the traffic is redistributed to the next closest in seconds.
That is why the major CDNs operate their own ASNs and their own portable IP prefixes. Cloudflare is AS13335; Akamai operates multiple ASes for historical reasons; Fastly, AWS (CloudFront) and Google Cloud CDN operate their own. Owning the ASN and the IP block is not a technical luxury — it is the prerequisite for doing anycast at scale.
What this means for your data center
A corporate data center in Monterrey, Querétaro or CDMX does not need to operate its own anycast to serve globally distributed users. What it needs is to know how to contract it:
1. To serve global users from a single region, you need a CDN with anycast (Cloudflare, Fastly, Akamai, CloudFront). Every peso you put into multi-region proprietary infrastructure without a CDN is money lost — the CDN’s PoP is already 20 ms from the user.
2. To make your DNS fast and resistant to DDoS, use anycast resolvers (1.1.1.1, 8.8.8.8, 9.9.9.9) instead of an authoritative DNS of your own hosted in a single region.
3. If your service is multi-region and stateful — databases with replication, long sessions, websockets — design knowing that the edge can be anycast but the state lives behind. The edge does TLS termination; the origin is unicast.
4. To absorb volumetric DDoS, anycast is not optional. An on-premises defense with local scrubbing does not scale against 3 Tbps. You need a network with the advertisement footprint to dilute the attack before it reaches your rack.
The metric that separates a CDN provider from a hosting provider with nice marketing is the ASN and the anycast PoP footprint. If your “edge” provider does not operate its own AS and its own portable IP block, it is not doing anycast. It is doing GeoDNS with a different name — and inherits all the limitations of GeoDNS, including minute-scale failover.
Sources
- RFC 4786 — Operation of Anycast Services (BCP 126), IETF, December 2006
- RFC 7094 — Architectural Considerations of IP Anycast, IAB, January 2014
- Cloudflare — Network and anycast footprint disclosure, published 2026
- Akamai — State of the Internet / CDN footprint disclosure, 2026
- Verisign — The Anycast TCP Saga, TCP stability measurements over anycast
Want to master this?
Noxtel Academy →
