AWS WAF & Shield
Filtering malicious web requests before they reach your application, and protecting against DDoS attacks at the network and application layers.
Want a visual for this topic?
Generate a diagram tailored to AWS WAF & Shield — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Explain what AWS WAF filters and where it can be attached
- •Explain the difference between AWS Shield Standard and Shield Advanced
- •Write a basic WAF rule to block a common attack pattern
- •Explain how WAF and Shield work together in a layered defense
What is it?
AWS WAF (Web Application Firewall) inspects and filters HTTP/HTTPS requests to your application based on rules you define — blocking or allowing traffic based on patterns like SQL injection attempts, known malicious IP ranges, or rate-based thresholds. AWS Shield is AWS's DDoS protection service, with a free Standard tier automatically protecting all AWS customers against common network-layer attacks, and a paid Advanced tier adding more sophisticated protection and response support for larger, more targeted attacks.
Why it exists
Public-facing web applications and APIs are constantly probed by automated attack traffic — SQL injection attempts, credential-stuffing bots, and outright DDoS floods, all happening at internet scale, every day, against virtually any public endpoint. WAF and Shield exist to filter and absorb this malicious traffic before it reaches (or overwhelms) your actual application, without you needing to build custom request-filtering logic or DDoS mitigation infrastructure yourself.
Problem it solves
WAF solves the malicious-request-filtering problem (blocking SQL injection, XSS, and other common attack patterns at the edge, before they reach application code that might be vulnerable to them). Shield solves the traffic-flood problem (absorbing and mitigating DDoS attacks that attempt to overwhelm your infrastructure with sheer volume, at the network layer for Standard, and with more sophisticated application-layer mitigation and dedicated support for Advanced).
Intuition
WAF is like a bouncer at a club entrance checking each individual person against a specific set of rules (no weapons, must be on the list, no visibly intoxicated guests) before letting them in — it's evaluating each request individually against defined criteria. Shield is more like reinforced entrance doors and crowd control barriers designed to handle the physical situation of thousands of people trying to rush the entrance simultaneously, a fundamentally different problem (overwhelming volume) than checking each individual's credentials.
Analogy
A bank: WAF is like a teller carefully checking each transaction request against fraud rules before processing it. Shield is like the bank's physical security designed to handle a scenario where thousands of people try to storm the building doors simultaneously — one is about scrutinizing individual requests, the other about surviving overwhelming volume.
Technical explanation
WAF Web ACLs (Access Control Lists) contain an ordered list of Rules, each with a statement (the condition to match — e.g. a specific header pattern, a rate threshold, an AWS Managed Rule Group covering common vulnerability patterns like the OWASP Top 10) and an action (Allow, Block, or Count for testing rules without enforcing them yet). AWS Managed Rule Groups provide pre-built, continuously updated rule sets for common threats (SQL injection, known bad inputs, IP reputation lists) that you can attach without writing custom rules yourself. Shield Standard is automatically active for every AWS customer at no extra cost, providing protection against common, automated network and transport layer (Layer 3/4) DDoS attacks. Shield Advanced (a paid subscription) adds protection against larger and more sophisticated attacks including some application-layer (Layer 7) attacks, near-real-time visibility into attack details, integration with WAF for automatic rule deployment during an attack, and access to the AWS DDoS Response Team (DRT) for support during an active incident.
Architecture
A public-facing e-commerce API sits behind CloudFront (which Shield Standard automatically protects) with a WAF Web ACL attached, combining AWS Managed Rule Groups (covering common SQL injection/XSS patterns) with a custom rate-based rule (blocking any single IP exceeding 2,000 requests in 5 minutes, mitigating credential-stuffing and scraping attempts) — all before traffic ever reaches the origin ALB and application servers behind it.
Workflow
- Attach WAF to your CloudFront distribution, ALB, or API Gateway (Shield Standard applies automatically with no configuration needed). 2) Start with AWS Managed Rule Groups covering common threats (SQL injection, known bad inputs) as your baseline. 3) Add custom rules for application-specific needs — rate limiting, geographic restrictions, blocking specific known-bad IP ranges. 4) Use Count mode initially to test new rules against real traffic without blocking anything, reviewing logs before switching to Block. 5) For business-critical public applications with a real DDoS risk profile, evaluate Shield Advanced for its expanded protection and incident response support.
Example
A ticketing platform expecting a high-profile on-sale event (a common DDoS and bot-scalping target) attaches a WAF Web ACL to their CloudFront distribution with AWS Managed Rule Groups for common attacks, a custom rate-based rule limiting requests per IP to prevent scalping bots from hammering the purchase endpoint, and subscribes to Shield Advanced ahead of the event specifically for its expanded Layer 7 protection and access to AWS's DDoS Response Team if a large attack occurs during the actual on-sale window.
Real-world usage
WAF with AWS Managed Rule Groups is a standard baseline security control recommended in AWS's own security best practices for any public-facing web application or API; Shield Advanced is commonly adopted by companies in industries frequently targeted by DDoS attacks (gaming, e-commerce during high-traffic sales events, financial services) specifically for its expanded protection scope and incident response support.
Trade-offs
Relying entirely on AWS Managed Rule Groups is low-effort and covers common threats well, but won't catch application-specific attack patterns unique to your API; writing custom rules catches more specific threats but requires ongoing maintenance and careful testing to avoid false positives blocking legitimate traffic. Shield Standard's free, automatic protection is sufficient for most applications' baseline DDoS risk; Shield Advanced's added cost is only justified when the business impact of a large, sophisticated, or application-layer DDoS attack is severe enough to warrant the expanded protection and incident response access.
Visual explanation
Picture incoming internet traffic passing through Shield first (always active, absorbing large-scale network-layer flood attacks automatically), then reaching WAF (evaluating each individual request against configured rules — rate limits, SQL injection patterns, geographic restrictions, IP reputation lists), and only requests that pass both layers reach your actual application (behind CloudFront, an ALB, or API Gateway, all of which WAF can be attached to).
Advantages
- —
AWS Managed Rule Groups provide continuously updated protection against common attack patterns without writing or maintaining custom rules
- —
Shield Standard's automatic, free protection against common DDoS attacks applies to every AWS customer with zero configuration
- —
WAF's Count mode lets you safely test new rules against real production traffic before enforcing them, avoiding accidentally blocking legitimate users
- —
Rate-based rules provide straightforward protection against credential-stuffing, scraping, and brute-force attempts without custom application code
Disadvantages
- —
Overly aggressive or poorly tested WAF rules can block legitimate traffic, causing real user-facing outages if not validated in Count mode first
- —
Shield Advanced has a meaningful subscription cost, justified mainly for businesses with genuine DDoS risk exposure, not a universal default
- —
WAF rule evaluation adds a small amount of latency to every request, though this is typically negligible compared to application processing time
- —
Keeping custom WAF rules relevant as attack patterns evolve requires ongoing attention, unlike the auto-updating AWS Managed Rule Groups
Common mistakes
- —
Deploying new WAF rules directly in Block mode without first validating them in Count mode against real traffic, risking blocking legitimate users due to an overly broad rule
- —
Relying only on AWS Managed Rule Groups without adding any custom rate-based rules, missing protection against application-specific abuse patterns (like scraping a specific endpoint) that generic rule groups won't catch
- —
Not attaching WAF at all to a public-facing API or website, leaving it exposed to common, well-known attack patterns that a baseline Managed Rule Group would have blocked essentially for free
- —
Subscribing to Shield Advanced without a genuine DDoS risk justification, paying for expanded protection that a lower-risk application doesn't actually need
- —
Forgetting that WAF must be explicitly attached to each resource (CloudFront, ALB, API Gateway) it should protect — it's not automatically applied account-wide
In the AWS Console
- 1
AWS Console → WAF & Shield → Web ACLs → Create web ACL
Select the resource type and specific resource to protect (CloudFront distribution, ALB, or API Gateway), then add rules.
A Web ACL must be explicitly associated with each resource you want protected — it's not automatically applied to everything in your account.
- 2
Web ACLs → [your ACL] → Rules → Add rules → Add managed rule groups
Select AWS Managed Rule Groups covering common threats (e.g. 'Core rule set,' 'SQL database' rule group) as a baseline.
Managed rule groups are maintained and updated by AWS automatically — you get ongoing protection improvements without manual rule maintenance.
- 3
Web ACLs → [your ACL] → Rules → Add rules → Add my own rules and rule groups
Create a rate-based rule specifying a request threshold per IP over a 5-minute window, initially setting the action to Count.
Review the rule's Count-mode logs for a period before switching the action to Block, to confirm it's not catching legitimate traffic patterns.
🎤 Interview questions
What's the difference between what AWS WAF and AWS Shield each protect against? (Listen for: WAF filters individual HTTP requests against rules — SQL injection, rate limits, bad patterns; Shield protects against DDoS traffic floods at the network/application layer.)
Why would you deploy a new WAF rule in Count mode before Block mode? (Listen for: to validate against real production traffic that the rule doesn't incorrectly match and block legitimate requests, before it actually starts blocking anything.)
What's the difference between Shield Standard and Shield Advanced? (Listen for: Standard is free, automatic, covers common network/transport-layer DDoS attacks; Advanced is paid, covers more sophisticated/larger attacks including some application-layer protection, plus incident response support.)
How would you protect an API endpoint from being hammered by a scraping bot? (Listen for: a WAF rate-based rule limiting requests per IP over a time window, potentially combined with AWS Managed Rule Groups for broader protection.)
Where can WAF be attached in an AWS architecture? (Listen for: CloudFront distributions, Application Load Balancers, and API Gateway — it must be explicitly associated with each resource needing protection.)