DDoS Attacks: What They Overload and How to Respond

A website can stop responding even while its application code is unchanged. A distributed denial-of-service attack tries to make a service unavailable by exhausting capacity somewhere along the request path. The bottleneck might be a network link, a connection-handling device or an expensive application endpoint.

A traffic spike alone is not proof of an attack. A popular link, a broken integration or a database problem can produce similar symptoms. The first useful question is what resource is failing and how its behaviour differs from normal traffic.

Three places an attack can consume capacity

• Bandwidth: volumetric traffic, including reflection and amplification attacks, can fill the connection before requests reach the application.
• Protocol and connection handling: attacks such as SYN floods put pressure on connection processing and network equipment.
• Application work: HTTP traffic can repeatedly trigger expensive searches, page generation or other operations.

These categories can overlap. DNS amplification is commonly a volumetric reflection attack, not simply an HTTP application-layer problem. Cloudflare’s DDoS overview explains the distinction between bandwidth, protocol and application attacks.

Match protection to the bottleneck

Application rate limits and a web application firewall can reduce unwanted HTTP requests. Caching can reduce repeated work at the origin. Neither creates upstream bandwidth when the server's internet link is already saturated; that requires coordination with a provider capable of filtering or absorbing traffic before it reaches the constrained link.

Reduce unnecessary exposure too. An internal database or administration service should not be publicly reachable merely because the website is. If a reverse proxy protects the site, review whether the origin still accepts direct public requests that bypass it. AWS’s attack-surface guidance recommends exposing only the resources, ports and protocols that clients actually need.

Protection has operational trade-offs. A shared office IP can represent many legitimate visitors, so a blunt per-IP limit may block customers. Challenges can interrupt APIs and accessibility tools. Test critical journeys when tightening rules, including login, payment callbacks and health checks.

A response worksheet for the first report

Prepare the following fields before an incident, then fill them from monitoring rather than guesswork:

• Impact: which hostname, endpoint or service is unavailable, and from where?
• Time: when did the change begin, with a clear time zone?
• Evidence: request rates, error rates, latency, link utilisation and representative logs.
• Contact: the hosting or mitigation provider's escalation route and account identifiers.
• Change log: each mitigation, its owner, its effect and how to undo it.

This worksheet is a starting point for your own runbook. Keep a separate communication channel available so the team can coordinate when the affected website is inaccessible. Avoid making several unrelated configuration changes at once; otherwise it becomes difficult to identify what helped.

Recovery includes legitimate traffic

Check real user operations, not just whether the home page returns a response. Remove temporary restrictions carefully and compare errors against the pre-incident baseline. Record whether the provider filtered traffic, the application rejected it, or the service remained unreachable.

A null route can contain wider network damage by discarding traffic to a destination, but it also discards legitimate access to that destination. Treat it as an explicit containment decision with your provider, not as evidence that the website has recovered.