For years, the standard answer to a large-scale DDoS attack has been straightforward: send the traffic to the cloud, scrub out the malicious packets, and return the clean traffic to the customer. For many organizations, this remains the most practical approach. A cloud mitigation provider can bring significantly more capacity to an attack than most companies could ever build into their own networks.
But there is another question that infrastructure teams are increasingly asking: What if we don’t want all of our traffic to leave our network in the first place? This matters to hosting providers, ISPs, telecom operators, banks, and other organizations where traffic control, latency, data handling, and infrastructure availability are critical. It is one reason we are seeing renewed interest in on-premises DDoS protection.
I don’t see this as a choice between cloud and on-premises. The more useful question is: where should a particular type of traffic or attack be filtered?
The Biggest Limitation of On-Premises Protection Is the Network Itself
There is an obvious objection to local DDoS mitigation: what happens when an attack is large enough to saturate the internet connection before the traffic reaches the filtering system?
The objection is valid. If a company has a 100 Gbps connection and an attacker sends 500 Gbps of traffic toward it, no software running inside that network can somehow restore the missing 400 Gbps of capacity. The traffic has already consumed the link.
This is one of the fundamental differences between on-premises and cloud mitigation. A cloud provider can absorb an attack upstream, using a distributed scrubbing network with significantly greater capacity than the customer’s own connection. An on-premises system, by contrast, has to process the traffic that actually reaches the customer’s infrastructure.
That makes capacity planning critical. Before deploying local DDoS protection, organizations need to understand not only normal and peak application traffic, but also the capacity of their network links, interfaces, servers, and packet-processing infrastructure. So I would not ask whether cloud or on-premises protection is “better.” The more useful question is: Where is the most effective point to stop the attack?
The Earlier a Packet Is Filtered, the Less It Costs to Process
Once DDoS mitigation moves inside the network, packet-processing performance becomes particularly important. An attack does not only put pressure on an application. Traffic may pass through network interfaces, routing infrastructure, firewalls, load balancers, and operating-system networking stacks before it reaches the service being protected. If every malicious packet consumes resources at multiple stages, those resources can disappear quickly.
This is why high-performance packet processing matters in local DDoS mitigation. One approach is DPDK, or the Data Plane Development Kit, which allows applications to process packets at high speed while reducing some of the overhead associated with traditional operating-system network stacks.
But packet-processing speed alone does not make a DDoS protection system effective. A system can process packets extremely quickly and still fail to identify an attack. The real challenge is combining performance with traffic classification: identifying anomalous behavior, recognizing attack patterns, and applying filtering decisions quickly enough to keep legitimate traffic moving.
In other words, effective DDoS mitigation sits at the intersection of how fast you can process traffic and how accurately you can decide what to do with it.
Not Every Attack Requires Application-Layer Inspection
Another reason local filtering can make sense is that many DDoS attacks do not require deep inspection of application traffic. At Layers 3–5, organizations can mitigate a wide range of network and transport-layer attacks, including volumetric floods, TCP attacks, reflection and amplification attacks, DNS attacks, and attacks targeting gaming and other specialized protocols.
In these cases, the protection system does not necessarily need to understand the application’s business logic. It needs to recognize abnormal network behavior and stop it as close to the network edge as possible. This can be particularly important for infrastructure providers: a hosting company or telecom operator may have hundreds or thousands of services behind the same network infrastructure, meaning a problem at the network layer can affect many customers at once.
The closer the mitigation point is to the traffic ingress, the more resources can potentially be saved further downstream.
Encryption Changes the DDoS Equation
Encrypted traffic creates another challenge. With traditional HTTP traffic, security systems can inspect the contents of requests. With TLS, that visibility disappears unless the traffic is decrypted. It is tempting to conclude that effective DDoS protection therefore requires decrypting traffic, but that is not necessarily the case.
Many network attacks can be identified from the characteristics of connections and packets rather than their application payload. Packet rates, connection behavior, protocol characteristics, and other traffic patterns can provide enough information to identify anomalies without accessing the underlying user data.
This becomes increasingly relevant with QUIC. QUIC was designed around encrypted transport, which means that some of the techniques traditionally used to inspect TCP traffic cannot simply be carried over. Modern DDoS protection therefore needs to operate effectively on encrypted traffic without making decryption a prerequisite for every mitigation decision. That is both a technical and an architectural consideration.
Where On-Premises Ends and the Cloud Begins
Every local DDoS protection system has a hard boundary: the amount of traffic the network can physically receive. Imagine a local mitigation system capable of processing several hundred gigabits per second. If an attack exceeds the capacity of the internet connection, some of that traffic will never reach the mitigation point.
This is where cloud mitigation becomes complementary rather than competitive. A practical architecture can use local filtering for attacks that can be handled within the customer’s network, while a cloud scrubbing layer absorbs traffic when an attack exceeds the available capacity.
The same principle can be applied to different layers of the attack. For example, network and transport-layer attacks can be filtered locally, while application-layer attacks can be handled by a cloud platform. Extremely large attacks can also be diverted upstream before they consume the customer’s connectivity.
This creates a multi-layered architecture in which the location of mitigation depends on the characteristics and scale of the attack. That flexibility is often more useful than trying to force every attack through the same protection layer.
Control Over Traffic Is Becoming a Security Requirement
Performance is only part of the story. For some organizations, control over traffic processing is itself a security or compliance requirement. A bank may want to minimize the number of external components involved in processing sensitive traffic. A telecom operator may need predictable latency. An organization operating an isolated network may not be able to use an external mitigation service at all. Data residency can also influence architecture decisions.
In these environments, “send everything to the cloud” is not necessarily the most practical answer. On-premises protection gives infrastructure teams direct control over where traffic is inspected and how mitigation is implemented. It can also make DDoS protection easier to integrate into environments where connectivity to an external service is restricted.
This changes what organizations expect from a DDoS protection product. It needs to fit into the existing network architecture, run on standard infrastructure, scale with the environment, and avoid becoming another single point of failure. That is one reason we chose a software-based approach for StormWall Appliance. Organizations can deploy the solution on servers they already own instead of building a separate hardware security stack.
The Architecture Matters More Than the Deployment Model
I came to DDoS protection from the backup and cloud world, where nobody asks whether local or cloud is “better.” You keep a local copy for fast recovery and control, and a cloud copy for scale and resilience. Looking at DDoS protection with that lens, the cloud-versus-on-premises question looks very familiar. Attacks have become larger and more sophisticated. Multi-vector campaigns are increasingly common. Encrypted protocols have changed what defenders can see. At the same time, infrastructure has become more distributed, and organizations have become more conscious of where their data and traffic are processed.
Against that background, the idea that DDoS protection must live either entirely in the cloud or entirely inside the customer’s network is too simplistic. A more practical architecture can have several layers.
Local mitigation can handle network-level attacks close to the infrastructure and keep traffic within the organization’s perimeter. Cloud mitigation can provide additional capacity when an attack exceeds what the local network can absorb. Application-layer protection can address attacks that cannot be reliably identified from network characteristics alone.
The value comes from combining these capabilities rather than treating them as mutually exclusive.
On-Premises Is Not a Return to the Past
I would not describe the renewed interest in on-premises DDoS protection as a return to an old model. It is better understood as a response to increasingly complex infrastructure.
Cloud mitigation remains one of the most effective ways to deal with attacks that are simply too large for an organization’s network. But more organizations also want control over what happens to their traffic before it reaches an external security infrastructure.
The future of DDoS protection, in my view, is therefore not about choosing between cloud and on-premises. It is about having the flexibility to decide where traffic should be filtered, which attacks should be stopped locally, when additional cloud capacity is needed, and how much control should remain inside the organization’s own infrastructure.
That is the thinking behind StormWall Appliance. We developed it not as a replacement for cloud DDoS protection, but as another option for organizations that need their own point of control over traffic filtering.
The fundamental objective has not changed: keep infrastructure available when someone is trying to take it offline. What is changing is where — and how — organizations choose to defend it.
