Local Detection or Cloud-Dependent Detection: What Changes

Every DDoS product does two separable things: it works out that traffic is hostile, and it does something about it. Marketing treats these as one capability. Architecture does not, and the seam between them is where products differ most and describe themselves least.

The question is not whether a product uses cloud intelligence. Nearly all of them do, sensibly. The question is which functions stop when it cannot be reached.

At a glance

Appliance	Architecture	Where the decision is computed	What a lost external path costs
Fully local	On the device, from its own observations	Nothing in detection; updates and support stop
Local with external enrichment	On the device, informed by a downloaded feed	Feed ages; detection continues on local evidence
Split decision	Externally, enforced locally	Classification stops; enforcement continues on last-known policy
Fully external	In the provider's network, where traffic is also cleaned	Traffic is not being cleaned at all

None of the four is wrong. They fail differently, and a buyer's job is to know which failure the estate can survive rather than to prefer one architecture in the abstract.

Four architectures, not two

The industry frames this as local versus cloud. There are four positions, and most confusion comes from products in the middle two describing themselves as if they were in the first.

Fully local. The device observes your traffic, builds its own picture of normal, and decides. Nothing outside the estate participates in a drop decision. Software updates and support still require a supplier, as they do for every product ever sold, but no live service sits in the decision path.

Local with external enrichment. The decision is computed on the device, using local observation plus data downloaded periodically — reputation lists, attack signatures, geographic databases. If the download fails, the data ages. Detection does not stop; it becomes gradually less current.

Split decision. Analysis happens externally — telemetry is exported to a service that determines what is hostile — while enforcement happens on local hardware. Lose the path and enforcement continues against whatever policy was last installed, but nothing new is classified. This architecture is common and is frequently described using the same language as the first two.

Fully external. Traffic is diverted to a provider’s network, where it is both classified and cleaned. Losing the path does not degrade detection; it means traffic is not being protected at all, and this is well understood by everyone who buys it.

What actually changes

Time to a decision

Local classification decides in the time it takes to process a packet. Split-decision architectures decide at the speed of a round trip plus analysis, which is fine for a slow-building volumetric attack and poor for a burst that is over before the loop closes. Pulse attacks — short, repeated bursts — exist partly because they exploit this gap.

Where the external path is long, this compounds. An estate whose international transit is thin inherits that latency in its defence, which is the specific reason the thin-transit case treats decision locality as an availability question rather than a preference.

Behaviour when the path fails

This is the property that matters most and is demonstrated least, because a demonstration happens on a working network.

The failure that concerns you is rarely the provider going down. It is your own transit degrading — during an attack, which is exactly when the dependency is needed. An architecture whose classification requires a healthy path to the outside has that requirement satisfied least reliably at the moment it matters most.

Novel vectors

Here the advantage genuinely runs the other way. A device that has only ever seen your traffic learns your normal well and knows nothing about an attack pattern first seen elsewhere last week. A shared view across many networks sees it and can distribute the knowledge.

For a well-known vector this is worth little; SYN floods have not changed and every product handles them. For a novel application-layer pattern it can be worth a great deal. A buyer who dismisses external intelligence is discarding something real.

What leaves the network

Split-decision and fully external architectures require traffic characteristics to travel to the analysing party. What travels varies enormously — flow records summarising volumes are a different proposition from full packet payloads — and the difference is rarely stated without being asked.

Where a data-residency regime applies, this converts an architectural choice into a compliance question, which is the ground the GCC residency analysis works through in detail. Under DORA the same dependency appears again as third-party concentration risk: a defence that requires an external service has added that service to the list of things your availability depends on.

The questions that separate them

Ask about functions, not about products. Nearly every product answers a whole-product question in whichever way is most favourable, and every one of them can do so honestly, because most are mixtures.

1. Which specific detection functions require reachability to a service you operate?
2. If that reachability is lost, which continue unchanged, which degrade, and which stop?
3. Is a licence or entitlement check in the decision path, and what is its failure mode?
4. What data leaves the estate for classification, in what form, to which jurisdiction, and with what retention?
5. How long can the device run disconnected before behaviour changes measurably?

Question 3 catches an architecture that is otherwise local. A device that classifies entirely on its own but stops working when it cannot validate a licence has a cloud dependency in the only place that counts, and this is a genuinely common arrangement that no datasheet describes as a dependency.

Testing it in an afternoon

The measurement is simple enough that there is no excuse for buying this property on trust.

Run a baseline: a representative attack against a representative service, recording drop rate, legitimate-traffic survival and time to mitigation. Then sever the device’s path to the manufacturer — at the firewall, not by unplugging its data path — and repeat the identical run.

Three outcomes, and they are unambiguous:

• Unchanged: classification is local. Note how long the test ran; some architectures degrade after a cached entitlement expires rather than immediately, so a long run tells you more than a short one.
• Gradual degradation: enrichment was lost. Establish over what period the data ages into irrelevance.
• Step change: the decision was being made elsewhere. This is not a defect, but it is now a known property with consequences you can plan around.

The full test structure, including how to keep this legal and safe, is in the proof-of-concept methodology and authorised testing.

Choosing on purpose

An estate whose exposure is volumetric saturation should not be optimising for detection locality, because the upstream tier does the work and where it decides is nearly irrelevant. An estate under a residency obligation, or one whose transit is thin, or one that must keep operating through a degraded international path, is choosing something structural and should know which of the four architectures it has bought.

The mixed answer is usually the right one and is treated properly in cloud, on-premises or hybrid: local decisions for what arrives, an upstream tier for what would otherwise fill the circuit, and a clear understanding of which layer is still functioning when the other is not. What matters is that the arrangement was chosen rather than discovered during an incident.