DDoS Mitigation: Telling an Attack From a Sales Rush

It is 10 a.m. on Black Friday. Response times are climbing and requests are several times higher than normal. You need to decide quickly whether this is the sale working or an attack, because the right responses point in opposite directions. Real customers need more capacity. An attack needs blocking, and adding capacity just gives it more to consume. On metered cloud, attack traffic can become a bill on top of the outage.

This article covers the signals that separate a sales rush from a distributed denial of service (DDoS) attack, the three kinds of attack and where each one is stopped, and what to do in the first ten minutes. If firewall rules are new to you, start with the glossary.

Why peak day is when the two look alike

Both raise traffic sharply, both slow pages down, and both can start within minutes. Attackers also know when downtime costs a retailer the most. A busy sale day is the obvious time to try extortion or plain disruption.

The difference is in the shape of the traffic, not the size. That means looking past total requests to where traffic comes from, what it asks for and what it does next.

Signals that point to real customers

It follows your marketing. Traffic jumps minutes after the email goes out or the ads switch on.

It moves through the site. Visitors land on product and category pages, then a share of them go to the cart and checkout.

Orders rise with traffic. Conversion might dip under heavy load, but orders still climb.

It comes from where your customers are. Countries, cities and networks match your normal audience.

It looks varied. A mix of devices, browsers and referrers, from your email, ads and social posts.

Signals that point to an attack

It ramps with no trigger. Nothing went out, and traffic still multiplied.

It hammers one thing. Search, login, the cart API or another expensive, uncached endpoint takes most of the requests.

Orders stay flat while requests climb. This is the clearest single signal.

It comes from unusual places. Countries you do not sell to, or ranges belonging to hosting providers and data centres rather than homes and mobile networks.

It looks identical. The same user agent string, no user agent at all, or request rates per address that no human could produce.

Your servers look quiet but the site is down. If bandwidth is saturated while web server logs look normal, a network-level flood may be filling the connection before requests ever reach your application.

DDoS filtering is included on every InMotion Cloud plan, alongside the rest of our managed services.

Three kinds of attack, three places to stop them

Volumetric attacks try to fill your network connection with junk traffic. They have to be filtered upstream, before the traffic reaches your servers, because no amount of server capacity helps once the pipe is full.

Protocol attacks exhaust connection tables in firewalls, load balancers and servers, often with floods of half-open connections. They are filtered at the network edge.

Application-layer attacks send requests that look like real visitors, aimed at expensive pages. They are the hardest to separate from customers, and they are stopped closer to the application with rate limits, caching, bot challenges and web application firewall rules.

The first ten minutes

1. Check the marketing calendar. Did an email, ad or influencer post go live? If so, treat it as customers until the data says otherwise.
2. Compare requests with orders. Rising together means customers. Diverging means look harder.
3. Look at the top URLs, addresses and user agents. One endpoint or one pattern taking most of the traffic is a strong sign of an attack.
4. Check bandwidth and any alerts from your host or CDN. Your provider may already see and be filtering a network flood.
5. Call your provider. Use the contact list from your runbook, not a general support form.
6. Apply narrow controls first. Rate limit the endpoint being hammered, block clearly abusive ranges and cache more aggressively. Avoid blocking whole countries unless you never sell there, because broad blocks turn away buyers.
7. Write down what you changed and when. You will need it to undo the changes and to review afterwards.

Prepare before peak day

Know your baseline. Record normal and peak traffic for the last few weeks so a spike has something to be compared with.

Set rate limits now on login, search, cart and any API that does heavy work per request.

Cache product and category pages so an application-layer flood hits the cache, not the database.

Expose only what you need. Review your firewall rules and security groups so that databases and admin panels are not reachable from the internet.

Agree who can authorise blocking. On peak day, waiting for approval is expensive.

Have a holding page ready, such as a queue or "back in a moment" page, that you can switch on without a code change.

Where DDoS mitigation stops

Mitigation filters attack traffic. It does not make an application that cannot handle real customers faster, and it cannot tell a scalper's buying bot from a person when both behave politely. Low-rate attacks such as credential stuffing can also slip under volume-based filtering. Treat mitigation as one layer, alongside capacity planning, rate limits and sensible firewall rules.

How InMotion Cloud handles it

DDoS filtering is included on every InMotion Cloud plan. It detects attack traffic, including by matching known attack patterns, and filters it before it reaches your environment. Pricing is fixed and there are no egress fees, so an attack does not turn into a data transfer bill.

Inside your environment, you control security groups and firewall rules, and our engineers can help you tighten them before peak day and respond with you if something happens.

Summary

On peak day, a sales rush and an attack look alike in total traffic, so look at its shape. Customers follow your marketing, move through the site and place orders. Attacks arrive without a trigger, hammer one thing and leave orders flat. Prepare rate limits, caching, contacts and authority before the day, and in the moment, block narrowly so customers still get through.

Frequently asked questions

How can I tell if a traffic spike is a DDoS attack? Compare requests with orders, check whether one URL or pattern dominates, and see whether the spike followed a marketing send. Customers buy; attacks rarely do.

What is the difference between a DDoS attack and high traffic? High traffic is real visitors using your site. A DDoS attack is traffic sent deliberately to exhaust your bandwidth, connections or servers so real visitors cannot get through.

Will adding servers stop a DDoS attack? Rarely. Volumetric attacks fill the network before servers matter, and application-layer attacks scale with you. Filtering and rate limiting do more.

Should I block traffic from other countries during a sale? Only countries you never sell to. Broad blocks during a sale tend to turn away real buyers, including customers using VPNs or travelling.

What should be in a DDoS response runbook? Contacts for your host and CDN, who can authorise blocking, where to see traffic and orders, the rate limits you can switch on, and how to enable a holding page.