Picture this: it’s a Tuesday morning, and your phone starts buzzing. Customers are complaining that your site won’t load. You open it yourself and the page spins… and spins… and eventually times out. Your hosting dashboard shows the server is fine — CPU normal, plenty of memory — yet your traffic graph has a vertical cliff where visitors used to be. You haven’t changed anything. Nothing is broken. And yet, for all practical purposes, your website is down.
Welcome to your first distributed denial-of-service attack — or at least, your first suspected one. A DDoS attack doesn’t break into your site or steal your data. It simply drowns it: flooding your server, your network connection, or your application with so much junk traffic that real visitors can’t get through. It’s the digital equivalent of a thousand prank callers jamming a business phone line. This guide explains what an attack looks like from the site owner’s chair, the three main attack types, the layers of defense available to you, and — most importantly — what to ask your hosting provider before you ever need the answer.
What a DDoS Attack Actually Is
At its core, a DDoS attack is a resource-exhaustion problem. Every server can handle a finite number of simultaneous connections, a finite amount of bandwidth, and a finite rate of requests. An attacker marshals a botnet — thousands or millions of compromised devices, from hacked routers to insecure cameras — and points them all at your site at once. Each individual request looks more or less legitimate. Together, they exceed your capacity, and legitimate visitors get crowded out.
Two things surprise most site owners. First, the attack usually has nothing to do with you personally. Most DDoS attacks are opportunistic, extortion-driven, or aimed at someone sharing your infrastructure — your site is collateral damage on a shared IP or network. Second, you cannot “fix” an attack from inside your server. If the flood is saturating your network connection, no amount of code optimization will help, because the junk traffic never even reaches your code. Defense has to happen upstream, before the traffic arrives — which is why your provider choice matters so much.
What It Looks Like From the Site Owner’s Chair
Here is how a typical volumetric attack unfolds for a small business site, minute by minute — so you can recognize one instead of chasing the wrong problem.
Minute 0–10: “The site is slow.” The first sign is usually complaints, not alerts. Pages load sluggishly or time out intermittently. Your instinct says the server is struggling, so you check the dashboard — and everything looks healthy. CPU is fine, memory is fine, disk is fine. This mismatch (healthy server, unreachable site) is the classic signature: the bottleneck is the network pipe, not the machine.
Minute 10–30: “The site is down.” Traffic graphs show inbound bandwidth spiking to many times its normal level while real pageviews collapse. If you can reach your server at all, access logs show a flood of requests from scattered IP addresses, often requesting the same heavy page or just hammering the homepage. Your host may send an automated notice about unusual traffic — or null-route your IP, which is their emergency brake: they blackhole your address to protect the rest of their network, taking you offline to save everyone else.
Minute 30–90: “What do we do?” This is the painful window. If you have DDoS protection in place — a CDN or scrubbing service that absorbs and filters the flood — traffic gets rerouted through it and the site recovers while the attack continues harmlessly upstream. If you don’t, your options are limited: wait it out (most attacks last minutes to hours), ask your host for help, or hurriedly sign up for protection mid-attack, which is like buying an umbrella in a downpour.
After: the debrief. The attack stops as suddenly as it started. Your site comes back. Nothing was stolen, nothing was broken — but you lost hours of availability and possibly revenue. The right response is not relief but preparation: whatever you wish you had in place during the attack, put in place now, before the next one. And make sure your backups and disaster recovery plan is current — not because DDoS destroys data, but because every outage is a reminder that recovery plans earn their keep.
The Three Kinds of DDoS Attacks
Defenses differ by attack type, so it helps to know the three families. You don’t need deep technical knowledge — just the shape of each.
1. Volumetric attacks
The blunt instrument: sheer bandwidth floods, measured in gigabits per second, designed to saturate your network connection. Think of it as a flash mob blocking the road to your shop. Defense is purely about capacity and filtering upstream — your server never stands a chance alone, which is why CDNs and scrubbing centers exist.
2. Protocol attacks
These exploit the machinery of network connections themselves — for example, floods of half-opened connections that tie up your server’s connection table. They use less bandwidth than volumetric attacks but can be just as effective. Modern firewalls and load balancers at the provider level typically filter these.
3. Application-layer attacks
The sniper rifle: relatively low-volume floods of requests that target expensive parts of your application — the login page, the search box, the checkout. Each request looks legitimate and forces your server to do real work (database queries, password hashing), so a modest flood can exhaust the application. These are the hardest to filter automatically because the traffic mimics real users, and defense often involves rate limiting, bot detection, and a web application firewall.
Defense in Layers
No single product stops every attack. Effective DDoS protection is layered, with each layer handling what it’s best at. Here is the stack, from the outside in:
- CDN / edge network (first and most important for most sites). A content delivery network puts a global network of servers in front of your site. Attack traffic hits the CDN’s massive distributed capacity instead of your origin server, and the CDN filters junk before passing clean traffic through. For a typical small business site, sitting behind a reputable CDN is the single highest-value DDoS defense available — it also speeds up your site worldwide as a side effect.
- DNS-level protection. Attacks can also target your DNS, making your domain unresolvable even though the server is fine. Using a managed DNS provider with anycast and built-in DDoS resilience keeps your domain reachable. This is cheap or free and often overlooked.
- Network and transport filtering. Your hosting provider’s firewalls, and dedicated scrubbing services for larger targets, filter volumetric and protocol attacks upstream. Under the shared responsibility model, this network layer is squarely the provider’s job — but only if your plan actually includes it. Budget hosting often doesn’t.
- Web application firewall (WAF). A WAF inspects HTTP requests and blocks malicious patterns: SQL injection probes, bot floods on login pages, known attack signatures. This is your main defense against application-layer attacks, and many CDNs bundle a managed WAF.
- Rate limiting and bot management. Cap how many requests a single client can make in a time window, and challenge suspicious automated traffic. Done well, this stops application-layer floods without annoying real visitors; done badly, it blocks legitimate users. Start with conservative limits on expensive endpoints like login, search, and checkout.
- Origin protection. Lock down your origin server so it only accepts traffic from your CDN or WAF — otherwise attackers can bypass every layer above by hitting your server’s IP directly. This one configuration step is frequently skipped and completely undermines the rest.
For a clear technical primer on how these attacks work, Cloudflare’s learning center has an excellent DDoS attack explainer.
What to Ask Your Provider Before You Need It
DDoS protection is one of those features where the fine print matters enormously, and the time to read it is now. Ask your host these questions directly — by ticket or chat, so you have the answers in writing:
- “Is DDoS mitigation included in my plan, and at what level?” Many hosts advertise “DDoS protection” that turns out to be basic network filtering with no application-layer help and no guarantee. Get specifics: volumetric only, or also application-layer? Automatic or manual?
- “What happens if I’m attacked — will you null-route my IP?” Null-routing protects the provider’s network by sacrificing your site. Some providers do it automatically at a threshold; others offer scrubbing first. Know which yours does, and at what traffic level the decision triggers.
- “Can I put a CDN in front of my site, and will you help lock down the origin?” Any decent host should say yes to both. If they resist origin lockdown or charge extra for basic cooperation, that’s a red flag.
- “Is there a WAF available, managed or self-service?” For application-layer protection, you want either a managed WAF from the provider/CDN or a self-service one you can configure. “We don’t offer one” is an acceptable answer only if your plan is to get one elsewhere.
- “What’s the escalation path during an active attack?” Who do you contact, is support 24/7, and what’s the realistic response time? An attack at 2 AM is exactly when you’ll need this answer.
Under Attack Right Now? Do This
If you’re reading this mid-incident, here is the short version: don’t try to out-configure the flood from your server. First, confirm it’s actually an attack and not a traffic spike or a runaway script — check your access logs and bandwidth graphs. Second, contact your host immediately and ask for mitigation; they can see and filter upstream traffic you can’t. Third, if you have a CDN account, route your DNS through it now — most major CDNs can absorb an attack within minutes of onboarding, even mid-attack. Fourth, enable “under attack” or equivalent challenge modes if your CDN/WAF offers them; they’ll inconvenience some real visitors but keep the site alive. Finally, communicate: post a status update for customers so they know you’re aware and working on it. Silence during an outage reads as indifference.
DDoS protection follows the same logic as all cloud security: you can’t prevent every attack, but you can make your site an unrewarding target and recover fast when one lands. Put the CDN in front, lock down the origin, know your provider’s answers in writing, and keep that recovery plan tested. The next attack will still be annoying — but it’ll be a footnote, not a crisis. AWS documents its own managed protections in the AWS Shield service pages, which are worth a read even if you host elsewhere, just to calibrate what “included protection” should look like.
