What a DDoS attack is

A Distributed Denial of Service (DDoS) attack is an attempt to disrupt availability by flooding or overwhelming a target with traffic or requests. “Distributed” means the traffic typically comes from many sources at once, which makes it harder to block using a single rule. The goal is usually to cause one or more of the following outcomes: legitimate users can’t reach the service, requests time out, or performance drops sharply.

In practice, DDoS incidents are often detected by symptoms (latency, error rates, bandwidth saturation, CPU exhaustion, or connection table pressure) and then investigated using traffic and system telemetry.

How DDoS attacks work (the main patterns)

DDoS attacks are not all the same. The technique depends on which resource becomes the bottleneck.

1) Volumetric (bandwidth) saturation In a volumetric attack, the attacker tries to consume the target’s inbound bandwidth so legitimate traffic can’t get through. Even if the application is fine, the network path becomes overwhelmed.

2) Protocol-layer exhaustion Here the attacker targets how connections are established and maintained. By sending traffic that triggers expensive state changes (for example, many half-open connections or repeated handshakes), the attacker can exhaust resources such as connection tracking tables.

3) Application-layer (request) attacks At the application layer, the attacker focuses on making the server do costly work per request. This can include generating many “valid-looking” requests that still drive high CPU, expensive database queries, or slow downstream dependencies. Even at modest bandwidth, the service may degrade because the application can’t keep up.

Limitations and why impacts vary

Several factors change how an incident behaves and how confident you can be that it is DDoS.

DDoS is about pressure, not necessarily “illegal hacking.” A DDoS may involve traffic patterns that resemble legitimate clients but are scaled or orchestrated to cause disruption. This means you need to look at patterns and effects, not only at the presence of “bad payloads.”

Some events look like DDoS but aren’t. Traffic spikes can come from sudden popularity, product launches, monitoring mistakes, crawler surges, or outages in upstream components that trigger retries. Without correlation to system metrics and traffic characteristics, you can mislabel a benign spike.

Defenses have different choke points. Network capacity, upstream routing, rate limiting, connection handling, and application caching all mitigate different classes of attacks. A defense that helps against volumetric floods may not solve application-layer exhaustion.

“Effectiveness” depends on where the bottleneck is. If the service is already under normal load, additional traffic can tip it over quickly. If autoscaling and caching are in place, some attacks may cause only partial or short-lived symptoms.

It helps to distinguish DDoS from other availability and security events.

DDoS vs. rate limiting / abuse prevention Rate limiting is a defensive control; DDoS is the attack behavior. Many deployments combine both: rate limiting helps when traffic volume grows, but sophisticated application-layer attempts may still consume expensive processing before limits trigger.

DDoS vs. outages An outage can be caused by configuration errors, failed dependencies, or capacity issues that are not attacker-driven. DDoS is characterized by concentrated, adversarial traffic patterns that correlate with availability degradation.

DDoS vs. bot traffic Some bot traffic is benign or semi-benign (search indexing, legitimate API clients). The distinguishing factor is intent and impact: whether the traffic overwhelms resources and aligns with disruption symptoms.

Practical checks: how to validate a suspected DDoS

If you’re trying to determine whether a spike indicates DDoS-like behavior, focus on checks that connect traffic evidence to system impact.

1) Correlate timing with service symptoms Compare the onset of latency, timeouts, elevated error rates, CPU/memory pressure, bandwidth saturation, or connection errors with the time window of increased traffic. A strong temporal correlation supports an availability-impacting event.

2) Identify which resource is the bottleneck Look for indicators such as exhausted bandwidth, spikes in concurrent connections, rising handshake/connection errors, or application CPU/queue growth. This helps classify the attack pattern (volumetric, protocol, or application-layer) and narrows what defenses are likely to be effective.

3) Inspect traffic sources and patterns Check whether requests come from many distinct client IPs or networks, whether they concentrate on specific endpoints, and whether request rates ramp rapidly. Broad distribution and synchronized surges are common in DDoS, though not exclusive to it.

4) Compare request “shape” across endpoints If only certain endpoints degrade while others remain stable, it may suggest targeted application-layer pressure. If overall ingress bandwidth and transport-level metrics spike together, volumetric behavior is more likely.

5) Reduce uncertainty with baseline comparisons Compare current traffic against your normal baselines (same time-of-day/day-of-week) and against known campaigns or deployments. This reduces the chance of confusing routine demand, retries, or monitoring activity with adversarial traffic.

Safety note: uncertainty is normal

Because real incidents differ by environment and telemetry quality, you often can’t “prove” intent from traffic alone. What you can do is assess whether the observed patterns and correlated system impact match common DDoS characteristics, then apply the most relevant availability controls for the suspected bottleneck.