A Fastly DDoS test answers one question: when adversarial traffic arrives, how much of it does the edge serve from cache, and what reaches your origin when it cannot.
It is not a test of whether Fastly's network works. Fastly absorbs very large floods at its edge as a matter of public record, but only for traffic it can answer from cache. That single qualifier is the whole subject.
Fastly is a caching reverse proxy before it is anything else. Its edge is a heavily modified Varnish that you program in VCL, and increasingly in Fastly Compute Wasm code. So the resilience of a Fastly-fronted service is a function of one number under pressure: the fraction of attack traffic that hits cache versus the fraction that becomes a request your origin has to answer.
This is the Fastly-specific instance of structured DDoS testing, with siblings for AWS, Azure, GCP, and the other reverse-proxy edge, Cloudflare. Fastly shares Cloudflare's structural split, the edge and the origin live on separate infrastructure, and that shared property is covered in depth on the Cloudflare page rather than re-derived here.
Where Fastly diverges is the center of gravity. Cloudflare's story is a secret being kept: the origin's address. Fastly's story is a cache being hit: the attacker's job is to manufacture misses, and the test's job is to measure how many get through.
At a glance: what a Fastly DDoS test validates
| Fastly control | What it is supposed to do | What the test actually verifies |
|---|---|---|
| Edge cache (Varnish) | Serve responses from the POP so the origin never sees the request | The cache hit ratio under a cache-busting attack, and the request rate that reaches origin when it collapses |
| VCL / Compute logic | Your edge code: routing, normalization, blocking, rate logic | Whether the logic you wrote actually runs in the order you think, and holds under adversarial input |
| Edge Rate Limiting | Cap requests per client key over a window at the POP | Whether the counting key and threshold engage where intended without rejecting legitimate bursts |
| Next-Gen WAF (Signal Sciences) | Signal-and-threshold L7 detection at the edge or as an origin agent | Whether it is in blocking mode, not monitoring; whether thresholds fire on your traffic shape |
| Origin Shield | Funnel all POP cache misses through one shield POP to protect origin | Whether shielding is enabled, and what the origin fan-out looks like without it |
| Origin lockdown (IP allowlist, TLS auth) | Accept connections only from Fastly | Whether a direct connection to the origin from outside Fastly's ranges is refused |
The recurring theme is Fastly-shaped: the platform gives you a fast programmable cache and a set of controls, and the resilience lives in what is cacheable, what you programmed, and whether the origin stays reachable only through the edge.
A cache defends a request only while that request stays cacheable. The moment an attacker makes it unique, it becomes a pass to origin, and the same volumetric pressure the edge would have shrugged off lands on a single backend.
The protection surface you are testing
Before designing the test, be precise about what each layer does. Fastly exposes more of its request lifecycle to you than most edges, because you write it, which makes the test plan unusually concrete and also unusually easy to get wrong.
The edge is a programmable cache
Fastly's edge runs Varnish, and you shape its behavior with VCL: subroutines like vcl_recv, vcl_hash, vcl_fetch, and vcl_deliver decide how a request is normalized, what it keys on, whether it is cacheable, and what is served. Fastly Compute adds a Wasm runtime for the same job in a general-purpose language.
This is the property that makes Fastly different to test. On a hyperscaler you audit a managed service's configuration. On Fastly you are auditing code, and code has ordering, branches, and bugs. A protection that lives in a VCL subroutine can be correct in isolation and defeated by an earlier return(pass) that never lets it run.
Caching and the cache-miss problem
A cached response is answered at the POP nearest the client, and the origin never hears about it. An uncacheable response, a PASS in Varnish terms, is proxied straight to the origin every single time.
What is uncacheable is larger than teams assume. POST and other state-changing methods, anything behind a Set-Cookie or a Vary that fragments the object, authenticated endpoints, search queries, and any URL carrying a unique query string the origin has to interpret. Each of those is a request the cache cannot short-circuit.
That is the surface an attacker aims at. A flood of identical GET / requests is the easy case: the cache absorbs it. A flood of GET /?_=<random> requests, or requests that rotate a cache-busting header, misses on every hit and converts a cheap edge-absorbed flood into an expensive origin flood. The most valuable number a Fastly test produces is the cache hit ratio while under exactly that pressure, and the origin-facing request rate when it falls.
Origin Shield
Fastly runs many points of presence, and by default a cache miss at any of them opens its own connection to your origin. Under a distributed cache-busting attack, that means misses arriving at your backend from POPs worldwide at once.
Origin Shield collapses that fan-out: you designate one POP as a shield, and all other POPs fetch misses through it, so the origin sees requests from a single intermediary and benefits from a second, consolidated cache tier. Whether shielding is enabled, and where the shield sits relative to the origin, is a real and testable variable in how much a miss storm actually reaches the backend.
Edge Rate Limiting
Fastly gives you rate limiting at the edge, both as VCL primitives (ratecounters and penaltybox objects you increment and check) and as a more productized Edge Rate Limiting feature. It counts requests against a key you choose over a window and applies an action when the count crosses a threshold.
As on any edge, the power and the trap are both in the key. A limit keyed on client IP alone misses a distributed flood whose per-source rate stays low, and punishes many real users behind one CGNAT address. Because on Fastly you often assemble this yourself, the test also has to confirm the counter is actually consulted on the uncacheable paths that need it, not just the ones that were easy to instrument.
Next-Gen WAF: signals, thresholds, and mode
Fastly's Next-Gen WAF is the former Signal Sciences product, and its detection model is worth stating precisely because it differs from a signature ruleset. Rather than matching each request against a corpus, it tags requests with signals (SQLi, XSS, anomalous behavior, custom signals you define) and raises a site alert when a signal's rate from a source crosses a threshold, then acts on that source.
It deploys in more than one place: at the Fastly edge attached to a service, or as an agent-and-module pair running at your own origin or application. Where it runs changes what it can see and where enforcement happens.
The mode is the finding that recurs. The Next-Gen WAF runs in blocking, not blocking (monitoring, where it observes and alerts but drops nothing), or off. A WAF left in not-blocking mode produces a beautiful signal timeline and stops no attack. This is Fastly's instance of the single most portable edge finding, the exact analog of AWS WAF in COUNT, Azure WAF in Detection mode, a Cloud Armor rule in preview, and a Cloudflare rule in Log.
Origin lockdown
Because Fastly and your origin are separate systems, the origin needs its own lock that says accept connections only from Fastly. Two mechanisms carry it: an origin firewall that allowlists Fastly's published IP ranges (Fastly serves that list from its API so an allowlist can be kept current), and origin authentication, where Fastly presents a client certificate via mTLS or injects a shared secret header that the origin verifies and requires.
A service with a perfectly tuned WAF is still trivially defeated if neither is in place, because the attacker who has the origin IP never sends a packet the edge will ever see. This is the same class of failure detailed for the other edge in Cloudflare DDoS testing and end to end in how attackers bypass CDN DDoS protection; on Fastly the lock differs only in the mechanism names.
What Fastly DDoS testing actually surfaces
A useful test is organized around the gaps that recur across real Fastly services. On Fastly the first of these is not a misconfiguration in the usual sense. It is a property of what you are serving, and it leads.
The cache-busting attack: manufacturing misses
The defining Fastly gap is that an attacker decides, request by request, whether your edge is a shield or a passthrough.
Fastly absorbs a cacheable flood almost for free. So a competent adversary does not send a cacheable flood. They rotate a query parameter, vary a header that appears in your Vary, target a POST endpoint, or hit an inherently dynamic path like search or login, and every request becomes a PASS. The edge dutifully proxies each one to your origin, and the fact that the traffic transited a global CDN provides no protection at all, because none of it was ever eligible for cache.
The test drives both shapes and compares them. A cacheable HTTP flood to confirm the cache absorbs it, then a cache-busting flood at the same edge request rate to measure the origin-facing pass rate. The gap between those two origin curves is the real exposure, and it is the number a datasheet about edge capacity will never tell you.
Remediation is design work, not a toggle: normalize away frivolous query strings in VCL so cosmetic variation still hits cache, cache what can safely be cached even briefly (a short TTL on a hot dynamic object changes the math), enable Origin Shield, and put edge rate limiting and Next-Gen WAF thresholds specifically on the uncacheable paths, because those are the only ones that can actually be flooded to origin.
The WAF sitting in monitoring mode
The Next-Gen WAF is frequently deployed in not-blocking mode during onboarding, to watch what it would catch before risking false positives on real users. Then nobody promotes it to blocking.
The result is a service that records attacks in fine-grained signal detail and stops none of them. The test submits canonical malicious payloads and abusive patterns and confirms the relevant signal crosses its threshold and the source is actually blocked, not merely alerted on in the console. Confirm it separately for edge deployment and any origin-side agent, because the two are configured independently and drift apart.
The defense you wrote in VCL
Because your edge logic is code, part of the test is a code review with traffic behind it.
Common failure modes are ordering and coverage. A return(pass) or an early return(lookup) placed before your rate-limit check means the check never executes on the requests that matter. A normalization rule that runs after the hash means cache-busting variants still fragment the cache. A blocking condition written for one path silently does not apply to the three others that were added later. VCL and Compute logic can be unit-tested and diffed like any code; a DDoS test confirms the deployed behavior matches the intended behavior under input an attacker actually sends.
Rate-limit thresholds and the counting key
A rate limit is only as good as its key and its window. The test drives floods at increasing rates and source counts and checks two failure directions at once.
Too loose, or keyed only on IP, and a distributed flood slips under the per-source threshold while the aggregate buries the origin. Too tight, and a legitimate burst trips the limit and the rule becomes the outage. Calibrating that boundary is the point of rate limiting, and on Fastly it has the extra wrinkle that the limit only helps on paths where you remembered to invoke it.
Origin exposure: the bypass that skips the cache entirely
If the origin IP leaks and the origin accepts connections from anywhere, the attacker connects to it directly and every edge control, cache included, is irrelevant. This is the same failure class as on Cloudflare, so the mechanics are covered there and in origin IP exposure; the short version is that the address leaks through historical DNS, certificate transparency logs at crt.sh, non-proxied subdomains, and hardcoded IPs, and the defining test is mechanical.
From a host outside Fastly's published ranges, open a direct TCP connection to the candidate origin IP on 443. It must be refused at the origin firewall, or fail origin authentication. If it completes and serves your site, the edge is decorative.
Detection-to-mitigation timing for a novel flood
Fastly also offers automatic L7 DDoS mitigation that acts on attributes of the traffic rather than fixed signatures. Like any autonomous system, it needs a brief interval to characterize a previously unseen pattern before mitigation reaches steady state.
The number that matters is the interval from attack onset to effective mitigation for your traffic shape against your endpoints, measured rather than quoted. Cacheable volumetric pressure is absorbed at the edge essentially immediately; a cache-busting L7 flood that resembles real users is the slow case, and where tuned VCL, edge rate limiting, and a blocking Next-Gen WAF earn their place. Folding those intervals into a defensible posture score is the work of DDoS resilience testing.
Fastly authorization: you are testing through someone else's network
A Fastly test traverses infrastructure you do not own, and that changes the authorization picture in the same way the Cloudflare test does.
On the through-edge path, your test traffic crosses Fastly's global network before it reaches anything of yours, and Fastly's own automatic mitigation cannot tell your authorized test from a real attack. High-volume simulated traffic through the edge falls under Fastly's acceptable-use and testing terms. The thresholds and the process change over time, so the durable instruction is procedural: before generating load, read Fastly's current stance on load and penetration testing of your own service, and coordinate as it requires.
On the direct-to-origin path, the traffic never touches Fastly; it lands on whatever hosts the origin, and is governed by that host's policy instead. Underneath both sits the non-negotiable: written authorization from the owner of the target. Platform terms are an additional gate on top of that consent, never a substitute for it, and keeping the blast radius contained is what makes any of this safe to run near production.
Designing the test: environment, scope, and measurement
The discipline that keeps a Fastly test informative and non-destructive has a Fastly-shaped contour.
Environment selection
Fastly's configuration is versioned: services are cloned and activated as numbered versions, and the whole config can be managed through the API and Terraform. That makes a faithful staging service straightforward, the same VCL or Compute code, the same WAF signals and rate rules, fronting a staging origin that mirrors the real one.
A mirror exercises the real edge logic without touching live users. But one finding cannot be confirmed in staging: origin reachability of the real public IP. That check runs against production infrastructure, scoped to a single direct connection attempt with explicit abort criteria, because it is the production origin's exposure you actually care about.
Scope as a bounding document
The scope names the service and the exact hostnames, the VCL subroutines and WAF rules in play, the maximum request rates and source counts, and specifically the mix of cacheable and cache-busting traffic, because on Fastly that mix is the variable that determines what the origin feels. It records the test windows aligned to change control and the kill switch: the ability to activate a previous service version, flip the WAF to blocking, or engage rate limits on demand.
Measurement per control
Each control gets its own measured outcome. Cache: the hit ratio under each traffic shape and the origin-facing pass rate. WAF: which signals fired, in which mode, and whether the source was blocked. Rate limiting: the rate at which the cap engaged and whether realistic bursts survived. Origin: whether the direct connection attempt was refused.
The deliverable is not that the site stayed up. It is a per-control characterization: what the cache absorbed, what passed to origin, which layer engaged at what threshold, and what a real user experienced while it did.
Mapping attack classes to Fastly controls
A thorough test exercises each layer against the control meant to defend it. A service tuned against one class can fall to another at a fraction of the volume.
- L3/L4 volumetric and protocol (SYN flood, UDP reflection, carpet-bombing) meet the edge's raw anycast absorption capacity. The test confirms the edge takes the pressure and the origin never sees it.
- Cacheable L7 floods are the cache's job, and the good case: high volume, absorbed at the POP, origin untouched. The test confirms the content is actually cacheable and stays cached under load.
- Cache-busting and uncacheable L7 floods (HTTP flood, pulse-wave bursts against dynamic paths) are the real risk surface. They pass to origin, so they exercise edge rate limiting, WAF thresholds, Origin Shield, and ultimately the origin's own capacity.
- Application-logic abuse (credential stuffing under the rate limit, checkout abuse, expensive search) is the hardest class, because the requests are syntactically valid and inherently uncacheable. Only custom signals, tuned WAF thresholds, and bot management using JA3/JA4 catch them.
- Direct-to-origin is not a Fastly control at all. It is defended, or not, by the origin firewall and origin authentication, and it is the class a test must check from outside Fastly.
Procurement note: subscription versus project engagement
One consideration sits at the procurement layer rather than the technical one. Fastly's protection is plan-and-product tiered, and validating that protection is a separate discipline procured on its own terms.
DDoS testing services are sold both as an ongoing subscription and as a discrete project engagement, and the two suit different cadences. Change-triggered testing, after a VCL overhaul, a WAF mode change, a new origin, or a Compute migration, maps naturally onto project engagements: the test happens when the change happens. A service under constant churn may prefer a standing capability. Neither is universally correct; match the engagement model to the cadence the service actually warrants.
FAQ
What is Fastly DDoS testing?
Controlled, authorized generation of attack-shaped traffic against a Fastly-fronted application, to verify how the service behaves under pressure. It measures what the edge cache absorbs versus what passes to origin, whether the Next-Gen WAF and rate limits are enforcing rather than monitoring, whether your VCL logic runs as intended, and whether the origin is reachable directly past Fastly.
Does Fastly's cache make DDoS testing unnecessary?
No. The cache absorbs cacheable floods well, which is exactly why real attacks target what is uncacheable: cache-busting query strings, POST endpoints, search, and login. Testing measures the origin-facing pass rate under that pressure, which is the number that actually predicts an outage.
What is a cache-busting attack on Fastly?
A flood engineered to miss the cache on every request (rotating a query parameter or header, or hitting inherently dynamic paths) so that each request becomes a PASS proxied to the origin. It converts a flood the edge would have absorbed into one the origin has to answer, and it is the defining Fastly failure mode.
Do you need Fastly's permission to run a DDoS test?
For the through-edge path, effectively yes: high-volume simulated traffic crosses Fastly's network and its automatic mitigation cannot distinguish your test from a real attack, so it falls under Fastly's acceptable-use and testing terms. Read Fastly's current policy and coordinate. The direct-to-origin path is governed by the origin host's policy. Either way, written authorization from the target's owner is mandatory.
Can an attacker bypass Fastly to reach my origin?
If the origin IP leaks and the origin accepts connections from anywhere, yes, and that single condition voids the entire edge, cache included. It is the first thing a Fastly test checks. The defenses are an origin firewall that allowlists Fastly's published ranges and origin authentication via mTLS or a required secret header.
What a Fastly test is really auditing
Five years from now, Fastly will still front traffic at an anycast edge, Varnish will still answer cache hits at the POP, and a PASS will still travel to your origin. Those properties are stable.
What drifts, and so has to be re-verified, is everything layered on top:
- the cacheability of your responses, one new
Set-CookieorVaryaway from turning a cached path into a passthrough - the VCL you wrote, where an early
return(pass)can quietly route around a control that still looks present in the code - the Next-Gen WAF mode, where a not-blocking rule outlives the onboarding window that created it by years
- the rate-limit keys and thresholds, calibrated against a traffic shape the application has since outgrown
- the origin allowlist, which goes stale every time Fastly changes an IP range or someone stands up a new origin without the firewall
Fastly does not ship a slow edge. It ships a programmable cache whose protection is entirely a function of what you made cacheable and what you coded around it. The edge will hold. The open question, the one only a test answers, is how much of the next attack your origin ends up answering itself.