WAF and Shield: a complete AWS guide for production teams

WAF and Shield: Protecting Web Apps at the Edge

By day 80 of this AWS journey, you've likely deployed applications handling real traffic, real users, and real threats. Today we tackle the security layer that sits closest to your users: WAF and Shield. These services form your first line of defense against web exploits, bots, and DDoS attacks—stopping malicious requests before they even reach your application code.

I've built several production platforms where we saw attack patterns within hours of launch. A poorly configured API endpoint becomes a target for credential stuffing. A search field gets hammered by SQL injection attempts. Without proper edge protection, you're firefighting in your application logs instead of preventing fires altogether. WAF and Shield change that equation.

AWS WAF: Rules for SQL Injection, XSS, and Bad Bots

AWS WAF (Web Application Firewall) is a managed service that lets you define rules to allow or deny HTTP(S) requests based on patterns you specify. It sits in front of CloudFront, Application Load Balancer (ALB), API Gateway, or AppSync—and inspects requests before they hit your application.

The core power of WAF comes from matching conditions. You write rules that inspect request components: HTTP headers, query strings, request body, URI path, IP address, even geographic origin. When a request matches your rule, you take an action: allow, block, or count (for testing).

Let's talk about the three most common threats WAF protects against.

SQL Injection

A SQL injection attack embeds SQL commands in user input, hoping your application concatenates it directly into a database query. For example, a malicious actor submits username as ' OR '1'='1 to bypass authentication.

WAF can detect SQL injection patterns through regex rules or, more practically, by using managed rule groups (covered next). A simple pattern-based rule might look for common SQL keywords in request parameters:

# Example of what you'd check (conceptual—actual implementation uses AWS console or SDK)
# If query string contains: UNION, SELECT, DROP, INSERT, DELETE
# Action: Block

I once saw a legacy CRM integration that didn't parameterize queries. We deployed a WAF rule to block requests containing UNION SELECT in the email parameter. Caught dozens of attacks before they reached the database.

Cross-Site Scripting (XSS)

XSS attacks inject JavaScript into your page, allowing attackers to steal session cookies, redirect users, or deface content. A classic example: a comment field accepts <script>alert('xss')</script> and displays it to other users.

WAF detects XSS by identifying HTML/JavaScript patterns in request parameters. Rules look for <script> tags, event handlers like onerror=, or encoded variations.

On a SaaS platform I helped secure, we blocked requests where the search parameter contained script, iframe, or onload. Combined with proper output encoding in our React app, this created defense in depth.

Bad Bots

Not all bot traffic is valuable. Scrapers, competitors harvesting your pricing data, or credential stuffing attempts come from automated sources. WAF lets you identify and block these bots based on their User-Agent headers, request patterns, or IP reputation.

A common pattern: block requests where the User-Agent is missing or matches known scrapers like certain versions of curl or wget hitting your web application (as opposed to your intentional API).

Managed Rule Groups: Start with AWS Managed Rules, Then Tune

Writing rules from scratch is tedious and error-prone. AWS provides curated managed rule groups that cover OWASP Top 10 vulnerabilities, known exploits, and common attack patterns. Think of them as battle-tested templates built by AWS security experts.

Core Rule Set (CRS)

The AWS managed rule for core rule set protects against SQL injection, XSS, local file inclusion, remote file inclusion, and PHP injection. It's the foundation I always recommend enabling first.

Known Bad Inputs

This rule group blocks requests that match patterns from known malicious payloads. AWS maintains this list based on threat intelligence, so you benefit from updated signatures without manually patching.

Bot Control (Premium)

If you subscribe to AWS WAF Bot Control, you get machine learning-based bot detection that classifies traffic as legitimate, suspected bot, or verified bot. For a ride-hailing platform I worked on, this reduced fake account creation attempts by 87% in the first week.

Tuning for Your App

The challenge with managed rules is false positives. A legitimate API client might include characters that trigger XSS rules. Your solution is to enable rules in count mode first, monitor CloudWatch logs, and then switch to block mode once you've whitelisted legitimate patterns.

For example, a trading platform's API legitimately sends JSON with angle brackets for mathematical operators. We created an exception rule that allowed these characters specifically in the formula parameter, bypassing the XSS rule for that case:

# Conceptual exception rule
Rule: "Allow math operators in formula parameter"
Condition: HTTP method == POST AND URI path == /api/backtest
Action: Allow (even if core rule set would block)

In the AWS console, you'd add this as a rule with a statement that uses a regex pattern or byte match condition specific to your API structure.

Rate Limiting: Block Abusive IPs Automatically

Rate limiting is your defense against brute force attacks, API scraping, and DDoS-like behavior from smaller threat actors. AWS WAF lets you set a threshold: if an IP makes more than X requests in Y seconds, block it.

Why Rate Limiting Matters

On a travel booking platform, we saw credential stuffing attempts: thousands of requests per minute from a single IP trying different password combinations. A rate limit rule blocking IPs after 100 requests per 5 minutes stopped these attacks cold, while legitimate users never hit that threshold.

Configuring Rate Limiting in WAF

You create a rate-based rule that counts requests from each IP address (or a custom scope key like API key, if you prefer). When the count exceeds your threshold within the time window, WAF blocks that IP for a specified duration.

A typical configuration:

• Rate limit: 2000 requests per 5 minutes
• Action: Block
• Scope: IP address
• Exemptions: Cloudflare IPs, your analytics vendor's crawlers (if needed)

For more granular control, use a scope key to rate limit by API key, session token, or custom header. This prevents one legitimate user from getting blocked just because they're on the same corporate network as an attacker.

Monitoring Rate Limit Events

When an IP gets blocked, log it. Use CloudWatch Logs to monitor rate limit hits, and set up alarms if you see spikes. A sudden increase in rate limit blocks might indicate a targeted attack—useful intel for your security team.

Shield: Standard DDoS Protection Is Included; Advanced for High-Risk Apps

AWS Shield is AWS's DDoS protection service. It operates at the network and transport layers (layers 3 and 4) to mitigate volumetric attacks, while WAF operates at the application layer (layer 7).

Shield Standard

Shield Standard is free and automatically enabled for all AWS customers. It protects against common DDoS attacks: UDP floods, SYN floods, DNS query floods, and HTTP floods up to certain thresholds. For most applications, this is sufficient.

The magic happens at AWS's edge: your traffic is routed through AWS's global network, which absorbs and mitigates attack traffic before it reaches your origin. You don't configure anything—it just works.

Shield Advanced

If you're a high-traffic service or your business is critical (payment processing, healthcare, public-facing APIs), Shield Advanced adds:

• Higher thresholds: Protects against larger attacks (terabits per second scale).
• DDoS cost protection: AWS won't charge you for scaling costs incurred during a DDoS attack if you're subscribed to Advanced.
• 24/7 DDoS Response Team (DRT): AWS experts who help you during attacks and optimize your configurations.
• Real-time attack notifications: Immediate alerts when Shield detects an attack on your resources.

I recommended Shield Advanced for an e-commerce platform during Black Friday season. The cost was roughly $3,000/month, but the peace of mind—and the DDoS cost waiver—made it worth it. When a competitor's disgruntled employee did launch a DDoS attack the day before the sale, the DRT had us mitigated in 12 minutes.

Integrating Shield with WAF and CloudFront

For maximum protection, layer them: Shield (network layer) + WAF (application layer) + CloudFront (caching and edge distribution). A request goes through Shield's DDoS checks, then CloudFront caches static content and accelerates delivery, then WAF applies your custom rules.

This combination is particularly effective because CloudFront's cached responses bypass your origin entirely for most requests, reducing the load on your backend during attacks.

Common Mistakes

Mistake 1: Blocking too aggressively without monitoring. I've seen teams enable all managed rules, then get flooded with complaints about legitimate APIs breaking. Always use count mode first, review CloudWatch logs, and whitelist exceptions before blocking.

Mistake 2: Forgetting to log WAF activity. If you don't enable logging to CloudWatch Logs or S3, you have no visibility into what WAF is blocking. You can't tune rules or investigate false positives without logs. Set this up immediately.

Mistake 3: Setting rate limits too low. A limit of 100 requests per minute might make sense for a login endpoint, but it's too strict for an API returning paginated lists. Use different rate limit rules for different paths or scope keys.

Mistake 4: Relying on WAF alone for security. WAF is one layer. You still need secure coding practices, input validation at the application level, parameterized queries, and secrets management. WAF catches what slips through; it doesn't replace defense in depth.

Mistake 5: Not budgeting for Shield Advanced when you should. If you're running a service where 1 hour of downtime costs your business $100,000, Shield Advanced at $3,000/month is a rounding error. Don't penny-pinch on critical infrastructure.

Key Takeaways

• AWS WAF inspects HTTP(S) requests at the application layer and blocks based on patterns: SQL injection, XSS, bad bots, and custom rules.
• Start with AWS managed rule groups (Core Rule Set, Known Bad Inputs) rather than writing rules from scratch—they're battle-tested and frequently updated.
• Always enable WAF logging and test rules in count mode before enabling block mode to avoid false positives.
• Rate limiting rules block IPs exceeding a request threshold in a time window, protecting against brute force and API scraping.
• Shield Standard is free and automatic for all AWS customers; Shield Advanced adds higher thresholds, cost protection, and 24/7 expert support for high-risk applications.
• Layer WAF and Shield with CloudFront and proper application-level security for defense in depth.
• Monitor WAF activity continuously through CloudWatch Logs and CloudWatch Metrics to tune rules and detect attacks.