Regional service delivery
Distributing service locations can shorten network paths and reduce round-trip times. Results depend on peering, routing policy and where users connect.
One address.
A distributed
network.
Understand how anycast routes traffic to services around the world—and what that means for performance, availability and resilience.
A practical guide to anycast networkingBGP routing Service distribution Network resilience
The fundamentals
What is anycast?
Anycast makes a single IP address reachable from multiple network locations. The network selects which location receives each user’s traffic.
On the public internet, this selection is typically made through the Border Gateway Protocol (BGP). A service can operate in London, Singapore and Sydney while presenting the same destination address to its users.
One important distinction
The preferred route is determined by network policy. It is not necessarily the shortest geographic path or the location with the lowest latency.
Routing fundamentals
How anycast directs traffic
Internet-scale anycast uses the Border Gateway Protocol (BGP) to make one destination reachable from multiple locations. These four stages explain how routes are advertised, selected and updated.
- 01
Announce a shared prefix
Multiple points of presence advertise the same IP prefix through BGP, making the service reachable from several network locations.
- 02
Select a preferred route
Each network evaluates the available announcements using its routing policy. The selected path reflects network topology and operator preferences.
- 03
Deliver traffic to a PoP
Packets follow the selected route to a point of presence. Users in different regions can reach different locations through the same destination address.
- 04
Adapt to route changes
When a location withdraws its announcement, routing converges on an alternative path. Recovery time depends on detection, policy and network conditions.
Interactive demonstration
One address. Watch the route change.
Follow a request through the network. See how locations announce the same address, how a preferred route is selected, and what changes when that route is withdrawn.
Destination address
203.0.113.10UNCHANGEDAnnouncements · service → network
Route announcement Request Withdrawal
These example policies belong to the client’s ISP. Local preference 200 wins over 100 even when the AS path is longer. BGP learns these routes independently of individual requests.
# Manchester ISP · illustrative routing state Destination: 203.0.113.10 Announced prefix: 203.0.113.0/24 LHR LOCAL_PREF 200 AS_PATH 64497 64498 64500 AMS LOCAL_PREF 100 AS_PATH 64499 64500 JFK LOCAL_PREF 80 AS_PATH 64501 64502 64500 [BGP] Learning route announcements.
A simplified topology with fictional routing policy and documentation addresses. Timing is illustrative; real convergence varies. The drawing does not show geographic distance or the return path. BGP decision process ↗
Architectural benefits
Distributed reach. Consistent access.
Anycast supports globally distributed services through regional delivery, alternative routing paths and a consistent destination address.
Improved service resilience
When a location withdraws its route, BGP can steer traffic toward another available PoP. Recovery depends on convergence and spare capacity.
Consistent service addressing
Additional locations can advertise the existing service prefix. Once their routes are accepted, they can serve traffic without changing the destination address used by clients.
Within a point of presence
One location. Multiple service instances.
Anycast selects a point of presence (PoP), which may contain multiple servers. Within that location, equal-cost multi-path routing (ECMP) can distribute flows across service instances. Flow-based hashing keeps packets from the same connection on a consistent path while the forwarding configuration remains stable.
8/8 servers live
one IP 203.0.113.10 · many servers
Select a server to change its availability. This ECMP model reassigns flows across the available servers and keeps at least one online. In production, changing the server pool can disrupt existing connections; graceful draining needs additional support.
203.0.113.10 is reserved for documentation. Internet deployments advertise an accepted IP prefix, not a globally routed individual /32.
Architecture comparison
Unicast and anycast, compared.
Both approaches deliver packets to an IP address. The distinction is how many network locations advertise that destination.
| Characteristic | Unicast | Anycast |
|---|---|---|
| IP announcement | One location announces the destination. | Many locations announce the same destination. |
| Routing | Traffic travels to the same network location. | BGP selects a preferred available location. |
| Latency | Depends on the path to that one location. | Often lower when traffic can stay regional. |
| When a location fails | Recovery needs a separate failover mechanism. | Traffic can reroute after the route is withdrawn. |
| Traffic distribution | Traffic converges on one location. | Traffic can be distributed across multiple PoPs. |
Operational considerations
Design for the service, as well as the network.
A successful deployment aligns routing behaviour with application requirements. Consider connection state, health monitoring and capacity alongside the benefits of distribution.
Suitable applications
Independent request–response services
Services such as DNS over UDP can answer individual requests without maintaining a persistent connection, reducing the impact of a change in service location.
Resilient web delivery
HTTP and HTTPS services can use anycast when their design accounts for connection state, route changes and appropriate retry behaviour.
Distributed traffic mitigation
Routing can distribute attack traffic across several locations. Effective protection also requires sufficient capacity, traffic filtering and operational coordination.
Route-based service failover
Health monitoring can trigger the withdrawal of an unavailable location's route, allowing networks to select an alternative announcement.
Planning requirements
Connection continuity
A route change may send an established flow to a location without the required session state. Long-lived connections need suitable recovery or state-management strategies.
Routing-policy constraints
BGP considers attributes such as local preference and AS-path length. Geographic proximity, current congestion and measured latency do not directly determine the selected route.
Service health and monitoring
A location that continues advertising while its service is unavailable may still attract traffic. Route withdrawal should reflect application health as well as network reachability.
Capacity and route security
Remaining locations need capacity to handle redistributed traffic. Prefix filtering and route-origin validation help protect announcements; service security remains a separate requirement.
Real-world applications
Supporting essential internet services
Anycast is used across DNS, content delivery and network protection. These examples illustrate how the same routing principle supports different service requirements.
Cloudflare — 1.1.1.1
A public DNS resolver that uses distributed infrastructure to make a consistent service address available across its network.
DNS root servers
The root server system distributes service instances across many locations. Anycast helps make root DNS infrastructure broadly reachable.
Google Public DNS — 8.8.8.8
Google Public DNS uses anycast to route queries to its resolver infrastructure through a consistent set of public IP addresses.
DDoS mitigation
Distributed ingress locations can share the traffic directed at a service. Combined with filtering and sufficient capacity, this supports DDoS mitigation.
FAQ
Frequently asked questions
Clear explanations of the concepts, applications and limitations of anycast.
What is anycast?
Anycast makes a service address available from multiple network locations. Traffic is delivered to one of those locations according to the routing system. On the public internet, BGP typically determines which route a network prefers.
How does anycast work?
Participating locations advertise the same IP prefix. Networks select among those announcements using their routing policies, then forward packets along the selected path. When an announcement is withdrawn, traffic can move to another available location after routing converges.
What is the difference between anycast and unicast?
A unicast destination is associated with one network location, which may contain several servers. An anycast destination is advertised from multiple locations. The distinction concerns network reachability rather than the number of servers behind the address.
What is anycast used for?
Common applications include authoritative DNS, public DNS resolvers, content delivery networks and distributed DDoS mitigation. Suitability depends on the service's connection behaviour, state requirements and operational design.
Is anycast suitable for TCP and HTTPS?
Yes, provided the service accounts for route changes and connection state. A stable route can keep a connection at the same location. If routing changes during a session, packets may reach a server without that session's state, requiring reconnection or additional application support.
How does ECMP relate to anycast?
Anycast can select the service location; ECMP can distribute traffic across equal-cost paths within that location. Many implementations hash packet-header fields to keep a flow on one path. Changes to the available paths can alter that assignment.
Does anycast always select the geographically nearest location?
No. BGP selects routes according to network policy and path attributes, not geographic distance or measured response time. A nearby location may be preferred, but the shortest physical distance does not guarantee the selected route or the lowest latency.
Sources & further reading
Technical references and further reading
Explore the operational guidance, architectural considerations and provider documentation behind the concepts presented in this guide.
- IETF · RFC 4786
Operation of Anycast Services
Best-current-practice guidance for the design, deployment and operation of anycast services.
- IETF · RFC 7094
Architectural Considerations of IP Anycast
Architectural guidance covering routing behaviour, transport protocols and service continuity.
- Cloudflare Learning Center
Anycast networking overview
An introduction to anycast routing and its role in distributed content delivery.
- Google for Developers
Google Public DNS documentation
Provider documentation on public DNS architecture, anycast routing and service behaviour.
- Root Server Operators
Root server system
Information about root DNS server operators and the distribution of service instances.
- Cloudflare
Cloudflare network
Provider information about network reach and distributed service infrastructure.