DDoS attacks against UK businesses have become cheaper to launch and harder to distinguish from legitimate traffic over the past few years, largely thanks to the rise of accessible “booter” and “stresser” services on the dark web and the growth of large IoT botnets. For anyone running production infrastructure on colocated servers, DDoS protection isn’t an optional add-on anymore — it’s a baseline requirement, and it’s worth understanding how it actually works rather than trusting a vague “we have DDoS protection” line item.

The attack types you’re actually defending against

• Volumetric attacks. UDP floods, ICMP floods, and amplification attacks (DNS, NTP, memcached reflection) that aim to saturate available bandwidth. These are measured in Gbps and can exceed hundreds of Gbps in large-scale attacks, far beyond what most individual server connections or even most facility uplinks can absorb without upstream mitigation.
• Protocol attacks. SYN floods, fragmented packet attacks, and Ping of Death variants that exploit weaknesses in the TCP/IP stack itself, aiming to exhaust server or network device resources (connection tables, state tracking) rather than raw bandwidth.
• Application-layer attacks. HTTP floods, Slowloris-style slow connection attacks, and targeted requests against expensive endpoints (search functions, login forms, API calls that trigger database queries). These are measured in requests per second rather than bandwidth, and are the hardest to detect because the traffic looks legitimate at the network layer — it’s the pattern and volume that gives it away.

How mitigation actually works

Effective DDoS protection operates in layers, because no single technique handles all three attack types above:

• Upstream scrubbing. For volumetric attacks, traffic needs to be diverted — via BGP route announcement — to scrubbing infrastructure with enough capacity to absorb the attack volume, clean the traffic, and forward only legitimate packets back to the origin network. This has to happen at a scale most individual businesses can’t build themselves, which is why it’s typically provided at the network/facility level.
• Rate limiting and connection tracking. At the network edge, limiting connection rates per source IP and validating TCP handshakes (SYN cookies) mitigates protocol-layer attacks without needing full scrubbing capacity.
• Application-layer filtering. A web application firewall (WAF) and behavioural analysis to distinguish genuine user traffic from automated flood traffic hitting the same endpoints — this is where attack traffic and real traffic look most similar, and where false positives (blocking real customers) become a genuine risk if the filtering is too aggressive.
• Anycast and traffic distribution. Spreading incoming traffic across multiple points of presence so an attack against one entry point doesn’t take down the whole service — more relevant for content delivery and DNS than for a single colocated server, but worth knowing about as a complementary layer.

Always-on versus on-demand mitigation

There’s a meaningful difference between “we can mitigate a DDoS attack” and “we mitigate it automatically, in seconds, without you having to call anyone.” On-demand mitigation — where traffic only gets rerouted through scrubbing infrastructure once someone notices an attack and manually triggers it — can mean minutes of downtime before protection kicks in, which for a volumetric attack against a colocated server is more than enough time to saturate the link. Always-on mitigation continuously monitors traffic patterns and triggers scrubbing automatically the moment an anomaly is detected, typically within seconds.

Questions to ask before you assume you’re covered

1. Is DDoS mitigation always-on, or does it require manual activation once an attack is detected?
2. What’s the total scrubbing capacity available, and is it shared across all customers during a large-scale attack?
3. Does protection cover volumetric, protocol, and application-layer attacks, or only network-layer traffic?
4. Is there a cost per mitigated attack, or is protection included as standard?
5. What’s the typical time-to-mitigation once an attack starts?

What you can control at your end

Provider-side mitigation handles the traffic flood, but application-layer resilience is partly your responsibility: rate-limiting expensive API endpoints, caching aggressively where possible, keeping software patched against known amplification vectors, and having a clear incident response plan that doesn’t rely on someone being awake and available at 3am to notice a problem — this ties directly into broader business continuity planning for UK SMEs.

Network-level DDoS mitigation is included as standard across our colocation and dedicated server platforms, with always-on monitoring and automatic scrubbing rather than a manual, reactive process. If you’ve had a previous DDoS incident and want a technical review of what happened and how it would be handled on our network, get in touch.