Read summarized version with
At 7:31 PM, a server crossed 90% CPU. At 7:32:30, an engineer who’d never seen this specific traffic pattern before had already opened the right dashboard. By 7:36, the attack was being filtered at the edge, and by 7:37 the load was back to normal. Nobody outside the incident channel ever knew it happened. That’s the whole article, really. Everything below is just how those five minutes actually work, and how you can tell whether your own infrastructure would survive them.
One of our customers is an e-commerce business that gets hit with DDoS attempts on a regular basis. Revenue depends entirely on uptime, so every attempt is a direct threat to the business, not just an engineering headache. The attempts don’t stop, which is exactly why we built a process that catches them at the alert stage instead of at the “why is the site down” stage. This article is about that: how good incident management actually works, with real examples from our own Managed Services work.
Why five minutes is the bar, not an exaggeration
A DDoS attack, distributed denial-of-service, is when someone floods your infrastructure with traffic until real users can’t get through. It doesn’t need to be sophisticated. A flood of requests to one product page, one login endpoint, one API, is often enough to slow a server to a crawl or knock it over completely. Cloudflare’s 2026 threat report clocks roughly 5,300 network-layer DDoS attacks per hour globally, and over 90% of them finish inside ten minutes. Our research shows Layer 7 attacks specifically are up 104% since 2023, mostly because DDoS-for-hire platforms have turned “launch an attack” into a checkout flow: pick a duration, pick a bandwidth tier, pay in crypto, done. It’s not a rare event anymore. It’s background noise on the internet, and at some point it will point at you.
Here’s the technical detail that matters more than either stat: AWS’s own DDoS resiliency guidance is blunt about this. AWS Shield Standard, the protection that’s automatically on for every AWS resource, handles the classic infrastructure-layer floods, SYN floods, UDP reflection, that kind of volumetric noise, at no cost and with no configuration. But it explicitly does not stop a Layer 7 attack dressed up as normal traffic. A flood of well-formed HTTP requests to a real product page, at a rate a human might plausibly generate, doesn’t trip any network-layer defense. Nothing about the packets is malformed. The only thing wrong with it is the pattern, and pattern-based detection is a different layer of the stack entirely. That gap, between “AWS blocks this for free” and “you have to configure this yourself,” is exactly where our incident started.
1. Observability tuned to how you actually run things
A generic “is the server up” dashboard tells you something is wrong. It rarely tells you what to do about it. Real observability is built around the specific stack, traffic patterns, and failure modes of the system it’s watching, which means it looks different from one implementation to the next.
How this varies across our projects. For a customer running a serverless AWS stack, we build mainly on native AWS tooling around CloudWatch, alarms on Lambda concurrency, API Gateway error rates, and similar signals. For a customer running a fleet of EC2 instances, we maintain a golden image with monitoring agents baked in, so a new instance joins observability automatically the moment Auto Scaling spins it up. For one e-commerce customer who gets DDoSed regularly, observability runs on Grafana, Prometheus, and Loki, with HAProxy logs feeding a dashboard that breaks traffic down by path, not just by volume. That per-path view is what turns “load is high” into “load is high on this one product page,” which is the difference between an investigation and an instant answer.
The common thread isn’t the specific tools. It’s that the setup is chosen deliberately for what could actually go wrong, instead of bought once and left generic.
2. Escalation that filters noise instead of paging everyone
The second piece is making sure the right person actually sees the alert, quickly, without burning out the team on false alarms. A flat “page everyone for everything” approach fails in both directions: real incidents get lost in the noise, and people stop trusting the pager.
The pattern we use routes by severity. A short-lived, minor spike lands quietly in a chat channel for whoever’s on shift to check. A harder signal, a disk hitting its IOPS limit when it normally sits around 30%, triggers escalation loud enough to guarantee someone acknowledges it. On projects with 24/7 coverage, a high-priority alert typically follows a ladder like this: it hits chat and the escalation system at once; if it hasn’t auto-resolved within a minute (filtering out the noise of things that fix themselves), the on-duty engineer gets an SMS and a push notification; if that goes unacknowledged for another minute, the system calls their phone directly. Each rung exists to fail safe against a human being asleep or slow to check their phone, without paging someone at 2 AM over something that would’ve resolved on its own.
3. Runbooks instead of improvising under pressure
The third piece is what happens once a person is actually looking at the problem. Under time pressure, improvising is slow and inconsistent, even for a good engineer. A runbook removes that variable. Every runbook we write follows the same four-part shape:
- Trigger – the alert or request that leads you here.
- Validation – how to confirm what’s actually going on.
- Steps to resolution – the specific actions to take.
- Escalation criteria – when and how to bring in more help.
It sounds almost too simple to matter, but that’s the point. A runbook doesn’t ask an engineer to rediscover, mid-incident, what usually causes this alert on this project. It tells them, based on the project’s own history, and sends them straight to the most likely cause instead of a generic top-to-bottom investigation.
The examples: what DDos attack looks like in practice
A DDoS attack on a single product page. On the e-commerce customer mentioned above, a P1 alert fired at 7:30 PM: one instance had jumped to 90% CPU. It didn’t auto-resolve within a minute, so the on-duty engineer got the escalation push and acknowledged it a minute and a half after the first alert. The runbook’s validation step pointed straight at traffic distribution per path, because on this project, DoS and DDoS attempts are by far the most common cause of this specific alert. The HAProxy dashboard showed nearly all the traffic hitting one product page. Steps to resolution: add that page’s path to a regex set already wired into an AWS WAF rule with a Challenge action attached.
Here’s what that one line actually does. Challenge issues a JavaScript-based proof-of-work puzzle and requires a valid aws-waf-token cookie before a request proceeds. A real browser solves it invisibly, in milliseconds, no CAPTCHA, no friction a shopper would ever notice. A basic bot script, the kind behind most low-effort DDoS-for-hire traffic, can’t execute JavaScript or manage cookies properly, so it never gets through. Add one path to one regex set, and the traffic sorts itself.
- Response time: 1.5 minutes, first alert to acknowledgment.
- Resolution time: 3 minutes, acknowledgment to mitigated traffic.
- End to end: under 5 minutes, zero downtime.
Why not just block the IPs? Botnet traffic is often spread across thousands of addresses, residential proxies, and compromised IoT devices, so a static IP blocklist is a losing game of whack-a-mole, and it risks catching real visitors on shared or rotating IPs. A behavioral challenge doesn’t care what IP a request came from. It cares whether the client can act like a browser, which is a much harder thing for a cheap bot to fake.
The same pattern at 3 AM
On another project, an unnatural traffic surge started building at 3:25 AM. It crossed the alert threshold at 3:56, and the on-duty team got a call. By 4:03 the customer had been notified, by 4:04 the root cause was traced to a specific path being hit by an unusual concentration of US traffic, and by 4:08 a WAF challenge rule was live and the load was already dropping. The customer found out from the incident report the next morning, not from a dead site at 4 AM.
When the fix isn’t DDoS related at all
The same proactive posture shows up outside traffic attacks, too. On another engagement, we found that a customer’s development and staging environments were open to anyone, anywhere, no restrictions at all. Real vulnerability, zero tickets filed, because nobody outside the infrastructure team would have known to look. We introduced a VPN, restricted access to the customer’s own offices and authorized individuals, and ran the knowledge transfer needed so the dev team’s workflow didn’t skip a beat. The customer didn’t have to notice the gap, let alone request the fix.
That’s really the point of all three examples together: the specific fix changes every time, but the shape of the response doesn’t.
What happens after the load drops
Resolving the incident isn’t the finish line. Once traffic is back to normal, the team holds an incident review, writes up a report, and defines follow-up work: new alerts that would catch this faster next time, or an evaluation of what could be automated further without a human in the loop. Every incident is supposed to make the next one cheaper to handle. That compounding is what separates a proactive process from a merely fast one.
If you’re reading this and honestly don’t know where you stand
Most businesses aren’t lying awake worrying about DDoS. They’re just not sure where they stand, and not sure is its own kind of risk, because you find out the hard way, mid-incident, with customers watching. A few honest questions worth asking yourself:
- If your traffic spiked right now, would anyone know inside a minute, or would you find out from a customer complaint?
- Could you tell, in under thirty seconds, which specific page or endpoint is taking the abnormal load, or would you be staring at one “load is high” graph with no way to drill down?
- Is there a documented, tested action your team can take without waiting for a senior engineer to wake up?
- Has anyone actually checked whether your traffic patterns need WAF rules on top of the automatic protection AWS already gives you, or are you assuming Shield Standard covers everything?
- After your last traffic spike, did anything get written down and fixed, or did everyone just move on once it passed?
If two or more of those made you wince, that’s a normal starting point, not a failure. Infrastructure usually gets built to handle expected load, not adversarial load, and DDoS mitigation tends to get added only after an attack, or after someone finally asks the right question first. The fix isn’t necessarily “hire a 24/7 team tomorrow.” It’s often smaller: get visibility into traffic by path, not just by volume; put one WAF rule in front of your highest-value endpoints; write down the first three steps of what to do when the alert fires, even a rough version. Each of those closes a real gap on its own.
Where Dedicatted fits
Dedicatted has been building and running infrastructure like this for over 9 years, with around 80 engineers and 140+ projects delivered. As an AWS Premier Tier Services Partner and a top 2% global AWS partner with MSP designation, we combine deep cloud expertise with hands-on engineering delivery. We’re SOC 2 and ISO 27001 certified, with Managed Services SLAs specific down to the minute rather than “same day”: Platinum customers get a 15-minute response on P1 incidents, Gold gets 30 minutes, Silver gets an hour, all with 24/7 coverage.
The point of Managed Services, in plain terms, is that we take full ownership of the infrastructure so the business doesn’t have to think about it, the same way an accountant handles your taxes so you don’t have to become one. You still get full visibility: an incident report for every incident, regular operational and business reporting, and SLA monitoring you can actually check against. The work doesn’t disappear. It just stops being your problem.
Want to see where your own setup stands?
If your business depends on being available, and it probably does, we’d be glad to look at your infrastructure together and tell you honestly where the gaps are: in monitoring, in alerting, or in what happens after the alert fires. Try the MSP calculator at msp.dedicatted.com, or just start a conversation with the engineers who’d be on the other end of that phone call.
