How to Choose DDoS Protection for Global Businesses

Short answer: Do not buy DDoS protection by advertised capacity — judge it by three things instead: which attack surfaces it covers, what has to be true for it to engage, and how it fails. On Cloudflare, unmetered layer 3/4 and HTTP DDoS protection is included on every plan, Free included. Non-HTTP ports need Spectrum (paid plans, and custom TCP/UDP requires Enterprise), and protecting an entire IP prefix needs Magic Transit (Enterprise-only). All of it depends on one precondition: traffic must actually route through Cloudflare, and your origin must not answer the public internet directly.

Ask the right question first: not “how many gigabits”, but “what is actually exposed”

Most DDoS buying conversations start with capacity — “how many Gbps can you absorb”. That number is largely meaningless for a business expanding overseas, for a simple reason: capacity is the vendor’s problem, not yours. Any serious provider operates an anycast network with far more ingress capacity than an attacker can assemble. What actually decides whether you survive an attack is three other things:

1. Coverage — does the service cover the attack surface you actually have? A business running only a web front end and one API has a completely different exposure profile from one running game servers, VoIP, or an entire IP block.
2. Preconditions — what must be true for the protection to engage at all? Plenty of “protection purchased” situations produce zero protection because traffic never routes through the scrubbing network.
3. Failure boundaries — where does it stop working, and what happens in the gap? Every product has a layer it does not cover; the question is whether you know where that edge is before the attack rather than during it.

Three attack surfaces, three different answers

Your exposure	What the attack looks like	The mechanism that fits	Plan threshold
Web / API on HTTP(S)	Volumetric floods, HTTP floods, slowloris	Reverse proxy absorbs and filters at the edge	HTTP DDoS protection is on all plans; tuning depth is plan-dependent
Non-HTTP TCP/UDP (game, VoIP, MQTT, custom ports)	Protocol floods, connection exhaustion	Port proxy in front of the service	Spectrum — paid plans; custom TCP/UDP needs Enterprise
An entire IP prefix, any protocol	Anything, including protocols a proxy cannot parse	Tunnel or BGP announcement of your prefix	Magic Transit — Enterprise-only

The most expensive mistake on this table is buying the third row’s answer for a first-row problem, or discovering during an incident that your game backend is on row two while your protection only covers row one.

What every plan includes — and what it does not

The baseline is unusually broad. The documentation states it plainly: Cloudflare provides unmetered and unlimited DDoS protection at layers 3, 4 and 7 to all customers on all plans and services, and the availability table marks Standard unmetered DDoS protection (layers 3–7), HTTP DDoS attack protection and network-layer (L3/4) protection as available on Free, Pro, Business and Enterprise alike.

So the Free-to-Enterprise difference is not “does it mitigate a large attack”. It is about how much you can see and steer:

Capability	Free / Pro / Business	Enterprise with Advanced DDoS Protection
HTTP DDoS rule overrides	1 override, expression not customisable	up to 10, with custom expressions
Log action on DDoS rules	not available	available (Enterprise + the add-on)
Adaptive rules	error-based adaptive rules only	all adaptive rules; profiling adds country, user agent, query string and ML scores
Alerting	standard	“Advanced alerts with filtering”
Sensitivity threshold	default trigger at 1,000 errors per second; Pro/Business/Enterprise also require ~5× the normal error rate	same defaults, tunable per override

Two naming traps are worth knowing before you quote a plan internally. First, “Advanced DDoS Protection” the add-on (the table above) is a different thing from “Advanced DDoS Protection systems” — Advanced TCP, DNS and programmable flow protection — which the documentation marks as available to Magic Transit customers. Second, some blog posts still refer to “HTTP DDoS Attack Analytics”; that name is no longer used in current documentation.

A separate, frequently missed threshold: Sensitivity levels (High / Medium / Low / Essentially Off) belong to the DDoS managed rulesets, not to the WAF. The WAF’s equivalent tuning knob is the OWASP score threshold (Low ≥ 60, Medium ≥ 40, High ≥ 25). Conflating the two produces change requests that cannot be implemented.

The decision path

Cloudflare capabilities vs. what your team must own

Item	What Cloudflare provides	What your team must do
Absorbing volumetric attacks	Unmetered L3/4/7 mitigation on all plans	Make sure traffic actually traverses Cloudflare
HTTP flood mitigation	HTTP DDoS managed ruleset; 1 override on lower plans	Tune sensitivity, decide on the add-on if you need more
Request-rate control	Rate limiting rules — 1 / 2 / 5 / 100 by plan; periods from 10 s to 65,535 s	Choose counting keys; own absolute ceilings in the app
Origin protection	Reverse proxy hides the origin address	Replace leaked origin IPs; restrict origin to Cloudflare ranges
Emergency brake	Under Attack Mode	Decide who is authorised to enable it, and when to turn it off
Non-HTTP business	Spectrum / Magic Transit	Confirm protocol and prefix requirements before you sign

Boundaries and non-applicable cases

• DNS-only records get nothing. If a hostname is grey-clouded, requests go straight to your origin; no edge mitigation applies. This is the single most common reason a purchased protection “does not work”.
• A leaked origin IP defeats the proxy. The documentation’s framing is that behind a reverse proxy attackers can only target the proxy itself — which is true only while the origin address is unknown and unreachable from the internet.
• Rate limiting is not a precise counter. It is explicitly not designed to let an exact number of requests through, and counters accumulate per data centre with a few seconds of mitigation delay. Absolute quotas belong in your application.
• Under Attack Mode is not a configuration. It is documented as one of the last resorts, inserts an interstitial of roughly five seconds, and is expected to affect third-party analytics. Treat it as a break-glass control with an owner and a revert step.
• Multi-CDN or partial-proxy architectures need an explicit answer to what happens to traffic that does not traverse Cloudflare. “Most of it does” is not an answer.

FAQ

Do I need Enterprise to survive a large attack? No. Unmetered L3/4/7 protection is on all plans including Free. What Enterprise changes is observability and control: more DDoS overrides with custom expressions, the Log action, adaptive rule breadth and advanced alerting — plus access to Magic Transit and custom-protocol Spectrum, which are genuinely unavailable otherwise.

Does a CDN automatically protect me? Only for the traffic that goes through it, and only for the layers it proxies. A CDN in front of your static assets does nothing for a game server on a bare IP, and nothing for your origin if its address is public. See the dedicated piece on this question below.

How do I verify the protection is actually working? Three checks, in order: every hostname you care about resolves to Cloudflare and is proxied; your origin answers nothing from the public internet except Cloudflare ranges; and a controlled test produces the mitigation or challenge you expect rather than a timeout at the origin.

We already pay a cloud provider for DDoS protection. Is this redundant? Not necessarily, but stacking two reverse proxies without a plan usually hurts: you lose the client IP at the second hop, health checks and caching behave differently, and nobody owns the origin allowlist. Decide which layer is authoritative and make the other one a pass-through.

Related reading

• Can a CDN Protect Your Website from DDoS Attacks?
• How to Mitigate HTTP Flood and Layer 7 Attacks
• How to Choose an Enterprise Web Application Firewall
• DDoS protection capabilities