DDoS-Protected VPS: What the Label Actually Means (and What to Check)

Can a VPS really include DDoS protection?

Yes. A VPS can include genuine DDoS protection, but the value depends on where the filtering sits and which layers it covers. Real protection scrubs traffic upstream at the network edge across L3, L4 and L7. Weak protection reacts late, only at your server, or simply drops your IP.

The word “protected” on a product page carries almost no information on its own. Two hosts can print the same phrase while one runs a multi-terabit filtering fabric and the other runs a threshold that blackholes you at the first sign of load. The rest of this guide gives you the vocabulary to separate them: the attacks that hit a VPS, the layers that stop each one, the difference between always-on and on-demand mitigation, why packet rate matters more than bandwidth, and the seven questions that force a vague answer into a specific one.

The attacks that actually hit VPSes

Most VPS attacks fall into two buckets: volumetric floods that fill your uplink and application floods that exhaust the server. Amplification, SYN and fragmented-packet floods dominate the first; HTTP floods and slowloris dominate the second. The table below maps each to the layer that stops it.

Amplification is the reason a single home broadband line can knock over a datacentre uplink. The attacker spoofs your IP as the source of a small request to an open DNS, NTP, memcached or CLDAP server, and that server fires a much larger reply back at you. The multiplier between request and reply is the amplification factor, and it ranges from a handful for some protocols to several orders of magnitude for others. The US CISA / US-CERT guidance on UDP-based amplification attacks (alert TA14-017A) catalogues those factors by protocol; the worst offenders it lists turn a trickle of outbound requests into a flood large enough to saturate most uplinks.

SYN and ACK floods work differently. They do not need much bandwidth, they need packets: a torrent of tiny forged handshakes that fills the server’s connection table and burns CPU on state it will never complete. Fragmented-packet floods add reassembly cost on top. All three are transport-layer problems, which is why they are dropped upstream at the network edge rather than on the box itself.

L3/L4 vs L7: what network scrubbing can and cannot see

Network scrubbing at L3/L4 sees packets — source, destination, protocol, rate — and drops floods by the million without touching payload. It cannot read an HTTP request or a game login, so an L7 flood that mimics real users passes straight through. L7 defence lives closer to the application.

Think of it as two filters with different eyesight. The L3/L4 filter reads envelopes: it can see that ten million identical SYN packets are arriving from spoofed sources and shred them without ever opening one. That is exactly the right tool for volumetric and packet-rate floods, and it works at line rate because it never has to understand what the traffic means.

An L7 flood defeats that filter on purpose. The requests are well-formed, they complete a real handshake, and each one looks like a legitimate user asking for a page or logging in. Stopping them needs a defence that understands the application protocol — rate and behaviour analysis for a web stack, or protocol-aware filtering for a game server, the approach covered in how to protect a Minecraft server from DDoS. A provider that only advertises L3/L4 numbers has told you nothing about how it handles application floods. Our edge filters L3, L4 and L7, which is why we quote all three rather than a single bandwidth figure.

Always-on vs on-demand: the first 30 to 90 seconds

Always-on protection filters every packet all the time, so an attack meets mitigation with no gap. On-demand protection sits idle until a detector trips, then reroutes your traffic through a scrubbing centre — a swing that commonly costs the first 30 to 90 seconds. Our network is always-on.

The gap is the whole story. An on-demand system has to notice the attack, decide it is real, and shift your routes so traffic flows through its scrubbers before anything gets filtered. During that window the flood lands on your server untouched, which for a short, sharp attack can mean the attack is already over by the time mitigation engages. Detection latency is therefore a spec worth asking for by number, not a footnote.

On-demand is acceptable when attacks are rare, sustained rather than bursty, and a minute of downtime at the start is tolerable. It is the wrong model for anything real-time. On our network there is no swing to wait for: filtering is always in the path, detection runs in under one second, and traffic is never rerouted to a distant scrubbing centre and back.

Gbps vs Mpps: why packet rate beats bandwidth

Bandwidth headline numbers hide the real bottleneck. Small-packet floods break routers on packets per second, not gigabits. A 64-byte SYN flood at 10 Gbps is roughly 14.8 million packets per second, and it is the packet rate — not the raw bandwidth — that overruns forwarding hardware first.

Forwarding a packet costs the same lookup work whether the packet is 64 bytes or 1,500. So a flood of tiny packets makes a router do far more work per gigabit than a flood of large ones. That is why the 10 Gbps figure above translates to nearly 15 million decisions a second: fill a link with minimum-size frames and the packets-per-second rate, not the bit rate, is what melts the forwarding plane. A provider that only quotes Tbps has answered the easy half of the question.

Our published mitigation capacity is 3.2 Tbps. The packets-per-second ceiling that matters most for small-packet floods, {{CAPACITY_MPPS}}, is not a figure we currently publish, so treat any provider’s Tbps headline — ours included — as only half the answer, and ask for the Mpps rating alongside it. A large-packet flood at the same bandwidth is a fraction of that packet rate and far easier to absorb; the small-packet case is the one that decides whether a network holds.

Null-routing is not protection

Null-routing, or blackholing, discards every packet bound for your IP — attack traffic and your users alike. It protects the provider’s network, not your service, because the outcome is exactly what the attacker wanted: you offline. When a plan advertises “free DDoS protection” with no detail, this is often what it means.

Blackholing is trivial to run and cheap for the provider. When traffic to an address crosses a threshold, the provider advertises a route that sends everything for that IP to a discard interface. The upstream links stay healthy and the attack stops hurting the network — by taking your service down completely. From the attacker’s point of view it is a clean win, achieved for the price of tripping a counter.

Real mitigation does the harder thing: it separates bad packets from good ones and keeps your service reachable through the attack. That is the line the next section’s questions are designed to expose.

7 questions to ask any provider before buying

Before you pay for any anti ddos vps, get written answers to these seven questions. Each one maps to a spec that a serious provider already publishes on its network page. If a sales team cannot answer them quickly, that silence tells you where the protection actually stands.

1. What is the total mitigation capacity, in Tbps and Mpps? Bandwidth and packet rate are separate ceilings; a real answer gives both, not just the bigger-sounding one. (Maps to: capacity.)
2. Is filtering always-on, or on-demand? If on-demand, ask what happens during detection and reroute, and how long that swing takes. (Maps to: always-on vs on-demand.)
3. Which layers are covered — L3, L4, L7? An L3/L4-only network has no answer for HTTP floods and other application-layer attacks. (Maps to: L3/L4/L7.)
4. What is the detection-to-mitigation time? Ask for a number in seconds, not the word “fast”. (Maps to: detection time.)
5. What happens above the threshold — filter or null-route? This is the single question that separates protection from a blackhole. (Maps to: null-route policy.)
6. How much protected bandwidth is included, and what does extra cost? Some plans protect a small slice and meter the rest. (Maps to: protected bandwidth.)
7. Where does scrubbing physically happen relative to your server? If the scrubbers sit in another city, every packet detours there first. (Maps to: where scrubbing happens.)

That last point is worth dwelling on, because location changes the latency maths. If scrubbing is in a different region, your traffic takes the long way round on every request — fine when it is deliberate, as with remote DDoS protection with a GRE tunnel routed to a scrubbing edge on purpose, and a problem when it is an on-demand surprise you did not price in. Seven answers in writing turn a vague “yes we protect you” into a spec you can compare across providers.

How protection works on our network

On our network, every VPS sits behind 3.2 Tbps of always-on mitigation at the Frankfurt edge. Filtering covers L3, L4 and L7, runs with detection under one second, and never reroutes your traffic. There is no separate add-on and no surcharge — protection is on from the moment the VPS boots.

The filtering is part of the network itself, not a box bolted on after the fact. Traffic for a DDoS-protected VPS in Frankfurt enters through our own autonomous system, AS211138, and DE-CIX, the largest internet exchange in Europe by traffic volume, then gets scrubbed at the edge before it ever reaches your instance. Because mitigation is always in the path, there is no detection swing and no window where a flood lands unfiltered.

Two things follow from that design. First, the answers to all seven questions above are the same for every plan we sell, from the entry VPS at 3.49 euro per month upward, because the protection is a property of the network rather than a tier you upgrade into. Second, latency stays flat: with no rerouting, a protected instance in Frankfurt behaves like an unprotected one right up until the moment attack packets are being dropped. The facility is a Tier III datacentre in Frankfurt am Main, and the network is backed by a 99.9% uptime SLA.

FAQ