When a public service slows down, the first question is not simply whether traffic has increased. It is whether legitimate requests are failing because a particular resource is exhausted, and whether the traffic pattern fits a deliberate denial-of-service attempt. Recognizing the early signs of a distributed denial-of-service (DDoS) attack requires a baseline, a view of the application, and visibility into the network path before the origin. A busy launch, an upstream routing issue, a failed dependency, and a DDoS attack can initially look similar.
This article follows the incident investigator’s decision: what to measure first, how to separate network saturation from application exhaustion, when to escalate to an upstream provider, and what evidence to preserve. A DDoS attack can come from large botnets, reflected traffic, or coordinated HTTP clients. None of these patterns can be diagnosed reliably from a single spike on a dashboard.
Establish what normal traffic and service health look like
Start with the most recent comparable hour, day, or business event. Record typical requests per second, bandwidth, concurrent connections, error rates, response times, and successful transactions. A retail launch can produce a real traffic surge; the fact that it is unusually large does not make it malicious. Conversely, an application-level attack can disable a database or expensive search endpoint without a spectacular bandwidth graph. Baselines should consider time of day, geography, marketing activity, and known scheduled jobs.
Build alerts around relationships between metrics rather than a single threshold. For example, a rapid growth in incoming requests accompanied by falling successful transactions and sharply rising 503 responses is more concerning than higher requests with stable success and normal latency. If the load balancer reports healthy responses while users cannot reach the service, investigate DNS, routing, and the upstream path. If connections establish but queue behind a saturated worker pool, the bottleneck is likely closer to the application.
Make monitoring actionable by attaching an owner to every signal. Network operations need bandwidth and packet telemetry, application responders need HTTP methods, URLs and error distributions, and service owners need customer impact. Test the alert path before an incident: an alarm that nobody receives or understands does little to reduce downtime.
Recognize the early symptoms without mistaking an outage for an attack
The most useful symptom is a change in the ratio of workload to useful results. Watch for connection timeouts, sharply increased latency, elevated 429 or 5xx responses, and a sudden drop in completed logins, purchases or API calls. If normal request volume remains steady but database latency rises, investigate an application fault as seriously as a hostile request flood. If legitimate users in one region fail while others succeed, compare internet routes and CDN points of presence rather than assuming the origin has collapsed.
Request characteristics matter. Unexpected concentrations on costly endpoints, bursts of nearly identical requests, abnormal user-agent or session distributions, and unusually high connection churn can justify closer inspection. But an attack can mimic ordinary browsers, and legitimate automated clients can look suspicious. Confirm intent only as far as the evidence allows; mitigation decisions can be made on observed harm even while attribution remains uncertain.
Compare edge telemetry with origin logs. A CDN might absorb a surge that the origin never sees. On the other hand, direct-to-origin traffic can bypass controls and expose the server even while CDN statistics look reassuring. The same timestamp and application request identifiers should connect edge, firewall, load-balancer, application and infrastructure records. Clock synchronization and retention are essential when the affected system is unstable.
Two comparisons catch many false alarms. First, look at requests and successful business events together: a campaign that doubles traffic and doubles completed orders is unlike a flood that raises requests while reducing orders to almost zero. Second, compare the same endpoint from several regions and from inside the hosting environment. A regional route failure may resemble an attack from one network while other users remain healthy. Keep the decision tentative until the paths are reconciled.
A monitoring team should also record which observation is primary and which is derived. CPU usage from a single host, a load balancer’s median response time, and a cloud service’s sampled mitigation event do not measure the same population. Define alert windows and clock sources so an investigator does not mistake a five-minute aggregate for a sharp one-second burst. Keep enough resolution for useful evidence without collecting sensitive payloads unnecessarily.
Determine which layer is being exhausted
Volumetric attacks try to saturate links or upstream processing capacity. Packet- and bandwidth-rate spikes, dropped packets and near-capacity interfaces may be more revealing than HTTP logs. A target whose upstream link is full cannot recover merely by installing a firewall rule at the already-saturated origin: the traffic must be filtered or absorbed before it reaches that bottleneck. Internet service providers and scrubbing services are therefore often part of the response.
Network and transport exhaustion includes connection-state pressure, such as high rates of TCP SYN packets that consume tracking resources. A rate of new connections out of proportion to completed handshakes or useful requests can be a clue. Protocol-specific defenses and correctly sized connection limits can help, but aggressive thresholds can also disconnect legitimate clients behind shared IP addresses.
Application-layer attacks target operations that require substantial CPU, database access, memory or dependency calls. A relatively modest request rate against search, login, checkout or report generation can degrade service. Distinguish inexpensive cached requests from expensive uncached ones. WAF rate controls, bot detection, origin shielding, caching and application-level capacity controls may be more relevant here than generic network filtering. No single mechanism covers every layer.
Investigate botnets, reflection and IoT devices with evidence
Distributed requests often originate from compromised computers, hosted systems or insecure internet-connected devices. An Internet of Things (IoT) camera or router may participate in a botnet without its owner knowing. Distributed origins make blanket address blocking unreliable, but the number of sources alone is not a measure of severity: the real questions are how much harmful traffic reaches the service and how quickly legitimate work is displaced.
Reflection and amplification can make the apparent sources misleading. An attacker can send requests that cause third-party servers to direct much larger replies toward a victim; source-address spoofing is relevant to some network-layer variants. For such traffic, investigate protocol patterns and upstream anti-spoofing or filtering rather than attempting to identify every compromised sender from a web server log. An HTTP flood can involve different behavior and requires application telemetry.
Not every flood is a botnet, and not every botnet-related event is a DDoS. Correlate threat intelligence carefully: a flagged address or device family is a lead, not proof that all matching traffic is malicious. Share packet captures, request summaries, timestamps and provider alerts with the incident lead while protecting sensitive customer data.
Take the first response actions in a safe order
Declare impact before naming an adversary. Record which services, regions and customers are failing, then activate the on-call and provider escalation process. Protect logs and operational snapshots, but do not delay mitigation solely to complete attribution. If traffic saturates the link before reaching the application, call the upstream or DDoS provider early; local application adjustments cannot restore bandwidth already exhausted outside the network.
Choose mitigations that match the failing layer. Upstream diversion or scrubbing addresses large network floods; connection controls can help with state exhaustion; application rate rules, caching, bot challenges or endpoint-specific throttling can reduce expensive HTTP floods. Preserve a path for legitimate users: test rate limits against shared carrier networks, accessibility requirements, and known partner integrations. Extreme blocking may turn an attack into a self-inflicted outage.
Do not confuse endpoint malware controls or employee VPNs with public-service DDoS protection. Antivirus can reduce the risk that an owned device joins a botnet, and a VPN can protect a user connection, but neither normally absorbs a flood aimed at an organization’s public ingress. For resilience, separate ingress capacity, application limits, dependency protection and tested escalation procedures.
Consider a two-stage incident: a high-rate UDP flood saturates an edge link, and then a smaller HTTP flood targets an expensive search route. Upstream filtering may solve the first symptom while the search failure remains. The incident leader should record the measured effect of each rule change and check a real user transaction after each step. If the target becomes stable but the application still returns errors, treat the remaining problem as a separate failure rather than declaring all mitigations ineffective.
Understand exactly what cloud DDoS services protect
Cloud controls differ by architecture and by layer. AWS Shield offers network and transport protection for relevant AWS resources, while additional application-layer measures depend on the protected service and configurations such as AWS WAF. Do not assume a product tier automatically shields an unprotected public origin. Verify where traffic enters, how the provider learns normal traffic, which support path is available during an event, and what changes are safe to make without disabling legitimate clients.
Azure DDoS protection covers qualifying Azure public-IP and network resources according to the selected protection model. It should be combined with application architecture and relevant web-layer controls rather than presented as a universal replacement for those controls. Test what diagnostic signals the service exports, how quickly responders can reach provider specialists, and whether protected and unprotected IPs have been correctly inventoried.
A CDN or application gateway can absorb some unwanted requests while a concealed origin continues serving valid traffic. But a public origin IP, an uncovered API hostname, or a database dependency can remain a separate failure path. Provider documentation is a starting point; deployment configuration and a controlled exercise are the evidence that the claimed protection actually applies.
Preserve evidence and avoid premature attribution
During an incident, collect an immutable timeline of alert onset, network throughput, connection counts, request/error rates, firewall actions and service impact. Include which filtering rules were enabled, when the provider began mitigation, and which customer operations recovered. A sudden traffic fall might reflect successful filtering, a client outage, or an attacker changing methods. Validate recovery with synthetic transactions and real application metrics, not traffic volume alone.
Treat geographical location, IP reputation and a single user-agent string as clues rather than identity. Shared gateways, cloud proxies, address spoofing and compromised devices weaken simplistic attribution. Avoid copying raw log payloads containing secrets into tickets or external tools. Record confidence, evidence gaps and next actions explicitly so the follow-up report is usable by responders who were not on shift.
Turn the incident into measurable readiness
The best post-incident result is a tested change, not a longer list of generic security products. Update baselines and response thresholds, close direct-origin exposure where feasible, exercise upstream escalation, and verify that edge and application logs retain the identifiers investigators need. Practice a tabletop scenario where a network flood and an application dependency failure occur together so the team does not treat one dashboard as definitive.
In Security+ study, DDoS is more than an attack definition: the SY0-701 objectives include distributed denial of service and indicators such as resource consumption. In practice, the valuable skill is distinguishing attack patterns, matching a defense to the bottleneck and proving that service has recovered. A site that can explain why a warning fired, what was changed and how user transactions recovered has stronger DDoS readiness than one that merely recognizes the name of an attack.
A useful recovery exercise includes three explicit acceptance criteria: a representative legitimate transaction completes within the service target, the network and application controls record which traffic was blocked, and the on-call team can turn temporary rules off safely after the incident. It also includes an exception path for shared IP addresses and essential partner integrations. Without such criteria, a dashboard can show a smaller attack even while legitimate users remain locked out.
