Synopsis#
This chapter explains the principles and practice of operating more than one content delivery network at the same time. Multi-CDN is used to improve availability, performance, and resilience. It also increases complexity and cost. This document describes when multi-CDN is appropriate, how to design it, and how to operate it reliably.
Fit analysis#
Multi-CDN is most useful when service level objectives require high availability across many regions, performance varies between providers in different areas, regulatory or commercial risk must be spread across vendors, or large traffic bursts cannot be absorbed by a single provider. It is less appropriate when traffic volume is low, the operational team is small, or application features depend on one vendor’s proprietary services.
Architecture patterns#
Common deployment patterns include DNS-based steering, layer 7 proxy or aggregator, client-side selection, and hybrid designs. DNS-based steering uses authoritative DNS to direct traffic to different CDNs based on geography, network, or other metrics. A layer 7 proxy or aggregator routes HTTP requests through a proxy that selects the target CDN in real time. Client-side selection uses code in the application or SDK to choose a CDN endpoint. Hybrid designs combine two or more of these methods.
flowchart LR
Client --|DNS lookup|--> Resolver
Resolver --> AuthoritativeDNS
AuthoritativeDNS --> CDN_A
Client --|HTTP(S)|--> L7_Proxy
L7_Proxy --> CDN_B
Client --|SDK decision|--> CDN_C
Traffic steering#
Traffic steering is the process that selects which CDN will serve a request. Policies can be based on geography or ASN, latency or throughput, real user measurement, synthetic measurement, or cost. These policies can be combined to balance performance, reliability, and spend, but they need clear precedence rules and guard rails to avoid oscillation.
Signals and data#
Reliable steering depends on accurate and timely data. Useful sources include synthetic probes from multiple regions, real user measurements embedded in pages or apps, BGP and routing signals, CDN health and status endpoints, and analysis of logs and metrics. Data collection should be continuous, representative of real users, and resilient to outliers.
Origin strategy#
The origin must be reachable by all CDNs in the configuration. Designs include a single origin with shielding, multiple origins in different regions, or a mix of both. Authentication at the edge can use signed URLs or tokens. Cache keys should be consistent across CDNs so that object identity is stable regardless of the serving provider.
Security parity#
All CDNs in the set should enforce the same security controls. That includes TLS configuration, web application firewall rules, bot mitigation, origin authentication, and any IP allowlists or rate limits. Changes should be applied and verified across providers to avoid gaps.
Feature parity#
Features like image optimization, video packaging, and edge functions vary by provider. Prefer portable features and deterministic URLs for any transforms. Where differences cannot be avoided, document them and test behavior in each CDN before enabling a rollout.
Operations#
Operating multi-CDN requires staged rollouts with canary traffic, incident playbooks that cover detection, isolation, and reroute, monitoring and alerting aligned with service level objectives, and regular configuration reviews across providers. Post-incident reviews should include routing decisions and data quality checks.
Cost and contracts#
Expect different commit structures, potential overage charges, and egress cost differences by region. Build a cost model that includes realistic traffic mixes and growth. Cost-aware routing can direct traffic to the most economical provider while meeting performance requirements if it is constrained by guard rails.
Compliance and data residency#
Some deployments require routing within jurisdictional boundaries and careful handling of logs and telemetry. Confirm where user data is processed and stored, and maintain audit records for routing decisions and configuration changes.
Implementation notes#
Confirm that multi-CDN solves a real requirement. Choose a steering architecture and the signals that feed it. Prepare origins and authentication for multiple CDNs. Align security controls. Test failover and rollback. Deploy monitoring and alerting with clear thresholds. Train operators. Review costs. Document the configuration and keep it current.
See the detailed chapters on architecture patterns at /multicdn/architecture-patterns/, traffic steering at /multicdn/traffic-steering/, and signals and telemetry at /multicdn/signals-telemetry/.
References#
RFC 1034 and RFC 1035 for DNS. RFC 9110 for HTTP semantics.
Synopsis This chapter explains how to collect, process, and apply telemetry for multi-CDN routing. It covers real user measurements, synthetic probes, provider health and routing data, logs from the service stack, and the aggregation and alerting that turn signals into safe decisions. The goal is to make routing reflect user experience and to change paths only when evidence supports a better outcome.
Measurement goals All measurement should support a small set of goals. Confirm that users receive correct content with acceptable latency and reliability. Detect faults and degradations fast enough to protect users. Provide data that is stable enough for routing but sensitive enough to catch regressions. Keep the cost and complexity of the system proportional to its value.
...
Synopsis This chapter explains how changes to routing, configuration, and content are tested and deployed in a multi-CDN environment. It covers pre-production validation, cohort design, canary strategies, progressive exposure, measurement, guard rails, rollback, and record keeping. The goal is to make changes reversible, observable, and limited in blast radius.
Purpose and scope Multi-CDN adds variables at several layers. DNS answers, proxy behavior, client logic, cache identity, and origin controls can all change outcomes. Testing must isolate causes and confirm improvements using indicators that reflect user experience. Rollouts must keep a safe default path and apply controls that prevent fast spread of harm.
...
Synopsis This chapter describes how transport security and certificate management function in a multi-CDN deployment. Topics include certificate lifecycle and automation, subject naming choices, OCSP and certificate transparency, origin authentication with mutual TLS, session behavior across providers, and controls that keep the security posture consistent while avoiding service disruption.
Scope and goals The transport layer must present a uniform and reliable interface regardless of which CDN serves a connection. Users should see correct certificates, modern protocol support, stable cipher policy, and predictable session behavior. Operations should see an automated lifecycle that avoids expirations, supports rapid revocation, and provides clear observability. The origin path should authenticate CDNs in a way that cannot be replayed from the public internet.
...
Synopsis This chapter explains how to design and operate traffic steering for multi-CDN. It covers inputs and data quality, common policy types, precedence rules, health and failover, stability controls, cost awareness, and rollout practices.
Inputs and data Effective policies need inputs that reflect user experience and provider health. Synthetic measurements provide controlled and repeatable data but can miss last mile conditions. Real user measurements capture actual paths and networks but require sampling, privacy controls, and careful aggregation. Health signals from providers are useful but should not be trusted without verification. Logs and metrics from the service stack provide the ground truth for outcomes.
...
Synopsis This chapter describes multi-CDN delivery for streaming video. It covers manifest and segment behavior for HLS and DASH, CMAF packaging and low latency modes, cache strategy for live and on demand, access control with tokens and keys, DRM and license services, session stickiness and failover, telemetry for quality of experience, and operational patterns for events and steady state.
Protocol context Most HTTP streaming uses HLS or MPEG-DASH. Both expose a manifest that references media segments. CMAF provides a common container and supports small chunks for low latency playback. The CDN caches manifests and segments and forwards misses to a packager or origin. Multi-CDN adds parallel caches and different network paths, so parity of behavior is required for correctness and quality.
...
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.
...