Nobody decides to let their CDNs drift apart; it happens one reasonable change at a time — a TTL fixed on platform A during an incident, a redirect added on B by whoever knew that dashboard, a header tweak that “we’ll port next sprint.” Six months later the two edges are cousins, not twins, and every failover is a behaviour change. Sync is not a tool you buy; it is a discipline with four parts, and skipping any one of them restores drift as the default state.
Why drift is the default state
Two structural forces guarantee drift unless countered. First, the platforms are genuinely different: rule engines with different primitives, different default behaviours (query-string handling, Vary treatment, redirect semantics), different names for the same idea — so even a faithful port is a translation, and translations decay. Second, urgency routes around process: incident fixes land on whichever platform is misbehaving, at 2 a.m., by dashboard, and the follow-up ticket to port them is the most-skipped ticket in delivery. The countermeasure is structural too: make the synced path the easy path (one definition, one command, both platforms) and the dashboard the exceptional one — because a discipline that relies on people voluntarily doing double work loses to 2 a.m. every time.
Express intent once: the config-as-code layer
The foundation is a single source of truth that describes behaviour, not vendor syntax: a repository defining hostnames, origins, cache rules (path patterns, TTL classes, key rules), redirects, headers, and the security posture — the same catalogue the security parity matrix rows come from. Both platforms’ real configurations are then generated from this intent layer, via each provider’s Terraform provider or API. The intent layer forces a healthy design pressure: it can only express what both platforms support, which surfaces every vendor-exclusive dependency at design time instead of failover time — the moment you want to write “use platform A’s special feature X,” you are making a documented portability decision, the topic of edge compute without lock-in, rather than an accidental one.
Translate per platform, honestly
The generators that turn intent into vendor config are where honesty lives. Semantics differ in ways that matter: platforms disagree on rule evaluation order, on what a “bypass cache” means for downstream headers, on default query-string normalization — so each translation needs a documented mapping, and where a platform cannot express an intent exactly, the gap gets recorded in the intent file itself (platform-b: approximated, see note) rather than silently absorbed. Resist the lowest-common-denominator trap in both directions: don’t dumb the estate down to the weaker platform’s worst gap, and don’t let the stronger platform’s extras accrete unmanaged — extras are allowed, but they live in the intent layer too, flagged as single-platform, so the failover behaviour delta is a known list, not a surprise. Where a genuine third-party abstraction fits your estate, the orchestrator products in our comparison do parts of this translation commercially; the discipline stays yours either way.
One change process for every change
Every delivery change — feature, fix, incident response — flows through the same pipe: edit intent, review, generate, deploy to staging hostnames on both platforms, run the test suite, deploy to production on both, verify. The pipeline makes double-deployment automatic, which is what finally beats the 2 a.m. problem: the emergency fix is made in the intent layer and lands on both edges in one command, no port ticket to skip. For the genuine emergencies where someone must touch a dashboard directly, the rule is reconciliation-by-deadline: the pipeline detects the manual change (section five) and the owner either backports it into intent or reverts it within a day. Change history in one repo also gives multi-CDN its missing audit trail — who changed what behaviour when, across both platforms, in one log.
Detect drift: tests, exports, audits
Trust nothing; verify two ways. Behavioural: a cross-edge test suite that requests the same paths through each CDN explicitly (resolving each platform’s target directly) and compares what matters — status, cache behaviour, headers, redirects, token enforcement — run on schedule and after every deploy; a check passing on one edge and failing on the other is drift caught before an incident finds it, the same suite philosophy as the security parity tests. Declarative: nightly config exports from each platform diffed against what the generators last produced, which catches dashboard changes that behavioural tests might miss. Wire both into alerting, review the drift log in the quarterly audit, and treat a quiet month of zero drift as the success metric it is. Parity held this way is what makes every other multi-CDN promise — failover, splitting, steering — actually true on the day it’s needed.