How to Design DDoS Defense Architecture: On-Premises Scrubbing, Cloud Scrubbing, Protected IP, and Protected CDN

How to Design DDoS Defense Architecture: On-Premises Scrubbing, Cloud Scrubbing, Protected IP, and Protected CDN

A DDoS defense architecture answers one question: can attack traffic reach the origin? Every option differs not in whose protection capacity is larger, but in where along the path the scrubbing happens, and whether the origin can be addressed directly from the outside. Understand that layer and the division of labour becomes obvious.

On-premises scrubbing puts appliances inside the data center so traffic reaches the facility before filtering. Cloud scrubbing diverts traffic to a scrubbing center first and returns clean traffic to the origin. A protected IP exposes only a proxy address so the real origin hides behind it. A protected CDN merges scrubbing with acceleration and lets the origin accept only CDN return traffic. These are not substitutes but components for different attack shapes and architectural constraints.

This guide covers mechanics and selection criteria only, not protection capacity figures or price tiers, which belong to procurement parameters and are listed in the DDoS protected server buying guide. The question answered here comes earlier: at which layer should your traffic be scrubbed?

1. Define Which Segment the Defense Must Cover

1.1 Attack Surface and Where Scrubbing Sits

Any internet-facing service can be decomposed as user, public internet, access layer (an IP or a CDN), and origin. Attacks can target any segment, but the goal is always either to take down the origin or to saturate bandwidth. Position therefore determines effect.

If scrubbing happens before the access layer, the origin never sees the flood, but the access layer itself must hold. If scrubbing happens in the origin's facility, attack traffic has already consumed the facility's ingress bandwidth, and survival depends on uplink capacity. And if the origin can be addressed directly and bypasses the protection, everything at the access layer becomes decorative. Those three cases underpin every option below.

To test whether an option holds up, ask three questions in order. Can the origin be bypassed? At which layer does scrubbing capacity live, and who pays for it? Is the return path after scrubbing stable? If any answer is missing, the design deserves a discount on reliability. That is also why a single figure such as how many Gbps of protection is close to useless for decisions: two options with the same headline capacity, one able to hide the origin and one not, can behave in opposite ways.

1.2 Separate Volumetric, Connection, and Application Layer Attacks

Volumetric attacks such as UDP floods, DNS reflection, and NTP reflection aim to fill bandwidth, and inbound volume far exceeds normal business traffic. Connection-based attacks such as SYN floods and connection exhaustion aim to fill connection tables, and the volume may be unremarkable. Application layer attacks such as HTTP floods, slow requests, and high-rate scraping aim to exhaust application capacity, and bandwidth looks almost normal.

Each class needs a different defense. Volumetric attacks need large scrubbing capacity and proximity-based diversion. Connection attacks need SYN proxying and connection limits. Application attacks need behavioural analysis, rate limiting, and human verification. Before selecting anything, be specific about which class threatens you; that is far more useful than asking broadly for a protection number. How protection resources map to attack classes also appears in the security hardening category.

2. On-Premises Scrubbing: Appliances Inside the Facility

2.1 The Benefit: No Architecture Change, No Added Latency

On-premises scrubbing means scrubbing appliances deployed on the facility side, with traffic entering the data center, passing through detection and filtering, and then reaching the origin. For the application this is transparent: no DNS change, no certificate change, no application-side work, an unchanged origin IP and path, and no added latency.

For latency-critical services such as games, real-time media, and trading APIs, that matters. Any diversion-based design introduces extra hops and forwarding delay; on-premises scrubbing does not.

2.2 The Fatal Shortcoming: A Saturated Facility Uplink

The boundary of on-premises scrubbing is equally clear. It only acts after traffic has entered the facility. If the flood exceeds the facility's uplink bandwidth, the egress is congested before scrubbing even begins, and legitimate requests die alongside the attack.

The harder case is a shared uplink, where an attack on another tenant in the same facility degrades your connectivity too. On-premises scrubbing therefore suits facilities that genuinely have protection capacity and spare uplink, not ordinary data centers repackaged as protected hosting. Ask what the ratio of scrubbing capacity to total uplink is, and what happens on overage.

3. Cloud Scrubbing and Traffic Diversion

3.1 What Triggers Diversion

The mainstream form of cloud scrubbing is direct connection in normal times and diversion during an attack: legitimate traffic reaches the origin directly, and when detection finds anomalies, DNS resolution or routing switches to a scrubbing center that filters traffic before returning it to the origin. The design avoids constant added latency, and the price is that the switch itself takes time.

Trigger conditions are therefore the core parameters: is the trigger an inbound volume threshold, a packet rate, a connection count, or a protocol signature? Is detection in seconds or minutes? Is the switch automatic or does it require manual confirmation? How long until it takes effect, which depends on the DNS TTL and the refresh behaviour of recursive caches worldwide. Those parameters decide whether you are breached in the first few minutes of an attack.

TTL creates a real trade-off. A short TTL makes the switch effective quickly but raises query volume and lowers cache hit rates. A long TTL resolves more stably in normal times but slows diversion during an attack. The mechanics are covered in how smart DNS resolution works.

3.2 The Return Path Decides the Actual Experience

Once diversion is active, users no longer reach the origin directly; they reach the scrubbing center, which then returns traffic to the origin. The quality of that return path directly determines user experience. A scrubbing center far from the origin, or a return path that takes public detours, adds latency that can be worse than the attack itself.

So three questions matter when evaluating cloud scrubbing. Where are the scrubbing centers, and is there a nearby one? Does the return path use a dedicated line or the public internet? Is the return bandwidth billed separately? The third is often missed: most scrubbing services bill on the clean traffic returned to the origin, so return bandwidth is a cost line, and high-volume services pay a substantial sum there.

4. Protected IP: Hiding the Origin

4.1 The Key Question: Has the Origin IP Actually Stayed Secret

The protected IP model is intuitive. Only a protected IP is published, all traffic arrives at the protection node, and clean traffic is forwarded to the real origin. Attackers hit the protected IP while the origin hides behind it.

The whole model rests on one premise: the origin IP has never leaked. Once the real IP is found, attackers go around the protected IP and hit the origin directly, and the protection becomes irrelevant. Because protected IP services often do not restrict the origin to accept traffic only from protection nodes, or require extra configuration of a whitelist, the consequences of a leak are usually severe.

4.2 Common Ways an Origin Leaks

The leak paths are more numerous than expected: historical DNS records retained in third-party history databases, subdomains pointing at the origin, the sending IP in mail headers, outbound requests made by the origin itself such as webhooks and analytics callbacks, certificate issuance records and transparency logs, and any other port the origin exposes directly such as SSH, control panels, and database ports.

The clean-up actions can be enumerated. Replace the origin IP at the same time you adopt the protection. Configure the origin firewall to accept return traffic only from protection nodes. Audit every subdomain and historical record. Separate mail sending from the origin. Close unneeded outbound-facing ports on the origin. A fuller checklist is in the server hardening basics checklist.

5. Protected CDN: Scrubbing and Acceleration Combined

5.1 Return Authentication Is the Critical Joint

A protected CDN places scrubbing at the edge and also handles static acceleration. Access is through a CNAME to the provider's domain, the origin no longer exposes an IP, and it accepts only return requests from CDN nodes.

The main risk is equally clear. If return requests are not authenticated, anyone who learns the origin IP can forge return requests and hit the origin directly, or bypass the CDN and obtain unfiltered content. Return authentication such as signed URLs, authentication headers, origin IP whitelists, and mutual TLS is therefore not optional but the precondition for the design to work at all.

5.2 Paths That Bypass the CDN

As with protected IP, bypass paths must be closed one by one. Can the origin still be reached directly from the public internet, when it should accept only CDN node ranges? Are there subdomains or legacy domains not behind the CDN? Do mail headers expose the real IP? Does the CDN configuration omit certain ports or protocols?

A practical check: after configuration, access the origin IP from an external network and confirm every port times out or is refused, then compare responses through the CDN against direct access to confirm content is not available directly. For how caching and origin pulls work, continue with how a CDN works.

One reality to accept is that a protected CDN's effect depends heavily on cache hit rate. If attacks hit cacheable static requests, edge nodes answer directly and the origin barely notices. If they hit uncacheable dynamic endpoints, every request must return to the origin, and the edge only filters and rate limits, leaving origin capacity as the ceiling. Caching what can be cached and moving authentication and rate limits to the edge is often more effective than buying more scrubbing capacity.

6. Two Concepts That Must Stay Separate

6.1 Scrubbing Is Not Blackholing

Many people read DDoS protection as automatic filtering during an attack, yet a substantial number of facilities respond to traffic beyond their capacity with blackhole routing: the attacked IP is withdrawn from the routing table and all traffic, legitimate or not, is dropped until the attack ends.

The difference is business continuity. Scrubbing means the service stays available and some malicious requests are dropped. Blackholing means the service is entirely unavailable, for as long as the attack lasts. So ask explicitly what happens beyond capacity: continued best-effort scrubbing with rate limiting, or an IP block, and for how long, whether it can be lifted manually, and whether it re-triggers automatically.

Granularity deserves the same question: only the attacked port, or the whole IP on all ports, and whether other IPs on the same machine are affected. None of this is visible in normal times, and on attack day it is everything.

6.2 DDoS Protection Is Not a WAF

DDoS protection addresses the traffic layer, L3 and L4, plus part of L7 flooding such as HTTP floods. It does not address injection, broken access control, sensitive data exposure, scraping, or credential stuffing. Those sit exactly in the OWASP Top 10 range and belong to the WAF and to application code, as covered in web security basics and the OWASP Top 10.

A common misjudgement follows. Buying DDoS protection is treated as finishing security, when in fact it keeps the service from dying while a WAF and code hardening are what keep data from being taken. Build and accept the two layers separately. Accept DDoS protection on availability during an attack, and accept the WAF on interception rate and false positive rate.

7. Selection Criteria and Combinations

7.1 A Framework of Four Dimensions

The first dimension is attack type. Pure volumetric attacks at large scale need capacity and nearby diversion. Connection-based attacks centre on SYN proxying and connection table size. Application layer attacks centre on the WAF and rate limiting, where buying more scrubbing bandwidth achieves almost nothing.

The second dimension is whether the architecture can change. Can you accept CNAME access? Can you replace the origin IP and allow only proxy return traffic? Can you tolerate a small latency increase? If all three are acceptable, a protected CDN is usually the best value. If the only acceptable answer is no DNS change and no added latency, on-premises scrubbing or a BGP-based protected IP fits better.

The third dimension is whether the origin can be hidden. If the origin IP is widely known through history records, third-party systems, or mail headers, clean that up before buying protection. Protection installed before clean-up delivers a fraction of its value.

The fourth dimension is what the budget is billed on. Bandwidth-based billing with a committed floor plus burst suits relatively stable traffic volumes. QPS or request-based billing suits API businesses dominated by application layer attacks. Pick the wrong dimension and you either waste money in normal times or lose control of the bill during an attack.

7.2 Combined Architectures and Drills

Real production environments rarely use one shape. A common combination puts a protected CDN at the public entry to handle L7 filtering, restricts the origin to CDN return traffic with an IP whitelist, adds cloud scrubbing as a volumetric backstop for critical services, and keeps on-premises scrubbing in the origin facility as the last layer. The cost is not trivial, but it is a reasonable investment for revenue-sensitive services.

Whatever the combination, run drills. Simulate a diversion switch in a low-traffic window and record the time to effect, the propagation time, and the change in availability. Simulate direct access to the origin and confirm the whitelist holds. Simulate an overage and confirm the blackhole trigger and the release procedure. A defense architecture that has never been drilled will most likely reveal configuration gaps the day an attack arrives.

For wider comparison, several providers with long track records in scrubbing and international networking are worth reviewing. Cloudflare security products are built around an anycast network with unified L3 to L7 protection, Akamai security products bring deep edge capacity and scrub experience, Imperva leans toward application layer protection and data security, and Radware focuses on scrubbing centers and behavioural analysis. Fill in the four dimensions above before comparing offers.

Source: 16IDC original, specifications, pricing and terms are subject to each provider's official documentation and contract.