DDoS Mitigation Architecture Library

Architecture diagrams in this field are usually drawn by a supplier, which means they are drawn around one product and cannot be compared with each other. The six below are drawn identically — same node shapes, same colours, same left-to-right chain — so that the differences between them are differences in architecture rather than in draughtsmanship.

At a glance

Appliance	Pattern	Decision made	Capacity above your circuit
Single-site enterprise	Locally, on the appliance	Contracted separately, engaged on demand
Multi-site enterprise	Locally, at each site	Distributed by anycast, plus an upstream tier
Carrier or ISP	From flow records, upstream of the customer	Owned; that is the business
Multi-tenant hosting	Per tenant, on shared infrastructure	Owned, and shared between tenants
Regulated or financial	Locally, with evidence retained locally	Contracted, with the dependency documented
Restricted cross-domain	Locally, with no external path at all	Not applicable; the gateway is the boundary

The third column is the honest one. Only two of the six patterns own capacity above their own circuit, and the other four have to contract for it or accept the ceiling.

1. Single-site enterprise

One internet-facing site, one circuit, one inline appliance sized to that circuit. An upstream arrangement exists for volumetric events and is engaged on demand.

What decides it: simplicity. There is one path, one policy, one place to look during an incident.

What it cannot do: survive an attack larger than the circuit without the upstream tier engaging, which takes time. And the appliance is a daily dependency for all traffic, which is the cost of being inline.

The question that tests the fit: how long can the service tolerate degradation while the upstream tier engages? If the answer is seconds, this pattern needs the upstream tier to be always-on rather than on-demand, which changes its economics considerably.

2. Multi-site enterprise

Several sites, anycast or DNS-based distribution in front, an inline tier at each site.

What decides it: an estate whose users are geographically spread, or one that needs a site to be able to fail without taking the service with it.

What it cannot do: anycast distributes load, and it distributes an attack too — which is usually helpful, because each site sees a fraction. It does not help where an attack is targeted at one site’s address specifically, and it complicates any stateful function that assumes a client stays on one node.

The question that tests the fit: does any service in the estate hold session state that breaks if a client is re-routed mid-session? If yes, that service needs a stable path and should be treated as pattern one inside pattern two.

3. Carrier or ISP

Detection from exported flow records across the network, diversion to scrubbing capacity when something is found, clean traffic returned to the subscriber.

What decides it: owning the capacity. A carrier has the one thing a customer cannot buy — room above the customer’s circuit — and the vantage point to see an attack while it is still upstream.

What it cannot do: see packet content. Flow records show volumes, distributions and protocol mixes in excellent detail and application-layer attacks that are normal in volume rarely appear in them at all. This is the structural limit of the pattern, and it is why carriers who sell protection usually pair it with something inline for customers who need L7 coverage.

The question that tests the fit: what is the diversion time, measured, including route convergence? Everything the pattern promises is bounded by that number, and it is the reason pulse attacks are effective against it.

The commercial construction on top of this pattern is worked through in turning protection into a service.

4. Multi-tenant hosting

Shared edge infrastructure, per-tenant protection policy, tenant services behind it.

What decides it: protecting other people’s traffic. One policy across tenants with different normal profiles either refuses somebody’s ordinary business or is too permissive to protect anybody, so per-tenant policy is a platform requirement rather than a premium tier.

What it cannot do: isolate the shared path. An attack on one tenant consumes circuit capacity, shared session tables and shared processing budget that every other tenant is using. Damage scales with how many customers shared the path, not with attack size.

The question that tests the fit: can one tenant’s traffic trigger another tenant’s limits? That is enforcement independence, and it is the property to test rather than read about, for the reasons in hosting and data centres.

5. Regulated or financial

Inline appliance with local classification, incident evidence retained on infrastructure the organisation controls, a transaction path treated separately from the customer-facing one.

What decides it: two obligations rather than one. Availability, and the ability to reconstruct an incident for an authority within a deadline. The second changes the design in ways capacity planning never does.

What it cannot do: avoid the upstream question. This pattern is still capped by the circuit, so it needs a contracted tier above it — and that contract is now a documented third-party dependency rather than a procurement detail.

The question that tests the fit: can your own staff export an incident record, in your own format, without the supplier’s help? If not, the pattern is incomplete regardless of how well it mitigates. The sector reasoning is in banks and payment infrastructure.

6. Restricted cross-domain

A gateway between a less trusted domain and an enclave, local classification, no outbound path to any supplier, updates loaded offline.

What decides it: a policy constraint rather than a traffic one. Where no external connectivity is permitted, every architecture above is unavailable and the design collapses onto the gateway.

What it cannot do: use anything that requires reaching a supplier — hosted consoles, external classification, live entitlement validation. The last one is the trap, because it behaves perfectly during an evaluation conducted on a connected network.

The question that tests the fit: what is the licence grace period, in days? In this pattern it is the permanent operating condition rather than a contingency, and a product measured in days is unusable regardless of its detection quality. The full treatment is in air-gapped and restricted networks.

Choosing between them

Three questions decide which row you are in, and they are worth answering before any supplier is contacted.

Where must the decision be made? If a residency rule, a thin international path or an operational-independence requirement applies, classification has to be local and rows one, two, five and six are the candidates. If not, the carrier pattern’s economics are hard to beat. The distinction is worked through in local versus cloud-dependent detection.

What may be in the failure domain on an ordinary day? An inline device is a dependency on every quiet Tuesday, not only during attacks. Estates that cannot accept that are pushed toward the diverted patterns and inherit their diversion window in exchange. The two axes are separated properly in inline or out-of-path.

Who owns the capacity above your circuit? Only rows three and four own it. Everyone else contracts for it, and the contract’s terms are part of the architecture rather than an afterthought.

Once the row is chosen, the sizing arithmetic is the same in all six and is in capacity sizing. What changes between patterns is not how much you need but who is responsible for which part of it — and writing that division down is the single most useful artefact this exercise produces.