Why an On-Premise DDoS Appliance Lowers TCO Instead of Raising It

When a network architect requests budget for a dedicated on-premise DDoS appliance, the response is predictable: this looks like duplication. The organisation already runs a next-generation firewall, an IPS and a web application firewall, and every one of those datasheets carries a line about flood protection. The question that comes back from the budget review is reasonable — why pay twice to drop bad traffic?

The reflex is rational if security is read as a list of features. If a firewall can drop a malformed packet and a mitigation appliance can drop a malformed packet, the two look interchangeable on a spreadsheet, and the appliance adds rack space, power, support and a purchase order.

That reading misses where the cost actually lives. A security estate is not a list of features; it is a chain of processing, and each control in the chain is sized, licensed and staffed against the volume that reaches it. Change what reaches the first stateful device and you change the inputs to every commercial model behind it. That is the argument of this article, and it ends somewhere finance can act on: an on-premise DDoS appliance is the one line that goes up so that several larger lines can go down.

The stateful paradox

What makes a modern firewall valuable is exactly what a flood attacks.

Stateful inspection means the firewall does not evaluate packets in isolation. When a client opens a connection, the firewall records source, destination, ports, sequence numbers and protocol flags in a session table and allocates memory to hold it. Subsequent packets are matched against that record. This is what allows policy, identity awareness and deep inspection to work at all.

State-exhaustion attacks target that memory. In a SYN flood the attacker sends connection requests that never complete; the firewall dutifully allocates a table entry for each one and waits for an acknowledgement that never comes. The table fills with half-open connections. Once it is full the firewall cannot track new sessions, and it has two options, both bad: drop new legitimate connections, or fail open and stop inspecting.

Vendors mitigate this with SYN cookies, aggressive session ageing and connection-rate limits. These work, and they are not free. Every cryptographic cookie calculated for a malicious packet is CPU that is not available for policy evaluation, signature matching or routing. The defence competes for the same budget as the function.

The distinction that matters for procurement is this: a firewall defending itself is not defending the estate. If the firewall stays up by shedding half of everything arriving, it has survived and your services have not. The device is green in the monitoring dashboard and the business is offline.

A dedicated mitigation appliance behaves differently by design. It is largely stateless, or it holds state in purpose-built hardware intended for exactly this pattern, and it discards anomalous traffic without building a full session record for every flow. Placed in front of the firewall, it absorbs the exhaustion attack before the firewall’s interfaces ever see it. The session table stays populated by real users.

Sizing economics: which peak are you buying for?

That architectural difference turns into money at the moment somebody sizes the perimeter.

Firewalls are specified against peaks — throughput, concurrent sessions, new connections per second — plus headroom for growth across a three-to-five-year lifecycle. The question that decides the purchase order is which peak you are sizing for.

With no mitigation layer in front, the firewall is the first thing attack traffic touches, so the sizing input is no longer your busiest legitimate hour. It is the largest flood you expect to absorb on premise. Because stateful inspection is memory- and CPU-bound, covering that peak usually means stepping up a chassis class rather than adding a little headroom.

The step up is not a single number on a quotation. It carries a larger support contract, more power and rack space, and — because vendors commonly tier software licensing by platform or throughput — a higher price for every subscription running on the box, from URL filtering to malware inspection. You pay the attack peak once in hardware and then again, annually, in licences attached to it.

Put a mitigation appliance at the edge and the input changes. The firewall can be sized against legitimate business traffic, which is a number you can forecast, rather than against adversary behaviour, which is a number you cannot. That often means a smaller chassis class, a lower licence tier, and a refresh driven by business growth rather than by the day the session table filled.

The cost of inspecting traffic you are going to throw away

Beyond chassis class, there is a second and less visible waste: deep inspection spent on traffic that will be discarded.

TLS decryption, IPS signature matching and WAF rule evaluation are the most expensive operations per gigabit anywhere in the stack. Decryption means intercepting the key exchange, negotiating ciphers, decrypting the payload, holding plaintext in memory, handing it to the inspection engines and re-encrypting on the way out. Signature and rule engines must reassemble fragments, normalise streams and evaluate payloads against large rule sets. Every one of those steps is capability you bought, licensed and powered.

When there is nothing shedding junk upstream, that capability is spent on garbage. In an application-layer flood the WAF performs the full cryptographic and analytical sequence on each request, and then discards it. The organisation ends up buying a larger inspection platform and a higher throughput licence in order to keep up with traffic it never wanted to inspect in the first place.

A mitigation appliance drops that traffic on behaviour — request rates, malformed structure, known-hostile sources — before the expensive stages are reached. The inspection capacity you licensed is then spent on traffic that might actually be interesting.

The part nobody prices: event multiplication and the SIEM

The firewall and inspection savings are real. The logging cost is the one that catches organisations by surprise, because it is the only one that scales with attack volume in real time and lands on a contract that was signed years ago.

Most SIEM platforms are priced on consumption — events per second, or ingested volume per day. Every log line counts.

A flood does not just consume bandwidth. It multiplies telemetry. A single malicious packet can produce a log line on every device that sees it: a flow record at the edge router, a deny at the firewall, a signature alert at the IPS, a rule match at the WAF, an error at the load balancer or the application. One packet becomes several billable events, spread across several systems, and a flood of even modest packet rate becomes millions of events in minutes.

The consequences arrive in four forms.

Licence exposure. Consumption-priced platforms bill overage or force a tier upgrade at renewal. The cost of an attack therefore does not end when the attack does; it is crystallised in next year’s contract.

Storage and retention. Compliance obligations rarely distinguish between useful and useless events. Attack telemetry is retained on the same schedule as everything else, on the same storage tiers, for the same number of months.

Performance collapse. Ingestion pipelines congest, indexing falls behind, and search slows to the point where analysts are querying a system that is minutes or hours behind reality. In the worst case the platform sheds events to protect itself.

Detection quality. When the logging platform is saturated, a genuine intrusion is harder to see, and adversaries are aware of this. That is a security consequence rather than a financial one, and it deserves its own treatment rather than a paragraph here — we examine it separately.

An appliance at the edge changes the arithmetic at the source. Devices downstream do not log what never reaches them. There is no deny to record, no signature to alert on, no application error to raise. The event volume that hits the SIEM stays close to its baseline, which is the number the contract was written against.

Operational cost: the hours nobody budgets

The last recurring cost is labour, and it is the one security teams feel most.

When there is no upstream absorber, attacks surface as symptoms across the estate: CPU warnings on the firewall, memory pressure on load balancers, latency alerts from application monitoring. Those alerts page someone.

Every incident then runs the full cycle. Triage has to establish whether this is a fault, a release problem or an attack. Escalation pulls in senior network staff, frequently outside working hours. A bridge is opened. Engineers read packet captures and hand-write access lists or rate limits under time pressure — which is also the situation in which legitimate traffic is most likely to be blocked by mistake.

The direct cost is overtime, callouts and occasionally external support. The larger cost is what those people were not doing: the segmentation project, the identity migration, the threat-hunting programme. Absorbing crude floods by hand is expensive work that produces no durable improvement.

The five-year picture

Presented as a single purchase, the appliance is an increase. Presented across the estate and across a refresh cycle, it changes the direction of several larger lines.

Two of these deserve a caveat rather than a claim. Chassis class and licence tier only fall if your next refresh or renewal is genuinely being driven upward by attack traffic; if you were going to buy that platform anyway for business reasons, the saving does not exist. And the SIEM line only falls if your ingest is actually spiking during incidents — which is measurable, and which some estates will find is not the case.

The honest counterweight

Three limits, stated plainly, because a business case that survives the first hostile question is worth more than one that sounds better in the room.

Physics caps what the appliance can do. It cannot filter traffic that has already saturated the circuit delivering it. If the flood exceeds your access capacity, the circuit fills upstream of the appliance and it is powerless. Everything above that line requires capacity closer to the source — an ISP scrubbing service or a cloud tier — and the on-premise device does not replace it. What it covers is everything below the line, which is where state-exhaustion, application-layer and sub-saturating attacks live.

The cost is certain; the savings are not. Capital cost and support renewal are contractual. The savings depend on attack frequency, on whether your licences are actually consumption-priced, and on whether your next refresh was being driven by attack peaks. Those are assumptions, and they should be labelled as assumptions when you present them.

An organisation that is rarely attacked may not recover it. If there is no history of sustained campaigns and no particular reason to expect them, this is a resilience purchase rather than a cost-reduction one, and it should be argued on those terms — for a small operator, deferring the purchase and building the no-capital tier first is a defensible outcome. Presenting speculative savings to a finance committee is how a security team loses the room for its next request.

Building the case internally

A CFO does not care about session tables. They care about deferred capital, predictable operating cost, and expensive people doing work only expensive people can do. The translation requires four measurements from your own environment — not from a vendor document.

1. Peak session-table utilisation on the firewall during a normal week, and during any minor flood you have records for. The gap is the portion of your firewall sizing that exists because of attack traffic.
2. Events per second at baseline and during an incident, with the ratio between them. Set that against your licensed ceiling and your overage terms.
3. Inspection throughput headroom on the IPS and WAF, and how much of the consumed capacity is spent on traffic that is ultimately dropped.
4. Incident hours booked to DDoS triage over twelve months, including out-of-hours escalation, converted into a labour figure your finance team already recognises.

Then present it as an architecture argument rather than a product one: the estate is currently sized, licensed and staffed for adversary behaviour, and this change moves those inputs back to business behaviour. That framing survives scrutiny because it does not depend on predicting the next attack — only on describing what the current architecture already costs.

For organisations whose deciding constraint is the logging tier rather than the firewall, one detail is worth checking in a proof of concept: whether the appliance’s own logging can be tuned to report incidents rather than packets. An appliance that mitigates a flood silently and reports a single summarised event is doing the SIEM argument properly; one that forwards a log line per dropped packet has moved the problem rather than solved it. Appliances designed to run detection entirely on the device tend to summarise at the edge for the same architectural reason, but this is a question to test rather than to accept.

Framing it correctly

The duplication reflex is understandable and wrong. It compares feature lists and ignores that each control in a security chain is sized, licensed and staffed against whatever reaches it.

Let state-exhaustion traffic and volumetric noise arrive at the stateful perimeter and you have quietly committed to over-provisioning the firewall, spending premium inspection cycles on discards, inflating a consumption-priced logging contract and staffing night shifts for traffic a device should have absorbed. None of those appear as a line item called “DDoS”. They appear as chassis upgrades, licence tiers, storage growth and overtime.

An on-premise mitigation appliance is a single, visible line that removes the upward pressure from several less visible ones. Whether it nets out positive is a question your own measurements answer — but it is the right question, and it is not the one the duplication reflex asks.