Why I Moved Part of My Traffic Off a Cloud WAF In 2026

Source: Dev.to

The Default Architecture Most of Us Use

If you’re running a typical web service today, the architecture probably looks like this:

Internet
   │
   ▼
Cloud WAF / CDN
   │
   ▼
Origin server
   │
   ▼
Application

Benefits

• Your origin IP is hidden
• Large‑scale DDoS protection
• Global caching
• Automatic WAF rules

Cloud WAFs are also easy to deploy because traffic simply passes through a proxy network—often it’s literally just a DNS change. For public websites and APIs, it’s hard to beat that convenience.

After running several services behind this architecture, however, I started encountering edge cases where the model wasn’t ideal.

Problem 1 – Not All Services Should Sit Behind a CDN

The first issue appeared when we started handling non‑traditional web traffic:

• internal dashboards exposed via VPN
• developer tools
• webhook endpoints
• large file uploads
• internal APIs

These workloads behave differently from a public website. They often involve:

• authenticated clients
• large request bodies
• long‑lived connections
• unusual headers or protocols

A CDN‑optimized WAF can become an awkward fit. For example, many WAF engines inspect request bodies only up to a certain size (depending on the plan). That’s fine for normal web traffic, but if your application frequently handles large payloads, you may find the security layer doing partial inspection or bypassing certain checks.

Problem 2 – The “Black Box” Problem

Cloud security platforms are powerful—but they are also abstracted. You usually get:

• dashboards
• rule toggles
• aggregated logs

…but you rarely see the raw request behavior in detail. When debugging attack traffic I often needed answers to questions like:

• What exact payload triggered the rule?
• What did the request body look?
• Which scanner generated it?
• What happened before the request was blocked?

Cloud dashboards typically show the result of the decision, not the full context. That abstraction is intentional—it keeps things simple—but sometimes you want more control.

Problem 3 – The Cost of Routing Everything Through One Network

When everything goes through a cloud WAF, the following components become tightly coupled:

• DNS
• traffic routing
• security
• caching
• (sometimes) load balancing

Most of the time that’s fine, but occasionally you need flexibility such as:

• exposing a service temporarily
• routing certain traffic directly
• running private endpoints
• testing infrastructure without the proxy layer

When a single edge network owns all of those pieces, those experiments become harder.

The Hybrid Approach I Eventually Settled On

Instead of removing the cloud WAF entirely, I ended up with a split architecture:

Internet ─────► Cloud WAF / CDN ─────► Public Web Apps
                     │
                     ▼
               Internal Gateway
                     │
                     ▼
               Self‑Hosted WAF Layer
                     │
                     ▼
                    Services

Public traffic still uses the edge network, while some services bypass it and go through a local security layer. This approach preserves the benefits of the cloud edge—global performance, massive DDoS protection, easy caching—while giving us more control for specialized services.

Where Self‑Hosted WAFs Still Shine

When I started experimenting with local filtering layers again, I remembered why they were popular before cloud WAFs took over. A self‑hosted WAF sits directly in your infrastructure:

Internet
   │
   ▼
Reverse Proxy + WAF
   │
   ▼
Application

That placement gives you things cloud platforms can’t always provide:

Full Request Visibility

• Raw payloads
• Headers
• Request bodies
• Complete traffic logs

This makes debugging attacks significantly easier.

Fine‑Grained Control

Because it runs in your environment, you can implement rules such as:

• Endpoint‑specific policies
• Per‑service rate limits
• Behavior rules based on internal logic

Cloud WAFs support custom rules, but they usually operate within platform constraints. Running your own layer removes those limits.

Local Traffic Filtering

Many attacks never need to hit your application. Common probes include:

GET /.env
GET /.git/config
GET /wp-login.php
GET /phpmyadmin

A local WAF can block these instantly without involving upstream services.

What I Look For in a Self‑Hosted WAF

After trying a few options, I realized the most useful features for small teams are actually pretty simple:

• Bot challenges
• Request filtering
• Rate limiting
• Good traffic visibility

You don’t necessarily need an enterprise‑grade security appliance; you just need something that can sit in front of your services and reduce noise.

Recently I’ve been experimenting with SafeLine WAF, which packages these features into a relatively easy‑to‑run self‑hosted system. The interesting part isn’t that it replaces cloud WAFs—it’s that it fits nicely into the hybrid model described above, acting as a security layer for traffic that doesn’t benefit from going through a CDN.

If you’re curious, check out their website.

Safepoint Cloudline is here:

When You Should Absolutely Stay on a Cloud WAF

To be clear, cloud WAFs are still the best choice for many situations.

If your application is:

• a public website
• a global SaaS product
• heavily cacheable
• latency‑sensitive worldwide

then the edge‑network advantages are enormous. The global scale of providers like Cloudflare is impossible to replicate locally.

Final Thoughts

The biggest lesson from running production services is that security architecture rarely stays static. What works for a small web app might not work for:

• internal tools
• APIs
• large uploads
• specialized infrastructure

Cloud WAFs solved many problems for developers, but they also introduced a new pattern: everything goes through the edge network.

• Sometimes that’s perfect.
• Sometimes it isn’t.

The solution, at least for me, wasn’t choosing one model over the other. It was simply using both where they make sense.