What are Multiple CDN Domains?
Using multiple CDN domains distributes asset URLs across distinct hostnames for separation, migration, branding, or routing. Each hostname may use different certificates, cache policies, or origins.
How Multiple CDN Domains work
Multiple delivery hostnames divide requests into independently addressable namespaces even when they ultimately use one CDN or origin. The arrangement can separate customers, security boundaries, migration stages, or classes of media, and each hostname participates in DNS, certificate, cache-key, and browser-origin behavior. It is therefore an architectural routing choice rather than a guaranteed performance optimization, especially with modern connection reuse.
Key facts
- 1A browser treats different hostnames as different origins, so fonts, canvas-readable images, scripts, and authenticated media may require explicit CORS behavior even when one company controls both names.
- 2Hostname sharding can add DNS lookups and TLS connections. Under HTTP/2 or HTTP/3, splitting assets may reduce multiplexing benefits unless connection coalescing is possible and correctly configured.
- 3Certificates, DNS records, ownership validation, and CDN routing must be maintained for every custom hostname; expiry or misrouting can break only one tenant or asset class and evade broad checks.
When Multiple CDN Domains matter
Use separate domains to isolate tenants or asset classes, support custom branding, or migrate providers gradually. More hostnames add DNS, TLS, CORS, cookie, and cache-configuration complexity.
Common use cases for delivery
These examples cover delivery broadly, not specifically Multiple CDN Domains.
- Serving image, audio, video, and document derivatives to a geographically distributed audience.
- Protecting private assets worldwide with expiring or signed requests.
- Reducing repeated processing and origin traffic by caching deterministic results.
Working with delivery
This guidance covers delivery broadly, not just Multiple CDN Domains.
A client requests an asset using a URL or playback manifest. A delivery layer evaluates authorization and cache state, serves a cached response when possible, or retrieves the asset from its origin before forwarding and optionally caching it.
Delivery choices determine more than download speed. Cache keys, origin behavior, authorization, geographic routing, invalidation, and egress cost decide whether an asset is fast, current, and available to the right audience.
What you gain
- Edge caching places frequently requested assets closer to viewers.
- Explicit cache and authorization rules reduce avoidable origin work.
- Multiple delivery variants let clients request an asset suited to their context.
What it costs
- Long cache lifetimes improve hit ratio but make replacement and invalidation more difficult.
- Signed access protects private media but adds key management, clock, and cache-partitioning concerns.
- More variants improve client fit while increasing storage, cache fragmentation, and operational complexity.
Before production
- 1Define cache keys, cache lifetime, invalidation, and authorization behavior explicitly.
- 2Measure time to first byte, cache-hit ratio, egress, and behavior after an origin failure.
- 3Test signed and unsigned requests at the CDN edge, not only against the origin.