At 3 a.m., the symptom usually isn't "DDoS detected." It's a payment API returning intermittent 502 responses, login requests consuming every application worker, and an origin link that looks saturated even though legitimate traffic hasn't changed. The immediate fix is to move the affected service behind an always-on reverse proxy or activate the documented cloud diversion policy, then verify that the origin sees only cleaned traffic.
sudo ss -s
sudo ss -ant state syn-recv
sudo journalctl -u nginx --since "10 minutes ago" --no-pager
sudo tcpdump -ni any 'udp or tcp'
Don't start by restarting the web server. Confirm where the traffic is being absorbed, preserve the telemetry, and make sure the origin's public path can't bypass the mitigation layer. Cloud DDoS protection is an operating model, not a switch you turn on after the first alarm.
Table of Contents
- What Cloud DDoS Protection Actually Does
- How Scrubbing, Diversion, and Rate Limiting Work
- Inline, Cloud Scrubbing, and CDN-Based Models
- Integrating Cloudflare and On-Prem Plus Cloud
- Reading a DDoS SLA Like an Operator
- Cost and Benefit Without the Marketing Math
- Multi-Layer Protection and 24/7 Monitoring in an Enterprise Strategy
- Common Misconceptions and a Short Pre-Deployment Checklist
What Cloud DDoS Protection Actually Does
Cloud DDoS protection places an off-premises mitigation layer between the Internet and your origin. That layer receives traffic, inspects it, removes malicious flows, and forwards legitimate requests to the service. For web applications, it commonly operates as a reverse proxy. Cloudflare describes this model as a service sitting between incoming traffic and the website, analyzing requests before they reach the origin server. Its DDoS mitigation report also supports the practical placement rule: the protected layer must be in front of the origin, not beside it.
The benefit is headroom. Your data center no longer has to receive every packet before deciding whether that packet is legitimate. A distributed provider can absorb traffic outside your network boundary, while your origin receives a smaller, inspected stream.
Cloudflare reported that its global DDoS systems mitigated 47.1 million attacks in 2025, more than double its 2024 total, with an average of 5,376 attacks every hour across that year. Network-layer attacks accounted for 34.4 million of the 2025 total, compared with 11.4 million in 2024, according to the Cloudflare 2025 DDoS threat report. The useful lesson isn't that one provider has a large number. It's that cloud-based mitigation is designed for continuous, automated traffic handling at a scale most individual facilities won't provision locally.
The traffic path matters
A typical design has four moving parts:
- Diversion: BGP announcements or DNS steering move traffic toward the mitigation network.
- Scrubbing: The provider classifies flows and removes traffic that matches attack behavior.
- Rate limiting: Policies constrain abusive sources, paths, methods, or protocols.
- Forwarding: Clean traffic returns to the origin through a controlled route.
The choice between always-on and on-demand diversion changes the failure window. Always-on routing keeps the provider in the path and avoids waiting for a route change during an attack. On-demand routing can reduce clean-traffic latency and cost, but detection, signaling, BGP convergence, and policy activation all have to work under pressure.
Production rule: If the origin remains directly reachable, attackers can bypass the cloud layer and turn a successful mitigation into a partial one.
Cloudflare's telemetry illustrates why manual response is inadequate. Its Q1 2025 reporting described roughly 700 hyper-volumetric attacks exceeding 1 Tbps or 1 Bpps, with typical durations of only 35 to 45 seconds and peaks reaching 6.5 Tbps and 4.8 Bpps. The Cloudflare Radar DDoS report makes the operational requirement clear: detection and traffic handling must happen within seconds, not after a ticket reaches a human operator.
How Scrubbing, Diversion, and Rate Limiting Work
Start with diversion because every later control depends on traffic reaching the right inspection point. For HTTP services, DNS-based steering or a CNAME-based arrangement sends users to the proxy edge. For IP-based services, the provider can advertise the protected prefix through BGP. In always-on mode, the mitigation network is the normal path. In on-demand mode, a threshold or operator action triggers the announcement.
The cutover itself can fail even when the filtering policy is correct. DNS caching delays the change, certificate provisioning can lag behind a hostname move, and BGP convergence can leave some paths pointed at the old route. Operators should validate both the control-plane change and the data-plane result.
What happens inside the scrubber
A scrubbing center collects flow telemetry, identifies packet and request fingerprints, compares traffic against signatures and policy, and forwards traffic that passes inspection. Depending on the service, suspicious HTTP clients may face a challenge, while clearly invalid network flows can be discarded earlier in the pipeline.
Simple volume thresholds don't handle blended attacks well. An attacker can combine raw network floods with legitimate-looking requests against login, search, checkout, or API paths. A filter that only checks packets per second may miss an application attack. A proxy that only sees HTTP may miss UDP, ICMP, or other services sharing the same infrastructure.
For practical help with recognizing the first signs, keep a documented DDoS attack detection procedure beside the escalation contacts. It should identify who can approve a route change, who owns application rate limits, and who confirms that the origin is receiving clean traffic.
Where rate limits fire
Rate limiting is most effective when it maps to how the service works:
- Per source: Useful for obvious abuse, but unsafe when many users share an address or carrier NAT.
- Per autonomous system: Useful when one network delivers abnormal traffic, but it can block legitimate corporate or mobile users.
- Per path: Strong for expensive endpoints such as authentication, search, and checkout.
- Per method or token: Useful for APIs where authenticated clients have different behavior from anonymous requests.
Static limits are easy to explain but often create false positives during promotions or product launches. Adaptive policies compare current behavior with a known legitimate baseline and change enforcement as the service changes. That baseline needs review. If it was created during an attack, the system can learn the wrong normal.
A provider's headline capacity also isn't the same as the throughput actively available to your traffic at a given moment. NETSCOUT's threat intelligence reporting emphasizes dedicated edge scrubbing capacity and unused headroom for concurrent attacks. Ask how capacity is reserved, how attacks affecting multiple customers are handled, and whether selective mitigation can protect one service without disrupting another.
Inline, Cloud Scrubbing, and CDN-Based Models
No deployment model sees the whole environment. An inline appliance sees traffic that crosses its inspection point, a cloud scrubber sees traffic routed through its edge, and a CDN sees the protocols and connections it terminates. The right choice depends on the workload, the attack path, and the latency you can tolerate when traffic is clean.
| Model | Best For | Latency Impact | Capacity Ceiling | Visibility Gaps |
|---|---|---|---|---|
| Inline appliance | Known links, private services, state exhaustion, local policy enforcement | Usually low on the local path | Limited by provisioned link, appliance throughput, and facility capacity | Doesn't see traffic that bypasses the appliance or attacks outside the local path |
| Cloud scrubbing | Public IP services, mixed protocols, large volumetric events, multi-site protection | Adds path distance when always-on, or cutover delay when on-demand | Distributed provider capacity, subject to available and reserved headroom | NetFlow and packet context may be incomplete after traffic leaves the local edge |
| CDN-based protection | HTTP and HTTPS applications, cacheable content, web challenge workflows | Often low for users near an edge, but proxy processing adds a clean-path dependency | Distributed edge capacity for supported web traffic | Doesn't inherently cover arbitrary UDP, gaming protocols, or non-web services |
Inline appliances
An inline device is valuable when the failure mode is local. It can enforce state limits, recognize malformed sessions, and apply policies to traffic headed toward a known server segment. It also gives the local team packet and flow visibility without waiting for a third party.
Its limit is physical. If the attack consumes the upstream circuit before traffic reaches the appliance, the appliance can't filter what it never receives. An appliance also won't automatically protect a second facility or a cloud workload unless the routing design places that traffic through the same inspection point.
Cloud scrubbing
Cloud scrubbing is the stronger fit for attacks that can fill a transit circuit or overwhelm several sites at once. The trade-off is operational complexity. You must maintain route advertisements, origin authentication, return paths, logging, and a clean way to withdraw protection without creating asymmetric routing.
For a mixed estate, a DDoS protection service for websites can cover the web layer while a separate cloud transit design handles non-web services. Don't assume that protecting the website protects the payment API, DNS, mail, or an exposed management interface.
CDN-based protection
A CDN is effective when the provider can terminate TCP and TLS, cache legitimate content, challenge suspicious clients, and keep expensive requests away from the origin. It is less suitable for services that need direct connections, low-jitter UDP, custom protocols, or long-lived sessions that the proxy can't interpret correctly.
The visibility question should be explicit in the design review. Decide which team can see client identity, request headers, origin response codes, flow records, and packet samples after the CDN or scrubber becomes the edge.
Integrating Cloudflare and On-Prem Plus Cloud
The cleanest integration pattern for HTTP workloads is a proxy-fronted overlay. The hostname points to the provider, the provider terminates the client connection, and the origin accepts traffic only from approved proxy paths. This arrangement simplifies application-layer inspection, but it creates dependencies around certificates, access controls, cache behavior, and origin reachability.
CNAME flattening can make a proxied hostname appear as an address record to clients while preserving the provider's edge selection. The operator still needs to test TTL behavior, certificate issuance, health checks, and rollback. A DNS change isn't complete when the dashboard says it succeeded. It is complete when clients reach the new edge and the old path no longer accepts bypass traffic.
IP-based services require a different control plane. BGP or anycast announcements move the protected prefix toward the scrubbing network. Return traffic must follow a compatible path, and the operator needs to watch for asymmetric routing, stale announcements, and a provider withdrawal that exposes the origin before local controls are ready.
| Pattern | Routing Mechanism | Protocol Coverage | Visibility at Edge | Typical Cutover Risk |
|---|---|---|---|---|
| Proxy-fronted cloud overlay | DNS steering or CNAME-based proxying | Primarily HTTP and HTTPS | Strong request-level visibility, limited visibility into non-proxied services | TTL lag, certificate errors, origin bypass |
| On-prem plus cloud | Inline filtering with BGP diversion or controlled discard | Local policy plus selected routed protocols | Strong local flow context, cloud telemetry may be separate | Asymmetric routing, split ownership, incomplete route testing |
| Always-on cloud transit | Permanent BGP or anycast path | Broad coverage when the provider supports the protocol | Strong edge view, reduced local packet visibility | Clean-path latency, logging dependency, provider outage |
| On-demand cloud transit | BGP announcement after detection or operator action | Broad coverage after activation | Local view before diversion, provider view after diversion | Detection and convergence delay, partial attack exposure |
The hybrid pattern
A hybrid design lets the local appliance absorb state exhaustion and protocol anomalies while the cloud layer handles sustained volumetric traffic. It only works if the handoff is unambiguous. Define whether the local device forwards suspicious traffic, drops it, or triggers diversion. Define who can change the route and who can approve a rollback.
The common visibility gaps are predictable:
- A web proxy won't show UDP or ICMP attacks that never enter the proxy path.
- NetFlow may stop at the scrubbing hop or arrive with different fields and sampling behavior.
- Operators may chase the same event across two dashboards with different clocks and identifiers.
- An application team may see increased errors without knowing that a network policy changed upstream.
Cloudflare management is relevant when a team needs help maintaining proxy rules, DNS changes, and edge policies, but management doesn't remove the need for an independent origin path and a tested rollback.
Always-on routing is usually preferable when the service is sensitive to even brief saturation, the clean-path latency is acceptable, and the organization can't staff rapid route changes. On-demand routing is reasonable when latency matters, attacks are infrequent, and the team has rehearsed detection, announcement, validation, and withdrawal.
Reading a DDoS SLA Like an Operator
A DDoS SLA is useful only when its language maps to telemetry you can collect during an incident. Read it like a peering agreement. Ignore the headline until you understand the trigger, the measurement point, the exclusions, and the remedy.
Clauses that change the outcome
Time to mitigate needs a precise start and stop event. Does the clock begin when the provider detects the attack, when its SOC opens an incident, or when your team submits a ticket? Does the clock stop when a rule is created, when traffic reaches the scrubber, or when the origin error rate recovers?
A short mitigation commitment can be misleading if route convergence takes longer than the commitment. An on-demand BGP design also has separate intervals for detection, announcement, propagation, filtering, and clean traffic delivery. The SLA should identify each one or state clearly which interval it covers.
Coverage scope must distinguish volumetric, protocol, transport, application, API, DNS, and encrypted traffic. A service that protects a web proxy may not cover a directly routed UDP service. A network-layer commitment may not include a costly application attack that uses valid-looking requests.
Concurrent attack limits matter in multi-tenant environments. Ask whether several targets under one account count as one event or several, and whether mitigation capacity is reduced when attacks overlap geographically or affect different customers.
False positives need both a definition and a remedy. A claimed false-positive rate is not enough if the provider doesn't define the population measured, the exclusion rules, or the credit trigger. A service credit also doesn't restore a blocked payment flow.
Verification questions
Request the last twelve months of post-incident reports, if the provider makes them available, and ask for detection-to-mitigation telemetry from a comparable customer environment. Confirm whether the SLA covers the proxy hop, the origin path, or only the provider's own edge.
Then test the operational path. Create a harmless policy change, verify that the event appears in both monitoring systems, and confirm that support can identify the protected asset without asking your team to reconstruct the architecture during an outage.
Operator's test: If you can't identify the exact metric that starts and stops the SLA clock, you can't use the SLA as an incident control.
Cost and Benefit Without the Marketing Math
A useful cost model starts with the traffic path, not the vendor's capacity claim. List the subscription or service commitment, protected bandwidth, clean-traffic charges, overage rules, logging, and support. Then add the costs that appear when mitigation is partial or when the team has to tune policies under pressure.
| Cost Line | Cloud Scrubbing | Self-Operated Appliance | Hybrid |
|---|---|---|---|
| Service commitment | Recurring protection and support charges | Appliance purchase, licensing, and maintenance | Cloud service plus local equipment |
| Transit during attack | May remain controlled if diversion happens early | Origin and upstream circuit still carry the attack until local limits apply | Local link handles the first stage, cloud handles diverted volume |
| Engineering effort | Policy tuning, route testing, vendor coordination | Rule maintenance, hardware lifecycle, capacity planning | Coordination across local and cloud control planes |
| Telemetry | Provider dashboards, exported flow data, log retention | Direct packet and flow access | Rich local context plus provider telemetry that must be correlated |
| Capacity risk | Depends on available scrubbing headroom and concurrent events | Bounded by facility links and appliance throughput | Reduced local exposure, but the handoff must work |
| Failure mode | Misrouting, proxy bypass, provider or control-plane dependency | Saturated upstream, appliance failure, insufficient capacity | Conflicting policies, asymmetric routing, unclear ownership |
A practical calculation
For a mid-sized e-commerce property facing a sustained attack, don't begin with the claimed peak capacity. Estimate the cost of lost orders, support load, emergency engineering time, excess transit, log storage, and recovery work. Then compare that total with the recurring cloud commitment and the cost of maintaining an internal mitigation path.
A self-operated design carries capital and staffing requirements. The appliance needs replacement planning, tested rules, spare capacity, and people who can respond outside business hours. It also can't remove traffic that has already saturated the upstream connection.
A cloud design shifts more of the capacity problem outward, but it introduces clean-path latency, provider dependency, data export costs, and a requirement to keep the origin locked down. A hybrid design usually has the most moving parts. Its value comes from giving operators a local control point for protocol and state problems while preserving a path for large floods to leave the facility.
Budgeting rule: Calculate the cost of an incomplete mitigation, not just the cost of a successful one. Partial scrubbing, excess transit, false positives, and manual recovery often dominate the invoice.
The break-even point moves with workload characteristics. A public API with strict availability requirements places more value on automatic diversion than a low-volume brochure site. A UDP-heavy service may justify broader transit protection even when its web traffic is modest. A service with strong caching may gain more from an edge proxy than from sending every packet through a general-purpose scrubber.
Multi-Layer Protection and 24/7 Monitoring in an Enterprise Strategy
A resilient design uses layers with different jobs. The CDN handles cacheable web traffic and application challenges. The cloud scrubber absorbs traffic that would fill the facility or transit path. The local appliance protects state tables, private segments, and protocol behavior that the cloud layer can't see.
Monitoring connects those layers. Without correlated telemetry, operators mistake a real customer surge for an attack, or they see an application failure and miss the route change that caused it. The monitoring system should join BGP state, NetFlow, firewall events, proxy logs, origin response codes, and resource utilization on a common timeline.
Cloudflare's public network analytics documentation identifies useful fields for an operations runbook: attack count, attack traffic relative to normal traffic, largest attack rates, mitigated attack bytes, top source, and estimated attack duration. Those fields aren't enough on their own, but they give the incident commander a consistent starting view.
Handoff points need owners
Write ownership into the runbook:
- Detection: The NOC or vendor SOC identifies abnormal flow or request behavior.
- Triage: The network team determines whether the event is volumetric, protocol-specific, application-layer, or blended.
- Activation: The authorized operator changes the route or enables the mitigation policy.
- Validation: The application owner confirms that legitimate transactions work and the origin is no longer exposed.
- Stabilization: The team tunes rate limits, blocks bypass paths, and preserves evidence.
- Rollback: The route owner withdraws temporary changes only after the origin and upstream path are healthy.
An operator running its own hardware alongside cloud scrubbing adds real value when that operator can inspect local flows, isolate tenants, preserve packet evidence, and apply a policy before cloud diversion completes. The equipment is not a substitute for external capacity. It is a local control and visibility point.
In multi-tenant infrastructure, the production failure is often uneven. One customer may be behind a proxy, another may expose a game service directly, and a third may share DNS or transit dependencies with both. A single "protected" label hides those differences. Inventory each public service, its protocol, its route, its owner, and its logging path.
Common Misconceptions and a Short Pre-Deployment Checklist
Cloud protection doesn't stop every failure. It may not cover east-west traffic, a directly exposed management service, local state exhaustion, or a protocol outside the provider's profile. Protection also doesn't work merely because a policy exists in a dashboard. DNS, BGP, certificates, origin access controls, and return routing must align.
An SLA doesn't guarantee that the origin survives every event. It may promise a mitigation response while the application remains unhealthy because the database, authentication service, or local circuit is exhausted. Treat the SLA as one control in the design, not as a replacement for capacity, segmentation, and monitoring.
Run this checklist before go-live
- Confirm DNS behavior: Document TTL expectations, proxy status, certificate ownership, and rollback authority.
- Validate routing: Test the intended anycast or BGP advertisement and confirm the origin path can't be bypassed.
- Baseline legitimate traffic: Record normal request paths, protocol mix, source distribution, and application resource use.
- Test false positives: Exercise login, checkout, API authentication, long-lived sessions, and approved automation.
- Verify logging: Confirm that proxy, scrubber, firewall, NetFlow, and origin logs reach the people who investigate incidents.
- Document escalation: Name the route owner, application owner, provider contact, and decision-maker for emergency policy changes.
- Test withdrawal: Rehearse rollback and verify that a withdrawn route doesn't expose an unprotected origin.
Ask one question before signing: What doesn't this provider cover, and who owns that gap?
ARPHost, LLC provides colocation, bare metal servers, VPS hosting, private clouds, managed services, and cloud security management for teams that need a clearly operated infrastructure path. Review ARPHost, LLC to discuss protected hosting or a hybrid design with local hardware, monitoring, and escalation responsibilities defined before an incident.
Leave a Reply
You must be logged in to post a comment.