How Much Bandwidth Can Multi-CDN Networks Provide for DDoS mitigation?

A single top-tier provider such as Akamai advertises more than a 1 Pbps edge capacity, while Fastly reports 427 Tbps and Cloudflare lists 388 Tbps. 

‍

When I stitch two or three of these together in a multi-CDN, the blended pool tops a petabit per second of clean bandwidth, which is roughly 150 × larger than the biggest volumetric DDoS we have seen so far (Cloudflare blocked 7.3 Tbps in May 2025).

‍

Here’s why I’m obsessing over these raw bandwidth numbers:

‍

What Do DDoS Attacks Do?

‍

When a botnet tries to knock you offline with a volumetric CDN DDoS attack, it’s essentially yelling louder than your servers can listen. 

‍

Bits per second (not fancy exploits) become the metric that matters. If I can guarantee that the edge in front of me speaks with a louder megaphone than the botnet, I win. 

‍

That’s the heart of CDN DDoS mitigation: buy so much network fabric that the attacker can’t afford the bandwidth bill to out-shout you.

‍

How Does a Single CDN Defends Against DDoS

‍

Every established CDN with DDoS protection uses Anycast. The same IP space is advertised from hundreds of points of presence (PoPs).

‍

Attack traffic fans out, hits the closest PoP, gets scrubbed, and the legitimate requests continue downstream. A few reference numbers:

‍

‍

Any one of these is already an order of magnitude above the nastiest public attacks. Azure, for instance, mitigated a 2.4 Tbps event back in 2021 and didn’t blink.

‍

Then Why is a Multi-CDN Strategy Needed?

‍

Capacity headlines are global aggregates. A 400 Tbps backbone looks enormous until you realise a burst aimed exclusively at your Singapore users will be handled by maybe 20 Tbps of local edge ports. 

‍

If the botnet is regionally focused and your audience is too, you can still drown.

‍

How a Multi-CDN Multiplier Works

‍

So I spread the load. I keep my authoritative DNS on an independent provider and rotate A/AAAA records for my application; roughly 40 % of sessions ride Cloudflare, 35 % ride Fastly, and the balance sits on Akamai. With weighted routing I can push or pull traffic in real time.

‍

Because the PoP maps only overlap partially, the regional head-room does stack more efficiently than you’d think: Fastly’s APAC build-out complements Cloudflare’s heavy EMEA presence; Akamai’s massive depth in tier-2 metros fills in the long-tail. 

‍

In practice, I see 70–80 % of the arithmetic sum become usable. With the big-three example above, that’s still ≈1 Pbps × 0.75 ≈ 750 Tbps of effective cushion; well above the entire “hyper-volumetric” threat class we see in 2025.

‍

How Much Bandwidth Can You Realistically Draw

‍

When you buy CDN DDoS security you’re really reserving four things:

‍

• Burst bandwidth – often “unmetered” but governed by AUP. Cloudflare’s free tier is technically unlimited yet subject to abuse checks.
• Packets per second (PPS) limits – attacks can be low-bps but high-pps; always check the fine print.
• Regional quota – some SLAs break out North America vs EMEA vs APAC.
• Mitigation latency – how fast the scrubbing rules propagate. Cloudflare brags about auto-mitigation in <3 s.

‍

If you stitch two or three contracts together, you will have a better leverage on demanding written escrows totalling hundreds of terabits in every critical region. 

‍

A vendor who won’t put it in writing probably can’t deliver it.

‍

Theoretical Calculation

‍

I start with headline numbers:

‍

• Akamai ≈ 1 000 Tbps
• Fastly   427 Tbps
• Cloudflare 388 Tbps

‍

Total arithmetic pool = 1 815 Tbps (≈ 1.8 Pb/s).

‍

In practice, POP maps don’t line up perfectly. Empirically I see 70–80 % of the sum become usable because traffic shifts toward whichever provider owns the fattest local ports. Using a conservative 75 %:

‍

1 815 Tbps × 0.75 = 1 361 Tbps (≈ 1.36 Pb/s).

‍

Compare that to the largest public volumetric blast; 7.3 Tbps. This buffer is 187 × larger. An attacker would have to commandeer more than half of today’s entire residential uplink market just to dent the shield. 

‍

That’s the beauty of raw bandwidth economics.

‍

Engineering The System

‍

Keep these knobs tuned:

‍

• DNS TTL at 30–60 s. Lets me re-weight traffic mid-attack without leaving stub resolvers in limbo.
• BGP Anycast fail-open. If a provider black-holes under pressure, routes fall back to the others.
• Mutual health probes. Each CDN origin location hits the others over a private Service-Mesh so I spot silent failures.
• Config parity. Matching cache keys, WAF rules, and TLS versions avoids “it works on CDN A but 502s on CDN B” surprises during an emergency.

‍

In simpler terms: you don’t want to be rewriting firewall JSON at 3 a.m. with packets flying. Normalise ahead of time.

‍

Take This With a Grain of Salt - Caveats

‍

I love quoting edge-capacity numbers because they make the math easy, but here’s where reality sneaks in and you should temper expectations:

‍

1. Fair-use clauses trump marketing slides.
   Every “unmetered” or “unlimited” CDN DDoS protection plan hides a traffic-abuse section. If an attack starts crushing routers that share infrastructure with Fortune-100 clients, the provider can (and will) rate-limit your prefix to protect the wider fleet. I’ve watched SOC engineers quietly shave a customer’s burst allowance from 400 Gb/s to 50 Gb/s mid-incident.
2. Capacity is shared, not dedicated.
   The 1 Pb/s Akamai touts isn’t a private moat. It’s first-come, first-served across thousands of tenants. If three other giants are getting hammered at the same time, the slice left over for your storefront might be single-digit terabits.
3. Regional ceilings still exist.
   Even in a multi-CDN blend, the São Paulo POP you lean on might cap at 4 Tb/s while the brochure screams 300 Tb/s for LatAm. An attacker who geotargets that weak spot can force an early failover to your other networks; and if those networks are thin in Brazil too, users will feel the latency spike.
4. PPS limits bite before bandwidth limits.
   Vendors publish headline “bits per second,” but their hardware ACLs often choke on packets-per-second floods long before the link saturates. A low-bandwidth SYN storm can tip over a 400 Gb/s port that’s configured for 60 Mpps.
5. Mitigation latency isn’t uniform.
   Cloudflare’s auto-mitigator pushes a rule in ~3 s; some regional nodes on smaller CDNs still require manual approval. During that window an attack can exhaust local buffers and trigger fail-safes that shed connections; users see that as downtime even though “capacity” is technically untouched.
6. Commercial leverage matters.
   The written SLA is only as strong as your billing footprint. If you’re a low-seven-figure client, the provider’s NOC will move heaven and earth; if you’re on a starter plan, they’ll protect you, but not at the expense of their whales.
7. Cost balloons with sustained floods.
   Most CDNs waive overage during genuine attacks, yet once traffic is deemed “after-glow” you start paying for egress and extra WAF rules. A week-long campaign can triple your monthly bill if you don’t negotiate caps up front.
8. Complexity creates new failure modes.
   Multi-CDN BGP fail-open is great until one provider silently advertises a more specific route and sinks all traffic into a half-built POP. Every extra network is another variable that can misbehave at 3 a.m.

‍

So yes, stacking Akamai, Fastly, and Cloudflare can give me theoretical petabit head-room, but I never assume I’ll get to wield the whole hammer. 

‍

I draft contracts that spell out regional minimums, PPS ceilings, and mitigation SLAs; I drill failovers monthly; and I keep finance ready for a sticker shock if an attacker decides to stay for dessert.

‍