GitHub went down for roughly ten minutes on 28 February 2018, and the reason it did not go down for longer had very little to do with the number on anyone’s front page. According to GitHub’s own engineering write-up, inbound traffic peaked at about 1.35 Tbps from a memcached reflection attack, and the site stayed unavailable or intermittent only until its traffic was routed to Akamai’s scrubbing network. That event is the one buyers now reach for when they ask about Tbps scrubbing capacity. It is also the event most likely to send them shopping for the wrong thing: a bigger aggregate number, rather than capacity in the right place, at the right packet rate, covering all three of the surfaces an attacker can reach.
So how much do you actually need? The honest answer starts with your own uplink, not the provider’s marketing.
What a Tbps Figure on a Datasheet Actually Measures
When a vendor prints a capacity figure, it can mean at least three different things, and they are not interchangeable.
- Global aggregate: the sum of every scrubbing centre’s capability across the network, including centres on continents your traffic never touches.
- Per-point-of-presence capacity: what a single scrubbing location can ingest and clean. This is the number that defends you, because attack traffic enters at the nearest peering points to the botnet, not at a global average.
- The contracted slice: what is actually reserved for your prefixes if several customers are under fire at once, which in most contracts is nothing at all. Capacity is pooled and oversubscribed, in the same way an airline sells more seats than it flies.
There is a second distinction that datasheets rarely make: forwarding capacity versus mitigation capacity. A centre may have terabits of port capacity and still fall over on packet rate or session state, because inspecting, classifying and dropping traffic costs far more per packet than moving it. Akamai’s reporting on the GitHub event put the peak at roughly 1.35 Tbps, but the figure security teams should have taken away was the packet rate, measured in the region of 127 million packets per second. Hardware dies at packet rate long before it dies at bit rate.
For a buyer whose users and origin sit in London, Frankfurt and Ashburn, the aggregate is close to useless as a sizing input. What matters is the capacity of the nearest scrubbing centre to where the junk traffic lands, and how quickly the provider can anycast the load out across neighbouring sites before the local PoP saturates.
One question separates the straightforward providers from the rest. Ask what happens when two large customers are attacked in the same hour, in the same region. The good answers involve reserved capacity, documented load-shedding policy and upstream signalling to transit partners. The bad answer is a pause.
Sizing the Headroom Your Estate Really Needs
Start with the pipe you own. A colocation customer on a 10 Gbps transit port is offline at 12 Gbps of inbound junk, regardless of how many terabits sit upstream, because the saturation happens on the port before the traffic ever reaches a scrubbing decision. That is the whole argument for upstream cloud mitigation over on-premises appliances, and it is why anyone buying rack space should work through a colocation DDoS protection checklist before signing, rather than after the first incident.
The sizing arithmetic has three inputs:
- Your uplink: 1, 10 or 100 Gbps per port, and the aggregate of all ports into the estate. Anything above that line is an outage unless mitigation happens upstream of it.
- Observed attack sizes against organisations like you: vendor threat reporting, including Cloudflare’s quarterly DDoS threat reports, has consistently found that the overwhelming majority of network-layer attacks are small, well under a gigabit, with a thin tail of terabit-scale events. Size for the band you will actually meet, then buy headroom for the tail.
- Headroom ratio: a multiple of the largest attack you consider plausible, not of the largest attack ever recorded. Ten times your transit capacity is a defensible starting point for a mid-sized estate; a hosting provider carrying other people’s risk needs considerably more.
The goalposts move, and contracts should say so. The Spamhaus attack of March 2013, reported at roughly 300 Gbps, was a record at the time. Five years later a single reflection vector produced more than four times that against GitHub. Any capacity clause written without a review mechanism will be stale inside two renewal cycles.
Sustained Rate Versus Burst
Short bursts of several hundred gigabits, lasting under a minute, are now common. They do not usually exhaust a scrubbing network. What they exhaust is your detection and diversion window: by the time flow telemetry has sampled, a threshold has tripped and a BGP announcement has converged, the burst is over and your users have already seen timeouts. Repeat that every twenty minutes for a day and the aggregate capacity figure is irrelevant. The useful metric is time to mitigate.
The Second Axis: Packets and Requests
Bit rate is one axis. Packet rate and request rate are the other. A flood of 64-byte packets at a few hundred million packets per second can exhaust forwarding tables, NAT state and session tables on firewalls while sitting nowhere near the advertised Tbps ceiling. Likewise an HTTP request flood measured in requests per second can knock over an application origin at bandwidth you would not notice on a graph. If a sizing conversation with a provider only discusses terabits, it is an incomplete conversation.
Where Extra Scrubbing Capacity Stops Helping
Capacity gets bought for one surface and then quietly assumed to cover three. It does not.
Authoritative DNS. This is the layer most often left unmanaged, and the Mirai-driven attack on Dyn in October 2016 is the standing lesson. Organisations whose websites were perfectly healthy became unreachable because the authoritative DNS answering for their domains was not. If your scrubbing tier covers your web prefixes but your nameservers sit with a registrar on a free tier, your resilience has a single point of failure that no amount of upstream capacity will touch. Secondary DNS with a second independent provider costs a fraction of a capacity upgrade.
Application-layer floods. Layer 7 request floods and TLS handshake attacks arrive inside legitimate-looking sessions at modest bandwidth. They are defeated by rate limiting, challenge logic, bot classification and origin tuning, not by scrubbing headroom. The differences between the big proxy vendors show up far more sharply here than in their capacity claims.
Carpet bombing. Spread a few hundred gigabits thinly across every address in a /22 and no single destination IP crosses a per-host detection threshold. Detection configured per host sees nothing. The transit link still saturates. Ask explicitly whether thresholds are evaluated per prefix as well as per IP.
State exhaustion behind the scrubbed path. Clean traffic is still traffic. A stateful firewall, load balancer or origin application that falls over at a few hundred thousand concurrent sessions will fall over on the scrubbed side of the service, having been passed exactly the traffic the contract promised to deliver.
Always-On or On-Demand: When the Capacity Actually Arrives
With on-demand mitigation, capacity is theoretical until diversion completes. The number to negotiate is time from first packet to clean traffic, and it is the sum of detection, decision, BGP announcement, internet convergence and return-path setup. Several of those steps are outside the provider’s control. A contract that promises a 15-minute mitigation SLA against attacks that last eight minutes is selling you reporting, not protection.
Return-path mechanics catch colocation buyers out more than anything else in this field. Diverted traffic has to get back to your origin somehow, typically over GRE tunnels, a direct cross-connect or a dedicated circuit, and that path is asymmetric: inbound via the scrubbing centre, outbound straight to the internet. Tunnel MTU, keepalive behaviour and the capacity of the return circuit all become part of your sizing. Mechanically, this is where the plumbing of a cloud scrubbing service deserves more scrutiny than its headline numbers.
Always-on proxying suits web estates: no diversion delay, full layer 7 visibility, at the cost of terminating TLS with a third party and adding a hop. Routed always-on protection suits whole prefixes, including non-HTTP services, with less application visibility. Price and size them as different products, because that is what they are.
Agree in writing who can trigger diversion, on what evidence, out of hours, and how that process is proved. A twice-yearly diversion test, scheduled and observed, is worth more than any clause. Many ISP-bundled offerings never get tested at all, which is one reason to understand what UK ISP-level protection covers and what it quietly excludes.
Questions to Put to a Provider About Capacity
- What is the capacity of the scrubbing centre nearest our users, and nearest the regions our attack traffic typically originates from? Per PoP and per region, not global.
- Is our capacity shared, reserved or oversubscribed, and what is the policy when several customers are attacked simultaneously?
- What packet-per-second and request-per-second rates can be mitigated, as distinct from forwarded?
- What is mitigated inline, what is signalled upstream to transit partners, and at what point does ISP-level blackholing enter the chain? Blackholing completes the attack; know when it will be used on you.
- Are detection thresholds evaluated per prefix as well as per IP?
- What does post-incident reporting contain: vectors, peak bits, peak packets, source distribution, and the elapsed time from first packet to clean traffic?
The UK’s National Cyber Security Centre sets out the same logic in its denial of service guidance collection, which is worth reading alongside any vendor proposal, not least because it frames the problem as service availability rather than bandwidth.
What the Capacity Tier Does to Your Bill
UK managed DDoS pricing is not keyed off the provider’s headline capacity. Quotes are typically built from a clean bandwidth commit, measured in megabits or gigabits of legitimate traffic delivered to you, plus the number of protected prefixes or IPs, plus a support tier. Move up a capacity tier and the bill usually changes through those levers rather than through a single line item.
The charges that surface after the quote are predictable enough to ask about in advance: burst and overage rates on clean traffic (often billed at 95th percentile), per-prefix or per-IP fees as your estate grows, additional protected ports or tunnels, and incident support hours outside the included allowance. A seasonal ecommerce peak that trebles clean traffic for six weeks can cost more in overage than the next tier would have cost outright.
Size the premium against downtime, not against fear. Take the revenue or service minutes genuinely at risk for the services in scope, multiply by a defensible outage duration, and set that against the annual difference between tiers. If the sum does not justify the upgrade, the honest conclusion is to spend the money on secondary DNS, origin hardening and a tested diversion runbook instead. There is a board-ready model for that calculation if you need to present the number upwards.
A defensible answer on Tbps scrubbing capacity looks less like a single figure and more like a short paragraph: our transit is X, our plausible attack band is Y, we need Z times headroom at the PoP nearest our traffic, with stated packet-rate handling, per-prefix detection, separate cover for authoritative DNS and layer 7, and a measured time to clean traffic. Take that to a provider and the conversation changes immediately.
Frequently Asked Questions
How much Tbps scrubbing capacity does a mid-sized business actually need?
Work from your own transit capacity rather than from record attack headlines. If your estate sits behind 10 Gbps of transit, you need upstream mitigation that comfortably exceeds the largest attack you consider plausible against your sector, with meaningful headroom at the scrubbing centre closest to your traffic. For most mid-sized organisations that is a question of hundreds of gigabits in the right region, not terabits globally.
Is a provider’s advertised Tbps figure per scrubbing centre or across the whole network?
Almost always across the whole network. Ask for the per-point-of-presence and per-region figures, because attack traffic enters at the peering points nearest the botnet, and that is the capacity defending you. Also ask whether capacity is reserved or oversubscribed when several customers are attacked in the same window.
Does scrubbing capacity protect authoritative DNS and application-layer traffic?
Not by default. Volumetric scrubbing addresses network and transport floods against the prefixes in scope; authoritative DNS and layer 7 request floods usually need separate services and separate contract lines. The 2016 attack on Dyn took websites offline through DNS alone, and organisations that had bought web mitigation only were still unreachable.
Why can an attack take a site down well below the provider’s Tbps ceiling?
Because packet rate, session state and application cost break equipment before bandwidth does. Small-packet floods at hundreds of millions of packets per second exhaust forwarding and state tables, and carpet-bombing attacks spread volume across a prefix so that no single address trips a per-IP threshold. Bit rate is only one of the axes that matter.
Does a bigger capacity tier cost more in UK managed DDoS pricing?
Usually, but indirectly. Quotes are built around clean bandwidth commit, protected prefixes and support tier, so the extra cost typically appears as higher commit, per-prefix charges and overage rather than as a line labelled capacity. Ask for the burst and overage rates in writing before you compare two proposals, and check the pricing terms current at the time you sign.