We build Flowtriq as a SaaS product with a lightweight agent, so our position on this topic is obvious. This post explains why DDoS protection has been slow to move to the cloud, what the trade-offs are, and where the agent-based SaaS model works well and where it does not.
Every other infrastructure tool moved to the cloud
Think about the infrastructure tools your team uses daily. Monitoring: Datadog, New Relic, Grafana Cloud. Logging: Splunk Cloud, Elastic Cloud, Papertrail. Error tracking: Sentry, Bugsnag. APM: Datadog, Dynatrace. Security: Crowdstrike, SentinelOne. Incident management: PagerDuty, OpsGenie.
All of these categories followed the same trajectory: they started as on-prem software (or hardware), moved to SaaS, and the SaaS version won. The reasons are consistent: lower upfront cost, faster deployment, automatic updates, no hardware maintenance, and predictable operational expenditure.
DDoS protection is an outlier. The dominant products in 2026 are still hardware appliances (Arbor, Radware, Corero, FortiDDoS) or self-hosted software that requires a dedicated server (most open-source detection tools). The SaaS options that exist are mostly cloud scrubbing services (Cloudflare, Akamai), which are a different product category: they proxy your traffic through their network rather than monitoring your infrastructure.
The gap is notable. There is no "Datadog for DDoS detection" in the way that operators expect from a modern SaaS tool: install a lightweight agent, get a web dashboard, start seeing data immediately. That is what the market needs, and what it is slowly starting to get.
Why DDoS has been slow to move
The hardware assumption
DDoS protection was born as a hardware category. The original problem was: inspect every packet crossing your network edge at line rate and filter out the bad ones. That required specialized hardware, custom ASICs, FPGAs, or high-performance NICs. Software running on commodity hardware could not match the packet-per-second performance of dedicated silicon.
This assumption was valid in the 2000s and into the early 2010s. Commodity server hardware could not process 10 Gbps of traffic at line rate. Custom hardware could. The gap between what software could do and what the network demanded justified the appliance model.
In 2026, that gap has narrowed dramatically. Modern Linux kernels with XDP (eXpress Data Path) can process tens of millions of packets per second on commodity hardware. eBPF allows custom packet processing logic in the kernel without kernel module development. DPDK (Data Plane Development Kit) pushes packet processing even further by bypassing the kernel entirely. The performance argument for dedicated hardware is weaker than ever for most use cases.
The distinction matters: if your goal is to inspect and scrub 400 Gbps of traffic inline at a carrier peering point, you still need specialized hardware. If your goal is to detect attacks on a server handling 10 Gbps and apply local mitigation rules, commodity hardware running Linux with XDP handles it comfortably.
The latency sensitivity argument
Opponents of SaaS-based DDoS protection argue that detection must happen locally because sending traffic telemetry to a cloud backend introduces latency. If detection happens in the cloud, the time from attack onset to detection includes the network round-trip time between the server and the cloud backend.
This argument has merit for some architectures, but less than it appears. The critical question is not where detection happens, but how fast the response is end-to-end. A local detection engine that detects in 1 second but requires 8 minutes of manual mitigation has a worse total response time than a cloud-based detector that detects in 3 seconds and triggers automated mitigation within 1 second of detection.
Moreover, the agent-based model (where the agent runs on the server and reports to a cloud backend) combines local and cloud processing. The agent can apply local mitigation immediately (kernel-level firewalling) while simultaneously reporting to the cloud backend for dashboard updates, alerting, and BGP-based mitigation. The detection and initial mitigation happen locally, with zero cloud latency. The cloud backend adds visibility and coordination, not latency.
The data residency concern
Some operators, particularly in Europe and in regulated industries, have concerns about sending network traffic data to a cloud service. Traffic metadata, packet samples, and attack data may be subject to data residency requirements. If the cloud backend is in a different jurisdiction, the operator may need to verify compliance with GDPR, NIS2, or industry-specific regulations.
This is a legitimate concern, but it is the same concern that applies to Datadog, Splunk Cloud, and every other SaaS infrastructure tool. The industry has largely resolved it through regional data storage, data processing agreements, and SOC 2 compliance. DDoS SaaS products face the same requirements and can meet them the same way.
The "decouple hardware and software" request
One of the most common requests from operators evaluating DDoS tools is: "I want the detection and mitigation intelligence of an enterprise tool, but I do not want to buy dedicated hardware to run it."
"We want to decouple the detection software from the hardware. We want detection running on our existing infrastructure, not on a separate appliance that we have to rack, power, and maintain."
This request reflects the broader infrastructure trend of decoupling compute from hardware. Virtualization decoupled workloads from physical servers. Containers decoupled applications from operating systems. SaaS decoupled software from infrastructure entirely. DDoS detection is one of the last categories where the software is still tied to specific hardware.
The agent-based model is the answer to this request. A lightweight software agent runs on the operator's existing servers, performing detection and local mitigation. The cloud backend provides the dashboard, alerting, historical data, and coordination layer. No additional hardware required.
Software agents vs. hardware appliances
The comparison is not abstract. Here are the specific trade-offs:
Deployment time. An agent installs in minutes with a single command. A hardware appliance requires procurement (2-6 weeks), physical installation, network integration, and configuration (2-4 weeks). Total deployment: minutes vs. months.
Scaling. Adding an agent to a new server means running an install command. Adding capacity to an appliance means buying a bigger appliance or adding another unit. Agent scaling is linear and immediate. Appliance scaling is stepped and requires procurement.
Updates. Agent updates deploy automatically or with a single command across all nodes. Appliance updates require firmware upgrades that are tested, scheduled, and applied during maintenance windows. Agents get new features continuously. Appliances get new features annually.
Visibility granularity. Agents see traffic at the server level. They know which process owns which connection, which service is targeted, and what the per-server baseline is. Appliances see traffic at the network edge. They know aggregate flow data but not per-server details unless the servers export telemetry to the appliance.
Failure modes. An agent that fails affects one server. An appliance that fails affects the entire network (unless deployed in HA pairs, which doubles the hardware cost). Agent architecture has a naturally distributed failure domain. Appliance architecture has a centralized failure domain.
Performance ceiling. A dedicated ASIC can process packets faster than a software agent on commodity hardware. For inline scrubbing at 100 Gbps+, appliances still have a performance advantage. For detection and local mitigation on individual servers handling 1-40 Gbps, the performance difference is not meaningful.
Cloud-native DDoS detection. No hardware required.
Flowtriq's agent runs on your existing Linux servers. The cloud backend provides the dashboard, alerting, and coordination. Install in 5 minutes, start detecting immediately.
Start Free Trial →What the SaaS model enables
Beyond the operational advantages, the SaaS model enables capabilities that are difficult or impossible with appliance-based architectures:
Cross-network intelligence. A SaaS platform with agents across multiple customer networks can detect attack trends before they hit individual operators. If a new attack vector is seen across several networks simultaneously, the platform can push updated detection signatures to all agents in real time. Appliances operate in isolation; they see only the traffic on their local network.
Continuous improvement. Detection algorithms, classification models, and mitigation strategies improve continuously in the cloud backend. Every agent benefits from improvements without any action from the operator. Appliances require firmware updates that operators may delay or skip.
Multi-site coordination. Operators with infrastructure in multiple data centers or regions need visibility across all sites. A SaaS dashboard provides this naturally because all agents report to the same backend. With appliances, multi-site visibility requires a separate management platform or manual correlation between isolated deployments.
Elastic storage. Attack forensic data (PCAPs, traffic timelines, classification records) is stored in the cloud backend with elastic capacity. There is no local disk to fill up, no retention policies driven by hardware constraints. Storage grows with usage, not with hardware purchases.
When appliances still make sense
We would be dishonest if we claimed appliances are obsolete. There are specific scenarios where dedicated hardware is the right choice:
Inline scrubbing at carrier scale. If you need to inspect and filter 100 Gbps+ of traffic inline at a carrier peering point with sub-millisecond latency, dedicated hardware with custom ASICs is still the answer. Software on commodity servers cannot match this performance at this scale.
Air-gapped environments. Some networks are not connected to the internet by policy (military, certain government, some financial). A SaaS tool that requires a cloud backend is not an option. An on-premise appliance is.
Regulatory hard requirements. If your compliance framework specifically mandates on-premise security hardware (not common, but it exists in some sectors), a SaaS agent may not satisfy the requirement regardless of its technical capabilities.
For everyone else, and that includes the vast majority of hosting providers, ISPs, data center operators, and enterprises, the question is whether the appliance model's overhead (hardware cost, deployment time, maintenance burden, expertise requirement) is justified when software-based alternatives provide comparable detection and faster deployment at a fraction of the cost.
The rest of infrastructure answered that question years ago. DDoS protection is catching up.