Always-On Is Right When
Services carry strict availability SLAs where even brief degraded performance is unacceptable. The organization faces frequent attacks or sophisticated low-volume attacks that automated detection may miss.
Network Security
Always-On vs On-Demand DDoS Mitigation
How much attack traffic hitting your infrastructure before mitigation activates is acceptable?
The choice between always-on and on-demand DDoS mitigation determines how much attack traffic reaches your infrastructure before protection is active, the ongoing latency profile of your internet connectivity, and which attack types you are actually defended against.
Vendor-neutral DDoS architecture design based on your environment, not provider preferences.
-1-1-1.png)
The Core Issue
What the choice actually determines beyond activation delay
The activation delay of on-demand mitigation is the central operational risk, but it is not the only dimension that matters. The model choice also determines which attack types are effectively defended, how clean traffic returns to your infrastructure, and how cost scales with attack frequency and attack size.
Critical Operational Gaps
Generic always-on versus on-demand labels obscure the architectural specifics that determine real-world outcomes.
On-demand activation latency varies significantly with provider architecture and pre-established BGP sessions
Application-layer attacks often bypass volumetric detection thresholds entirely
Always-on routing latency depends heavily on scrubbing center geography and anycast footprint
False positive activation causes unnecessary latency and scrubbing charges for benign traffic spikes
Return path architecture is commonly overlooked until after an attack exposes gaps
Architectural Framework
The right choice depends on service availability requirements, attack exposure, and provider architecture specifics.
On-Demand Is Right When
Services can tolerate a short window of degraded performance while mitigation activates. Always-on latency overhead would impair user experience and attacks are infrequent enough to justify the cost model.
Implementation Process
Five steps to arrive at a defensible DDoS mitigation architecture for your environment.
1
Classify Services
Segment services by availability SLA, revenue impact, and attack exposure to drive protection tier decisions.
2
Assess Attack Profile
Review attack history and industry patterns to match architecture to realistic threat exposure.
3
Evaluate Provider Architecture
Map scrubbing center locations and anycast coverage against user and data center locations.
The Hybrid Approach
For enterprise environments with diverse service profiles, the right answer is usually tiered protection.
Highest Priority Services
Always-on cloud scrubbing combined with application-layer WAF protection for revenue-generating services with strict SLAs.
General Enterprise Connectivity
On-demand cloud protection with fast-activation SLA, combined with on-premises DDoS appliances sized for circuit capacity.
Internal Infrastructure
On-premises filtering combined with on-demand upstream protection for extreme events that exceed circuit capacity.
Outcomes
- Protection model matched to service availability requirements
- Defense against both volumetric and application-layer attacks
- Cost structure aligned with actual attack frequency and exposure
- Unified operational visibility across protection tiers
Who This Fits
- Organizations designing DDoS protection architecture from scratch
- Teams reassessing current defenses after an incident
- Enterprises comparing specialist providers against ISP-provided options
- Organizations whose service portfolio spans critical and general connectivity
Attack Type Spectrum
Different attack types require different architectural approaches
A DDoS architecture that addresses only volumetric attacks leaves application-layer attack surface undefended, and modern attacks commonly combine both vectors.
Volumetric Attacks
Network Layer
UDP reflection amplification, ICMP floods, and TCP SYN floods target bandwidth and connection capacity.
Best Fit
Always-on or on-demand cloud scrubbing is effective for these classic attack types.
Protocol Attacks
Transport Layer
TCP state exhaustion and fragmented packet attacks target stateful devices and are handled at the scrubbing layer.
Recommended
Application-Layer Attacks
L7 Protection Required
HTTP floods, slow POST attacks, and API abuse run at low bandwidth and bypass volumetric detection.
Best Fit
Requires web application firewall or application-aware scrubbing service.
Why IVI
Vendor-neutral architecture design based on your environment
No Preferred Vendor
IVI approaches DDoS architecture without vendor bias because the right answer depends on the environment rather than provider relationships.
How It Works
Architecture emerges from service classification and attack exposure analysis rather than predetermined vendor preferences.
Unified Visibility
Aegis co-managed services correlates on-premises appliance telemetry, circuit performance, and upstream scrubbing activation into a single operational view.
Related Resources
Related Resources
Review related solution pages, supporting materials, and additional resources that help explain where this solution fits and how it can be applied.
FAQs
Frequently Asked Questions
Common questions about DDoS mitigation architecture decisions.
Can we use always-on for some services and on-demand for others?
Yes, and for most enterprises this is the right answer. Always-on protection for the most critical and frequently-attacked services, on-demand for general connectivity, on-premises appliances for small attacks that do not require upstream involvement. The cost of always-on protection concentrates where it delivers the most value.
How do we reduce the BGP activation delay for on-demand protection?
Pre-established BGP sessions with the scrubbing provider are the single largest factor. Configuring BGP sessions in advance rather than establishing them reactively reduces diversion time from minutes to seconds. Pre-configured protection templates and automated detection with human-initiated override are additional factors.
What is the typical latency overhead of always-on routing?
The overhead depends on where scrubbing POPs sit relative to users and origin infrastructure. An anycast provider with POPs closer to users than the origin can deliver neutral or even slightly improved latency. A regional scrubbing provider poorly placed for a given geography can add enough overhead to degrade user experience on latency-sensitive applications.
Does DDoS mitigation defend against application-layer attacks like HTTP floods?
Traditional volumetric DDoS mitigation at the network layer does not reliably defend against application-layer attacks. HTTP floods, Slowloris, and API abuse run at low bandwidth and do not generate volumetric signatures that trigger scrubbing. L7 protection requires a web application firewall or application-aware scrubbing tier.
How does CDN-integrated protection compare to dedicated scrubbing services?
CDN-integrated DDoS protection proxies all application traffic through the CDN's global anycast network continuously, absorbing attacks at the edge. For web applications and APIs, this is often the most operationally simple option addressing L3, L4, and L7 attacks through a single architecture. The limitation is that non-HTTP protocols remain outside the protection scope.
What role do on-premises DDoS appliances still play?
On-premises appliances handle small and medium attacks inline with no activation delay, no upstream coordination, and no per-incident scrubbing charges. For attacks within the capacity of the internet circuit and the appliance itself, on-premises mitigation is instantaneous. The limitation is that attacks saturating the upstream circuit cannot be mitigated on-premises.