L7 vs L3/L4: Can a CDN Stop All Attacks?
Foreword
In the last article, we looked at how to protect your origin server when using a CDN, and ended with a question: can a CDN stop all attacks? This article answers it. We will compare L7 request floods with L3/L4 DDoS attacks, see why they hurt a server in completely different ways, and find out where a CDN helps — and where it cannot.
What L3, L4 and L7 Actually Mean
These numbers come from the network model. L3 works with IP packets and routing. L4 works with TCP and UDP connections and ports. L7 is where HTTP lives — the layer of actual page requests and API calls.
Your website runs at L7, but the plumbing below it can be broken without a single HTTP request being sent. That is the core of this comparison.
How L3/L4 Attacks Work
L3/L4 attacks aim at the plumbing. A volumetric flood pushes huge amounts of traffic — often amplified through public servers — until your bandwidth is saturated. A SYN flood opens thousands of half-open TCP connections until the connection table is full.
In both cases your server never gets to do real work. The traffic does not even look like visitors. It is noise aimed at the network itself.
How L7 Attacks Work
L7 attacks look like real visitors. An HTTP flood sends request after request to expensive pages: search boxes, login forms, database-heavy endpoints. Bandwidth stays modest, but every request costs CPU time and database queries.
This is the pattern behind CC attacks — cheap for the attacker, expensive for the server.
The Key Differences
So, Can a CDN Stop All Attacks?
Here is the honest answer: a CDN covers a lot, but not everything.
At L7, a CDN is your best friend. Static requests die at the cache, and WAF rules plus rate limits filter most of the rest before they reach your origin. For example, the CDN of the well-known cloud service provider VMRack comes with WAF, CC and DDoS protection strategies, and the rules can be self-configured, so an HTTP flood loses most of its power before it touches your server.
At L3/L4, things change. If the flood hits the CDN’s own network, the provider absorbs it — that is what their network is built for. But if attackers have found your origin IP, they can send the flood straight to your hosting provider, and no CDN can filter traffic that never passes through it. That is why the previous article matters: hide the origin, and whitelist only CDN ranges.
One more gap deserves attention: services you never proxied through the CDN — mail, game servers, APIs exposed directly — sit outside its reach entirely.
When an Attack Arrives: Triage First
Check two things before acting. If bandwidth is pegged and connections are maxed, you are looking at L3/L4 — contact your provider and ask for network-level filtering. Your server cannot win that fight alone.
If CPU is high and logs are full of dynamic requests, it is L7 — enable WAF and rate limiting at your CDN, and tighten origin rules as we discussed last time.
Conclusion
L7 and L3/L4 attacks are different animals: one exhausts your application, the other exhausts your network. A CDN stops most L7 floods and absorbs edge-level volume, but it cannot protect an origin that is exposed below the HTTP layer.
Hide your origin, keep defenses at both layers, and the question becomes practical: a CDN cannot stop all attacks — but it stops enough, when the rest is handled.
Thank you very much for reading to the end!
Related Reading
