Layer 7 DDoS attacks have changed. Short bursts, millions of IP addresses, minimal payload. By the time an alert fires, the damage window has often already passed. In 2025, 70% of applications faced at least one DDoS attack, and 60% of those required behavioral detection to stop because static rate limits alone were not enough. This guide is a practical first 30-minutes runbook for SRE, DevOps, and Security teams responding to a suspected Layer 7 DDoS on websites and APIs.
Is this actually a Layer 7 attack? Confirm before you act
If you have not confirmed your symptoms yet, start with our DDoS symptoms guide before committing to a response path. Treating the wrong attack type costs you the first 10 minutes, and in a Layer 7 incident, that is often the most expensive mistake.
This runbook is optimized for suspected application-layer DDoS on websites and APIs, where traffic often looks valid at first and the real job is fast confirmation and targeted mitigation. If the issue is a pure upstream bandwidth flood, your ISP or network provider may also need to be engaged in parallel.
The core problem is this: a Layer 7 flood and a volumetric flood can look identical from the outside. Both cause slowdowns, errors, and timeouts. But the response path is completely different. Before your team commits to any mitigation steps, check for these three signals.
Signal 1: Where is the strain showing up first? Layer 7 attacks stress your app CPU, thread pool, database connections, or cache before bandwidth is saturated. If your network throughput looks normal but your app server is struggling, that is application-layer. If bandwidth is pinned and everything on the shared link degrades together, that is volumetric.
Signal 2: Is one endpoint taking the hit? Pull your top URLs by request volume. In a Layer 7 flood, one route almost always stands out: login, search, checkout, or a specific API path. If one route is absorbing a disproportionate share of traffic while the rest of the site looks relatively normal, you are looking at application-layer.
Signal 3: Do the requests look structurally valid? Layer 7 traffic uses real HTTP methods and correctly formed requests. Pull a sample from the hotspot and look for repetition: identical user agents at high volume, no session tokens where you would expect them, or timing patterns too uniform to be human.
In this guide, “hotspot” means the specific page, route, or API path getting a disproportionate share of requests during the attack, for example a login page, search route, checkout path, or authentication API.
All three signals present? You are dealing with a Layer 7 attack. Move to Section 2.
Not sure? Use this table to confirm.
| Signal | Layer 7 attack | Volumetric attack |
|---|---|---|
| Where strain appears first | App CPU, threads, DB, cache | Bandwidth, packets per second |
| Endpoint pattern | One or few routes hammered | Broad, no clear hotspot |
| Request structure | Valid HTTP, repetitive patterns | Malformed or high-volume packets |
| Network throughput | Often normal or moderate | Pinned near link capacity |
| Other services affected | Usually isolated to the app | Everything on the shared link degrades |
| IP blocking effect | Little to no impact | Can help, not sufficient alone |
Once confirmed, move to Section 2 and split your team into response lanes before anyone touches a rule.
Own Your Lane: How Three Parallel Workstreams Contain a Layer 7 Incident Faster
When teams reach out through our under attack page mid-incident, one pattern shows up repeatedly: everyone is working the problem, but in the same place. One person is checking logs, another is on the same dashboard, and the origin is still directly reachable. In the first two minutes, speed comes from parallel checks, not perfect analysis. Split the team into three lanes before anyone starts making multiple changes.
Three lanes, assigned before mitigation begins.
Lane 1: WAF or security engineer — owns the edge Rate limits, WAF rules, challenge flows, and bot controls. All edge-layer decisions run through this lane.
Lane 2: SRE or DevOps engineer — owns the origin Connection timeouts, load balancer health, direct origin exposure, and graceful degradation. All origin-side decisions run through this lane.
Lane 3: Communications owner — owns stakeholder updates Status page, internal updates to leadership, and customer-facing communication. Keeping this lane active means the other two are not interrupted by status requests while working the incident.
For enterprise teams with dedicated security and infrastructure functions, these lanes map naturally to existing roles. For smaller teams where one person covers both security and infrastructure, the lane structure still applies. Treat them as parallel workstreams rather than sequential steps and be explicit about which workstream you are in at any given moment.
Everything in Sections 3 and 4 maps back to these three lanes.
If your team has a dedicated SRE function, make the SRE lane explicit from minute zero. Security usually sees traffic shape first, but SRE sees service degradation first through latency, error rate, and origin health. Running those signals in parallel is what helps teams separate a Layer 7 attack from a normal outage quickly.
Minutes 0–15: First Moves That Determine How the Next 15 Go
The 15-minute mark is a guide, not a hard stop. Work across all three lanes overlaps and feeds into each other in real time. Use the role labels to skim directly to your lane.
Here is how all three lanes run in parallel across the first 15 minutes.
| Minute | WAF / Security Engineer | SRE or DevOps Engineer | Communications Owner |
|---|---|---|---|
| 0–2 | Identify the hotspot endpoint from traffic analytics | Verify origin is not directly reachable | Open incident channel and notify the response team |
| 2–5 | Apply per-route rate limiting on the hotspot | Flag origin exposure to WAF engineer if found | Post first public status update |
| 5–10 | Enable challenge flows (CAPTCHA or crypto challenge) on the hotspot | Tighten load balancer timeouts on hot endpoints | Set internal update cadence with incident owner |
| 10–15 | Make one rule change, observe for 2–3 minutes before the next | Confirm origin is not scaling out to absorb flood traffic | Send first internal update to leadership |
| Ongoing | Share block and challenge rates with SRE every few minutes | Share origin health status with WAF engineer every few minutes | Hold cadence, keep updates brief and factual |
Here is what each lane is doing and why the sequence matters.
WAF or security engineer
Start with the hotspot endpoint instead of just looking at source IPs. In a Layer 7 flood, blocking IPs reactively produces very little result when the attack is rotating across thousands of sources. The endpoint is the constant. Find it first.
Once identified, apply per-route rate limiting on that endpoint. If you have baseline traffic data, use it to set a starting threshold. Without it, start conservative and adjust. The tradeoff is real: a threshold set too tight starts blocking legitimate users, too loose and the flood continues unchanged. Aim for the point where attack traffic is visibly throttled but conversion-critical actions like login completions are still succeeding.
Before reaching for hard blocks, enable challenge flows such as crypto challenges or CAPTCHA on the hotspot. Challenges separate bots from real users without taking the endpoint offline, which hard blocks do not allow for.
Make one change, then wait two to three minutes and observe the effect before making another. Stacking multiple rule changes simultaneously makes it impossible to attribute what worked and what made things worse.
SRE or DevOps engineer
The first check is origin exposure. Attackers frequently bypass the CDN or WAF entirely by targeting the origin IP directly. If the origin is reachable without going through the edge, that changes the entire threat picture. Flag this to the WAF engineer immediately if you find it, because no amount of edge-layer rule tuning will help if traffic is bypassing the edge.
Once confirmed or ruled out, tighten connection timeouts on the load balancer for the hotspot endpoints. Shorter timeouts reduce resource lockup and free up capacity faster. The caveat is worth noting: cutting timeouts too aggressively will start failing legitimate long-running requests such as file uploads or report generation. Tune with that in mind.
Do not scale out origin capacity to absorb the flood. Scaling helps during legitimate surges where more capacity means more throughput. Against a Layer 7 flood, it increases your infrastructure bill while the attack continues at the same intensity.
Keep the WAF engineer updated on origin health every few minutes. Rate limit decisions at the edge depend heavily on what is happening at the origin, and assumptions made without live data lead to rules that are either too aggressive or too passive.
Communications owner
Post a status update within the first five minutes, even if the root cause is still being confirmed. A single line such as “We are investigating increased error rates and will update shortly” is enough. The absence of any update generates more inbound noise than a brief, honest one, and that noise lands on the people actively working the incident.
Set an internal update cadence with the incident owner, every five to ten minutes, and stick to it. Predictable updates keep leadership and stakeholders from reaching out directly to the engineers working the problem.
Minutes 15–30: Read the Signals, Adjust, and Know When to Call for Help
The 15-minute mark is not a reset. All three lanes stay active and the work overlaps. The shift in this window is one of intent. The first 15 minutes were about getting controls in place. This window is about reading whether those controls are working and deciding what to do next.
Here is how all three lanes run in parallel across minutes 15 to 30.
| Minute | WAF / Security Engineer | SRE / DevOps Engineer | Communications Owner |
|---|---|---|---|
| 15–18 | Check if error rate on hotspot is dropping and block rate is rising | Reassess origin strain after initial mitigations | Post second public status update confirming mitigation is underway |
| 18–22 | If block rate rises but error rate holds, shift from IP blocks to behavioral rules | Revisit timeout and connection limits based on current edge signals | Align with incident owner on whether leadership needs a separate brief |
| 22–25 | Distinguish HTTP flood from bot attack in logs and adjust mitigation path | Consider serving maintenance response on hotspot if origin is still strained | If no clear improvement by minute 20, brief leadership proactively |
| 25–30 | If two rounds of tuning have not moved error rate, prepare evidence package and escalate | Share live origin health with WAF engineer to inform escalation decision | Notify users that investigation is ongoing and update ETA |
| Ongoing | Keep capturing rule change log with timestamps | Keep communicating origin health to WAF engineer | Hold update cadence without waiting to be asked |
Here is what each lane is actually doing and why the sequence matters.
WAF or security engineer
Three signals tell you mitigation is working: the error rate on the hotspot is dropping, your WAF block and challenge rate is rising, and the origin CPU and backend strain reported by the SRE is starting to ease. All three moving together is a good sign. One or two without the third usually means the attack is still getting through somewhere.
The signal that tells you the attacker has adapted is specific: block rate rises but error rate does not drop. This usually means the attack is rotating IP ranges or changing request patterns fast enough to stay ahead of your current rules. When this happens, stop adding IP-based blocks and shift to behavioral rules that look at request sequences, session patterns, and timing rather than source addresses.
Check whether the attack is mostly HTTP flood behavior, bot-driven behavior, or both, and adjust mitigation path. This is also the point to look more carefully at how the Layer 7 attack is behaving. In practice, an incident can be both an HTTP flood and bot-driven at the same time. HTTP flood describes the attack behavior at Layer 7. Bot attack usually describes the source pattern or automation behind it. The practical takeaway is to choose the fastest mitigation path for what you are seeing. If traffic is repetitive and automated, raise behavioral controls, challenges, and bot protections. If one route is getting hammered, protect that endpoint first and reduce expensive work behind it.
SRE or DevOps engineer
If the origin is still under strain after the first round of mitigations, consider temporarily returning a maintenance response on the hotspot endpoint while WAF rules continue taking effect. This is a hard call because it means real users on that endpoint get a maintenance page rather than a slow or erroring response. The tradeoff is that it protects everything else running on the origin while the edge-layer controls stabilize.
Revisit timeout and connection limit settings based on what the WAF engineer is seeing at the edge. If block rates are rising and fewer requests are reaching the origin, it may be safe to ease some of the more aggressive timeout settings that were protecting the origin in the earlier window. If the attack is still getting through, hold or tighten them. The two lanes need to be talking directly here because edge rule changes directly affect what reaches the origin, and origin health directly affects what rate limits make sense at the edge.
Communications owner
Post a second update confirming that mitigation steps are underway. Stakeholders and users do not need technical detail. They need to know the team is actively working the problem and when to expect the next update. Keeping the language simple and the cadence predictable reduces inbound noise more than any amount of technical explanation.
If the incident is running past 20 minutes without clear improvement, brief leadership separately and proactively. Being caught off guard at minute 25 is harder for leadership to absorb than a short, calm update at minute 20 that says the team is still working it and escalation is being considered.
When to Stop Tuning and Call for Help
The threshold for escalation is worth deciding before an incident starts, because optimism under pressure has a way of delaying the call by exactly the wrong amount of time. If two rounds of rule tuning have not moved the error rate in 15 minutes, stop trying to out-tune the attacker manually and get managed help on the call.
When you escalate, have the following ready because the SOC team will ask for it the moment they join: top endpoints and their request rates during the peak window, top source IPs and ASNs if available, screenshots of key metrics including error rate, p95 latency, and origin CPU, and a timestamped log of every rule change made since the incident began. Having this package ready cuts the time to effective mitigation significantly.
If you are an AppTrana customer, this section may feel academic. The SOC team monitors for anomalies around the clock and will already be reaching out to start mitigation before you have finished reading this far.
For everyone else, that is probably worth knowing.
Reach out through our under attack page and our security engineers will join you live.
Four Things Teams Almost Always Get Wrong in the First 30 Minutes
- Chasing source IPs instead of the target endpoint – In a Layer 7 flood, the attack rotates across thousands of IP addresses. Blocking them one by one feels productive but changes nothing. The endpoint being targeted is the constant. Start there.
- Scaling out origin capacity to absorb the flood – Spinning up more instances makes sense during a legitimate traffic surge. Against a flood, it just means more servers absorbing attack traffic at your expense while the error rate stays exactly where it was. Push mitigation to the edge first.
- Stacking multiple WAF rule changes at once– When the pressure is on, the instinct is to do everything simultaneously. The problem is that if the error rate moves after three simultaneous changes, there is no way to know which one worked or which one started blocking real users. One change, observe, then decide.
- Disabling caching on the hotspot to “see what is really happening”Caching absorbs a significant share of requests before they ever reach the application. Turning it off during an active flood to get cleaner diagnostic data removes one of the cheapest defenses available at exactly the wrong moment. Read logs from your CDN or WAF instead.
If your team is dealing with a Layer 7 attack right now, reach out through our under attack page, and we will get on a call with you immediately.
