Anycast is not a latency cure

2 August 2026 · 7 min read

Anycast means announcing the same IP prefix from several locations and letting BGP pick the nearest one. It is a genuinely elegant idea, and it is sold as a latency product. It is not one. It is a routing product, and latency is a side effect that usually goes the right way.

What it actually buys you

Three things, in order of how reliable they are:

• Failure isolation. If one site withdraws the prefix, BGP reconverges and traffic moves. This is the real win and it works without any application changes.
• DDoS absorption. Attack traffic gets split across every site that announces the prefix. In practice this means each site sees a fraction of the flood, and the closer the attacker is to a site, the more that site eats.
• Latency. Usually better, sometimes worse, occasionally much worse.

The part that goes wrong

BGP picks a route by AS-path length, then by a long list of tiebreakers that have nothing to do with distance. The result is that "nearest" is a statement about routing policy, not geography. A city with a well-connected transit provider can be reached through a city two thousand kilometres away, and you will never see it in a traceroute because the path looks short.

I have seen a prefix announced from Frankfurt and Singapore where users in Dubai consistently landed in Singapore — a longer physical path, a shorter AS path. The latency penalty was around 90 ms, and it was invisible in every dashboard we had, because each site reported healthy.

Anycast optimises for BGP's opinion of distance. That opinion is formed by contracts, not by fibre.

Connection stickiness

The other thing that bites is that routing changes break established flows. If BGP reconverges mid-transfer, packets start arriving at a different site that has no state for that connection, and the connection dies. TCP will retransmit into a black hole until it times out.

For HTTP this is mostly invisible — browsers retry, users see a spinner. For long-lived connections it is not. This is why every serious anycast deployment either keeps state synchronised between sites or terminates connections at the edge and speaks a stateful protocol internally.

Workload	Anycast suitability
DNS resolvers	Excellent — single packet, stateless
HTTPS with short requests	Good — retries hide reconvergence
Video streaming	Workable with session resumption
Long-lived TCP sessions	Poor — reconvergence kills flows
Stateful databases	No

How to check whether it is working

Do not trust the vendor map. Measure from the outside, from places you do not control:

for r in fra sin dub; do
  echo "== $r"
  curl -s -o /dev/null -w '%{time_connect} %{time_total}\n' \
    --resolve example.com:443:203.0.113.10 \
    https://example.com/health
done

Then compare against the same measurement over unicast. If anycast is not clearly better on p50 and no worse on p99, it is not doing the job you bought it for — and you are carrying the reconvergence risk for free.

The honest summary

Anycast is worth deploying for resilience and DDoS reasons. If latency is your only motivation, a single well-placed node plus a CDN will usually beat a poorly-tuned anycast mesh, and it will be far easier to reason about at three in the morning.