A 200 Gbps flood hits your 10 Gbps uplink: what can a rented scrubbing centre do that your edge firewall cannot?

## The shape of the problem A volumetric denial-of-service attack does not defeat a security control; it defeats a **pipe**. Your service reaches the internet through a transit circuit of some fixed capacity — say 10 Gbps. When an adversary directs 200 Gbps of traffic at your addresses, the congestion happens on your upstream provider's router, on the interface that faces you. That interface has 10 Gbps of outbound capacity toward you and 200 Gbps of demand, so it drops about 95% of everything — attack packets and real customers alike, without regard to which is which. Everything you own is *behind* that interface. Your edge router, your firewall, your load balancer and your servers only ever see the ~10 Gbps that got through. This is the single most important fact about volumetric attacks and it is the one candidates most often miss. ## Why edge filtering does not help A firewall rule that denies the attack sources is not wrong — it is simply irrelevant to the outcome. Consider what dropping a packet at your edge actually saves: | Where the packet is dropped | Bandwidth reclaimed on the congested link | |---|---| | Your firewall / server | none — the packet already crossed it | | Your edge router | none — same link | | Your transit provider's router | all of it | | A network several hops further out | all of it, closer to the sources | Dropping traffic only helps at or before the point of congestion. Since the point of congestion is the last mile you rent, only somebody upstream of it can help you. That somebody is either your transit provider (with a blunt instrument) or a mitigation provider you have contracted with. A second reason edge filtering fails: at these volumes the attack is usually spread across tens of thousands of sources, often reflected off innocent third-party servers, so there is no small source list to deny. And your firewall itself has a finite packet-per-second rating; a flood of small packets can exhaust its forwarding or state capacity long before it exhausts the bandwidth. ## What renting capacity actually buys A scrubbing provider operates edge capacity vastly larger than any single customer's uplink, distributed across many locations. Traffic destined for you is steered into that network, inspected and filtered there, and only the traffic judged legitimate is delivered onward to your origin. Two things are being rented, and they are different: - **Capacity** — the ability to take delivery of hundreds of gigabits without falling over. This is the part your own budget could never justify buying outright, because you would need it for a few hours a year. - **A vantage point** — a place in the path that sits ahead of the congestion, where a drop decision still means something. ## What it costs, and why that matters in the interview The half of this answer that separates a strong candidate from a weak one is the price. Renting clean pipes is not free protection; it is a set of ongoing obligations: - **Money on a quiet day.** Whether you keep traffic flowing through the provider permanently or only during an event, there is a standing fee, usually tied to a committed level of clean traffic, and often a separate per-event charge. - **Latency and dependency.** If your traffic always transits their network, every ordinary request pays whatever detour that implies, on every day of the year when nothing is happening — and their outage becomes your outage. - **A return path.** Cleaned traffic still has to reach your origin somehow, over a tunnel or a dedicated circuit that you also pay for and that has its own capacity ceiling. - **Someone else's verdicts.** The control that decides which of your customers are real is operated by a third party. Their logs are theirs; when a partner reports failures during mitigation, you can raise a ticket, not run a query. ## Where renting is the wrong answer If the attack fits inside your uplink — a few thousand requests per second against an expensive endpoint, say — the congestion argument does not apply, and diverting buys you latency, cost and a change window in exchange for a control that may have less context about your application than you do. Rented capacity is the answer to *volume*, and volume specifically. ## The honest one-line summary You cannot filter your way out of a full pipe from behind the pipe. You either own enough capacity to absorb the flood, or you rent someone else's — and renting has a bill, a latency cost, a dependency and a return path attached to it.