A denial-of-service attack is not subtle. The goal isn’t to break in — it’s to drown your server in so much junk that real visitors can’t get through. The moment your VDS gets a public IP, it joins a list that automated tools constantly probe, and sooner or later something will throw traffic at it. The reassuring part: most of that traffic never reaches your server, because we filter it upstream before it touches your machine. This post explains exactly what “up to 10 Gbps” covers, what the baseline mitigation does on its own, and where you still need to do your part.
DDoS protection and a firewall solve different problems. The firewall decides *what* is allowed to connect; DDoS mitigation decides *how much* traffic is legitimate enough to forward. You want both.
The three families of DDoS attacks
Almost every attack you’ll see falls into one of three buckets, and they fail your server in different ways.
Volumetric floods are the brute-force end of the spectrum. The attacker simply sends more bits per second than your link can carry — UDP floods, amplified DNS or NTP reflection, that sort of thing. Your server might be perfectly healthy, but the pipe leading to it is full, so nothing legitimate gets in. This is what people usually picture, and it’s measured in gigabits per second.
Protocol and state-exhaustion attacks are sneakier. Instead of flooding bandwidth, they exhaust a resource that’s expensive to track. A classic SYN flood opens thousands of half-finished TCP connections, filling the table the kernel uses to remember them. The traffic volume can be modest, but the server runs out of connection slots and stops answering anyone.
Application-layer attacks (Layer 7) look like real users. They send valid HTTP requests by the thousand to your slowest endpoints: a search query, a login form, a page that hits the database hard. Each request is legitimate on its own, so from the network’s point of view nothing is wrong. It’s your application that buckles.
Volumetric attacks fill the pipe, protocol attacks fill the table, and application attacks fill your CPU. Different problems, different defences.
What “up to 10 Gbps” actually means
The 10 Gbps figure is the capacity of our upstream scrubbing layer to absorb and filter inbound attack traffic for your server — the size of flood we can soak up and clean before it ever reaches you. It is not the speed of your VDS, and it isn’t a promise that any single attack will be exactly that big.
When a flood arrives, traffic destined for your IP is inspected at the network edge. Obvious garbage — spoofed sources, malformed packets, known reflection signatures, floods that don’t match any real session — gets dropped there. What’s left, the clean traffic, is forwarded to your server. From inside the VDS, a multi-gigabit volumetric attack often looks like nothing happened at all.
This baseline is included on every VDS at no extra cost. If your workload regularly attracts attacks larger than the baseline can absorb, higher tiers are available on request.
What the baseline filters automatically
The upstream scrubbing handles the first two families well, because both are visible at the network and transport layers:
- Volumetric floods — absorbed and dropped at the edge, up to the tier’s capacity, so your link stays usable.
- Protocol / state-exhaustion attacks — SYN floods, ACK floods, fragmentation tricks and reflection are recognised by pattern and filtered before they reach your connection table.
You don’t configure any of this, and there’s no agent to install. It runs in front of your IP continuously.
Note. The baseline is genuinely automatic for volumetric and protocol floods — but it cannot read your application. Layer-7 attacks that send valid-looking requests will pass straight through to your server. Those are yours to handle.
The limits, stated plainly
Two honest caveats.
First, scrubbing capacity is finite. “Up to 10 Gbps” means floods beyond that can still saturate the link. If you’re a likely target — gaming, crypto, a high-profile site — tell us, and we’ll size a higher tier before you need it.
Second, and more important for most people: application-layer attacks need application-level defences. Because Layer-7 traffic is indistinguishable from real users at the network edge, no amount of upstream scrubbing fixes a login endpoint being hammered. That defence has to live where the requests are understood — in your app and in front of it.
What you should still do yourself
Treat the baseline as your outer wall, then build the inner ones:
- Rate-limit expensive and auth endpoints. A simple per-IP cap stops a single source from monopolising your server.
- Cache aggressively. Static and cacheable responses served from cache cost almost nothing under load.
- Put a WAF / CDN in front of public web apps to filter bot patterns and absorb request spikes closer to the visitor.
- Set sane timeouts. Don’t let slow or stalled connections hold resources indefinitely.
A minimal nginx rate limit covers a surprising amount of ground:
# 10 requests/sec per client IP, small burst allowed
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
server {
location /login {
limit_req zone=api burst=20 nodelay;
}
}# reload after editing # nginx -t && systemctl reload nginx
The network keeps the floods off your pipe; rate limits, caching and a WAF keep the clever requests off your CPU. Between the two, the vast majority of denial-of-service attempts simply stop being your problem. And if something larger shows up, 24/7 human support is one message away — backed by a 99.999% SLA, so the protection is there when you actually need it.
