Does BYOIP Let You Keep the Same IP Prefix When You Add a Second CDN?
You keep the prefix, but you usually can't share it. BYOIP lets your IP prefix travel with you when you add or switch CDNs, and AWS even pitches CloudFront BYOIP as a way to migrate from other CDNs without changing IP infrastructure. What almost no provider allows is two CDNs announcing the same prefix at the same time.
Fastly demands exclusive announcement rights, Google Cloud doesn't support overlapping announcements, and AWS tells you to withdraw other announcements first. So the options that actually work are moving the prefix, splitting it into one /24 per CDN, keeping one provider on standby or steering with DNS across each CDN's own IPs.
What It Actually Means to Own and Advertise Your Own IP Prefix
Owning a prefix means it's registered to your organization at a regional internet registry like ARIN or RIPE. Advertising it means some network announces it through BGP routing so the rest of the internet knows where to send traffic. With BYOIP, you hand that announcement to your CDN, and you prove you're allowed to:
Each CDN normally announces under its own ASN, like Cloudflare's AS13335 or Amazon's AS16509, so every provider you add needs its own set of these.
Prefixes smaller than a /24 for IPv4 or a /48 for IPv6 are generally filtered on the internet, so a /24 is your smallest useful unit. CloudFront BYOIP asks for three /24 blocks, so a single /24 can't go there at all.
The payoff is that your addresses stop changing. Allowlists and firewall rules keep working no matter which CDN sits behind those IPs.
What Happens to Your IP Prefix When You Advertise It Across Multiple CDNs
Picture two CDNs announcing the same /24, each from its own ASN. Every network on the internet now sees two valid-looking paths and picks one using its own policy. Some users land on CDN A, some on CDN B, and you don't get to choose who.
That's why providers push back hard:
RPKI adds another trap. A ROA names one origin ASN, so if yours only covers CDN A, CDN B's announcement shows up as RPKI-invalid. Kentik measured that invalid routes reach between half and two thirds fewer networks. If both CDNs could announce under your own ASN, one ROA would cover both, but few CDNs offer that, and Cloudflare only does it through its account team.
The BGP Mechanics That Determine Which CDN Announces Your Prefix
Here's the thing I'd fix in how this usually gets framed: you decide which CDN announces your prefix, through your LOA and ROA. BGP decides which announcement each remote network believes, and that decides which CDN receives each user. The rules go roughly like this:
- Longest prefix wins first. A /24 beats a /23 no matter how long its path is. It's also how real hijacks work, as in the 2018 Route 53 incident built on more specific /24 announcements.
- Between equal prefixes, each network applies its own local preference, then usually picks the shorter AS path.
- AS-path prepending can make one path look worse, but it's best-effort. Cloudflare caps you at 3 prepends and says plainly that peers set their own priorities.
On top of that, anycast CDN catchments are notoriously hard to predict. Researchers behind the AnyOpt project found that even adding more anycast sites can make performance worse. Two anycast CDNs competing for one prefix multiplies that uncertainty, so you can nudge traffic, but you can't really steer it.
The Operational Risks of Sharing a BYOIP Prefix Across Two CDN Providers
If you try it anyway, these are the problems you sign up for:
- An unpredictable split. Each provider's capacity planning and security tuning assume it gets your traffic, and suddenly it only gets part of it.
- Security gaps. Users routed to the second CDN skip the first one's DDoS scrubbing and WAF rules, and Fastly reserves the right to de-aggregate or blackhole routes during an attack.
- Hijack alarms. Monitoring tools flag a second origin AS as a possible hijack. When Cloudflare withdrew its 1.1.1.1 routes in July 2025, another network's announcement of the same prefix looked, in Cloudflare's words, "exactly like a prefix hijack."
- Slow failover. Cloudflare says convergence after a withdrawal typically takes two to five minutes and can stretch past 11.
- Config drift. Both CDNs must serve the same hostnames with valid certificates on the same IPs, or users on one side get errors.
Debugging any of this needs solid edge observability, because the failure shows up as some regions being slow, not as one clean error.
When BYOIP Prefix Portability Actually Works and When It Does Not
For a move, go make-before-break. Cloudflare's guidance is to announce the same-length prefix from the new location, wait five to ten minutes, then withdraw the old one. For standby, Cloudflare's on-demand advertisement takes roughly two to seven minutes to enable.
If what you really want is two CDNs serving traffic at the same time, I'd skip shared BYOIP and steer with DNS instead. Each CDN keeps its own IPs, and a good DNS layer decides who gets which users. IO River, for example, steers traffic through DNS and documents failover in typically under a minute. Picking one of the top DNS providers for that layer gets you far more control than BGP ever will.
Whichever path you pick, plan for lead time. AWS says provisioning takes anywhere from two hours to a week, Google says multiple weeks, Cloudflare needs at least five hours and Fastly asks for 45 days.