Why Unfiltered Traffic Is Dangerous: Configuring AWS WAF
Unfiltered traffic almost never looks like an attack — it looks like rising latency. The handler pool is occupied by similar requests to forms, search, and authorization, free connections run out, and the application stops accepting new requests.
The queue grows, the account area responds noticeably slower, and some requests time out before they even reach business logic.
Failure under load occurs before autoscaling can help: a new instance takes longer to come up than the burst lasts, and the traffic itself is distributed across hundreds of addresses, so blocking inside the application has no effect.
Standard protection tools do not see this web application overload: suspicious requests are syntactically correct, target existing addresses, and differ only in density and the spread of sources.
Configuring AWS WAF moves filtering to the perimeter — before a request occupies a handler. Managed rule sets cut off known attack classes, rate limiting rules temporarily block a source that exceeds a threshold, and automation-sign detection separates bots from live users.
All decisions go into the log, so you can see which rule fired and whether it affected real customers.
Next, we break down how such protection is built: where the filtering boundary lies, how thresholds are selected for your traffic profile, and what to do about false positives so you do not lose orders.
What Managed Request Filtering at the Perimeter Provides
Request filtering at the perimeter solves one problem: junk traffic must not reach the application and database.
Without it, the stream of scanners, bots, and credential stuffing occupies connections, warms up templates, and loads the database with requests that will never become an order.
The load profile becomes bursty: useful users wait in line behind those who are simply enumerating addresses.
AWS WAF is placed in front of the application and works at the level of an individual request, not a connection. Rules describe what to consider normal: request frequency from a single address, characteristic signatures of typical attacks, disallowed methods, and body sizes.
Managed rule sets cover common classes of automated attacks, while custom rules add product-specific details — for example, limits on frequent requests to login forms or search.
The key risk here is false positives: blocking a live user is more costly than letting a bot through. Therefore, new rules are first enabled in count mode and do not block traffic — they only log events.
From the log of blocked requests, you can see which paths and headers matched the rule, after which thresholds are adjusted before blocking is enabled.
The result is measured by three numbers: the share of requests cut off before the application, response time under peak load, and the number of database requests.
On a typical web service, the share of filtered junk is tens of percent, and that is exactly what leaves the queue to the application.
The application receives a steady stream, stability under load stops depending on who is scanning the perimeter today, and the log remains a working tool rather than an archive.
Perimeter Protection Options: What Teams Choose and Why
The choice of approach depends on the predictability of legitimate traffic and on where the application receives requests.
Ready-made rule sets cover typical attack classes almost immediately after connection, but their thresholds are averaged and produce false positives in non-standard scenarios.
Therefore, the start is observation mode: rules count matches and do not block, while logs show which paths and parameters fall under suspicion.
Custom filtering rules describe the logic of a specific application: request frequency to the login form, allowed parameter values, and the order of API calls. They are more precise but require maintenance — changing a scenario may require editing conditions.
The limitations of perimeter filtering should also be taken into account: the contents of a secure channel are not fully parsed, and distributed credential stuffing is visible only in the application.
| Option | When It Fits | Limitations |
|---|---|---|
| Ready-made rule sets | Standard web project, a basic barrier is needed quickly | Averaged thresholds, false positives in non-standard scenarios |
| Custom filtering rules | Non-standard forms, public API, many automated requests | Requires a test environment and regular review of conditions |
| Observation mode | First stage of implementation or a change in traffic pattern | Does not protect: requests reach the application |
| Protection only on the application side | Internal services whose traffic does not go through the perimeter | Load on the application, resources are consumed before inspection |
In practice, the options are combined: observation on ready-made rule sets, then custom rules for the application logic, and switching to blocking based on confirmed matches.
Implementation Stages: From Traffic Audit to Handover of Procedures
Configuring AWS WAF starting immediately with blocking rules almost always affects live traffic: integrations, payment flows, and mobile clients fall under the filter.
That is why we go from observation to restriction — first we capture the request picture, then assemble the rule scheme, and only after that enable blocking. The order of stages is fixed: each step shows an effect, and rollback takes one operation.
- Traffic and entry point audit. We collect statistics on addresses, methods, headers, and the share of automated clients — we get a baseline against which we check everything that follows.
- Rule scheme. We prioritize threats: what to block hard, what to limit by request rate, and what to only log for now.
- Enable in observation mode. Rules count matches but do not interfere with visitors: you can see who blocking would have affected without impacting conversion or availability.
- Review of false positives. Using logs, we exclude service addresses, exchanges with external systems, and payment provider callbacks from the filter.
- Switch to blocking. We enable rules one at a time, with a rollback plan and a threshold after which we automatically return to observation.
- Validation on production traffic. We monitor the failure rate, response time, and completion of key scenarios under load and during peak hours.
- Handover of procedures. We provide the rule map, the procedure for adding exceptions, on-call scenarios, and escalation points.
Rule Configurations, Traffic Scheme, and Response Procedures
AWS WAF configuration does not end with enabling the filter — it ends with a set of artifacts that your team can open, read, and apply without us. Below is what remains with you after the work: configuration files, traffic flow scheme, access policies, and incident instructions.
- Rule configuration — a description of each set: what it blocks, what it only counts, and in what order it fires. Stored declaratively so that a rule can be rolled back with a single change.
- Traffic flow scheme — the request path from the entry point to the application, with inspection points marked and behavior on match: block, challenge, or allow with logging.
- Access policies — allowed sources, service address ranges, and the exception procedure for internal checks and partner integrations.
- Response procedure — who receives an alert about a spike in blocks, how to distinguish an attack from an error in the rule itself, and when a rule is switched to observation mode.
- Emergency mode instructions — step-by-step removal of restrictions if protection starts cutting off live users, with the responsible person indicated.
- Protection documentation — configuration record: date of the last change, who made it and why, and which routes it affects.
- Post-release checklist for the application — the conditions under which a new version is considered properly protected, and the procedure for checking on an environment copy.
Rules are reviewed on a schedule, not after an incident: once a quarter we compare the configuration with the current application scheme — new routes and forms easily fall outside protection.
Implementation on a Production Project: Metrics Before and After
A service with a high share of external traffic — a catalog with account areas and forms — kept all filtering inside the application.
During a burst of automated requests (parsers, form enumeration, frequent search requests), the application pool went into overload: the queue grew, some live users saw errors, and the on-call engineer spent up to half an hour finding the source and restarting nodes.
What Was Changed and What Resulted
Filtering was moved to the perimeter — to AWS WAF. First, the rules ran in observation mode: they counted what share of traffic they would have cut off and compared it with logs to avoid affecting legitimate bots.
Then blocking was enabled: signature rules for typical attacks, request rate limits per address and per session, separate sets for forms and APIs, and allowlists for search engines.
The share of requests cut off at the perimeter during burst hours reached up to a third of the incoming stream — the applications stopped seeing this traffic at all.
Incident response time dropped from hours to minutes: a new rule is introduced by editing the configuration, not by a code release. We separately set up alerts for growth in blocks so that a change in the attack pattern would be visible immediately.
The eliminated class of failures was application pool exhaustion under an automated burst and the resulting errors for live users. Rollback is switching a rule to count mode or disabling it, without a build and deployment: an incorrect setting does not bring down the service.
How Does WAF Differ from DDoS Protection and a Network Firewall?
These are three different layers that look at traffic with different depth. A network firewall and security group rules work with packets: source address, port, protocol.
To them, an injection attempt in a form parameter or a forged cookie is an ordinary allowed request to the web server.
DDoS protection kicks in even earlier and evaluates the flow profile: a burst of similar requests is cut off at the perimeter before it reaches the load balancer and applications.
AWS WAF parses the contents of an application-layer request: method, path, headers, query string parameters, body, and cookies.
Here, managed rule sets for common attack classes, custom conditions for specific forms and addresses, and rate limiting rules by address or session are used.
That is why request filtering catches what is indistinguishable from a live user to a network firewall: form exploitation, credential stuffing, and automated catalog crawling.
The boundary of responsibility runs along application logic. WAF does not check access rights, does not validate business rules, and does not prevent placing an order on someone else's account — those are code responsibilities.
But the application should not be the only line of defense either: without perimeter filtering, every enumeration attempt reaches the server and consumes its resources on par with useful traffic.
A working scheme is a combination of layers with a clear order of passage.
Perimeter protection suppresses mass attacks, network rules leave only the necessary ports open, request filtering limits frequency and cuts off malicious content, and the application checks authorization and data integrity.
If a layer is removed, the load is redistributed to the next one — and the failure manifests where it is harder to notice.
Common Technical Objections Before Starting Work
Objections before starting are almost always the same, and they concern not the choice of rules but the risk of bringing down live traffic.
The filter sits between the user and the application, so a configuration error is visible immediately — unlike tasks that can be deployed and fixed along the way. Below are the doubts that engineering teams raise at the very first meeting.
Will enabling the filter stop the service during setup?
No. We deploy the first stage in observation mode: rules count matches and write them to the log, but do not block requests. Traffic flows as usual, and we get a real picture — which requests the application receives and which legitimate clients fall under suspicion. Switching to blocking mode is a separate step, after the log review.
Will false blocks cut off live customers?
That is exactly why observation mode is needed. The log shows which rules fire on live users, and exceptions are configured for them — precisely, by request path or client attribute, rather than by disabling the rule entirely.
We raise the threshold where the rule is noisy and keep it strict where it catches real bypass attempts.
Is access to the code and repository needed?
No. We work with the filter configuration and entry points: it is enough to know the domains, routes, and headers the application expects. Access to source code and databases is not required — code changes are not part of the task.
Who reviews matches after launch?
We review using the log: we look at what exactly fired, separate automated scanners from live sessions, and decide whether to keep the rule, narrow it, or add the address to exceptions.
After launch, we hand over the procedure: which reports to review, how often, and by what signs to understand that a rule needs adjustment.
Let's Discuss the Task and Come Back with an Implementation Plan
To come back with a scope assessment rather than generalities, we need source data on traffic and the application's entry points.
Describe the task in your own words — what you are protecting, what incidents you have already encountered, and what result you consider successful; we will gather the rest ourselves during the conversation.
On the call, we will clarify and ask you to send:
- the entry point scheme — domains, load balancers, CDN, and the request chain to the application itself;
- a log export for a typical day and for a peak interval: they show the request profile and the share of service noise;
- a list of known incidents — scanning, credential stuffing, bursts of similar requests;
- a list of legitimate bots, partner integrations, and monitoring that must not be blocked;
- current rate limiting rules and where they are currently configured — on the load balancer, in the application, or nowhere;
- requirements for the operating mode: whether to start with observation or immediately with blocking;
- the access and change approval procedure — who holds the panel and how rules are approved.
From this data, we understand the scope of work and the order of stages.
We will come back with an implementation plan: what we configure in observation mode, over what period we collect statistics on false positives, at what point we switch rules to blocking mode, and how we roll back if a rule affects real users.
Let's discuss the task — send the logs and scheme, and we will come back with an assessment and a staged implementation plan.