Evaluated February 2026. Two mechanisms decide which edge serves a request, and they fail on completely different timescales. An anycast CDN hands the decision to BGP, which reconverges in roughly 2–30 seconds after a route withdrawal. DNS routing hands the decision to resolvers, whose caches push practical failover to 30–300 seconds even when the authoritative TTL is 20 seconds. Anycast wins on failover speed and cold-start latency; DNS steering wins on granularity, per-user control, and multi-CDN. Most large 2026 deployments run both: DNS selects the region, anycast selects the machine inside it.
If you are short-listing vendors, the routing model is not a footnote in the architecture diagram. It determines how fast you recover from a bad edge, whether you can drain 20% of a location, and how badly your latency numbers degrade for users behind public resolvers.
An anycast CDN announces the same prefix from many locations. The client never chooses; every transit network and peer between the client and the CDN runs its own best-path selection over local preference, AS path length, MED, and IGP cost. Latency is not an input to that algorithm. It is a frequent side effect, not a guarantee.
That is why anycast produces excellent medians and ugly tails. Hot-potato routing inside a transit provider can hand a subscriber in one metro to an edge two countries away because that is where the provider's cheapest handoff sits. You cannot fix it with a config change; you fix it with peering, prefix deaggregation, or BGP communities that influence upstream selection.
A DNS routing CDN answers a query with a hostname or address chosen by an authoritative server that sees, at best, the recursive resolver's address. EDNS Client Subnet (RFC 7871) improves this by passing a truncated client prefix, commonly an IPv4 /24. Coverage is partial: several major public resolvers send client subnet data, at least one large privacy-focused resolver deliberately does not, and corporate forwarders often strip it.
The control is real. You can weight a region at 5% increments, pin a customer to a specific stack, steer by ASN, or shift traffic between two CDNs on a dashboard. The cost is a resolution chain that adds a measurable first-request penalty on cold cache, typically 20–80 ms across two or three CNAME hops in 2026 measurements, plus a failover floor set by health-check interval, TTL, resolver cache, and client-side caching you do not control.
Six criteria separate the models in an evaluation. Assumptions: global consumer traffic, mixed HTTP/2 and HTTP/3, origin in one region, a compliance requirement that some traffic stays in-region.
| Routing model | Typical failover (2026) | Control granularity | Dominant failure mode |
|---|---|---|---|
| Anycast (BGP) | 2–30 s (route withdrawal plus reconvergence) | Coarse: announce or withdraw | Third-party path policy sends a region to a distant edge; overload concentrates on one site |
| DNS steering with client subnet | 30–120 s | Fine: per subnet, per ASN, weighted | Resolvers that strip or ignore client subnet fall back to resolver geography |
| DNS steering without client subnet | 30–300 s | Fine, but aimed at the wrong target | Users mapped to the resolver's location, not their own |
| Hybrid: DNS to region, anycast inside | 2–30 s intra-region, 30–120 s cross-region | Regional weights plus fast local recovery | Two control planes, two sets of health data, harder root-cause analysis |
| Client-side steering (multi-CDN switcher) | Seconds, per session | Per player or per request | Only works for apps you control; useless for third-party embeds |
The single most important conclusion: anycast recovers roughly an order of magnitude faster than DNS routing, but only DNS routing lets you move a defined fraction of traffic on purpose.
| Vendor | List price per TB (2026, estimate) | Published uptime SLA | Edge routing model |
|---|---|---|---|
| BlazingCDN | $4/TB at 25 TB, $2/TB at 2,000 TB | 100% | Confirm the model per account during evaluation; it is not spelled out in public docs |
| Bunny.net, CDN77, Gcore, Medianova | ~$5–$40/TB, region dependent | 99.9%–100%, tier dependent | Mixed anycast and DNS steering; verify per product |
| Fastly | ~$120/TB list, far lower on commit | 100% (enterprise) | Anycast |
| Amazon CloudFront | ~$85/TB at 10 TB, ~$20–$40/TB at high volume | 99.9% monthly | DNS-based steering by default, optional anycast address ranges since 2024 |
| Cloudflare | Not metered per TB on most plans; enterprise is custom | 100% (enterprise) | Anycast, every address announced from every site |
| Akamai | Contract only | Contract-negotiated | DNS mapping with short TTLs, refreshed from internal path measurements |
The takeaway from the table: pure-anycast vendors give you the fastest recovery with the least steering control, while DNS-mapping vendors give you the opposite, and price per TB varies by more than an order of magnitude across the same routing models.
BlazingCDN. Priced as flat pay-as-you-go tiers rather than per-region rate cards, with a 100% uptime SLA, NVMe SSD edge storage, and roughly one-hour onboarding for a standard HTTP pull configuration. Stability and fault tolerance sit in the same class as Amazon CloudFront while costing substantially less per TB, which matters most to enterprises moving hundreds of terabytes of software builds, game patches, or video. Honest limitation: the routing mechanics are not documented publicly at the level Cloudflare or Fastly publish, so put "describe the edge selection and failover path" in your RFP and validate it in the bake-off below rather than assuming.
Cloudflare. The reference implementation of anycast at scale, with the deepest peering and the most public writing about how it behaves. Limitation: steering granularity is coarse by design, and bandwidth economics are opaque enough that year-three costs are hard to model.
Fastly. Anycast plus a genuinely programmable edge; the best fit when routing decisions need to happen in code after the connection lands. Limitation: list pricing is high, so the economics only work with a committed volume deal.
Amazon CloudFront. DNS-based selection with tight integration into the rest of the AWS control plane, and an optional anycast address range for customers who need stable IPs for allowlisting. Limitation: on-demand list pricing is the most expensive per TB in this set, and the 99.9% monthly SLA is weaker on paper than the 100% SLAs elsewhere.
Akamai. Decades of investment in measurement-driven DNS mapping; still the strongest option when you need per-network steering in places where BGP paths are poor. Limitation: procurement and configuration cycles are long, and nothing is self-serve.
Bunny.net, CDN77, Gcore, Medianova. Cost-competitive alternatives in the same league on price, with capable routing for mainstream web and video workloads. Limitation: routing behavior differs between their products, and published SLA terms vary by tier, so read the specific contract rather than the marketing page.
Assumptions: 2026 published list pricing, North America and Europe delivery, no private discount applied, cache hit ratio irrelevant to egress billing.
BlazingCDN prices egress as flat pay-as-you-go tiers: as of 2026, $350 per month covers up to 100 TB ($3.50 per TB) and $4,000 per month covers up to 2,000 TB ($2.00 per TB), both with a 100% uptime SLA. For comparison, Amazon CloudFront's published on-demand tiers work out to roughly $7,050 for the same 100 TB in North America and Europe before any private pricing agreement.
At 2,000 TB per month the gap narrows in percentage terms because CloudFront's list tiers fall toward $20–$30 per TB, but the absolute monthly difference still runs into five figures. Negotiated enterprise contracts compress this; the routing model you choose does not change the bill, so evaluate routing and price as separate line items. If you want the full per-TB breakdown alongside routing behavior, the CDN comparison of price per TB and edge routing is the faster starting point than assembling six rate cards by hand.
| Workload | Best fit | Why |
|---|---|---|
| API and SaaS, short requests | Anycast CDN | No cold DNS penalty, fastest recovery, sessions are short enough that mid-flight route changes are cheap |
| Live streaming, large audiences | Hybrid or client-side steering | Need to shift measured fractions of viewers between vendors during an event |
| Game patches and software builds | Anycast with cost-optimized vendor | Throughput and price per TB dominate; a 50 ms routing difference is noise on a 4 GB download |
| Data residency requirements | DNS routing | Only DNS steering lets you assert which region answers, since BGP paths are not yours to control |
| WebSocket or long-lived connections | DNS routing, or anycast with reconnect logic | Anycast route changes drop in-flight sessions; the client must reconnect cleanly |
The pattern across the matrix: pick anycast when recovery speed matters more than placement control, and DNS routing when you must be able to say exactly where a given user's traffic went.
Anycast is usually faster on first request because it removes the DNS resolution chain, which costs roughly 20–80 ms on a cold cache in 2026 measurements. Steady-state latency depends on peering quality, not the routing model. A well-peered DNS-mapped network can beat a poorly peered anycast network in any given metro.
Plan for 30–300 seconds end to end. The chain is health-check detection interval, authoritative record change, TTL expiry at the recursive resolver, and finally client or runtime caching that may ignore the TTL entirely. Anycast failover skips all four steps and completes in BGP reconvergence time, typically 2–30 seconds.
EDNS Client Subnet (RFC 7871) narrows the error substantially but does not eliminate it. Coverage is incomplete: some large public resolvers do not send client subnet data on privacy grounds, and enterprise forwarders often strip the option. Traffic from those paths is still mapped by resolver location, which can be hundreds of kilometres from the user.
Yes, but the switching layer has to sit above the anycast layer. You either steer with DNS above two anycast vendors, accepting DNS failover timing, or you select CDN hostnames inside your own application or video player, which gives per-session switching but only for clients you control.
Resolve the hostname from multiple networks, then read the vendor's edge identification response header on an HTTP HEAD request and compare it against the TCP or QUIC handshake round-trip time. Run a traceroute from the same vantage point to see which transit network made the path decision. Repeat during peak hours, when routing and capacity pressure both change.
Two weeks, two vendors, four measurements. First, resolve the test hostname from at least 30 networks across your top five markets and record the answers plus TTLs. Second, measure handshake round-trip time at p50, p95, and p99 per market, not just the average. Third, capture the edge identity header for every request so you can prove which site served it. Fourth, ask each vendor to drain one location during a scheduled window and time the gap from last error to first successful request. Whoever refuses step four has answered the routing question for you.