Denial-of-Service Defense

A denial-of-service attack makes a service unavailable to its intended users. A distributed denial-of-service attack, or DDoS attack, sends the attack from many systems. Distribution gives an attacker more traffic sources and makes simple source blocking less effective.

Use one mental model: protect the service's narrowest resource while preserving legitimate work.

users and attackers
        ↓
internet capacity → provider edge → application edge → service → dependencies
        bandwidth       filtering       admission       work       work

An attack only needs to exhaust one limiting resource. That resource might be link bandwidth, packet-processing capacity, connection state, worker time, database connections, memory, or a paid dependency. Your defense must act before traffic consumes that resource.

What denial of service means

Availability is a property observed by a user. A server can remain powered on while users receive timeouts, errors, or unusable latency. Monitor the user-visible service, not only the health of individual machines.

DoS describes the effect and attack goal. DDoS describes a distributed source pattern. Neither term identifies one protocol or one mitigation.

DoS can result from several forms of exhaustion:

Volumetric exhaustion fills network capacity with bits or packets.
Protocol-state exhaustion consumes state in a host, firewall, proxy, or load balancer.
Application-resource exhaustion sends requests that consume disproportionate compute, memory, storage, database work, or downstream calls.
Reflection and amplification cause third-party systems to send replies toward a spoofed victim address. Amplification makes the replies larger or more numerous than the triggering requests.

These categories can overlap. A campaign may change vectors as defenders apply controls.

Start with the service, not the attack name

Inventory the complete delivery path for each critical service:

name resolution
    ↓
network path
    ↓
edge and traffic distribution
    ↓
application and identity controls
    ↓
data stores and external dependencies

Record the owner, provider contacts, public addresses, protocols, normal traffic, maximum tested load, scaling limits, and acceptable degradation. Include supporting services such as Domain Name System resolution and identity. A healthy application is still unavailable when users cannot resolve its name or sign in.

Define a service-level objective for availability and latency. Then determine which resources can fail that objective. This converts a vague DDoS concern into measurable capacity and response decisions.

Place controls before the bottleneck

A control on the origin server cannot recover an already saturated internet link. Large floods usually require upstream capacity and filtering from an internet service provider, cloud edge, content delivery network, or DDoS mitigation provider.

Distribute public traffic across an edge with enough capacity to absorb and classify it. Hide the origin from direct internet access where the architecture permits it. Allow origin traffic only from the approved edge or private path. Otherwise, an attacker can bypass the protected route and target the origin address.

Use multiple layers because each layer sees different evidence:

Layer	Useful controls	Main limit
Network provider	Scrubbing, source validation, traffic diversion, flow filtering	Needs prearranged routing and provider support
Distributed edge	Anycast distribution, packet validation, connection proxying, rate controls	Cannot understand every business operation
Web application firewall	Request inspection and rate-based rules	Encrypted or valid-looking requests can still consume origin work
Application	Authentication, per-identity limits, bounded work, queues, caching	Acts too late for a saturated upstream link
Dependency	Timeouts, concurrency limits, circuit breakers, quotas	Cannot restore capacity already lost elsewhere

Defense is an architecture, not a single appliance.

Match the control to the exhausted resource

Volumetric attacks

Measure both bits per second and packets per second. A high bit rate threatens link capacity. A high packet rate can exhaust packet-processing capacity before the link is full.

Move mitigation upstream. Use provider filtering or scrubbing, distributed edge capacity, and traffic engineering. Source address validation reduces the ability of networks to originate spoofed traffic. It is an ecosystem control: your network should deploy it, but you cannot assume every other network does.

Remote blackholing can discard traffic for a target before it reaches a congested link. It also discards legitimate traffic. Treat it as an emergency containment option when protecting other services is more important than preserving the targeted destination.

Protocol-state attacks

A TCP SYN flood attempts to fill state reserved for half-open connections. Common mitigations include SYN caches, SYN cookies, proxies, filtering, and carefully tuned connection handling.

The broader design principle is to delay expensive state allocation until the peer has shown evidence that it can receive traffic. Apply the same reasoning to transport handshakes, authentication challenges, and session creation.

Do not tune one queue or timeout in isolation. A larger queue consumes more memory. A shorter timeout can reject legitimate clients on slow paths. Test changes with representative traffic and failure conditions.

Application-layer attacks

Application requests can look valid while causing expensive work. One request might trigger a search, report, cache miss, database query, file conversion, or third-party API call.

Bound the work that one caller can cause:

limit request rate and concurrent work;
cap payload, batch, page, and response sizes;
set execution deadlines and cancellation;
cache safe repeated results;
queue work with bounded depth;
apply per-identity, per-operation, and per-resource quotas;
shed optional work before critical work;
isolate expensive dependencies with concurrency limits and circuit breakers.

Rate limiting is admission control, not a complete defense. A limit that is too broad can block many legitimate users behind one address. A limit that is too narrow can be bypassed through distributed identities or addresses. Combine signals and protect the scarce resource directly.

Design graceful degradation

Your goal is useful service, not perfect feature parity during an attack. Identify the smallest critical service and the features you can temporarily reduce.

Examples include serving cached read-only content, disabling expensive search filters, lowering unauthenticated quotas, pausing nonessential background work, or protecting authenticated transactions ahead of anonymous browsing.

Every degradation action needs an owner, trigger, rollback condition, and user communication plan. An emergency switch that nobody has tested is only a hypothesis.

Detect impact, not just traffic

Build a baseline for normal traffic by protocol, region, endpoint, response status, latency, and resource use. Alert on changes that threaten the service objective.

Track both attack and service signals:

Attack signal	Service signal
Bits and packets per second	External availability
Connections and handshake failures	Error rate and latency
Requests by endpoint and identity	Queue depth and saturation
Allowed, counted, and blocked traffic	Dependency health
Source, destination, protocol, and flags	Successful critical transactions

An increase in blocked traffic can show that a control is working. It does not prove that users are succeeding. Confirm service health from outside the protected environment.

Source addresses are weak evidence during spoofed or reflected attacks. Use them as one traffic dimension, not as an identity claim.

Prepare the response before the flood

Write a DDoS response runbook with these elements:

Define the service-impact trigger and who declares the incident.
Record provider escalation paths, account identifiers, protected resources, and round-the-clock contacts.
Preserve current architecture, address ranges, normal traffic, and tested capacity.
Preapprove traffic diversion, stricter limits, emergency filters, degradation, and blackholing where appropriate.
Define evidence to capture without overwhelming the logging system.
Assign internal and external communication owners.
Define recovery and rollback checks.

During an event, verify user impact first. Classify the exhausted resource and attack dimensions. Engage the provider early when the bottleneck is upstream. Apply the least destructive control that protects critical service. Watch for vector changes and collateral blocking.

After mitigation, keep heightened monitoring while removing temporary controls in stages. Compare the event with the baseline. Record which bottleneck failed first, which controls helped, which legitimate users were affected, and which contacts or decisions caused delay.

Test safely

Never generate unapproved flood traffic on the public internet. Coordinate tests with every hosting, network, and mitigation provider involved. Use a controlled environment and written limits.

Test decisions as well as capacity. Tabletop exercises can reveal expired contacts, unclear authority, missing telemetry, and untested rollback steps without sending attack traffic. Controlled load tests can then validate application limits and degradation behavior within authorized boundaries.

Limits of denial-of-service defense

More capacity buys time; it does not remove every bottleneck. Autoscaling can move exhaustion to a database or create uncontrolled cost. A web application firewall cannot repair a saturated upstream link. Blocking an address can harm legitimate users and may fail against spoofed or distributed traffic.

No architecture guarantees availability against every attack scale and vector. Good defense makes bottlenecks explicit, moves filtering upstream, bounds work, preserves critical functions, and shortens coordinated response.

A practical adoption path

Select one critical public service and map its entire delivery path.
Define user-visible availability and latency objectives.
Measure normal traffic and the capacity of each limiting resource.
Confirm provider protection, escalation, traffic-diversion, and origin-access arrangements.
Add limits for connections, requests, concurrency, payloads, queues, dependencies, and cost.
Define a minimum service and test graceful degradation.
Build dashboards that connect traffic dimensions to user-visible health.
Run a tabletop, then an authorized load and mitigation exercise.
Update architecture and runbooks from the results.