A denial-of-service attack aims to make a service unavailable, not to steal data. When that traffic comes from many distributed sources at once, it’s a distributed denial-of-service (DDoS) attack — and defending against it requires understanding which of several genuinely different attack categories is actually in play.

The three main categories

A joint guide from the U.S. Cybersecurity and Infrastructure Security Agency, FBI, and MS-ISAC on understanding and responding to DDoS attacks breaks DDoS techniques into three broad categories, each requiring a different defense:

  • Volumetric attacks aim to consume all available network bandwidth, simply by sending an overwhelming volume of traffic — the digital equivalent of flooding a road with far more cars than it can carry.
  • Protocol attacks exploit weaknesses in network protocols themselves, consuming server or network-equipment resources (like connection state tables) rather than raw bandwidth.
  • Application-layer attacks target the application directly, sending requests that look legitimate individually but are designed to exhaust server-side resources — CPU, database connections — at a much lower traffic volume than a pure volumetric attack needs, which makes them harder to distinguish from real user traffic.

Why mitigation depends on absorption capacity

The core defensive challenge with volumetric attacks specifically is one of scale: an origin server, however well provisioned, has finite bandwidth, and a large enough flood simply exceeds it. This is why DDoS mitigation for volumetric attacks relies heavily on distributed infrastructure with capacity far beyond what any single server could have — the same distributed edge network that gives a CDN its latency benefit also gives it enormous aggregate absorption capacity, since attack traffic gets spread across many geographically distributed points of presence rather than concentrated on one origin. AWS Shield and similar managed DDoS protection services are built on this same principle: sitting in front of an origin with enough distributed capacity to absorb an attack that would overwhelm the origin directly.

Where a WAF and rate limiting fit in

Volumetric scale isn’t the whole picture. Protocol and application-layer attacks are often mitigated differently: a web application firewall can filter out requests matching known malicious patterns, and rate limiting — capping how many requests a single source can make in a given period, discussed in What Is a Rate Limiter? — can blunt an application-layer attack even when the individual requests look superficially legitimate. Effective DDoS defense in practice usually combines several of these mechanisms rather than relying on any single one, precisely because the three attack categories require genuinely different countermeasures.

Distinguishing an attack from a legitimate traffic spike

A real operational challenge in DDoS defense is telling a malicious flood apart from a genuine, legitimate surge in traffic — a product launch, a viral moment — which can look similar in raw volume. This is where the observability practices covered elsewhere on this site matter directly: understanding a system’s normal traffic patterns, and having the monitoring in place to see when a spike’s shape (source diversity, request patterns, geographic distribution) looks abnormal rather than just large, is what allows a response to be targeted at actual attack traffic instead of accidentally blocking real users during a busy period.

Key takeaway

DDoS attacks fall into three genuinely different categories — volumetric, protocol, and application-layer — and effective mitigation combines distributed absorption capacity for volume, protocol-level defenses, and application-layer tools like WAFs and rate limiting, rather than any single universal fix. Telling a real attack apart from a legitimate traffic surge depends on the same monitoring and observability practices that matter for reliability more broadly.

This article explains general DDoS attack and mitigation concepts; specific defenses and capacity vary by provider and service. See our disclaimer.