Summary

  • A provider's aggregate scrubbing capacity and mitigation-time SLA do not, on their own, reserve clean throughput for one protected site.
  • The useful entitlement joins the covered prefix, routing mode, CIR, packet-rate envelope, validated handoff, clean-traffic evidence, degradation threshold and remedy.

Imagine an attack whose malicious packets are removed exactly as designed. After filtering, one gigabit per second of legitimate traffic remains. The provider dashboard says mitigation is active. The customer's application is still losing sessions because the clean stream must pass through a GRE tunnel, an upstream path, an edge router and an origin that were sized or tested on different assumptions. Which contract line proves that the clean gigabit had to arrive?

The numbers are hypothetical; the mechanism is not. Cloud DDoS service has at least two capacity surfaces. One is the provider's shared attack-absorption platform. The other is the path that returns legitimate traffic to a particular protected network. Buying the first does not automatically specify the second.

CIR is a commercial boundary, not a capacity slogan

Akamai's current Services Descriptions makes the distinction unusually visible. It defines Clean Bandwidth as traffic measured after mitigation and calculates it monthly at the 95th percentile. Regular samples are sorted, the highest five per cent are discarded, and the next value is compared with contractual Committed Information Rate, or CIR, for overage billing.

The same document defines CIR as the contracted monthly clean bandwidth stated in the order form and the minimum amount of Prolexic service for which the customer must pay. For Routed GRE, clean non-DDoS inbound traffic at each provisioned data-centre location must remain below that CIR unless Akamai approves otherwise.

Those are clear facts. A further conclusion must be marked as inference: because the public definition describes expected traffic and billing commitment, it should not be called dedicated or uncontended clean capacity unless the order form or SLA says so expressly. A buyer that treats CIR as a reservation without reading the governing schedule may be converting a billing metric into a performance promise that the public text does not make.

The handoff has its own engineering envelope

The public service description also places concrete requirements beyond the scrubbing centre. A location above 300 Mbps CIR needs a dedicated router capable of at least 10 million packets per second with IMIX traffic. Above 600 Mbps, the router location needs a 10 Gbps burstable upstream connection unless Akamai approves otherwise. Every dedicated router must be able to decapsulate GRE traffic at twice the location CIR.

The document allocates to the customer issues involving end-to-end transport from the Prolexic environment to the customer data centre and decapsulation at the received rate. An On-Demand customer is responsible for notifying Akamai when traffic must be rerouted unless it has bought Flow-based Monitoring. Applicable Prolexic Routed SLAs also depend on successful Service Validation during the previous 12 months.

This allocation does not show that a provider has failed. It shows why an attack outcome cannot be inferred from a provider-platform headline. Bits per second, packets per second, encapsulation overhead, route state, interconnect status and router capacity can all sit between successful filtering and a usable application.

Platform scale and customer entitlement answer different questions

Akamai's product material says Prolexic has more than 20 Tbps of dedicated DDoS defence capacity across 32 anycast scrubbing centres. It also presents a zero-second mitigation SLA and 100 per cent platform availability SLA, while Direct Connect offers 10 G and 100 G ports with stated connectivity-uptime levels.

These claims are relevant to provider resilience. They do not disclose a customer's order form, approved burst, contention treatment, false-positive tolerance, latency or loss threshold, credit formula or claim window. The public packet also does not prove how simultaneous attacks are allocated among customers. Those are unknowns, not defects that can be alleged from public material.

Evidence must reach the origin boundary

Akamai's reporting documentation separates pre-mitigation flow, post-mitigation flow and traffic to origin. Routed-event records can include alerts, packet captures, source lists, attack rates and vectors. Connection views can distinguish tunnels, circuits and protected addresses.

That structure suggests a useful evidence chain, but another boundary matters: public documentation does not establish that every field is legally authoritative for a credit. The contract should say which clocks, sampling intervals and measurement points govern. A provider can prove that attack traffic was removed while a customer proves that legitimate sessions failed; without a joined timeline, both statements may be true and the remedy may remain undecidable.

There is no allegation here that Akamai contends capacity, loses clean traffic or denies valid credits. Its documents are evidence of the service architecture and commercial definitions, not of a customer incident. The analysis is prospective: it asks what a buyer must settle before an attack.

Sources