Why architecture matters here

The architectural pull of anycast is what it deletes. A unicast global service needs a traffic-direction tier: geo-DNS (with its cache-granularity blur — resolvers, not users, get located, and TTLs pin decisions for minutes), or a global LB layer (an extra hop, itself needing to be global). Anycast removes the tier: the client sends packets to one address, and path selection at every router en route makes the placement decision packet by packet, at line rate, with zero added latency and no infrastructure of yours in the decision path. Failover inherits the same magic: when a PoP withdraws, the internet reroutes to the next-nearest announcement in seconds-to-minutes of BGP convergence, with no DNS TTL waiting and no client retry logic required.

DDoS behavior alone justifies the architecture for many operators. A unicast target concentrates every attacking bot's traffic onto one ingress; the same attack against an anycast prefix shatters across the entire edge — each PoP sees only the attack share whose sources are topologically near it, so a terabit-scale global attack becomes tens of gigabits per site: absorbable, filterable, survivable. This is why DNS infrastructure — the internet's most attacked layer — went anycast first, and why scrubbing providers anycast their ingest.

The discipline anycast demands is accepting what you don't control. BGP picks paths by AS-path length and local policy — a user in Mumbai can land in Singapore because their ISP's transit relationships say so; a peering change by a network you've never heard of shifts a million users between your PoPs overnight. Capacity planning must follow measured catchments, not geography; steering tools are coarse (prepending moves catchments in lumps, not percentages); and stateful protocols must survive the (rare but real) mid-connection route shift. Anycast rewards operators who treat the internet's routing system as a partner with its own opinions — and punishes those who assume it is a load balancer with an SLA.

Advertisement

The architecture: every piece explained

Top row: the routing machinery. The service owns an anycast prefix (a /24 IPv4 or /48 IPv6 — the minimum globally routable sizes, a real cost of entry) and announces it via BGP from every site — through its own AS at exchanges and transits, or via providers' infrastructure. Internet routing does the rest: each of the ~80k autonomous systems picks its best path per prefix (shortest AS path, tie-broken by local preference, MED, IGP cost), so every client network deterministically maps to one of your sites — its catchment. 'Nearest' is topological, not geographic: hop count in AS-space, shaped by peering economics.

Middle row: inside and between sites. Each edge PoP runs an identical stack (the invariant that makes anycast sane: any site can serve any request), typically with the prefix announced by border routers and spread across servers via ECMP with flow hashing — five-tuple hashing keeps a TCP flow on one server; consistent hashing limits reshuffling when servers join or drain. Health-driven withdrawal is the control plane: service health checks gate the BGP announcement (via BIRD/ExaBGP or routing-stack integration), so a sick PoP drains itself by silence — and the failure mode to engineer away is the zombie: a PoP healthy enough to announce but too sick to serve. Route instability is the standing caveat for stateful protocols: if the internet re-decides a client's catchment mid-TCP-connection, packets arrive at a site with no connection state. In practice, routes are stable for the vast majority of flows and short connections barely care; long-lived flows (large downloads, WebSockets) either accept rare resets, use connection-state sharing within a metro, or hand off to unicast after anycast-assisted connection establishment.

Bottom rows: applications and levers. Use cases sort by state tolerance: DNS/UDP is anycast's home turf (single-packet transactions, perfect fit); CDN edges and TLS front doors run TCP/QUIC anycast at planetary scale successfully (QUIC's connection IDs even survive some migration); long-lived stateful services think harder. Steering: AS-path prepending makes a site less attractive (coarse), BGP communities ask upstreams for regional scoping (no-export to some peers), selective announcement shapes catchments deliberately, and RTBH/Flowspec integrate DDoS response with the same routing machinery. The ops strip is the craft: continuous catchment measurement (RIPE Atlas, embedded beacons), per-PoP capacity vs measured catchment load, and drain/restore rehearsals as routine change practice.

Anycast — one IP, many places: routing as the load balancerBGP decides who serves whomAnycast prefixsame IP announced globallyBGP announcementsmany sites, one prefixInternet routingshortest AS path winsNearest siteper-router choiceEdge PoPsidentical service stacksHealth + withdrawalstop announcing = drainECMP + flow hashingstable within a siteRoute instabilitythe TCP session riskUse casesDNS, CDN edges, DDoS absorptionSteeringprepending, communities, RTBHOps — catchment measurement + per-PoP capacity + drain rehearsalserveannounceselectattractpowerdraintuneoperateoperate
Anycast: identical PoPs announce one prefix; BGP path selection maps each client network to its nearest site; withdrawal is the drain switch.
Advertisement

End-to-end flow

Run a global DNS + API edge on anycast and watch a week's events. The platform: one /24 announced from 28 PoPs; DNS answers and TLS termination at every edge, API requests proxied to three regional origins. Tuesday, normal operations: a user in São Paulo resolves and connects — their ISP's best path lands them at the GRU PoP, 12ms away; a Frankfurt user lands at FRA in 4ms. Catchment dashboards (built from resolver-source sampling and RIPE Atlas probes) show each PoP's share; GRU serves 6% of global traffic — capacity is planned against that measured share, not Brazil's population.

Wednesday: scheduled maintenance at FRA. The drain is one command: health gating withdraws FRA's announcement; BGP convergence moves its catchment to AMS and CDG over ~90 seconds; in-flight TCP connections to FRA complete (the border keeps forwarding established flows briefly during graceful drain); new connections land elsewhere. Users in the FRA catchment see +8ms latency and zero errors. Restore reverses it. The same afternoon, an ISP in Southeast Asia shifts peering; overnight, 2% of global traffic migrates from SIN to HKG — nobody did anything; the capacity headroom policy (every PoP absorbs its largest neighbor's catchment) is why this is a dashboard curiosity rather than a page.

Friday delivers the architecture's showcase: a 900Gbps UDP reflection attack against the prefix. No single site sees more than 55Gbps — the attack's sources are globally distributed, so anycast shreds it across all 28 PoPs, each within its scrubbing capacity; DNS keeps answering everywhere. Two PoPs near botnet concentrations run hot; prepending from one shifts a slice of its catchment to a quieter neighbor. Compare the unicast counterfactual: 900Gbps into one region's ingress — an outage negotiated with upstream scrubbing centers. Saturday's postmortem action item is pure anycast craft: the HKG zombie scare (a partial storage failure that kept announcements up while serving 500s for 4 minutes) becomes a deeper health gate — announcement now requires end-to-end request success, not process liveness — and a quarterly game-day drain of every PoP, because in anycast, the announcement is the SLA.