Choosing an edge strategy
Lesson 1 of 4 in Protecting the Edge.
The edge is the only place you can refuse traffic before it costs you anything. Every control behind it — a security group, an application-level check, a database permission — is a decision made after the request arrived, consumed a connection, and woke something up. So the exam's edge questions are rarely "which service does X". They name a threat, then hand you four services that all sound defensive, and the work is matching the threat's mechanism to the control that operates on that mechanism.
Five mechanisms cover almost every edge question. Volumetric DDoS consumes bandwidth and packet budget at layers 3 and 4 — the attacker does not care what your application does. Application-layer exploitation sends well-formed requests carrying malicious content: SQL injection, cross-site scripting, path traversal, deserialization payloads. Application-layer flooding sends legitimate-looking requests in volume at your most expensive endpoint — search, report generation, anything that queries. Bots and scraping are automated clients that may be polite, cheap, and still unwanted. Credential stuffing replays breached username/password pairs against your sign-in endpoint; every individual request is valid, which is exactly why generic filters miss it. And data exfiltration runs the other direction: something already inside reaching out.
| Threat | What it consumes | First answer | Tempting but wrong |
|---|---|---|---|
Volumetric / protocol DDoS (L3–L4) | bandwidth, packets, connection state | Shield Standard is already on. Shield Advanced adds per-resource detection, the response team, and cost protection. | AWS WAF — it inspects HTTP, so a SYN flood never reaches it as a request |
Application exploitation (L7 content) | your application logic | AWS WAF managed rule groups — core rule set, known bad inputs, SQL database | Network Firewall — it does not parse HTTP semantics the way WAF does |
Application flooding (L7 volume) | CPU, database, downstream quota | A WAF rate-based rule keyed on IP, forwarded IP, or a custom key | Shield Advanced alone — it mitigates infrastructure attacks, and relies on WAF for L7 |
Bots and scraping | content, inventory, pricing data | AWS Managed Rules Bot Control (common and targeted), plus CAPTCHA or Challenge actions | Blocking IP ranges by hand — bot fleets rotate addresses faster than you edit rules |
Credential stuffing | your sign-in endpoint and your users’ accounts | AWS Managed Rules Account Takeover Prevention (ATP) on the login path; ACFP for fake sign-ups | A rate-based rule only — a slow, distributed stuffing run never trips a volume threshold |
Data exfiltration (outbound) | your data, on the way out | Egress controls inside the VPC: Network Firewall domain lists and Route 53 Resolver DNS Firewall | CloudFront or WAF — inbound edge services see nothing your instances originate |
Which edge control answers this threat?
Interactive decision tree — outcomes:
- Shield Standard — already protecting you
No subscription, no configuration, no cost: always-on detection and inline mitigation of common and most frequently occurring network and transport layer attacks for all AWS customers. If a question offers "enable Shield Standard" as the fix, it is describing work that is already done.
- Shield Advanced — subscribe, then protect each resource
A paid subscription with per-resource protections you must turn on resource by resource: tuned detection, health-based detection with Route 53 health checks, SRT engagement, cost protection for scaling charges during an attack, and AWS WAF usage included for protected resources.
- Firewall Manager — one policy, every account
A Firewall Manager policy applies Shield Advanced protections, WAF web ACLs, DNS Firewall rule groups, security-group rules and Network Firewall configurations across an organization — and keeps applying them to resources created tomorrow. The org-scale answer to "how do we make sure nobody forgets".
- AWS WAF — managed rule groups first
A web ACL with the AWS managed core rule set and known-bad-inputs group covers the bulk of OWASP Top 10 injection and XSS classes without you writing a regex. Deploy in Count, measure, then Block.
- A WAF rate-based rule
Counts requests from an aggregation key over a trailing window and blocks while the key is over the limit. Scope it down to the expensive path so a flood of
/searchnever costs you/healthcheck. - Bot Control, with CAPTCHA or Challenge
The Bot Control managed rule group labels traffic by bot category and verification status; your own rules then decide what to do with each label — allow verified search crawlers, Challenge the ambiguous, Block the self-identified scrapers.
- Account Takeover Prevention on the login path
ATP inspects sign-in attempts for stolen-credential use and anomalous behaviour, labels them, and lets you block or Challenge. Credential stuffing is invisible to content filters because each request is well formed — this is the rule group built for it. ACFP is its twin for fraudulent account creation.
- Lock the origin, not the edge
If attackers reach the origin directly, no edge control is in the path. Make the origin unreachable except through CloudFront: OAC for S3, and a secret custom origin header that a WAF rule on the ALB requires.
- AWS Network Firewall for egress
Stateful domain lists and Suricata rules on the egress path, so instances can reach the destinations you named and nothing else. A VPC control, not an edge service — but it is the answer whenever traffic is leaving rather than arriving.
- Route 53 Resolver DNS Firewall
Block or alert on DNS queries for domains you distrust, with AWS managed threat lists for malware and command-and-control domains — and keep Resolver query logs, because exfiltration over DNS looks like ordinary resolution until you read the names.
Now the ordering, because the exam also asks where a control belongs. Traffic meets your controls in a fixed sequence, and each layer can only see what the layer before it passed:
Route 53 resolves the name — a routing and availability control (health checks, failover), not a filter. Shield mitigates infrastructure attacks inline at the edge, before anything becomes an HTTP request. CloudFront terminates TLS at the nearest point of presence, which both absorbs load and gives you one place to attach policy. AWS WAF, associated with the distribution, evaluates the request as HTTP — headers, URI, query string, body, cookies. Only then does CloudFront talk to the origin, and that hop is where origin verification lives: OAC for S3, a secret header for a custom origin. Inside the VPC, Network Firewall, security groups and NACLs take over, and they are what protects the parts of your estate no CDN fronts.
Two consequences worth memorizing. First, a control can only act on traffic that passes through it — if the origin has a public IP that answers requests, every edge control is optional from the attacker's point of view. Second, putting WAF at the CloudFront distribution rather than at a regional ALB moves evaluation to the edge, closer to the client and farther from your capacity; the same web ACL rules behave the same way, but blocked traffic never crosses a Region. The exception that matters: a web ACL for CloudFront is created in the Global (CloudFront) scope in us-east-1, while ALB, API Gateway, AppSync and Cognito web ACLs are regional and must live in the resource's own Region.
Key terms: AWS Shield Standard, AWS Shield Advanced, Web ACL, Rate-based rule, OWASP Top 10
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.