🟧 AWS WAF — Practical Baseline for Managed Rules, Rate Limits, and Logging

Intro: AWS WAF is most useful when teams stop treating it as a magic “block bad traffic” switch and start treating it as a tunable request-filtering layer in front of CloudFront, ALB, API Gateway, Cognito, App Runner, or other AWS HTTP entry points. This page focuses on a practical default posture for common web attacks, rollout order, tuning, and reusable starter configuration.

What this page includes

• where AWS WAF fits in a real AWS edge / ingress design;
• a sane baseline of AWS Managed Rules and custom rules;
• practical rate-limit patterns for login, search, and noisy APIs;
• logging, body-inspection, and tuning notes that reduce false positives;
• short Terraform-first examples you can adapt quickly.

What AWS WAF is good at — and what it is not

AWS WAF is a request inspection and traffic-control layer for HTTP(S) applications.

It is good at:

• filtering obvious malicious request patterns before they hit the app;
• enforcing rate limits on abusive paths or clients;
• adding managed protections for common web attack signatures;
• labeling and logging traffic so you can tune rules and investigate abuse;
• adding CAPTCHA / challenge friction where full blocking would be too risky.

It is not a replacement for:

• authentication and authorization;
• object-level and tenant-level access control;
• secure coding, validation, and output encoding;
• bot / abuse controls in business workflows such as signup, checkout, promo use, or account recovery.

Where to attach AWS WAF in AWS

Common placements:

• CloudFront + WAF for internet-facing web apps, static + dynamic sites, and APIs that already use CloudFront.
• ALB + WAF for regional ingress where CloudFront is not required.
• API Gateway + WAF for public APIs, especially when request throttling alone is not enough.
• Cognito user pool + WAF when auth endpoints themselves are under attack.
• App Runner / AppSync / Amplify / Verified Access when those are the AWS-native front doors.

Practical placement guidance

• Prefer CloudFront + WAF when the application is public, latency-sensitive, or exposed globally.
• Prefer regional WAF on ALB or API Gateway when the service is regional, internal to a geography, or already fronted by those services directly.
• Do not assume the same Web ACL should be reused everywhere without tuning. Login-heavy apps, JSON APIs, GraphQL endpoints, and public brochure sites usually need different custom rules.

A sane baseline rule strategy

A useful baseline is usually:

1. explicit allow/deny context rules;
2. rate-based custom rules for sensitive paths;
3. AWS Managed Rules baseline groups;
4. optional bot / fraud / challenge controls;
5. logging and tuning loop.

1) Start with small explicit context rules

Good early custom rules:

• block methods you do not need on specific paths;
• block requests to admin paths from the public internet if they should only exist behind VPN or private access;
• allowlist known monitoring or integration traffic where appropriate;
• enforce host-header expectations if multiple virtual hosts exist.

These rules are often higher signal than giant regex collections.

2) Put rate-based rules in front of noisy workflows

Typical high-value rate-limit targets:

• /login, /signin, /session, /oauth/*, /password-reset;
• search, preview, or export endpoints;
• public JSON APIs that are expensive or abuse-prone;
• GraphQL POST endpoints where a single path hides many operations.

3) Add AWS Managed Rules in a staged order

A strong default rollout order for many internet-facing applications is:

Recommended starter baselines by app type

Public website with forms and login

• CommonRuleSet
• KnownBadInputs
• AmazonIpReputationList
• login rate limit
• optional AnonymousIpList
• optional Bot Control for scraping and signup abuse

Public JSON API behind API Gateway or ALB

• CommonRuleSet
• KnownBadInputs
• SQLiRuleSet
• AmazonIpReputationList
• path-scoped rate limits per high-risk route
• optional CAPTCHA / challenge for suspicious anonymous traffic where browser flows exist

Admin plane / internal portal exposed through the internet

• CommonRuleSet
• KnownBadInputs
• AmazonIpReputationList
• AdminProtectionRuleSet
• tighter IP allowlists or geo restrictions where operationally acceptable
• aggressive rate limiting on login and MFA-related flows

Count first, then block

The safest rollout model is usually:

1. deploy new managed groups in Count mode;
2. inspect logs and sampled requests;
3. identify false positives and exception candidates;
4. switch stable groups to Block;
5. keep expensive or risky groups in Count longer.

This is especially important for:

• legacy apps with odd query formats;
• GraphQL and search-heavy APIs;
• admin routes with automation clients;
• apps that legitimately receive traffic through proxies or privacy networks.

Rate-limit patterns that actually help

Login / auth endpoints

Use low thresholds with short windows, scoped only to the relevant paths and methods.

Good signals:

• POST /login
• POST /oauth/token
• password reset request endpoints
• MFA verification endpoints

Prefer separate rules for:

• human browser login;
• API token issuance;
• admin login.

Search, export, report, and preview endpoints

These are common abuse magnets because they are computationally expensive and often scrape-friendly.

Use:

• slightly higher rate limits than login;
• per-IP or forwarded-IP aggregation;
• path-specific scope-down statements;
• block or challenge depending on customer experience tolerance.

GraphQL and generic POST APIs

Because many actions share one path, add rate limits and then use other signals such as headers, operation names at the app layer, or bot controls if needed.

Do not expect WAF alone to distinguish cheap and expensive business operations inside a single API path.

Logging, visibility, and investigation

A practical WAF deployment should always include:

• request logging to a central destination;
• sampled requests for tuning;
• CloudWatch metrics / alarms per important rule;
• correlation with application logs and identity events.

Good operating habits:

• alert on sudden increases in blocked requests, CAPTCHA / challenge activity, and rate-limit hits;
• create separate dashboards for login abuse, bot patterns, and generic managed-rule matches;
• keep WAF logs joined with edge / ALB / API Gateway logs when investigating attacks.

Request body size and inspection caveats

WAF body inspection is not infinite.

Practical review questions:

• are the critical attack inputs located in headers, query strings, URI, cookies, or body?
• does the protected resource type forward enough body bytes for the attack class you care about?
• are file-upload or large-JSON endpoints relying too heavily on WAF body inspection instead of application validation?

If the app accepts large bodies, use WAF as a front filter, not as the only detection layer.

Tuning patterns that reduce pain

Use path-specific scope-down statements

Do not apply the same threshold or same custom logic to the whole site if only a few routes are risky.

Use labels and follow-on rules deliberately

Managed rules can label requests. That makes it easier to:

• count first;
• observe the label distribution;
• write smaller follow-on rules for challenge, rate-limit, or block actions.

Exclude carefully, not broadly

If a rule causes false positives:

• identify the exact sub-rule or route behavior;
• scope the exception as narrowly as possible;
• document why the exception exists;
• revisit the exception after application changes.

Tune by environment

A production Web ACL should not be tuned only against synthetic traffic. Tune against:

• staging traffic that resembles production;
• production traffic in Count mode;
• attack simulations for login abuse, SQLi payloads, suspicious headers, and bot-like scraping.

Terraform starter example

See: AWS WAF v2 baseline Web ACL (Terraform)

This starter demonstrates:

• a WAFv2 Web ACL;
• a scoped login rate-limit rule;
• common AWS Managed Rules groups;
• visibility configuration and a logging hook.

Example: custom login rate-limit logic

statement {
  rate_based_statement {
    limit              = 100
    evaluation_window_sec = 60
    aggregate_key_type = "IP"

    scope_down_statement {
      and_statement {
        statement {
          byte_match_statement {
            field_to_match {
              uri_path {}
            }
            positional_constraint = "EXACTLY"
            search_string         = "/login"
            text_transformation {
              priority = 0
              type     = "NONE"
            }
          }
        }
        statement {
          byte_match_statement {
            field_to_match {
              method {}
            }
            positional_constraint = "EXACTLY"
            search_string         = "POST"
            text_transformation {
              priority = 0
              type     = "NONE"
            }
          }
        }
      }
    }
  }
}

This is deliberately simple. In a real deployment, tune the threshold from production traffic and decide whether to Block, Count, CAPTCHA, or Challenge based on user experience and threat model.

Example: protecting an admin path more aggressively

If /admin should never be reachable from the open internet, use:

• network restriction or private access first;
• then WAF allow/deny rules as a second barrier;
• then AdminProtection managed rules as a generic cleanup layer.

WAF should not be the only thing protecting an admin plane.

Operational anti-patterns

• enabling many managed groups in Block mode on day one without Count / tuning;
• using one Web ACL unchanged for brochure sites, APIs, and admin portals;
• relying on Anonymous IP blocking for customer apps where real users legitimately come through VPNs or privacy relays;
• expecting WAF to solve SSRF, broken authorization, or tenant-isolation flaws;
• ignoring logging because “managed rules are enough”;
• treating body inspection limits as if they cover all payload risk.

Fast rollout checklist

A reasonable AWS WAF baseline is usually ready when:

• the correct protected resource is chosen;
• at least one high-risk path has a scoped rate limit;
• the baseline managed groups are enabled and tested in Count mode;
• logging and dashboards are turned on;
• false-positive handling is documented;
• the team knows which routes are safe to challenge, and which must only count or block.

Read next

• AWS Security Baseline and Top Misconfigurations
• Cloud Auditing by API and Configuration State
• Cloud Audit Cookbook by Provider
• API Abuse Resilience and Rate Limits
• Account Takeover, Automation, and Bot Abuse

Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.