What a DDoS attack is
A Distributed Denial of Service (DDoS) attack is an attempt to make a website, application, API, or other online service unavailable or unreliable. Attackers do this by flooding the target with traffic or by triggering behavior that consumes critical resources (such as bandwidth, CPU, memory, connection slots, or database capacity).
The key idea is impact on availability. A DDoS does not necessarily aim to steal data or change content; it focuses on disruption, often by using many sources (“distributed”) instead of one connection.
How DDoS attacks typically work
DDoS attacks generally follow a simple operational loop: the attacker arranges traffic generation, sends the traffic toward a target, and sustains the load long enough to cause measurable service degradation.
In practice, “how they work” depends on the kind of overload:
- Volumetric overload: Huge amounts of traffic try to saturate a network link (bandwidth exhaustion). Even if servers are strong, packets may not reach them.
- Protocol/connection exhaustion: Traffic exploits behavior at the network or transport layers (for example, by consuming connection state), increasing the number of active sessions until the system can’t keep up.
- Application-layer (L7) overload: Requests are crafted to consume expensive application work—such as complex queries, authentication flows, or rendering—so the service slows or times out even with “normal-looking” traffic volume.
A related concept is that attackers may vary traffic patterns over time to avoid simple blocking and to keep pressure on different bottlenecks.
Differences and limitations (and why detection can be tricky)
Not all traffic spikes are DDoS, and not all DDoS attempts look the same. Consider a few important distinctions and limitations:
- False positives vs. real attacks: A marketing campaign, a legitimate traffic surge, a bug, or a dependency outage can look like attack traffic. Correlating with system health indicators (CPU, error rates, latency, queue depth) helps distinguish “more users” from “hostile behavior.”
- Capacity vs. exhaustion: If resources are already near limits, even modest external increases can cause symptoms similar to DDoS. In other words, the environment’s baseline matters.
- Multi-vector reality: Some incidents involve both network saturation and application stress at the same time. Treating the problem as only one type of DDoS can delay response.
- Not a guarantee of anonymity or perfect obfuscation: Attackers can hide or randomize traffic patterns, but most environments still leave measurable signals in telemetry.
A practical boundary: the goal of understanding DDoS is usually to improve incident readiness and resilience, not to “prove” intent. If service availability is affected, the incident response should focus on restoring stability while investigating the cause.
Practical checks: how to validate what’s happening
When you suspect a DDoS-related disruption, you can run lightweight checks that don’t rely on attacker attribution.
- Compare traffic volume with service symptoms: If request volume (or bandwidth) rises while latency and error rates spike, overload is plausible. If volume is stable but errors and CPU rise, that may point to application-layer work amplification or a bug.
- Look for rate and distribution patterns: Many sources sending similar request patterns, uneven geographies, or repeated failures can be indicators. Legitimate surges often show smoother curves and expected user journeys.
- Check which bottleneck is saturated: Identify whether network throughput, connection counts, thread pools, caches, or database capacity is the limiting factor. This guides what mitigation is relevant.
- Validate whether blocks reduce impact: If you apply rate limiting or filtering and measure improved latency/error rates (not just lower traffic), that suggests the mitigation is addressing the bottleneck.
- Correlate across layers and time windows: Align network metrics, load balancer/proxy logs, application logs, and database performance for the same time range. Consistent correlation strengthens confidence in a resource-exhaustion narrative.
If uncertainty remains, treat it as an availability incident first: prioritize keeping the service responsive, then refine the hypothesis about whether the cause is DDoS, a bug, or a legitimate surge.