During a suspected layer 7 bot attack, first identify the resource that is failing and the requests consuming it. Containment should reduce work before that bottleneck while preserving a usable path for legitimate traffic.
A large request count is not required. AWS documents that application-layer attacks can overload specific functions with relatively low traffic volumes. Request rate and application work are different measurements.
If the network link is saturated before your application can receive traffic, involve the network or upstream protection provider. An application rule cannot recover capacity it never gets to use.
Establish impact and assign one change owner
Record the affected user journey, start time, known deployment changes, and the service that first shows distress. Name an incident lead and one owner for traffic-policy changes so two teams do not unknowingly counteract each other.
Preserve a small, redacted sample of request evidence. Keep the full operational logs in their existing restricted system. Do not copy credentials, raw request bodies, or private customer records into an incident chat.
Separate confirmed observations from assumptions. “Search workers saturated while one query family increased” is useful. “A huge botnet attacked us” requires evidence you may not yet have.
Find the scarce resource
OWASP's denial-of-service guidance distinguishes application, session/protocol, and network exhaustion. Use that distinction to choose the response owner and enforcement point.
| Observed bottleneck | Inspect next | Candidate containment |
|---|---|---|
| Search workers | Query family and concurrency | Bound expensive search operations |
| Database capacity | Routes and query work | Restrict the contributing operation |
| Background queue | Admission rate and oldest job | Bound new jobs and duplicate submissions |
| Origin requests | Cache behavior and route mix | Restore safe caching or limit origin-bound work |
| Network bandwidth | Upstream and edge visibility | Escalate to the network protection path |
These are options to evaluate against your architecture, not commands to apply blindly during an incident.
Make one narrow change and observe it
Prefer a clearly scoped intervention: one expensive route, one client class, or one operation whose allowance is being exceeded. Record the configuration version and rollback action before enforcement.
Where supported, reduce admitted work before expensive processing begins. A rule evaluated after the database query may reject the response without relieving the database.
Do not create an unlimited queue as an alternative to rejection. That can postpone the failure and make recovery harder. Decide how the application communicates temporary unavailability to cooperative clients.
If identity is uncertain, use it as an investigation lead rather than a reason to block a broad shared network. Keep verified integrations and critical workflows visible in the impact review.
Check recovery from the user's side
A healthier CPU graph does not establish recovery if legitimate users are now blocked at the edge. Verify the affected journey through the normal public entry point using an authorized test account.
Compare successful work, failure rate, backlog, and the requests affected by the new control. Also check whether retries or traffic moved the load to a different route.
If the intervention does not reduce the bottleneck, revisit the causal assumption. Do not stack unrelated rules merely because the incident is still active.
Leave a usable incident record
Record what failed, what evidence linked the requests to that failure, which control changed, and what recovered. Keep unresolved questions explicit. Schedule removal or review of temporary exceptions and restrictions.
The traffic-spike diagnostic guide helps when the cause remains uncertain. The traffic flood use case frames the product boundary, including the distinction between application automation controls and upstream capacity protection.
Close the incident when the intended user journey is working and the emergency configuration has an owner, not simply when the request graph looks quieter.