The null-route problem: when a flood exceeds a provider's real capacity, the cheapest "mitigation" is BGP blackholing — withdrawing your IP from routing entirely. The attack stops, and so does your business. From the customer's side, "we mitigated the attack" and "we took you offline" can be the same sentence.
1. The actual protection layers
Real defense is a stack, and each layer handles what the one below it can't:
- Upstream volumetric filtering: the only layer that matters against big floods. A 10 Gbps link cannot absorb a 50 Gbps attack no matter how clever the software on your VM is — the pipe fills before packets reach it. Filtering at the transit/datacenter edge is where capacity lives.
- Edge ACLs and rate limits: dropping invalid TCP flag combinations, reflection-vector source ports (NTP 123, CLDAP 389, SSDP 1900), and enforcing per-protocol sanity caps at wire speed.
- Protocol-aware validation: SYN cookies for TCP; for game servers, packet validation that drops malformed Minecraft/FiveM/Steam-query payloads without touching real players.
- Application layer: HTTP floods, login abuse and game-protocol exploits are invisible to upstream filters — a bad request and a real request are identical packets. This layer is yours: firewalls, fail2ban, WAF rules, panel permissions.
2. Why geography is part of protection
Some protection schemes work by re-announcing your traffic through scrubbing centers on another continent. The mitigation is real — but every clean packet now travels to Europe and back, permanently adding 150ms+ to an Indian audience that was the reason you hosted in India. Ask where filtering happens, not just whether it exists.
3. The questions that expose a badge
- "What is your mitigation capacity, and is it stated in writing?" — a provider with real scrubbing says a number.
- "At what threshold do you null-route, and for how long?" — the honest answer involves scrubbing first and blackhole as last resort. "We protect you by taking you offline" is the wrong answer.
- "Where does filtering happen?" — in-country/on-net filtering preserves latency; offshore scrubbing reroutes your clean traffic.
- "Is protection always on or per-incident billed?" — paying per attack turns your worst day into their revenue event.
4. Where we stand — honestly
Our Delhi NCR, Mumbai and Singapore locations carry upstream volumetric DDoS protection (those regions are flagged DDoS-protected in our catalog; Frankfurt, US-East and Dhaka are not). That handles the L3/L4 floods that no VM-level tooling can survive. What it deliberately does not claim: application-layer protection — your WordPress login page, your game server handshake, your API. We document per-VM firewalling for that layer because pretending upstream filters cover it would be exactly the marketing we're criticizing in this article.
If you're a game-server customer, the practical takeaway: large UDP floods are our upstream's problem; bot-joining and protocol abuse are yours to configure against — and our guides cover it.