Why a flood aimed at one VPS is a flood at every guest on its node, why budget hosts answer with a null route, what DDoS protection has to mean on a VPS, what the guest still handles itself, the questions to ask a host, and when a protected VPS is enough or a dedicated server is the better buy.
A DDoS protected VPS is one whose traffic is filtered before it reaches the host node, so it stays reachable during a flood instead of being switched off to save its neighbours. Many VPS plans list "DDoS protection"; few say where the filter sits, how large an attack it takes, or what happens to your address when an attack is larger. Below: why budget hosts null-route a VPS at the first flood, what protection must mean on shared hardware, what stays your job, what to ask, and when to move to a dedicated server.
A VPS node is one physical server, and every guest on it reaches the internet through the same physical port. Your plan's port speed and guaranteed rate describe your share of it. A flood does not respect shares: traffic aimed at one guest arrives on the node's link, and once that link is full, every guest's legitimate traffic queues and drops with it.
RFC 5635 describes the pattern: more attack traffic than the links to the victim can carry, legitimate traffic starved, collateral damage to other customers. Its remedy is for the provider to discard traffic to the target address "in order to preserve network availability". That is a null route: the attacked VPS goes dark, its neighbours recover, and the attacker has what they came for. Null routing covers the mechanism. For a host with no filtering in front of its nodes, it is the only tool available, and the rational one.
No VPS port absorbs a modern flood by itself. Ours are 25 Gbps; measured in those ports, attacks from Cloudflare's reports look like this:
| Attack (Cloudflare report) | Size | × a 25 Gbps port |
|---|---|---|
| Routine for the Aisuru botnet (2025 Q3) | over 1 Tbps | over 40 |
| Aimed at a Minecraft server (2022 Q3) | 2.5 Tbps | 100 |
| Largest of 2025, lasted 35 seconds (2025 Q4) | 31.4 Tbps | 1,256 |
Cloudflare's Q3 2025 report says the majority of attacks are relatively small. Small is relative to the port, though, and reflection makes a full port cheap. CISA lists NTP's bandwidth amplification factor as 556.9, measured in payload bytes, so about 25,000 ÷ 556.9 ≈ 45 Mbps of spoofed requests can come back as 25 Gbps of replies. Types of DDoS attacks goes through the vectors.
Protection works only if the filter sits upstream of the node, at the network edge, where capacity is counted in terabits rather than in one server's gigabits. Attack traffic is dropped there, clean traffic continues to the node, and the shared port carries only what is left.
Anything closer to the VPS is too late for a volumetric flood. A firewall in the guest, rules on the hypervisor, an appliance behind the node's port: each inspects packets that have already crossed the full link. They help against small, slow attacks, not a full pipe.
Two more properties matter:
Upstream filtering removes floods that look like floods. Three things stay with you.
Your guaranteed rate. The filter passes what looks legitimate. Real users, plus any attack traffic the filter cannot tell from them, arrive through your plan's share. On a 1 Gbps guaranteed plan, plan on 1 Gbps, not on the 25 Gbps port.
The guest kernel. Traffic that slips through at low rates, such as a modest SYN flood, lands on your kernel's backlog and connection-tracking tables. RFC 4987 describes SYN cookies, which let a server answer a SYN without holding state for it. On a KVM VPS you run your own kernel and can tune those limits; a container VPS shares the host's.
The application. Network-layer filters see addresses, ports and packet shapes, not HTTP requests, so a flood of valid-looking requests to your login page passes them. Network-layer attacks were 78% of those Cloudflare saw in Q4 2025; the other 22% were HTTP floods, which need caching, web-server rate limits and Layer 7 filtering.
One more job: do not become a source. CISA advises disabling unneeded UDP services and rate-limiting DNS responses; an open resolver or a stray memcached port on a VPS is easy to find and aim at someone else.
| Question | A good answer | A warning sign |
|---|---|---|
| How large an attack is covered? | A number in Gbps or Tbps | A promise with no number |
| What happens above that? | Null route or not, for how long, who lifts it | "Case by case" |
| Where is traffic filtered? | At the network edge, before the node | On the node or in your guest |
| Network layer only, or Layer 7? | Each tier names its layers | No layer named |
| Which addresses are covered? | Every IPv4 and IPv6 address | Only the main IPv4 |
| What does an extra IP cost? | A price, and whether it is protected | Found out on the invoice |
How to choose a VPS has the rest of the checklist: cores, storage and guaranteed bandwidth.
Every plan on our unmetered VPS page runs on a 25 Gbps unmetered port with a guaranteed rate per plan, dedicated 3.2 GHz vCPUs, DDR4 and NVMe in RAID10, activated instantly in Frankfurt, Amsterdam, Paris, Madrid, Milan, Vienna, Dublin or Bucharest. All five include 100 Gbps DDoS protection:
| vCPU | RAM | NVMe | Guaranteed | DDoS included | Monthly |
|---|---|---|---|---|---|
| 1 | 4 GB | 50 GB | 1 Gbps | 100 Gbps | €29 |
| 2 | 8 GB | 100 GB | 2 Gbps | 100 Gbps | €59 |
| 4 | 16 GB | 200 GB | 4 Gbps | 100 Gbps | €119 |
| 8 | 32 GB | 400 GB | 6 Gbps | 100 Gbps | €239 |
| 16 | 64 GB | 800 GB | 8 Gbps | 100 Gbps | €459 |
Larger tiers are a choice on the order form when you configure the VPS:
| Tier | Filtering | Added monthly |
|---|---|---|
| 100 Gbps | L3/L4 | €0, included |
| 500 Gbps | L3/L4 | €149 |
| 1 Tbps | L3/L4 | €499 |
| 2 Tbps | L3/L4 | €999 |
| 5 Tbps | L3/L4 | €2,499 |
| 10 Tbps + Layer 7 | L3/L4 and Layer 7 | €4,499 |
All prices checked 26 October 2026; tier prices exclude VAT. The included tier is 100 ÷ 25 = 4 times what the port itself can carry, and 100 times the entry plan's 1 Gbps guarantee. To change tier on a running VPS, ask support; put the questions above to us too, and get the answers in writing.
A protected VPS is enough when:
Move to a dedicated server when:
DDoS protected dedicated server covers that side, from how scrubbing works to sizing a tier.
A DDoS protected VPS is a virtual server whose traffic passes through a filter at the provider's network edge before it reaches the host node. Floods are dropped there and legitimate traffic continues to the VPS, so the attack never fills the node's shared port and the host has no reason to null-route your address.
Because every guest on a node shares its physical port. A flood aimed at one VPS fills the link for all of them, and without filtering upstream the only quick fix is to discard all traffic to the attacked address. The neighbours come back online; the target stays dark until the route is lifted.
It covers floods up to four times what a 25 Gbps VPS port can carry, and Cloudflare reports that most attacks are relatively small. It does not cover botnets that routinely exceed 1 Tbps. If you have been hit at that scale before, pick a 1 Tbps or larger tier, or a dedicated server.
No. Network-layer (L3/L4) filtering judges packets by address, port and protocol behaviour, so well-formed HTTP requests from a botnet pass through it. HTTP floods need caching, rate limits in the web server and Layer 7 filtering, which on our plans comes with the 10 Tbps tier.
A server cannot filter a flood that has already filled its port, so protection has to sit upstream. How the filtering works, why hosts null-route unprotected IPs, always-on versus on-demand, what a 100 Gbps tier does and does not cover, how big a tier to buy and seven questions to ask any host.
A hidden primary, three secondaries in different cities and networks, TSIG-signed NOTIFY and zone transfers, a working Knot DNS config with automatic DNSSEC signing, and the dig commands that prove an authoritative DNS server answers correctly. Plus what it costs and when managed DNS wins.
Nobody watches the hardware of a dedicated server for you. What to monitor in five layers: disks, RAID, ECC memory and IPMI sensors; space, memory, load and clock; interface errors and bond members; the service from a second location; and a minimal Prometheus and Alertmanager stack with seven alert rules.