Preparing for the attacks you expect
Lesson 3 of 3 in Designing the Response.
Most incidents surprise you. A volumetric DDoS against a public endpoint does not — it is the one attack class you can be certain will eventually arrive, which is why the exam treats preparing for it as part of the response plan rather than part of the network design.
Start with the distinction that gets tested most. AWS Shield Standard is automatic, free, and already protecting you: it defends every AWS customer against common network and transport layer floods at the edge, with no configuration, no subscription, and nothing to enable. AWS Shield Advanced is a paid subscription on top of it, and — this is the part people get wrong — subscribing is not the same as being protected. After subscribing you must enrol specific resources as protected resources, one ARN at a time (or organization-wide through AWS Firewall Manager). An unenrolled load balancer in a Shield Advanced account has exactly Shield Standard’s protection, and no cost protection, and no response-team coverage.
| Shield Standard | Shield Advanced | |
|---|---|---|
Cost | Free — included for every AWS customer | Paid monthly subscription, with a one-year commitment, plus data-transfer fees |
Enablement | Automatic and always on; nothing to configure | Subscribe and then enrol each protected resource — two separate acts |
Layers | Common network/transport (layer 3 and 4) floods at the edge | Layer 3/4 plus application layer (layer 7) through AWS WAF integration |
Protected resource types | All AWS resources, implicitly | Explicit ARNs: CloudFront distributions, Route 53 hosted zones, Global Accelerator accelerators, Application/Network/Classic Load Balancers, Elastic IP addresses |
Detection tuning | None exposed to you | Health-based detection — associate a Route 53 health check so Shield knows what "unhealthy" looks like for this app |
Human help | None | Shield Response Team (SRT) access and proactive engagement — requires Business or Enterprise Support |
Automatic layer-7 mitigation | No | Yes — Shield can create and manage rate-based rules in the resource’s web ACL, in count or block mode |
Cost protection | No | Credits for scaling charges caused by a documented DDoS event — only for enrolled resources |
Org-wide enforcement | n/a | AWS Firewall Manager Shield Advanced policies enrol resources automatically as accounts and resources appear |
Four configuration decisions turn a subscription into readiness, and each one answers a question you cannot answer during an attack.
Which resources? Every internet-facing endpoint whose unavailability is an incident, enrolled explicitly — and enrolled by policy through Firewall Manager, so next quarter’s load balancer is protected on the day it is created rather than on the day it is attacked. How does Shield know you are unhealthy? By the Route 53 health check you associate with the protected resource: without it Shield is inferring distress from traffic shape alone, and with it detection is both faster and far less prone to firing on your own launch-day traffic spike. Who calls whom? With proactive engagement configured — contact details, a verified phone number, and health checks in place — the Shield Response Team contacts you when a protected resource’s health check goes unhealthy during an event, instead of waiting for you to raise a support case at 04:00. And what does WAF do? Shield Advanced’s layer-7 protection works through a web ACL on the protected resource, so the web ACL must exist, and the rate-based and managed rules in it are what actually absorb an application-layer flood. Edge rule design lives in Edge Protection; here it matters as a prerequisite — Shield Advanced with no web ACL has no layer-7 story.
A five-layer stack of Shield Advanced preparation, read bottom-up. Layer one: the subscription itself — organization-wide, with a one-year commitment, which on its own protects nothing specific. Layer two: protected resources — each CloudFront distribution, Route 53 hosted zone, Global Accelerator accelerator, load balancer, or Elastic IP enrolled explicitly by ARN, ideally automatically by an AWS Firewall Manager policy; cost protection applies only to resources at this layer. Layer three: an AWS WAF web ACL associated with each protected resource, which is the mechanism Shield Advanced uses for application-layer mitigation, including rate-based rules it can create and manage itself. Layer four: a Route 53 health check associated with each protected resource, giving Shield an application-specific signal for health-based detection rather than traffic shape alone. Layer five, emphasized: Shield Response Team access with proactive engagement configured, so AWS contacts you when a protected resource becomes unhealthy during an event — which requires Business or Enterprise Support and the health checks from layer four.
The second half of preparation is the unglamorous question of whether your recovery actually works. AWS Resilience Hub is the service the exam guide names for this, and its model is worth knowing because it is not a monitoring tool. You describe an application — assembled from CloudFormation stacks, Resource Groups, AppRegistry applications, Terraform state files, or EKS clusters — then attach a resiliency policy stating your RTO and RPO targets for different disruption types. Resilience Hub then runs an assessment: a static analysis of the application’s configuration against those targets.
What comes back is the useful part. Not a score alone, but a gap list — "this RDS instance has no cross-Region read replica, so your stated 1-hour RPO is not achievable" — plus three kinds of generated artefact: recommended Systems Manager documents for the standard operating procedures a recovery needs, recommended CloudWatch alarms for the signals that would tell you recovery is required, and recommended AWS Fault Injection Service experiments to verify the whole thing under failure. That last one is the loop closing: assess the plan, generate the test, run the test, re-assess.
What a readiness assessment actually buys you
Three things you cannot get from a document review. A stated RTO/RPO checked against configuration — the assessment compares your declared targets with what the architecture can physically deliver, which is how optimistic recovery plans die quietly before the incident rather than loudly during it. Generated operating procedures and alarms — SSM documents and CloudWatch alarms recommended per component, which you adopt as the runbooks and signals your plan was missing. A test plan — recommended Fault Injection Service experiments, so "we believe we can recover" becomes "we recovered, last Tuesday, in 23 minutes". Re-run the assessment after architecture changes and the drift shows up as a falling score.
Resilience, availability, and security — why a security exam asks
Because availability is a security property, and because the recovery machinery is the same machinery either way. A ransomware event and an AZ failure both end in "restore from a known-good state inside a committed RTO". A DDoS and a traffic surge both end in "shift traffic and scale". The exam tests resilience preparation in the incident-response domain precisely because security incidents are the disruptions people forget to include in their resiliency policy — so the honest question to ask of any Resilience Hub assessment is whether the disruption list includes a compromised deployment, not just a lost Availability Zone.
Where Shield and Resilience Hub meet: the DDoS runbook
A prepared DDoS response is short because everything in it already exists. Confirm it is an attack rather than a launch (CloudWatch and Shield metrics on the protected resource, not vibes). Confirm the resource is enrolled and the web ACL is attached. Let automatic application-layer mitigation act, or raise your own rate-based rule threshold down. Engage the SRT — or let proactive engagement engage you. Shift traffic if a cell is unrecoverable, using routing controls rather than hand-edited DNS. Then record the event for cost protection. Note what is not in that list: subscribing, enrolling, creating a web ACL, or finding a phone number.
Key terms: Shield Advanced proactive engagement, Health-based detection (Shield Advanced), AWS Resilience Hub
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.