Multi-CDN, failover and cost optimisation
When a second CDN is worth it, DNS-based and client-based steering, health-checked failover, log unification, and controlling egress and request costs.
When a second CDN pays for itself
| Motivation | Does a second CDN solve it | Cheaper alternative |
|---|---|---|
| A provider outage took the site down | Sometimes | Better origin protection and a documented fallback |
| Latency in one region | Yes | A provider with better coverage there |
| Egress cost | Yes, if rates differ | Cache harder and shrink assets |
| Commercial leverage | Rarely worth the complexity | Nothing - negotiate on volume |
| Compliance requiring two providers | Yes | Nothing else works |
| Load balancing at extreme scale | Yes | Fix the origin first |
A second CDN doubles the operational surface: two configurations, two log formats, two purge APIs and two sets of rules to keep in sync. It is justified when a single provider's failure is unacceptable or when the cost difference is material - not as a general principle.
Steering traffic
| Method | How | Failover speed | Complexity |
|---|---|---|---|
| DNS-based | Answer with different CNAMEs per provider | TTL-bound | Low |
| Weighted DNS | Split by percentage across providers | TTL-bound | Low |
| Client-based | The page picks a provider and requests from it | Immediate | High, and needs client logic |
| Anycast with two backends | One address, provider-side steering | Fast | Provider-specific |
| Full page version | A second hostname served by another provider | Manual | Low, but manual |
DNS steering that actually fails over
primary example.com -> primary CDN CNAME, TTL 60
check synthetic request every 30 s, from several regions
threshold three consecutive failures before switching
switch replace the answer to the secondary CNAME
verify confirm the new answer from two resolvers
switch back only after the primary has been stable for 30 minutes
Remember: a client that resolved just before the switch keeps using the
old answer for the full TTL, so plan for a minute of mixed traffic.- Keep the TTL short on the record that steers, and long on everything else.
- Health-check from outside the provider's network. A check inside the failing provider reports healthy.
- Do not switch automatically on a single failure. A flapping record is worse than a short outage.
- Rehearse the switch on purpose, in business hours, at least twice a year.
Cost control and log unification
- Get the numbers per asset class from each provider's logs: bytes, requests and cache status.
- Compute cost per 1000 requests and cost per GB for the same traffic on each provider. The ranking is rarely what the price list suggests.
- Shift the classes where one provider is clearly cheaper, and leave the rest alone.
- Aggregate logs into one schema. Two formats means two dashboards and no way to compare.
- Set a budget alarm on request count and egress separately. Attacks and misbehaving clients show up in the request count first.
- Review quarterly. Traffic mix changes and the cheapest option changes with it.
A single log schema for both providers
time, cdn, pop, cache_status, url, status, bytes, ttfb_ms,
client_country, user_agent_family, referer_host
With that, you can answer:
what share of requests does each provider serve?
what is the hit ratio for static assets per provider?
what is the cost per GB after normalising the log volume?
which provider is slower in the region that matters?| Cost lever | Effect | Risk |
|---|---|---|
| Longer TTLs on immutable assets | Large on requests and origin load | None if the URLs are hashed |
| Strip unused query parameters | Large on hit ratio | Must not change the response |
| Serve fewer renditions | Large on video | Visible quality loss |
| Block known scraper traffic | Medium on requests | False positives |
| Compress and convert images | Medium to large on egress | Quality regression |
| Cache HTML at the edge briefly | Large on origin load | Stale content for a short window |
| Move cold storage to a cheaper tier | Medium on storage | Slower restore |
⚠️
Two CDNs with cache keys that differ will produce different content for the same user depending on which one answers. Normalise cookies, query strings and Vary behaviour before adding the second provider, or you will spend the next quarter debugging a site that behaves differently depending on which edge answered.
FAQ
Is multi-CDN worth the complexity for a small site?
Almost never. A single provider plus a protected origin and a documented manual failover covers the realistic failure modes at a fraction of the cost.
How do I choose which CDN serves which traffic?
By asset class or region, and only when the difference is measurable. Splitting randomly across providers adds variance without a benefit.
Related
Security at the edge: WAF, DDoS and bot management Measuring CDN performance and debugging cache issues
Last refreshed 2026-09-18.