Availability is the target
A service can become slow or unreachable when demand exhausts a constrained resource. That resource may be a network link, packet-processing capacity, connection state or application work - not just bandwidth.
DDOS PROTECTION
Understand how DDoS protection works.
Learn how bandwidth, packets, connections and application requests create different pressures - and why the protection model must match the service.
Bandwidth
Packets
Connections
Requests
01 / FOUNDATIONS
What a DDoS attack actually stresses.
Distributed denial of service (DDoS) disrupts availability by directing load from multiple sources toward a service or the infrastructure it depends on.
Distribution changes the problem
Traffic arriving from many sources makes a simple source-based decision insufficient. Defensive analysis needs the service context and legitimate usage patterns alongside the observed load.
Categories can overlap
Volumetric pressure consumes delivery capacity. Protocol or state pressure consumes processing and retained state. Application pressure consumes request-handling resources. One incident can involve more than one category.
02 / DIMENSIONS
Bandwidth, packets, connections and requests.
One large number cannot describe every attack. Read the dimension, measurement boundary and affected resource together.
| Dimension | Unit / observation | Stressed resource | Interpretation limit |
|---|---|---|---|
| Bandwidth | Bits per second (bps) | Link and upstream delivery capacity | Volume alone does not describe packet, state or application cost. |
| Packets | Packets per second (pps) | Packet-processing work | Packet size changes the relationship between packet rate and bit rate. |
| Connections | New connections per second; concurrent sessions | Connection establishment and retained state | Concurrency is an occupancy, not a rate; both can matter. |
| Requests | Requests per second (RPS); work per request | Web workers, database, cache and backends | Equal request rates can create very different application loads. |
03 / LAYERS
Layers and resource exhaustion.
L3, L4 and L7 describe different protocol responsibilities. They help locate the problem without making attack categories mutually exclusive.
L3 · Network / IP
The network layer carries IP traffic across networks. Excess volume can strain link capacity, while packet handling can strain network processing. Volumetric pressure is a resource description, not a complete account of the traffic’s protocol layer.
L4 · Transport / state
The transport layer manages communication such as TCP connections. Connection establishment and retained state can consume finite resources. SYN-related pressure is one conceptual example; new connections per second and concurrent sessions measure different things.
L7 · Application / requests
Application requests can occupy web workers and trigger database, cache or backend work. A request need not exploit a software vulnerability to be expensive. Application exhaustion can happen before a network link becomes saturated.
04 / MITIGATION
How mitigation makes decisions.
Mitigation applies controls to reduce harmful load while maintaining useful service. The following is a conceptual model, not a universal provider pipeline.
Observe and classify
Observation may include volume, packet characteristics, connection behavior, request patterns and normal baseline context. Detection identifies a possible problem; observation alone does not remove load.
Filter, rate or validate
Controls may reject traffic, constrain a rate or validate a client interaction where appropriate. The choice depends on protocol, deployment and service needs. A false positive is a decision that affects legitimate traffic.
Forward and monitor
Permitted traffic continues toward the service. Monitor application health and legitimate-user impact as well as traffic levels. “Clean traffic” means traffic allowed through the controls, not a guarantee that every request is benign.
Incoming load
Mitigation
Filtered
Allowed traffic
Protected service
Always-on and on-demand
Always-on arrangements keep the relevant protection path engaged during normal operation. The exact controls and supported traffic still depend on the deployment.
On-demand arrangements activate or redirect to mitigation when needed. Activation, operational ownership and transition behavior must be agreed; neither model supplies a universal detection or recovery time.
05 / MITIGATION
Network mitigation and web reverse proxies.
These controls operate at different boundaries. The comparison concerns web reverse proxies; other transport-proxy designs also exist.
| Question | Network-oriented mitigation | Web reverse proxy |
|---|---|---|
| Where does it sit? | At an upstream or network boundary in the configured delivery path. | Between web clients and an origin application. |
| Which traffic is supported? | Depends on the protected network, protocols and service scope. | HTTP / HTTPS in this comparison; it does not cover every protocol. |
| What context is available? | Network and transport signals, with additional context depending on implementation. | Web-request context where the deployment can access it. |
| What about the origin? | Reachability depends on routing and access policy. | Origin separation needs deliberate access controls; proxying alone is insufficient. |
| What compatibility matters? | Supported protocols, routing and service requirements. | Application behavior, certificates and suitable TLS termination for HTTPS inspection. |
| Does it enlarge the uplink? | No. Protection and service delivery remain separate constraints. | No. Forwarded requests still consume origin delivery and application capacity. |
For HTTPS application inspection, a suitable point must have access to application context, commonly through agreed TLS termination. Do not assume a network control can inspect arbitrary encrypted request content.
06 / CAPACITY
Protection capacity and the service uplink.
Mitigation capacity describes a protection boundary. It does not turn the protected service’s network port into a larger port.
Scope the protection number
Ask whether a stated capacity describes a provider pool or an individual service, which dimension it measures and what limits apply. Aggregate protection capacity is not automatically dedicated to one customer.
Keep delivery capacity separate
The service uplink is the connection carrying traffic to or from the service. Allowed traffic still uses its finite delivery capacity. Legitimate high-bandwidth streaming needs sustained delivery; a bigger port alone does not provide better DDoS mitigation.
Account for application work
Filtered traffic still reaches finite CPU, workers, database, cache, storage and network resources. A successful filtering decision does not repair application bottlenecks or create processing capacity.
Mitigation capacity
Allowed traffic
Service uplink
Application capacity
07 / ORIGIN
Origin exposure and service design.
The origin is the service behind a proxy or delivery layer. Its access design must match the intended protection path.
Define expected ingress
If an origin remains directly reachable outside the intended protection path, application-facing controls may not cover that traffic. Review which upstream sources and service paths should reach it.
Assign access ownership
Coordinate firewall and access policy with the responsible operator. Preserve administration and monitoring through deliberately scoped access. A protection change should not accidentally remove the ability to manage the service.
Check compatibility
Review protocols, dependencies, certificates and TLS termination - the point where encrypted transport ends. Confirm how application traffic and supporting services fit the design before changing access.
08 / RESILIENCE
Resilience and realistic expectations.
Protection reduces a class of risk. A resilient service also needs capacity planning, recovery arrangements and clear operational ownership.
Leave workload headroom
Headroom is spare capacity for legitimate peaks and growth. Plan it around normal demand, expensive application work and dependencies. Mitigation does not guarantee application health or infinite capacity.
Separate the functions
DDoS mitigation controls harmful load. Redundancy supplies alternative capacity or paths for relevant failures. Backups support recovery of data. Monitoring supplies observations. These functions address different problems.
Set realistic expectations
Protection does not automatically guarantee zero downtime, zero latency, zero packet loss or zero false positives. It cannot promise coverage of every attack or recovery from unrelated infrastructure failures.
09 / RESILIENCE
Before deployment and during an incident.
Prepare decisions and evidence while the service is healthy. During disruption, keep observed symptoms separate from unverified conclusions.
Before deployment
- Identify services, protocols and required user experience.
- Record normal bit/packet/request rates and concurrent sessions, with measurement scope.
- Characterize legitimate peaks and expensive application work.
- Confirm service uplink and normal delivery requirements.
- Confirm supported layers, protocols and mitigation limits with the provider.
- Review expected origin ingress paths and access ownership.
- Confirm TLS termination, certificates and application compatibility.
- Confirm service locations and dependencies without assuming mitigation topology.
- Agree detection/activation model, escalation and management responsibilities.
- Document tested response/recovery procedures and capacity-review triggers.
When an attack is suspected
- Identify affected service, users and scope.
- Capture timestamps with timezone and duration.
- Record traffic and application symptoms without assuming cause.
- Check application, network and dependency health through established observability.
- Preserve sanitized logs and observations; omit credentials and customer payloads.
- Contact agreed provider/support responders with the evidence and service identifier.
- Follow tested response procedures; avoid untested emergency changes and verify legitimate-user recovery.
MATCH PROTECTION TO REQUIREMENTS
Plan protection around your service.
Bring your protocols, normal traffic patterns and operational responsibilities into the protection discussion.