What is a DDoS attack?

A distributed denial-of-service attack is an attempt to make an online service unavailable by overwhelming some part of the delivery path with traffic, requests, or connection pressure from many sources. The target might be a website, API, DNS service, network link, authentication system, checkout flow, or supporting infrastructure. The "distributed" part matters because the traffic does not come from one machine. It may come from compromised devices, rented infrastructure, open proxies, misused services, or other networks that make simple source blocking difficult.

DDoS attacks are availability attacks. Their direct goal is usually not to steal data or break into a system. The goal is to prevent legitimate users from reaching the service or to force defenders into disruptive emergency changes. That does not make them minor. Downtime can interrupt revenue, public services, support operations, incident response, and customer trust.

Three ways attackers create pressure

DDoS events are often grouped by the part of the stack they stress. Volumetric attacks consume bandwidth. They send enough traffic that links or provider capacity become saturated before the service can even make an application decision.

Protocol and state-exhaustion attacks pressure network devices, firewalls, load balancers, or servers by forcing them to track or process excessive network state. The exact mechanism varies by protocol, but the defender symptom is often high packet rates, connection pressure, or infrastructure exhaustion.

Application-layer attacks target the web or API layer. They may send HTTP requests that look ordinary but concentrate on expensive routes such as search, login, checkout, content generation, or API mutations. These attacks can be smaller in raw bandwidth while still overwhelming databases, application workers, caches, or third-party dependencies.

Real incidents can combine these patterns. A flood may distract the team while application abuse continues, or an application-layer attack may be accompanied by bot traffic that rotates sources and user agents.

How DDoS differs from normal traffic surges

A popular campaign, news event, sale, or breaking announcement can create a legitimate surge that looks stressful. The difference is intent and usefulness. Legitimate traffic should produce business outcomes: page views, logins, purchases, API success, downloads, or other expected actions. DDoS traffic consumes resources without healthy user outcomes.

Defenders should therefore compare volume with service value. Are users completing journeys? Are requests concentrated on unusual routes? Are source networks, geographies, user agents, or fingerprints changing abruptly? Are cache hit rates falling because traffic is bypassing cached content? Are response codes, timeouts, and origin load moving together?

This distinction matters because the best response to demand is often scaling, caching, and traffic optimization, while the best response to hostile traffic is filtering, rate control, bot mitigation, or upstream DDoS support.

Indicators defenders can use

Useful indicators depend on the attack type. Network teams may watch bandwidth, packets per second, flows, dropped packets, interface saturation, firewall CPU, routing changes, and provider alerts. Application teams may watch request rate by route, cache status, response latency, error rates, queue depth, database load, authentication failures, and third-party dependency behavior.

Security teams add context from source reputation, automation signals, header consistency, TLS or browser fingerprints, session behavior, account behavior, and WAF or bot-control outcomes. No single signal is enough. IP addresses can change, user agents can be spoofed, and high traffic can be legitimate. Strong detection combines traffic volume, request behavior, route sensitivity, and service health.

Time shape is also useful. DDoS traffic may arrive as a sudden wall, repeated bursts, slow sustained pressure, or waves that change as mitigation is applied. Capturing the timeline helps responders understand whether controls are working or merely shifting the problem.

Defensive concepts

DDoS resilience is built before the incident. The first layer is architecture: remove unnecessary public exposure, keep critical services behind appropriate edge controls, separate high-risk services where possible, and design origin systems so cacheable content can be served without unnecessary dynamic work.

The second layer is mitigation capability. Volumetric attacks may require upstream capacity, scrubbing, anycast distribution, or provider-level filtering. Protocol attacks need network and transport controls that can reduce harmful state or packet pressure. Application-layer attacks need route-aware rate limits, WAF policy, bot detection, caching, and monitoring that can distinguish expensive abuse from real user traffic.

The third layer is operational readiness. Teams need baselines, dashboards, runbooks, escalation contacts, and preapproved emergency actions. They should know who can contact network providers, who owns application routes, who can change security policy, and who communicates status to customers or internal stakeholders.

Common misconceptions

"DDoS protection is only about bandwidth" is outdated. Bandwidth still matters, but many damaging attacks target application bottlenecks, authentication systems, dynamic pages, or APIs with far less traffic than a classic network flood.

"A CDN automatically solves DDoS" is too broad. Caching and edge delivery help when content can be served away from origin, but dynamic routes, APIs, login flows, and cache-bypass behavior still need policy and monitoring.

"Blocking a country or ASN is a response plan" is risky. Geography and network-based blocks may reduce some traffic, but they can also block legitimate users and miss distributed sources elsewhere. They should be treated as scoped tools, not a strategy.

"An incident is over when traffic drops" misses the recovery work. Teams still need to confirm service health, review controls, identify exposed weaknesses, and capture lessons before data disappears.

Planning the response

A practical DDoS runbook should start with triage. Identify what is failing: bandwidth, packet processing, connection capacity, application workers, database resources, cache effectiveness, DNS, or a third-party dependency. Then identify what must stay available: public pages, login, checkout, APIs, administration, support, and monitoring.

Response actions should be proportional. Tighten rate limits on attacked routes before applying broad blocks. Serve cacheable content from the edge where possible. Challenge suspicious automation when blocking confidence is low. Move volumetric filtering upstream when local infrastructure is saturated. Preserve logs and metrics in forms that can survive high volume.

After the event, measure detection time, mitigation time, user impact, false positives, escalation quality, and control effectiveness. The best outcome is not just restored availability. It is a clearer understanding of which services were fragile, which signals mattered, and which changes will make the next event easier to contain.

Related learning

• UDP flood DDoS attacks
• What is a DDoS botnet?
• What is Layer 7?