AWS Shield Advanced is a subscription to capabilities, not to protection. The protection is the configuration you do afterward.
That distinction is the whole subject of this post. Enrolling a resource in Shield Advanced does not put a defense inline the way a WAF rule sits inline. It grants you a set of features, each of which engages under conditions you have to set up in advance, and each of which lets something through until it does.
Testing Shield Advanced is therefore not a test of whether it works. It works. The free Shield Standard tier already soaks up the large volumetric floods at the border, and Advanced is not the thing that makes that happen. A useful test measures the seams the marketing page skips: when automatic mitigation actually engages, how wide the window is before it does, what reaches your origin inside that window, and whether the human response loop you are paying for is reachable at all when you need it.
This is the Shield-Advanced-specific companion to AWS DDoS testing, which covers the whole AWS stack (enrollment coverage, WAF actions, origin exposure, autoscaling) at the level of the deployment. Here the lens narrows to one product and the questions its own documentation tends to answer in the imperative ("enable this," "configure that") rather than the indicative ("here is what happens under attack if you did not"). For how Shield Advanced weighs against a third-party mitigation edge in front of an AWS origin, the trade-offs are laid out in AWS Shield Advanced vs Cloudflare.
At a glance: what "Shield Advanced is on" actually means
Each Shield Advanced feature has a precondition. If the precondition is unmet, the feature is present on the invoice and absent from the request path.
| Feature | What it does under attack | The precondition you must have set up | What a test measures |
|---|---|---|---|
| Network-flow mitigation (L3/L4) | Absorbs volumetric and protocol floods at the AWS border | Resource enrolled; this is the always-on part | Detection-to-mitigation interval for the specific vector |
| Automatic application-layer mitigation (L7) | Places WAF rules automatically when it detects an L7 event | Explicitly enabled, per resource, on a resource that has an associated web ACL, after a baseline forms | Whether it is enabled, in Block not Count, and how long the baseline takes to be useful |
| Health-based detection | Sharpens L7 detection and reduces false positives | Route 53 health checks associated with the protected resource | Whether the health check reflects real application health, not just a 200 from a load balancer |
| Shield Response Team (SRT) | Human engineers author and apply mitigations during an event | Business or Enterprise Support, plus proactive engagement or a pre-granted IAM role | Whether the loop is reachable in minutes, not whether the team exists |
| Cost-protection credits | Refunds scaling charges caused by a qualifying attack | A claim filed after the event, within AWS's window | That someone knows to file it, and what the credit does not cover |
The pattern: Shield Advanced hands you levers. Enrollment pays for the levers. A test confirms which ones are actually connected to something.
Two automatic mitigations, and they are not the same switch
The single most common misreading of Shield Advanced is treating "automatic mitigation" as one thing. There are two, they operate at different layers, and they engage on entirely different terms.
Network-flow mitigation is always on and acts on signatures
The L3/L4 part is the piece that behaves the way people assume the whole product does. It runs at the AWS border, it needs no configuration beyond enrollment, and it acts on the shape of the packet flow: SYN floods, UDP reflection, malformed-packet floods, ACK floods. It is fast because it does not need to understand your application, only the anomaly in the traffic.
For this layer the test question is narrow and quantitative: for a given vector against a given enrolled resource, what is the interval from onset to effective drop rate? That is a time-to-mitigation measurement, and it is usually short. It is also the least interesting part of Shield Advanced, because it is the part you did not have to get right.
Application-layer automatic mitigation is opt-in, and it depends on things
The L7 part is where testing earns its keep. Shield Advanced can automatically place WAF rules into your web ACL when it detects an application-layer DDoS event against a protected CloudFront distribution or Application Load Balancer. This is a real, distinct capability, and it is off until you turn it on.
Three conditions gate it, and any one of them being unmet means an L7 flood sails through to your origin while the network layer, doing its job perfectly, sees nothing wrong.
First, it has to be enabled, per resource. It is not a global account setting and it does not follow a resource that was created after you configured it.
Second, the protected resource has to have an AWS WAF web ACL associated with it. Automatic application-layer mitigation works by writing rules into that web ACL. No web ACL, nowhere to write.
Third, and least visible, it needs a baseline. The feature learns the normal shape of your traffic before it can call a deviation an attack. A resource enrolled an hour before a test has no meaningful baseline, and a test run in that window measures the baseline-building period, not the steady-state defense.
There is also the Block-versus-Count choice, which is the same trap described for hand-written rules in AWS DDoS testing: automatic mitigation can be set to place its rules in Count, where it observes and records but blocks nothing. A dashboard full of "mitigations" that are all counting is the L7 equivalent of a fire alarm wired to a logbook.
The detection-to-mitigation window: what reaches the origin inside it
Every automatic defense has a window. Detection is not instantaneous, mitigation deployment is not instantaneous, and the sum of the two is a period during which attack traffic reaches whatever sits behind the control. On the network layer this window is short. On the application layer it can run to minutes, because the system is waiting to be confident enough to place a rule that might otherwise block real users.
The window is the number that matters, and it is the number no dashboard shows you by default, because the dashboard reports the mitigation once it exists, not the exposure before it did.
A test measures the window empirically. Drive a controlled application-layer event against a resource with automatic mitigation enabled, and record three timestamps: when the attack traffic started, when the first automatic rule appeared in the web ACL, and when origin-observed attack volume actually dropped. The gap between the first and third is your real exposure, and it is a property of your baseline quality, your health-check configuration, and the vector, not a fixed vendor figure.
What reaches the origin inside the window is the other half of the measurement. If the origin has autoscaling, the window is where scale-out is triggered by attack traffic. If the origin has connection limits, the window is where they are consumed. The window does not just delay protection; it hands a burst of adversarial load to everything downstream, and downstream was sized for users.
Health-based detection, and what it actually depends on
Shield Advanced can associate Route 53 health checks with protected resources, and it uses that health signal to detect application-layer attacks faster and with fewer false positives. The logic is sound: an anomaly in traffic that coincides with the application going unhealthy is a stronger attack signal than traffic anomaly alone.
The dependency is the catch. Health-based detection is only as honest as the health check behind it. A health check that pings a load balancer and gets a TCP handshake will report healthy while the application behind it is timing out every real request. A health check pointed at a static /health endpoint that returns 200 from a cache will report healthy through an attack that is drowning the dynamic paths users actually hit.
So the test does not stop at "is health-based detection configured." It asks whether the health check measures something that degrades when the application degrades. The way to check is to drive load at the expensive, stateful paths (search, login, anything that touches a database) and confirm the health check turns unhealthy when real user experience does. A health check that stays green through a degradation is worse than none, because it tells Shield Advanced the application is fine while users are getting errors.
The Shield Response Team: what engaging them requires, and what it does not do
Access to the Shield Response Team, the AWS engineers who write and apply bespoke mitigations during an active incident (the team formerly called the DRT), is one of the headline reasons organizations pay for Advanced. It is also the feature most likely to be discovered, mid-incident, to be unreachable.
Engaging the SRT is not a phone number you dial when things go wrong. It requires setup that has to exist before the attack.
The preconditions are concrete. The SRT is available on Business and Enterprise Support plans, not on Developer or Basic. Reaching them fast enough to matter generally means one of two things is already in place: proactive engagement, where the SRT contacts your configured on-call when Shield detects a significant event, or a pre-granted IAM role that lets the team inspect and modify your WAF rules without waiting for you to provision access during the incident. A team that has to be granted permissions after the attack starts is a team helping you in the second hour, not the first.
Just as important is what the SRT does not do. They are a human loop, so they operate on human latency: minutes to engage, more to understand a novel vector, more to author and validate a rule that will not also block your customers. They act on the resources they have access to; a distribution or balancer outside the granted scope is invisible to them. And they author mitigations, they do not replace the ones you should already have. The SRT is an escalation path for the attack your own rules did not anticipate, not a substitute for having rules.
The test here is an operational one, closer to a game day than a traffic exercise. Confirm the support tier is right, confirm proactive engagement or the SRT IAM role is configured and the contacts are current, and confirm the on-call who would receive that call knows what to do with it. This is the human half of the response loop that no configuration review can see.
Where Shield ends and your WAF begins
Automatic application-layer mitigation writes rules into your web ACL, which means it shares a namespace, a capacity budget, and an evaluation order with the rules you wrote yourself. That intersection is worth testing directly, because it is where two independently sensible configurations can interfere.
A web ACL has a capacity budget measured in Web ACL Capacity Units. Your managed rule groups, your custom rules, and your rate-based rules all consume it, and so does the Shield-managed rule group that automatic mitigation installs. A web ACL already near its capacity ceiling can fail to accommodate the automatic rules cleanly, and the failure mode is not obvious from either product's console.
Evaluation order matters too. A rate-based rule that terminates on a match earlier in the priority order can shed the traffic before the Shield-managed rules ever see it, which may be exactly what you want or may hide the L7 event from the automatic system that was supposed to characterize it. There is no universally correct ordering; there is only the ordering you validated against a real event versus the ordering you assumed.
The precise relationship between Shield Advanced's automatic L7 mitigation and your own rate-based rule calibration, taken apart in AWS WAF rate-based rule testing, is one to exercise as a pair, not to reason about on a whiteboard. Drive the event, watch which control fires first, and confirm the composite behaves the way you intended rather than the way each part behaves alone.
Cost-protection credits are a claim you file, not a shield
Shield Advanced offers cost protection: service credits for the scaling charges that a qualifying DDoS attack drives on protected resources, the CloudFront data transfer, the Route 53 queries, the load balancer capacity units, the EC2 scale-out that the attack forced. This is genuinely valuable, and it is routinely misunderstood as automatic.
It is a claim. Someone has to recognize that scaling charges were attack-driven, and file for the credit, within the window AWS defines. The credit applies to scaling of protected resources caused by a qualifying event; it is not a blanket waiver of your bill for the month, and it does not turn an economic-denial attack into a non-event if the attack drove costs somewhere the protection does not reach.
The test is procedural and it belongs in the runbook, not the traffic generator: confirm someone owns the credit-claim step, knows the window, and knows which resources are in scope. A cost-protection benefit nobody claims is a benefit you paid for and left on the table.
Testing it without re-running the whole AWS playbook
Two disciplines govern any AWS DDoS test and are not specific to Shield Advanced, so they are covered once elsewhere rather than restated here. AWS gates simulated-DDoS traffic separately from ordinary penetration testing, and clearing that gate before you send a packet is mandatory: see the authorization section of AWS DDoS testing. Keeping the test non-destructive (staging mirror first, tightly scoped canary, explicit abort criteria) is the subject of running a DDoS test without disrupting production and the complete guide.
What is specific to Shield Advanced is the target list. The test is designed around the features, and each feature gets a measured outcome: is automatic L7 mitigation enabled and in Block; how wide is the detection-to-mitigation window against a realistic vector; does the health check degrade when the application does; is the SRT loop reachable in minutes; do the automatic rules coexist with your own inside the web ACL's capacity and priority; does someone own the cost-protection claim. None of these is answered by the enrollment status, which is the only thing the billing console can confirm.
FAQ
What is AWS Shield Advanced testing?
Controlled, authorized generation of attack-shaped traffic against Shield-Advanced-protected AWS resources, to measure how the product's features behave under load: when automatic mitigation engages, how wide the detection-to-mitigation window is, what reaches the origin inside it, and whether the health-based detection and Shield Response Team loop are actually configured to fire. It validates the configuration around Shield Advanced, not whether Shield Advanced works.
Does Shield Advanced automatically block application-layer attacks?
Only if you enabled automatic application-layer mitigation on that specific resource, the resource has an associated WAF web ACL, a traffic baseline has formed, and the mitigation is in Block rather than Count. The L3/L4 network-flow mitigation is always on once a resource is enrolled; the L7 automatic mitigation is opt-in and conditional. A test confirms which state you are actually in.
What does the Shield Response Team require to help during an attack?
A Business or Enterprise Support plan, and setup that exists before the incident: proactive engagement so the team contacts your on-call, or a pre-granted IAM role so they can inspect and modify your WAF without waiting for access. They operate on human latency and only on resources they can reach, so a test verifies the loop is reachable in minutes and scoped to the right resources, not just that the team is included in the plan.
How do you measure the detection-to-mitigation window?
Drive a controlled application-layer event against a resource with automatic mitigation enabled and record three timestamps: attack onset, the appearance of the first automatic rule in the web ACL, and the actual drop in origin-observed attack volume. The interval from onset to real drop is your exposure window, and it depends on baseline quality, health-check accuracy, and the vector, not on a fixed vendor number.
Is Shield Advanced enough on its own?
No, for the same reason any single control is not: its value is a function of configuration around it. Enrollment buys features that engage on preconditions, and the outages seen on AWS are typically the preconditions left unmet, automatic L7 mitigation never enabled, a health check that lies, an SRT loop nobody set up, a web ACL too full to accept the automatic rules. Testing finds those before an attack does.
What enrollment cannot tell you
The stable facts about Shield Advanced will still be true in five years. Network-flow mitigation will absorb L3/L4 floods at the border. The SRT will author bespoke rules during incidents. Cost protection will credit attack-driven scaling. Automatic application-layer mitigation will write rules into your web ACL. Those are the product, and the product is dependable.
What decides the outcome is everything you did after you enrolled, and all of it drifts:
- automatic L7 mitigation that was enabled on the resources that existed at rollout, and never on the three added since
- a health check that passed the day it was created and has reported healthy through every real degradation since, because it measures a handshake, not the application
- an SRT engagement that was configured under a support plan that has since been downgraded, or with an on-call contact who left last quarter
- a web ACL that has filled with rules until there is no capacity left for the automatic ones to land
- a cost-protection benefit that no runbook assigns to anyone, so no one files the claim
Shield Advanced does not ship misconfigured. It ships a set of capabilities that are individually correct and collectively inert until you wire the conditions that make each one fire. Enrollment is a line item. Whether any of it fires when an attack arrives is a separate question, and the only way to answer it is to make one arrive on your own terms first.