Synopsis

This chapter defines multi-CDN and explains when the approach improves service outcomes. It describes benefits in availability, performance, and vendor risk, and it outlines added complexity in operations, security, and cost. A simple decision framework and a migration overview provide a practical start point.

Definition

Multi-CDN is the practice of serving the same property through more than one content delivery network under a single control plane. Requests are routed to one of several providers based on policy. Policies consider jurisdiction, health, performance, and cost in that order of precedence. Correctness and user experience remain the primary constraints.

flowchart LR subgraph Single U1[Client] --> C1[CDN] C1 --> O1[Origin] end subgraph Multi U2[Client] --> R[Routing layer] R --> A[CDN A] R --> B[CDN B] A --> O2[Origin or shield] B --> O2 end

Expected benefits

Availability improves because independent networks and caches reduce single points of failure. Global performance improves when regional variance between providers is exploited by routing. Capacity headroom increases during events. Vendor concentration risk is reduced along commercial, technical, and legal dimensions. Jurisdictional routing becomes possible where regulations require it.

Added complexity

Operations expand to include parity across providers, routing policy, and incident playbooks that act at regional scope. Security must align WAF rules, bot controls, rate limits, and origin authentication across providers. Cache identity and purge workflows must be consistent. Certificate lifecycle and protocol support must match. Telemetry must normalise logs and metrics so comparisons hold. Contract management must model commits and overage across more than one vendor.

Fit criteria

Multi-CDN fits properties with strict availability objectives across many regions, with measurable regional performance variance, with events that create burst traffic, or with explicit residency constraints. It is less suitable where traffic is small, where teams cannot operate added complexity, or where application features depend on a single vendor’s proprietary capability that cannot be reproduced elsewhere.

Components and layers

A deployment includes a steering layer, one or more CDNs, an origin or shield layer, and a control plane. Steering can operate at DNS, at a layer 7 proxy, in client code, or in a hybrid arrangement. The control plane evaluates signals and publishes decisions to steering. Origins provide a consistent source with shielding to absorb miss traffic.

flowchart TD SIG[Signals: RUM, synthetic, health, cost] --> CTRL[Control plane] CTRL --> POL[Policy store] POL --> DNS[DNS steering] POL --> L7[L7 proxy] POL --> CLI[Client hints] DNS --> CDNA[CDN A] L7 --> CDNB[CDN B] CLI --> CDNA CDNA --> ORI[Origin or shield] CDNB --> ORI

Decision framework

A minimal framework answers five questions.

  1. Is there a requirement that single-CDN cannot meet. Examples include strict regional availability, significant regional latency variance, or residency obligations.
  2. Which steering layer fits constraints and staffing. DNS is coarse and simple. Layer 7 is reactive and flexible. Client logic reflects last mile variance. Hybrids combine layers with precedence.
  3. What policy order preserves correctness. Jurisdiction and allowlist first, then health, then performance against objectives, then cost inside guard rails.
  4. How will parity be maintained. Define canonical cache keys, shared security policy, aligned TLS and protocol support, and a purge controller that translates intent to each API.
  5. How will results be measured. Publish indicators, windows, and dashboards that segment by provider, region, ASN, and protocol and that join routing decisions to outcomes.

Migration overview

A common path starts with a second provider behind DNS steering for limited regions. Signals and dashboards are established first. Traffic moves in controlled steps with canary cohorts. Origin shielding is introduced where upstream load is sensitive. Cache keys and purge behavior are aligned. Security policy is templated and translated. Certificates and protocol support are verified. After confidence grows, additional regions adopt routing, and hybrid layers are added where justified by variance.

Anti-patterns

Routing without evidence causes oscillation and cache collapse. Feature dependency on a single vendor defeats portability. Long TTL with frequent purges indicates a missing immutable asset strategy. Security exceptions that differ between providers introduce gaps. Cost-first routing without performance guard rails harms users and erodes trust. Telemetry that cannot be joined by region, ASN, and provider prevents diagnosis.

Interactions with other chapters

Architecture patterns are described in /multicdn/architecture-patterns/. Routing policy is detailed in /multicdn/traffic-steering/. Signals and windows appear in /multicdn/signals-telemetry/. Origin and cache identity are covered in /multicdn/origin-architecture/ and /multicdn/cache-consistency/. Security, TLS, and operations appear in /multicdn/security-parity/, /multicdn/tls-certificates/, and /multicdn/incident-playbooks/.

Further reading

RFC 9110 and RFC 9111 describe HTTP semantics and caching. RFC 1034 and RFC 1035 describe DNS. Material on service level objectives and error budgets informs objectives and guard rails.