A 200 Gbps flood hits your 10 Gbps uplink: what can a rented scrubbing centre do that your edge firewall cannot?
answer
- the fight happens upstream of you
- your transit link fills first
- dropping it late frees nothing
- someone with a much bigger front door
- capacity rented, with a bill attached
basics
~20 sNothing at your edge helps, because the transit link is already saturated before packets reach your firewall. A scrubbing provider has far more inbound capacity, absorbs and filters the flood upstream, and forwards only cleaned traffic to you.
solid answer
~50 sThe fight is lost upstream of anything you own. A 200 Gbps flood fills the 10 Gbps transit circuit itself, so your legitimate traffic is already discarded by congestion on your provider's side; a deny rule on your firewall only decides the fate of packets that survived the queue, and dropping them frees no bandwidth on the link they already crossed. Renting clean pipes moves the filtering to a network whose ingress capacity is measured in terabits: the provider takes delivery of the attack, discards it there, and hands you back only what passed. What you are buying is capacity and a place to stand, not a smarter rule. The price is real — a standing commitment or a per-event bill, a dependency on somebody else's control, and a return path you also have to pay for and keep working.
go deeper
Be ready to say plainly that the congestion happens on the link into your site, so any drop decision you make behind that link is too late. Name capacity, not cleverness, as the thing being rented.
An interviewer expects you to explain why source-based denies fail at this scale and to name what the rented service costs: a standing fee, added latency if traffic always transits it, and a return path you also pay for.
Show judgment about when not to divert. Say which attacks fit inside your uplink and should be handled where you have application context, and what your own edge must still do to traffic the provider has already passed.
Own the framing that this is a capacity purchase with a permanent dependency attached: somebody else's network in your critical path, somebody else's verdicts on your customers, and a bill that must be defended on the 364 days nothing happens.
## 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.
- If the provider absorbs the flood, why keep filtering rules at your own edge at all?Because the provider only filters what it can see and judge. Application-layer abuse that looks like ordinary requests, anything arriving direct to your origin because someone bypassed the diversion, and internal traffic never touch their edge. Rented capacity answers volume; your own edge still enforces policy on whatever survives the scrubbing, and it is the only place you have full logs.
- What kind of attack is the wrong reason to divert into rented capacity?One that fits comfortably inside your uplink. A slow application-layer flood at a few megabits per second causes no congestion, so the capacity argument does not apply. Diverting costs you latency, money and a change window, and the provider often has less context about your application than you do. Handle that where you can see the request and the session.
- Does the attack traffic stop when you divert?No. The adversary keeps sending; the traffic is simply delivered somewhere that can absorb it. That matters for two reasons: the moment you stop paying for or stop using the diversion, the flood lands on your uplink again, and any address of yours that is not covered by the diversion is still reachable and still attackable.
A blocked motorway does not clear because the car park at the end has a barrier. The jam has to be diverted before the exit, on a road wide enough to hold it.
saying these in an interview costs you the question
- Says a bigger firewall would have absorbed the flood
- Thinks denying source addresses at your edge frees uplink bandwidth
- Assumes the transit provider filters floods for free
- Treats scrubbing as free once the contract is signed
- Believes diverting makes the attacker stop sending