Coordinating Multiple CDNs Without Losing the Origin Boundary
An anonymous media-platform engagement combining provider routing, origin shielding, session-state changes and phased activation across acquired properties.
Acquired properties had different delivery rules
A media streaming platform had grown through acquisition. Its properties brought different CDN providers, cache policies, origin settings and vendor dashboards. A delivery change or investigation crossed several teams and support relationships. Origin overload during an event exposed the weakness of a manual recovery path: selecting another destination did not make that destination ready for the incoming workload.
Ampity's work on this anonymous engagement combined multi-provider traffic management, origin shielding, changes to session-state handling and shared operating visibility. The retained engagement account describes a phased introduction rather than an immediate replacement of every provider. Existing contracts, legacy integrations, content licensing and content protection constrained the choices.
For the platform leader, the decision was how to coordinate those responsibilities while acquired products continued operating. A provider switch needed to preserve the content path and its restrictions, not merely return a different network destination.
Why the team kept more than one provider
Consolidating delivery under a single provider would have reduced the number of configurations and commercial relationships to manage. The team instead wanted to retain provider choice and an alternative delivery path. That preference came with additional configuration, observability and incident responsibilities.
| Option considered | Attraction in this engagement | Reason for the recorded decision |
|---|---|---|
| Consolidate under one CDN | Fewer provider configurations and operating interfaces. | Rejected because the team wanted to avoid concentrating delivery and commercial dependence in one provider. |
| Keep providers with shared configuration tooling | Retain contracts while reducing inconsistent settings. | Insufficient for the intended health-based routing and recovery scope; operators would still make traffic decisions manually. |
| Add a traffic-management layer | Coordinate provider selection and investigation while retaining multiple delivery paths. | Chosen with an explicit increase in engineering and operating complexity. |
| Build a private edge network | More direct ownership of selected delivery locations. | Deferred because of capital and operating demands. |
These are the engagement's choices, not a universal ranking of CDN products. A team whose current provider meets its requirements may have a stronger case for simplifying configuration than for introducing another routing layer.
Routing decisions and content requests follow different paths
The design used a global traffic-management layer to select providers, an origin-shield responsibility to reduce repeated origin work, and externalized session state using Redis. It also separated live-stream handling from the ordinary on-demand path. Shared monitoring brought provider observations and player-side quality signals into the operating view.
DNS-based selection supplies an answer that clients can use to reach a destination. It does not imply that the DNS service proxies every video request. Resolver caching also affects when changed answers are used, as AWS's DNS guidance explains. Existing connections and the player need their own acceptance checks. The account does not specify their effective routing or reconnection settings.
The shield layer had a separate job: protect origin capacity when delivery paths requested content. A shared shield can also become a common dependency, so adding CDN providers does not by itself establish independent recovery paths. AWS documents CloudFront Origin Shield as a caching layer that can consolidate origin requests, including an arrangement where other CDNs use a CloudFront distribution as their origin. That is a current product example, not identification of this engagement's shield implementation.
Externalizing session state changed which origin-local state had to survive an instance change. It also introduced shared state availability and access responsibilities. The account does not establish Redis replication, session recovery or capacity settings, so this design choice cannot substantiate uninterrupted viewing.
Live content needed its own delivery contract
The recorded live path included regional ingest and encoder-failover coordination. Those responsibilities belong alongside the player, content origin and provider path. A healthy provider endpoint alone cannot establish that the expected live segment, authorization or decryption path is usable.
Live content should not be classified as universally uncacheable. AWS's Origin Shield documentation includes live video among its multi-CDN use cases. Cache suitability depends on the content and its freshness requirements. For a CloudFront-based comparison, cache-duration settings and response headers control how long objects may be served from cache. They do not supply a shared invalidation guarantee across unrelated providers.
For a comparable platform, classify manifests, segments, personalized responses and protected requests separately. Preserve the approved geographic and access restrictions for each. An alternate provider that can deliver a public object may still be unsuitable for a protected stream. These are proposed review questions, not newly asserted controls from the engagement.
Introduce shared controls before expanding routing authority
The engagement sequence began with the origin-shield layer and a gradual change to provider origin paths. Traffic selection then ran in shadow mode before routing authority expanded in stages. Automated failover work followed. Manual override and approval boundaries were part of the approach, with larger routing changes retaining human oversight.
That sequence separates changes to origin handling from changes to user destination. Shadow decisions can reveal disagreements with the current route, but they do not expose the alternate path to the same workload or demonstrate recovered viewing. In a comparable rollout, a conflicting destination, broken content restriction or unexplained origin-pressure change should hold further expansion until the responsible owner resolves it.
What this case establishes
This case preserves the recorded delivery scope and decision rationale. Matched measurement and exercise records are not available here, so it makes no availability, latency, savings, audience-scale or successful-failover claim. Those results cannot be inferred from the architecture or rollout sequence.
Review one content path without changing it
Use this proposed read-only worksheet for one approved content class and destination pair. Bind each row to a configuration revision, observation date, responsible owner and restricted evidence reference. Use sanitized identifiers, exclude session tokens, signed URLs and viewer records, and keep missing evidence marked UNKNOWN. The worksheet authorizes no playback probe, content retrieval, cache purge, traffic change or fault injection.
| Responsibility | Evidence to request from its owner | Hold condition |
|---|---|---|
| Provider selection | Current and proposed destination, selection signal, DNS or other routing mechanism, and the clients covered. | The selected route cannot be connected to the actual content path. |
| Content eligibility | Approved object class, geography, authorization and protection requirements on both paths. | The alternate path's eligibility or access rule is unknown. |
| Origin and shared state | Cache/shield path, origin readiness, session dependency and available capacity evidence. | Both paths share an unresolved dependency or target readiness is unproven. |
| Live-path continuity | Ingest, encoder, manifest/segment and player responsibilities relevant to this content class. | Endpoint health is the only evidence offered for usable viewing. |
| Change and recovery authority | Owner allowed to expand routing, stop condition, manual override and evidence needed before returning traffic. | A route can change without an accepted content or recovery boundary. |
For an illustrative review, suppose supplied records identify an alternate provider and its public-object route, but omit the stream's geographic restriction. Mark protected-stream eligibility UNKNOWN and assign it to the content/access owner. Do not fill that gap with a successful public-object response or a claim of recovery.
Choose one unresolved row and request the missing record before proposing a traffic change. If the next step is an authorized client-recovery exercise, use the separate DNS failover rehearsal rather than treating this worksheet as a test plan.
Technical reference
AWS's DNS, CloudFront Origin Shield and cache-expiration documentation were checked on 18 October 2026 for the general mechanisms linked above. They do not establish this engagement's providers, product versions, effective settings, test execution or outcomes.