ChatGPT
Perplexity
Claude
Cloudflare DDoS protection at Layers 3 and 4 (network-layer floods, SYN floods, UDP amplification) is unmetered and free on every plan, including the free tier. Layer 7 protection (HTTP and HTTPS floods, application-layer attacks) is also included on every plan but only gets advanced configuration on Business and Enterprise. Magic Transit (BGP-routed protection for entire networks behind Cloudflare) is a separate Enterprise-only product for protecting non-HTTP services and on-premise infrastructure. For most web platforms the free L3/L4 protection plus the included L7 protection is enough; the question is configuration, not licensing. The thing that actually matters is the sensitivity tuning per hostname and the runbook for what happens during an attack.
This is the guide that explains what each layer of Cloudflare DDoS protection actually does, what is free versus paid, when you need Spectrum or Magic Transit, and how to configure the controls so they work during a real attack rather than after.
What is the difference between L3, L4, and L7 DDoS attacks?
Three layers, three different attack patterns:
Layer 3 (network). Volumetric floods at the IP layer. UDP reflection and amplification attacks (DNS, NTP, memcached) are the classic L3 vectors. They aim to saturate your upstream bandwidth so legitimate traffic cannot get through. Measured in Gbps or Tbps.
Layer 4 (transport). SYN floods, ACK floods, RST floods, and connection-state exhaustion attacks. The goal is to overwhelm the server’s connection table or TCP stack. Measured in packets per second (pps).
Layer 7 (application). HTTP and HTTPS floods, slow-loris, cache-bypass attacks, and request-amplification attacks. These look like normal traffic and are designed to consume application resources (CPU, database connections, search-index queries) rather than network bandwidth. Measured in requests per second (rps).
Atomic fact worth banking: 94.4% of web DDoS attacks in 2025 ran under 100,000 requests per second. The headline-grabbing terabit-per-second floods still happen, but the dominant pattern is now smaller, more persistent L7 attacks designed to evade legacy detection thresholds. Defending only against the headline pattern misses the actual threat.
What is free vs paid in Cloudflare DDoS protection?
The Cloudflare DDoS posture across plans:
Free plan
- Unmetered Layer 3 and Layer 4 DDoS protection (yes, even free)
- Standard L7 DDoS protection with automated mitigation
- DDoS managed ruleset enabled by default
- Basic Security Events analytics
Pro plan ($25/month)
- Everything in Free
- Better L7 attack visibility in analytics
- Some additional managed rules
Business plan ($200/month)
- Everything in Pro
- Advanced rate limiting (the right characteristic for credential stuffing)
- Super Bot Fight Mode for bot DDoS
Enterprise (custom)
- Everything in Business
- L7 DDoS sensitivity tuning per hostname
- Custom DDoS rules using the full Rules language
- 24/7 SOC support during incidents
- SLA-backed mitigation guarantees
- Spectrum for non-HTTP TCP/UDP services
- Magic Transit for BGP-routed whole-network protection
The two atomic facts that matter for budget decisions: Layer 3 and 4 DDoS protection is unmetered on the free plan (Cloudflare absorbs the attack on their network at no per-request cost), and Layer 7 DDoS sensitivity tuning per hostname is Enterprise-only. For SMB and most mid-market sites, Business plan is the sweet spot. Enterprise is justified when you need per-hostname tuning, SLA-backed mitigation guarantees, or non-HTTP service protection.
How does Cloudflare auto-mitigate DDoS attacks?
Three mechanisms work together:
Network-layer absorption. Cloudflare’s anycast network announces your IP space from 300+ cities. A DDoS targeted at your origin gets distributed across the entire network and absorbed close to where it originates. The attacker cannot concentrate the flood against a single PoP.
The DDoS managed ruleset. Cloudflare runs a constantly updated ruleset that profiles request patterns against known DDoS signatures. When an attack matches, the ruleset auto-mitigates by dropping the offending requests at the edge. This is the layer that catches L7 floods automatically without operator action.
Adaptive challenge issuance. When request volume from a source spikes anomalously, Cloudflare issues challenges (JavaScript or managed) that real browsers solve and bots cannot. This degrades the attack without blocking legitimate users.
The combination is what makes attacks under 100K rps mostly invisible to operators. The auto-mitigation kicks in, drops the malicious traffic at the edge, and the application never notices. The Cloudflare DDoS protection product documentation covers the architecture in detail.
What was the Saudi DDoS threat landscape in 2025?
Three numbers worth knowing:
- Saudi Arabia recorded over 270,000 DDoS attacks in H1 2025, the highest in the MENA region.
- MENA application-layer DDoS attacks surged 236% year-on-year in Q2 2025, the highest on record.
- A single campaign against Saudi targets peaked at 1 Tbps using 24 different attack vectors simultaneously against telecom, energy, and cloud infrastructure.
The shift from large volumetric attacks to smaller persistent L7 attacks is the dominant 2025 trend. Defending only against the headline pattern misses most of the actual traffic. For Saudi-specific deployment patterns, see our guide on Cloudflare for Saudi Arabia.
How do I configure L7 DDoS sensitivity per hostname?
This requires Enterprise. On Pro and Business, sensitivity is set globally per zone. On Enterprise, you can set different L7 DDoS sensitivity for different hostnames within the same zone.
The pattern that works:
- Customer-facing booking, payment, and login hostnames: sensitivity HIGH. False positives are acceptable because customers can retry; the cost of letting an L7 attack through is conversion loss and SMS-cost abuse.
- Public marketing site: sensitivity MEDIUM. Lower false-positive tolerance because traffic patterns are more varied.
- Internal hostnames (admin, ops, monitoring): sensitivity LOW or OFF. These are IP-restricted anyway; the DDoS sensitivity adds little.
- API endpoints serving partners: sensitivity MEDIUM with a custom rule allow-listing partner ASNs.
The configuration is in the Cloudflare dashboard under Security > DDoS > HTTP DDoS attack protection. Each ruleset can be overridden per hostname with different actions (log, block, challenge) and different sensitivities. The Cloudflare HTTP DDoS managed rules docs cover the override syntax.
Do I need Spectrum or Magic Transit?
Most web platforms do not. The decision tree:
- Are all your services HTTP or HTTPS? Then the standard Cloudflare proxy on Pro, Business, or Enterprise is enough. No Spectrum or Magic Transit needed.
- Do you run non-HTTP services that need DDoS protection? (Game servers, FTP, SSH, custom TCP protocols.) Then Spectrum on Enterprise.
- Do you need to protect your entire network at the IP level? (On-premise data centre, cloud VPC with non-HTTP services.) Then Magic Transit.
Spectrum is a per-service edge proxy for non-HTTP protocols. It extends Cloudflare’s DDoS protection to arbitrary TCP and UDP ports. Common use cases: game servers, MQTT, custom binary protocols.
Magic Transit is a different product. It uses BGP to route your entire IP space through Cloudflare’s network, providing DDoS protection at the network layer before traffic reaches your data centre. You announce your prefixes via Cloudflare, they advertise them on the internet, and all traffic to those IPs gets DDoS-scrubbed at the edge before being delivered to you via GRE or Cloudflare Network Interconnect.
Magic Transit pricing starts in the enterprise range and includes a commitment. For most web platforms it is overkill. For telecoms, ISPs, gaming companies, and on-premise data centres with non-HTTP services, it can be the right architecture.
How do I configure DDoS protection plus Rate Limiting plus WAF together?
These three layers solve overlapping problems and need to be ordered correctly:
- Layer 7 DDoS catches volumetric application-layer attacks that match known DDoS patterns. Automatic, low-tune.
- WAF custom rules catch pattern-based attacks (specific signatures, business-logic abuse) that DDoS protection does not see as a “DDoS” because the volume is moderate.
- Rate Limiting catches abuse that looks like normal traffic individually but breaches a request budget over time (credential stuffing, OTP abuse, coupon enumeration).
Order in the Cloudflare evaluation pipeline:
- Skip rules (verified bots, payment webhook IPs)
- WAF custom rules (specific signatures, geo/IP blocks)
- Rate Limiting (request budgets)
- Managed Rulesets (OWASP, Cloudflare Managed, DDoS managed)
- Bot management (Super Bot Fight Mode or Enterprise Bot Management)
The full deployment order is covered in our Cloudflare WAF setup guide for booking and payment platforms. The WAF custom-rule library is in our Cloudflare WAF custom rules cookbook. The rate-limiting thresholds are in our Cloudflare Rate Limiting production patterns guide.
What does an L7 attack actually look like in production?
On the Saudi mobility platform we documented, six Layer 7 DDoS attempts hit the booking search endpoint in the first 90 days after Cloudflare onboarding. The largest peaked at 84,000 requests per second from a botnet distributed across many ASNs. The pattern was consistent: ramp from 5,000 rps to peak over 30-90 seconds, sustain for 5-15 minutes, then taper.
In every case Cloudflare’s L7 DDoS managed ruleset auto-mitigated within seconds. No paging, no manual response, no customer-visible impact on the booking flow. The security team reviewed the events the next morning rather than during the incident.
This is the operational outcome you should expect from a properly configured Cloudflare deployment. Auto-mitigation handles the routine attacks. Operator attention is reserved for the rare attack that punches through, which is what an Enterprise plan SOC retainer or your own on-call team is for.
Common mistakes to avoid
Leaving the origin IP reachable from the public internet. Cloudflare protects the edge, not the origin. If an attacker finds your origin IP from historical DNS records or leaked configuration, they can bypass the entire edge and DDoS your origin directly. Lock the origin firewall to Cloudflare’s published IP ranges after the proxy is enabled.
Assuming Free or Pro plans have no DDoS protection. They have unmetered L3/L4 and basic L7 by default. The upgrade path is for advanced configuration, not for getting any protection at all.
Setting L7 DDoS sensitivity to LOW because you do not want false positives. Sensitivity LOW means the auto-mitigation only fires on extreme attacks. Sensitivity HIGH catches more, with a small false-positive rate that real users can usually retry through. For customer-facing critical paths, HIGH.
Skipping the runbook for the rare attack that gets through. Auto-mitigation catches most attacks but not all. Have a documented runbook: who watches the dashboards, who has Cloudflare console access during an incident, when to engage Cloudflare’s SOC if you have Enterprise, when to roll out emergency rules.
Buying Magic Transit for an HTTP-only site. Magic Transit is a network-level product. If all your traffic is HTTP/HTTPS through Cloudflare’s proxy, the standard plan covers you. Magic Transit is for non-HTTP services or whole-network protection.
Forgetting to log push the DDoS events. Cloudflare Security Events shows the last 24 hours by default. For post-incident analysis and trend tracking, push DDoS event logs to S3, BigQuery, or your SIEM via Logpush.
Related production guides
For the WAF custom rules that catch pattern-based attacks alongside DDoS protection, see our Cloudflare WAF custom rules cookbook. For the rate-limiting layer that catches abuse-by-volume, our Cloudflare Rate Limiting production patterns guide covers per-endpoint thresholds. For the full deployment order, see our Cloudflare WAF setup guide for booking and payment platforms. For an end-to-end production deployment that absorbed six L7 DDoS attempts without operator intervention, the Saudi mobility platform case study shows the configuration running under real attack traffic.
Need DDoS Protection Configured for Your Production Site?
Cloudflare DDoS protection is included with every plan, but the configuration that actually holds up during an attack (per-hostname sensitivity, the runbook for the rare attack that gets through, the coordination with WAF and Rate Limiting, the origin firewall lock-down) is the work that distinguishes a deployment that survives peak traffic from one that goes down at the worst possible moment.
Tasrie IT Services provides comprehensive Cloudflare managed services to help you:
- Configure L3, L4, and L7 DDoS protection with sensitivity tuned per hostname for your real traffic patterns
- Decide on Spectrum or Magic Transit based on whether your services are HTTP-only or include non-HTTP protocols and on-premise infrastructure
- Hand over an incident runbook so your team can respond to the rare attack that needs human attention without losing minutes to dashboard navigation
We have configured Cloudflare DDoS protection for booking, e-commerce, fintech, and government workloads across Saudi Arabia, the UAE, and the UK, including the deployments documented in our cybersecurity services practice.