Configuring DDoS protection: what breaks without perimeter protection
A peak burst of requests rarely looks like an attack in the logs: the channel is saturated with subscription traffic, the connection queue on the load balancer grows, and the application starts responding on a best-effort basis.
Overloading the channel with requests consumes the headroom set aside for a sale or the morning peak — the failure arrives before monitoring can raise a clear signal.
Then the domino effect kicks in: service unavailability under load hits exactly the customers who generate revenue — payment, checkout, personal account. The on-call shift at that moment is extinguishing the consequence: restarting nodes, expanding the pool, tweaking limits.
The cause — malicious traffic that reached the application — remains in place and returns at the next peak.
Homegrown filters against this backdrop can be more dangerous than the attack itself: false positives from the filter cut off real users by geolocation or behavior, and real orders are lost along with the junk.
Perimeter protection — for example, on Cloudflare — works differently: malicious traffic is suppressed at the edge, before it takes up the channel and the application queue.
Configuring DDoS protection is not a checked box, but a set of thresholds, modes, and rules tailored to your traffic profile: where to enable inspection, which sources to consider trusted, at what levels to raise sensitivity so as not to affect your own users.
Below we break down how this is covered — from the filtering scheme to the procedure during an attack.
What changes after enabling filtering: five measurable effects
Traffic filtering is not a “set it and forget it” toggle: the effect shows up in the metrics that the on-call shift reviews every morning.
Below are five indicators that shift predictably if the filtering rules and thresholds are set for your traffic profile rather than left at defaults.
Availability under peak load
Junk requests are filtered out at the edge and never reach the applications — the service stops falling over during peak hours. Instead of minutes of unavailability, the graph shows a flat plateau, and there is no longer any need to expand the pool for every burst. We verify this with a synthetic burst from external locations, not using the filter’s own reports.
Recovery time after a burst
The attack is cut off at the ingress, internal services do not accumulate a queue or drop connections.
Recovery time is measured in tens of seconds instead of minutes of manual switching, and in most cases the on-call engineer learns about the attempt only after it has been mitigated — from the log.
Share of junk traffic blocked
Configured signatures and behavioral rules remove the bulk of parasitic load — only traffic with meaningful requests reaches the backend.
The difference is visible in the number of requests to the application while the volume of inbound traffic remains unchanged: the internal infrastructure stops being the bottleneck.
Eliminated class of failures
An entire class of outages goes away, where the cause is connection exhaustion or queue overflow under a flood of bots.
Incidents of this type simply stop being opened, and the review is not about “why it went down” but “how much was blocked.” This also changes the nature of on-call duty: nighttime wake-ups for the same reason disappear.
Load on the on-call shift
The volume of manual investigations stops growing along with the number of attempts: typical scenarios are covered by rules rather than engineer response. The shift spends time tuning thresholds and analyzing anomalies, not extinguishing the same failure.
Separately, we verify that legitimate peaks — sales, campaigns, partner integrations — pass without false blocks. We build the protection scheme on Cloudflare or built-in cloud tools — the choice depends on where the traffic lives and who is responsible for the rules.
Comparison of perimeter protection modes: when each is suitable
The protection mode is chosen not by the service’s capacity but by the class of attacks and by what happens to traffic in calm times.
Hence three forks: at what level the decision to drop packets is made, where the filter physically sits, and how quickly the route switches during an attack.
| Option | When it is suitable | Limitations |
|---|---|---|
| Built-in cloud provider protection | The service lives in the cloud, attacks are network-based and volumetric | Application-layer filtering is limited to templates; fine-grained logic for your own protocol is unavailable |
| External filter at the perimeter | You need rules for your own application and a single point for multiple sites | Traffic goes through a third party: latency, encryption, legal aspects |
| Local filter at your own site | You have your own network and channel; data sovereignty is important | Channel bandwidth is the ceiling: when it overflows, the attack lands on the uplink |
| Hybrid with failover switching | You need a permanent filter plus an on-call contour for peak attacks | Two sets of rules, coordinated thresholds, regular switching drills |
Permanent filter versus on-call mode
A permanent filter keeps traffic going through the protection contour at all times: the rules are battle-tested, behavior is predictable, but latency is added to every request.
On-call mode is enabled only during an attack — by switching DNS with a low TTL or announcing addresses — and the rest of the time traffic goes directly.
The thresholds for on-call mode are configured based on the normal traffic profile and tested in drills: otherwise, at the moment of an attack, it turns out that some rules block legitimate customers.
The limitation of any mode is not the filter’s capacity but the precision of the rules: an overly broad ban hurts availability more than the attack itself.
Implementation procedure: from traffic audit to handover to operations
The work proceeds so that protection is enabled without service downtime and without blocking live traffic: first we record how requests reach the application, then we choose the filter activation point, and only then we configure thresholds.
Audit and traffic scheme
We assemble a map: domains, real request sources, load balancers, proxies, external services via callbacks.
Separately, we check whether the client address is preserved along the entire path — this determines whether the filter can distinguish a bot from a human and whether it will block legitimate visitors.
- We capture the traffic flow diagram — from the entry point to the application, indicating which node accepts what and where real client addresses are visible.
- We choose the filter activation point: an external scrubbing perimeter (Cloudflare, AWS Shield, Cloud Armor), a load balancer, or a segment in front of a specific service. We record what is filtered always and what is filtered on a schedule.
- We configure trigger thresholds and rules: a baseline of requests per user, rate limits, anomaly indicators, exceptions for monitoring and partner integrations.
- We test the protection with a training attack — a controlled burst from a test contour: which rules triggered and whether normal traffic was blocked.
- We train the shift: how to read the dashboard, what to do when it triggers, how to temporarily relax the filter without opening the perimeter entirely.
- We put the protection into operation: enable blocking mode, formalize the on-call procedure and the quick rollback point.
Testing with a training burst
The burst shows at what load profile a rule triggers and how long it takes for normal service operation to recover. Based on the results, we adjust thresholds: remove unnecessary blocks and tighten what let the load through.
The output is protection enabled, tested, and handed over to the shift — with a procedure and a rollback point.
Documents and artifacts we hand over after implementation
Implementation of protection ends not with enabling filtering, but with handing over a package that your team uses to continue without us: understand the scheme, change thresholds, onboard the on-call engineer. Below is what you retain.
- Traffic flow diagram — the request path from the external contour to the load balancer and applications, filtering points, and areas not covered by protection.
- Configuration of filtering rules and thresholds: signatures, request rate limits, exception lists, and monitoring mode for new rules.
- Access policies for the control panel — separate accounts instead of a shared one, mandatory two-factor authentication, role-based permission boundaries.
- Change log of settings — what was changed, when, and why, who approved it, how to roll back: without it, incident analysis turns into guesswork.
- Instructions for independently adjusting thresholds — where the safe limit is and where blocking live customers begins.
- Post-change verification checklist — a set of requests and scenarios the on-call engineer uses to confirm that legitimate traffic passes.
Attack response procedure
This is a one- or two-page document read during an incident, not on a calm day.
It includes attack indicators and trigger thresholds, the escalation procedure with names and communication channels, the first actions of the on-call shift, criteria for switching to an enhanced protection profile and returning to normal. Separately — what to record in the log based on the results.
Case study: how failure spikes at peak load were eliminated
The client is a service with a pronounced daily peak: evening hours and the start of sales produced a multiple increase in requests, and with it came junk traffic — scanners, bots, repeated requests to dynamic pages.
The perimeter let everything through, and the application hit its limit before the real load arrived.
Before
The peak lasted 40–60 minutes. The share of requests reaching the application dropped to 55% — the rest was lost waiting for a response. Unavailability during the peak reached up to 12 minutes per evening: some users saw errors and left.
Engineers handled 5–7 nighttime incidents per month, each involving manual capacity expansion and log analysis.
After
The perimeter protection was built on Cloudflare and the rules were separated into layers: first filtering by behavior and address reputation, then rate limiting for sensitive routes, and only after that the queue to the application.
The share of blocked junk was about 30% of inbound traffic, and the share of useful requests reaching the application rose to 97%.
Over a month of observation, no unavailability during the peak was recorded, and ingress errors disappeared from the reports. Nighttime investigations were replaced by a scheduled weekly anomaly review.
Static assets and cache are served from the perimeter, so peak growth stopped being shifted onto the application.
How network-layer DDoS filtering differs from application protection
A network filter works with the flow, not with request content: it evaluates volume, source address, rate of new connections, and distribution across ports.
Such a filter suppresses volumetric bursts — amplification, SYN flood, botnets — before traffic occupies the channel to the servers. But it cannot distinguish a malicious request from a useful one if the former looks like an ordinary one.
Application protection looks inside the request: route, headers, body, frequency of requests to a specific form, session behavior.
Here targeted attacks are blocked — a burst on the login page, credential stuffing, slow requests that keep a connection open and are almost invisible by volume.
| Protection layer | What it blocks | What remains uncovered |
|---|---|---|
| Network and transport | Volumetric flows, amplification, SYN flood | Slow attacks and “legitimate” traffic with a useful request shape |
| Application | Bursts on a specific route, credential stuffing, session anomalies | Volume that clogs the channel before the request is even parsed |
| Combined scheme | Ingress volume plus semantic anomalies at egress | Requires coordinated thresholds; otherwise useful traffic gets cut |
Neither layer is self-sufficient. Without the network layer, the channel and load balancer hit the ceiling before application rules trigger, and the request simply never reaches them.
Without the application layer, everything that looks like a normal request passes through — the filter sees a smooth flow and does not react.
Tools like Cloudflare provide both planes in a single contour: first network rules are enabled, then application rules with thresholds tailored to the real traffic profile.
Combining the layers is the workable scheme — the filter holds volume, the application cuts anomalies, and thresholds are configured based on facts, not guesswork.
Technical concerns: false positives, latency, bypasses
False positives are not a property of protection but a consequence of thresholds set by eye. That is why rules first run in monitoring mode: we accumulate logs, analyze by endpoint, and add exceptions for payment system callbacks, mobile clients, and availability checks. Blocking is enabled only when there are no false hits left in the log.
Latency is determined not by filtering but by the inspection location. We place bot checks on cacheable responses at the edge so that cleaned traffic reaches the servers; for APIs we leave behavioral analysis without a challenge.
We measure response time at the 95th percentile before and after — the difference is usually within the margin of error.
What to do when the deployment scheme changes?
We bind rules to names and labels, not addresses, so when migrating or adding a load balancer, only the traffic ingress point changes. We define the procedure in advance: bring up the new contour, test filtering on a test flow, then switch production.
Does protection interfere with a secure channel?
No: analysis is based on connection metadata; content is parsed after termination. We leave internal calls on mutual authentication — the filter does not block trusted traffic and does not allow spoofing through.
Who is responsible for thresholds after handover?
We hand over the settings with documentation: what the rule is, which metric it reacts to, what happens when it triggers, and how to roll back. After that, the thresholds live with your team; we remain on support and revisit the rules as load grows.
Let’s discuss your task: what to send for assessment and a plan
So that the assessment and implementation plan are based on your infrastructure rather than general considerations, a few inputs are enough. From them we determine the traffic filtering point, protection operating modes, and the procedure for enabling without downtime.
- Traffic flow diagram. Where the load balancer is, where traffic is decrypted, which channels and external entry points are involved. This determines whether protection goes before or after the load balancer.
- List of services at the perimeter. Which applications and ports face outward, what is critical, and what can be temporarily closed during an attack.
- Incident history. What has already happened: channel bursts, application-layer floods, attempts to exhaust connections. Past attacks describe the traffic profile more accurately than any questionnaire.
- Availability requirements. Acceptable response time, behavior during false positives, which legitimate sources must not be blocked — partner integrations, mobile clients, office networks.
- Expected load profile. How many times the peak exceeds normal traffic, whether there are seasonal bursts and one-off events for which we prepare in advance.
- Responsible people on your side. Who grants access to the protection control panel and DNS records, who approves the maintenance window, and with whom we escalate at night during an attack.
With this set, we come back with an assessment and implementation plan: where protection goes, which thresholds we set, how we test rules on live traffic, and how we roll back with a single edit. Describe your protection task — then we will clarify the details with questions.