An Akamai DDoS test answers a different question than a cloud test does: not "is my configuration correct," but "does the traffic actually route through Akamai's mitigation, does the operated response close in time, and is my origin reachable by anyone who skips the whole thing."
Akamai runs one of the largest DDoS mitigation networks in existence. That is not in question. What a test interrogates is whether your estate is wired into it the way you assume, because Akamai defends by routing, and routing is a thing that is either in place or quietly is not.
This is the Akamai edge and mitigation stack: Prolexic for network-layer scrubbing and App and API Protector for the application layer. It is a separate subject from running compute on Akamai Connected Cloud, which is the Linode DDoS testing story, where the trap is a commodity instance the edge was never put in front of. Here the edge is the point, and the question is whether it holds under load.
It is the Akamai-specific instance of structured DDoS testing, a sibling to Cloudflare DDoS testing. The two are the closest pair in the set: both are pure edges in front of an origin that lives elsewhere, so both share one invariant, that all traffic must arrive through the edge. But Akamai reaches that invariant by a different route, literally, and the difference is what a test is built around.
Two ways Akamai mitigation gets in the path
Cloudflare is one anycast edge, always on, that you join by proxying a DNS record. Akamai is two distinct mitigation products reached by two distinct routing mechanisms, and they are provisioned and contracted independently.
Prolexic protects at L3/L4 by announcing your IP prefixes over BGP so entire ranges route to Akamai scrubbing centers, with clean traffic returned to you over GRE tunnels or dedicated connectivity. It is a routing decision made at the network layer, and it can defend infrastructure that has no HTTP hostname at all.
App and API Protector protects at L7 on Akamai's CDN edge, reached the ordinary CDN way: a DNS CNAME to an Akamai edge hostname, so requests resolve to the edge and the WAF, bot, and rate controls apply before anything reaches your origin.
An estate can have one, both, or neither. A financial API might route its prefixes through Prolexic and never touch the CDN edge. A content site might CNAME to App and API Protector and never announce a prefix. So on Akamai, "is protection in the path" is not one question. It is two, and they have separate answers you have to check separately.
The property that makes an Akamai test its own shape
Because Akamai mitigates by routing, and because Prolexic can run in two modes, the headline finding is not a permissive rule. It is a routing choice with a timing consequence.
Prolexic runs either always-on, with your prefixes routed through Akamai continuously, or on-demand, announced over BGP only once an attack is detected. On-demand is cheaper and simpler to live with day to day, and it carries a cost that only appears under attack: a diversion window. Detection, the BGP announcement, and route convergence across the internet all take time, and during that window the attack lands on your origin directly, before a single packet reaches a scrubbing center.
This is the same shape as an on-premise scrubbing center's diversion window, delivered as a managed service. Always-on collapses it to near zero at a steady-state latency and cost; on-demand trades that steady cost for an exposure gap you can only size by measuring it. Which mode you run, and how long the window actually is for your prefixes, is the first thing an Akamai test establishes.
The second property is that Akamai mitigation is operated, not autonomous. Cloudflare's dosd profiles and mitigates without a human in the loop. Prolexic includes a staffed Security Operations Command Center that can apply mitigations manually, tune scrubbing, and coordinate during an incident. That human loop is part of the control, which means it is part of what a test has to exercise, the same way a readiness assessment treats the response process as in scope rather than assumed.
At a glance: what an Akamai DDoS test validates
| Akamai control | What it is supposed to do | What the test actually verifies |
|---|---|---|
| Prolexic (routing mode) | BGP-routed L3/L4 scrubbing of whole prefixes | Whether it is always-on or on-demand, and the real diversion window if on-demand |
| Prolexic (scrubbing + return path) | Filter volumetric and protocol floods, return clean traffic | Detection-to-mitigation interval; that the GRE/return path itself is not the bottleneck |
| App & API Protector (WAF) | L7 inspection against managed and custom rules | Whether rules act in Deny, not Alert; rule ordering; false-positive posture |
| App & API Protector (rate + bot) | Rate controls and bot scoring at the edge | Whether the counting key and threshold engage; whether the action enforces |
| Site Shield | Restrict the origin to Akamai edge IPs only | Whether a direct connection from outside the Akamai ranges is refused |
| The operated response (SOCC) | Human detection, escalation, manual mitigation | Whether the runbook and escalation path actually close inside the attack's timeline |
The recurring theme is Akamai's own: the strongest controls in the catalog are routing and people, and both are things that are either wired in and rehearsed or merely contracted.
Any layer defends only the traffic that routes through it. Whether every prefix and every hostname actually does is the check worked through in is your protection actually in the path.
The protection surface you are testing
Be precise about each layer, and whether it is present and in the path, before designing the test. On Akamai that precision turns on the two routing mechanisms and the operated loop above them.
Prolexic: scrubbing as a routing decision
Prolexic sits at the network layer. When your prefixes are announced to Akamai, floods route to scrubbing centers that discard malformed packets, reflection and amplification traffic, SYN floods, ACK floods, and carpet-bombing across a range, then return what survives.
Two things about this are testable facts rather than assumptions. The first is the routing mode and its window, covered above and measured below. The second is the return path: clean traffic comes back over GRE tunnels or dedicated links with their own capacity, and a large scrubbed volume returning through an undersized tunnel can itself become a layer of first failure. The test confirms the return path carries a realistic post-scrub volume, not just that scrubbing works in isolation.
App and API Protector: the L7 edge
App and API Protector is the application-layer control on Akamai's edge. It evaluates requests against Akamai's managed rulesets and your custom rules, scores clients for automation, and applies rate controls, all before traffic reaches the origin.
Every rule carries an action, and the load-bearing distinction is Alert versus Deny. A rule in Alert logs what it would have caught and blocks nothing. This is the single most portable finding across every edge in the set, the same condition as a Cloudflare rule in Log, AWS WAF in COUNT, and Azure WAF in Detection mode. Rather than re-derive it, the Cloudflare test works through the mechanics; on Akamai the test submits canonical malicious payloads and confirms the WAF rule fires in Deny, not merely increments a counter.
Rate controls have the same trap as any rate limit: the value of the control is in the counting key and the threshold, not in its existence. A control keyed on client IP alone misses a distributed HTTP flood whose per-source rate stays low, and can punish real users behind a shared egress. Bot scoring, using signals including JA3/JA4 fingerprints, is only as good as whether its action is set to challenge or deny rather than log. Each of these is a hypothesis about traffic, and a test is how you find out whether the hypothesis is right.
The CDN edge and cache absorption
App and API Protector rides on Akamai's CDN, so cacheable content is served from the edge and never reaches the origin. That absorbs a large class of volumetric L7 pressure for free, and it has the same limit every cache does: it only absorbs what is eligible to be cached, and an attacker who manufactures cache misses converts an edge-absorbed flood into an origin flood. That mechanism is worked through for a programmable cache in Fastly DDoS testing; the test measures how much of a realistic attack the edge actually serves versus what becomes origin-facing load.
Site Shield: the origin lock
Because Akamai and your origin are separate systems, the origin needs its own lock that says "accept connections only from Akamai." Site Shield is Akamai's mechanism for it: a maintained list of the edge server IPs that will contact your origin, which you enforce at the origin firewall so that everything else is refused.
A perfect WAF and a fully scrubbed prefix are both worth nothing if the origin answers a direct connection, because the attacker simply never sends a packet either control will see. This is the origin IP exposure problem in Akamai form, identical in principle to Cloudflare's IP allowlist and examined end to end in how attackers bypass CDN protection. The Akamai-specific detail is that the Site Shield map changes over time, so the origin firewall has to track it, and a stale allowlist is its own slow failure.
The operated response as a control
Prolexic is sold with a manned SOCC and an emergency integration runbook. In an incident, humans can trigger on-demand routing, adjust scrubbing signatures, and coordinate with your team. That is a genuine strength, and it is also a dependency: the mitigation that matters may be the one a person applies, not the one a machine applied automatically.
A control that includes people is only validated by exercising the people. Does the escalation path reach someone with authority to act? Is the emergency contact current? Does an on-demand trigger, whether automatic or SOCC-initiated, actually converge inside the window your service can tolerate? None of that shows on a configuration page.
What Akamai DDoS testing actually surfaces
A useful test is organized around the gaps that recur on Akamai estates. They follow from the shape above: mitigation is routed, some of it is on-demand, and some of it is operated by people.
The routing mode is the headline
On a cloud with a managed WAF, the common finding is a rule in a permissive mode. On Akamai the prior question is whether the traffic is routed to mitigation at all, and if on-demand, how long it takes to get there.
The test establishes, in order, which prefixes are announced to Prolexic and whether always-on or on-demand, whether the CNAME for each public hostname actually resolves to the Akamai edge, and, for on-demand Prolexic, the measured diversion window from attack onset to steady-state scrubbing. An estate can hold a full Prolexic and App and API Protector contract and still run one service on a prefix nobody moved behind it, or a hostname whose CNAME was reverted during a migration.
The diversion window, measured not quoted
For on-demand Prolexic, "it eventually scrubbed" hides the number that matters. The window is detection time plus BGP announcement plus internet route convergence, and during it the origin absorbs the attack unmitigated.
The detect-gap archetype maps onto this exactly: traffic ramps, the trigger fires, a shaded window elapses while routes converge, and only then does the volume reaching the origin fall to the clean-pipe baseline. The point of measuring it is not to reject on-demand, which is a legitimate cost trade-off, but to know whether the window fits inside what your origin and your users can survive, and whether always-on is warranted for the prefixes that cannot tolerate it.
The operated loop has to close
Because the SOCC is part of the defense, a test that only measures automated behavior measures half the control. The exercise is the same discipline a readiness assessment applies: trigger the conditions that should invoke the human response, and time whether it closes.
This is where an operated service can be stronger or weaker than an autonomous one, and only a rehearsal tells you which. A current runbook, a reachable on-call with authority, and a rehearsed on-demand trigger make the human loop an asset. A stale contact list and an escalation path nobody has walked make it the slowest link in the chain, discovered mid-incident.
App-layer rules in Alert, and origin exposure
Two findings recur that this post deliberately does not re-derive, because they are identical across the edge siblings and are covered there in full.
App and API Protector rules left in Alert log attacks and block nothing, the exact detect-versus-enforce gap dissected in the Cloudflare and cloud posts. The test confirms every rule meant to defend is in Deny.
Origin exposure voids everything above it. If the origin's real IP leaks through historical DNS, a certificate transparency entry at crt.sh, an unmoved A record, or an IP baked into a client bundle, an attacker connects directly and skips Prolexic, the edge, and every L7 control at once. The defining test is mechanical: from outside the Akamai ranges, attempt a direct connection to the candidate origin IP. Site Shield, enforced at the origin firewall, must refuse it.
Akamai authorization: testing an operated service
An Akamai test differs from a self-serve edge test in one important way: you are generating attack-shaped traffic against a network with a staffed operations center whose job is to react to exactly that.
High-volume simulated traffic through Prolexic or the edge is traffic against an Akamai deployment, and Akamai's own testing guidance and acceptable-use terms apply on top of authorization from the target's owner. More than that, an unannounced test can trigger the very response you are trying to measure: the SOCC applying a mitigation, or on-demand routing engaging, turns your test into a live operational event for Akamai's team.
So the durable instruction here is not only procedural but collaborative. Coordinate the window with Akamai in advance, so the SOCC knows the traffic is authorized and so a planned test of the human loop is a rehearsal rather than a surprise. The specifics of contacts and process change over time, which is exactly why the rule is to confirm current guidance and coordinate, not to memorize a threshold. Underneath it all, written authorization from the legal owner of the target is mandatory, and the platform gates sit on top of that consent, never in place of it. Keeping the blast radius contained is what makes any of this safe to run near production.
Designing the test: environment, scope, and measurement
The structure that keeps an Akamai test informative and safe is the one that governs any production-adjacent test, contoured to routed, operated mitigation.
Environment selection
A faithful staging target mirrors production's routing and edge state: the same App and API Protector configuration exported and reapplied, fronting a staging origin, and where feasible a test prefix that exercises Prolexic in the same mode production runs. Configuration mirrors cleanly; the parts that resist mirroring are the two that matter most on Akamai, the real diversion window on your production prefixes and the reachability of the real origin IP. Both have to be confirmed against production, scoped to tightly bounded checks with explicit abort criteria, because it is the production routing and the production origin whose exposure you actually care about.
Scope as a bounding document
The scope names the exact prefixes announced to Prolexic and their mode, the hostnames CNAMEd to the edge and their App and API Protector policies, the Site Shield map in force, the GRE or return-path capacity, the maximum rates and source counts, the test windows aligned to change control, the kill switch, and the escalation path, including the agreed Akamai coordination contact for the window.
On Akamai specifically, the scope records routing mode per prefix and edge state per hostname at test time, because the test deliberately compares a through-mitigation path against a direct-to-origin path and, for on-demand prefixes, characterizes the diversion window.
Measurement per control
Each control gets a measured outcome. Prolexic: routing mode confirmed, detection-to-mitigation and, if on-demand, the diversion window; return-path headroom under post-scrub volume. App and API Protector: which rules fired, in which action, and the latency added. Rate and bot controls: the rate and key at which they engaged, and whether realistic bursts survived. Site Shield: whether the direct-to-origin attempt was refused. The operated loop: whether escalation reached an authorized responder inside the window.
The deliverable is not "the site stayed up." It is a per-control characterization: what engaged, automated or human, at what threshold, in what order, and what a real user experienced while it did. Folding those numbers into a defensible posture is the subject of DDoS resilience testing.
Mapping attack classes to Akamai controls
A thorough test exercises each layer against the control meant to defend it. The mechanics of each class are in DDoS attack vectors, and real adversaries rarely send one class at a time, which is the subject of multi-vector DDoS testing.
- L3/L4 volumetric and protocol (SYN flood, UDP reflection, ACK flood, carpet-bombing) are Prolexic's domain. The test confirms the prefix is routed, in which mode, and measures the diversion window and the return path under a realistic post-scrub volume.
- L7 HTTP floods (HTTP flood, HTTP/2 abuse, slow attacks) are App and API Protector and the CDN edge. They exercise rule actions, rate keys and thresholds, cache eligibility, and the cost of evaluation under sustained volume.
- Application-logic abuse (credential stuffing under the rate control, expensive search, cart abuse) is the hardest class anywhere, because the requests are valid. Bot and API controls address part of it at the edge; the rest is an application-code concern no platform solves for you.
- Direct-to-origin is not an Akamai control at all. It is defended, or not, by Site Shield and the origin firewall, and it is the class the edge cannot see, so a test must check it from outside Akamai.
Procurement note: subscription versus project engagement
One consideration sits at the procurement layer rather than the technical one. Akamai's mitigation is contracted and tiered, and the validation of that mitigation is a separate discipline procured on its own terms.
DDoS testing services are engaged both as an ongoing subscription and as a discrete project, and the two suit different cadences. An Akamai estate changes in ways that each warrant a test: a prefix moved from on-demand to always-on, a new service CNAMEd to the edge, a Site Shield map update, an App and API Protector policy overhaul. Change-triggered testing maps naturally onto project engagements; a continuously changing estate may prefer a standing capability. Neither is universally correct, and the annual commitments some vendors require can price out a team whose real need is a handful of well-scoped tests a year. Match the engagement model to the cadence the estate actually warrants.
FAQ
What is Akamai DDoS testing?
Controlled, authorized generation of attack-shaped traffic against an Akamai-protected estate, to verify how the mitigation behaves under pressure. It validates whether prefixes are routed to Prolexic and in which mode, the real diversion window for on-demand routing, whether App and API Protector rules act in Deny rather than Alert, whether the origin is reachable around the edge, and whether the operated response closes in time, rather than testing whether Akamai's network works in general.
What is the difference between Prolexic and App and API Protector?
Prolexic is BGP-routed L3/L4 scrubbing of whole IP prefixes, reached by announcing those prefixes to Akamai. App and API Protector is L7 WAF, bot, and rate protection on Akamai's CDN edge, reached by a DNS CNAME to an edge hostname. They are provisioned and contracted separately, so an estate can run one without the other, and a test checks each path independently.
Does on-demand Prolexic leave a gap?
Yes, a diversion window. On-demand announces your prefixes over BGP only after an attack is detected, so detection, announcement, and route convergence all elapse while the attack reaches your origin directly. Always-on routing removes that window at a steady cost. The test measures the real window for your prefixes so you can decide which mode each one warrants.
How does Akamai stop attackers reaching my origin directly?
Site Shield: Akamai publishes the edge IPs that will contact your origin, and you enforce that list at the origin firewall so every other source is refused. It is Akamai's form of origin lockdown, and like any allowlist it fails if the origin IP leaks and the firewall is not enforcing the current map. The direct-connection check from outside Akamai's ranges is the first thing a test confirms.
Do you need permission to run an Akamai DDoS test?
Treat it as required and coordinate it. High-volume simulated traffic is traffic against an Akamai deployment, so Akamai's testing guidance applies, and because Prolexic is operated by a staffed SOCC, an unannounced test can trigger a live mitigation response. Confirm current guidance, coordinate the window so the team expects the traffic, and obtain written authorization from the target owner regardless.
What an Akamai test is really auditing
Five years from now, Akamai will still scrub floods at BGP-routed scrubbing centers, App and API Protector will still evaluate rules at the edge, Site Shield will still be the origin's allowlist, and the network will still only defend what routes through it. Those properties are stable.
What drifts, and so has to be re-verified, is everything wired on top:
- the routing mode of each prefix, where an on-demand window nobody has measured is an exposure nobody has priced
- whether every public hostname still CNAMEs to the edge, or one was reverted in a migration
- App and API Protector rule actions, where an Alert-mode rule outlives the tuning exercise that created it by years
- the Site Shield map at the origin firewall, which goes stale every time Akamai updates it or a new origin comes up without it
- the emergency runbook and on-call, which nobody maintains until the day the SOCC calls and the number is wrong
Akamai does not ship a weak network. It ships mitigation that is entirely a function of how traffic is routed into it and of a response loop that includes people. The scrubbing will hold. The open questions, the ones only a test answers, are whether the traffic actually gets there in time, and whether the humans on the other end of the contract pick up.