WAF & DDoS Protection

The plain-language idea

WAF (Web Application Firewall) sits in front of CloudFront, an ALB, or API Gateway and inspects every incoming request against a set of rules attached to a web ACL, before the request ever reaches your application:

• Managed rule groups — AWS- or vendor-maintained signatures for known attack patterns, like SQL injection or cross-site scripting payloads.
• Rate-based rules — block or challenge an IP once it exceeds a request threshold within a rolling time window.
• Custom rules — string or regex matches, geographic restrictions, or IP allow/deny lists specific to your application.

Shield is AWS's DDoS protection, in two tiers:

• Shield Standard — automatic and free, active on every AWS resource by default. Protects against common network- and transport-layer (layer 3/4) DDoS patterns with no configuration required.
• Shield Advanced — a paid tier adding protection against more sophisticated, higher-layer attacks, near real-time attack visibility, cost protection (billing credits for the extra scaling costs an attack forces), and access to the AWS Shield Response Team (SRT) for hands-on support during an active attack.

See it in a real thing: a WAF rule blocking an injection attempt before it reaches API Gateway

A web ACL attached to API Gateway includes AWS's managed SQL injection rule group and a rate-based rule capping any single IP at a defined request threshold per five minutes. A request arrives with a SQLi pattern in a query string parameter — WAF matches it against the managed rule group and blocks it with a 403, and the request never reaches the backend Lambda function at all. Separately, an IP sending an abnormal volume of requests trips the rate-based rule and gets throttled, independent of whether any individual request looks malicious.

What people usually miss

Watch out

• WAF and Shield are infrastructure-edge defenses, not a replacement for app-layer security. The XSS/CSRF lesson's defenses (output escaping, CSRF tokens, SameSite cookies) protect against what a request does once it's legitimately let through; WAF's pattern-based rules are a broad net that complements those, not a substitute for actually escaping output or parameterizing queries in application code, since a crafted payload can evade signature matching.
• Shield Standard isn't something you opt into. It's already active on every AWS resource by default — a common misconception treats DDoS protection as an add-on someone has to remember to enable, when the baseline tier requires no action at all.
• Rate-based rules count per IP over a rolling window, and legitimate traffic can trip them too. A shared corporate NAT sending many users' traffic from one IP, or a genuine legitimate spike, can hit the same threshold a real attacker would — tuning the threshold against real observed traffic matters more than picking a low number defensively.
• A WAF rule matching an injection pattern is signature-based, not semantic understanding of the request. It catches known attack shapes; it doesn't guarantee an equivalent, differently-encoded payload is caught too — which is exactly why it's framed as defense-in-depth alongside real input handling in the app, not a standalone guarantee.

Why this matters in interviews

"How would you protect a public API from abuse or a DDoS attempt?" tests whether a candidate can name the specific layers involved — Shield Standard as an automatic baseline, WAF's managed and rate-based rules sitting in front of the entry point — and explicitly place that alongside, not instead of, the app-layer defenses like input validation and CSRF protection from elsewhere in this track.