A Web ACL is not a single filter but an ordered, priority-driven collection of rules and rule groups, evaluated sequentially against every request until a terminating action is reached — and that sequential, priority-driven nature explains nearly every advanced WAF behavior.

A Web ACL is attached to one of four supported resource types — CloudFront distributions, Application Load Balancers, API Gateway REST APIs, or AppSync GraphQL APIs — and every request to that resource is evaluated against the Web ACL’s rules in strict priority order. Each rule contains a statement (the condition being matched — an IP set, a regex pattern, a SQL injection detection, a geographic match) and an action (allow, block, count, CAPTCHA, or challenge). Critically, most actions are terminating: once a rule with a block or allow action matches, evaluation stops immediately and later rules are never even evaluated — while count actions are explicitly non-terminating, allowing evaluation to continue to subsequent rules regardless of the match.

Rule groups — reusable, self-contained bundles of rules, either AWS-managed, AWS Marketplace-provided, or customer-authored — are themselves evaluated as a single unit within the Web ACL’s priority order, but the individual rules inside a rule group retain their own internal priority and terminating behavior relative to each other. This nested evaluation model is precisely why understanding rule and rule-group priority together, not in isolation, is essential for predicting how a complex, multi-rule-group Web ACL will actually behave against a given request.

Every request evaluated by a Web ACL follows a deterministic path through rule priority order, potentially picking up labels along the way that later rules can specifically match on — a mechanism that enables genuinely sophisticated, multi-stage detection logic.

flowchart TD
    A["Request arrives at CloudFront / ALB / API Gateway / AppSync"] --> B["Web ACL evaluation begins at lowest priority number"]
    B --> C{"Rule statement matches?"}
    C -- No --> D["Move to next rule in priority order"]
    C -- Yes --> E{"Action type"}
    E -- Block/Allow/CAPTCHA/Challenge --> F["Evaluation terminates; action applied"]
    E -- Count --> G["Label applied if configured; evaluation continues"]
    D --> C
    G --> D
    F --> H["Response returned or request forwarded to origin"]
    D -.-> I{"End of rule list reached?"}
    I -- Yes --> J["Default action (Allow or Block) applied"]
    

Labels are the mechanism that turns this otherwise linear evaluation into something closer to a small rules-based state machine: a rule can apply a label to a request when its statement matches (typically alongside a non-terminating count action), and a later rule in the same evaluation can specifically condition its own statement on the presence of that label — enabling patterns like “only block this request if it matched pattern A earlier AND matches pattern B now,” which no single rule statement could express in isolation.

If a request reaches the end of the entire rule list without triggering any terminating action, the Web ACL’s configured default action applies — typically allow, though a default of block is used in genuinely high-security, deny-by-default architectures. This default action is easy to overlook during testing but determines the fate of every single request that no explicit rule ever matched.

Custom rules, AWS managed rule groups, and rate-based rules each solve a genuinely different threat-detection problem, and advanced Web ACLs almost always layer several types together rather than relying on any single one.

Custom rules, authored directly by the customer, express application-specific logic — blocking a specific known-bad header value, or allowing traffic only from a specific set of partner IP ranges — that no generic managed rule group could anticipate. AWS managed rule groups (the Core Rule Set for OWASP Top 10-style protections, the SQL Database rule group, the Known Bad Inputs rule group, and specialized bot-control and account-takeover-prevention rule groups) are maintained and updated by AWS’s own threat intelligence, giving continuous protection against emerging attack patterns without requiring the customer to write or maintain detection logic themselves. Rate-based rules track request volume from a given key (typically source IP, but configurable to other request attributes) over a rolling time window, automatically blocking or challenging sources that exceed a defined threshold — the primary mechanism for mitigating application-layer request floods and credential-stuffing attempts that a static signature-based rule would never catch.

Beyond simple single-condition rules, WAF supports genuinely composable logical statements, interactive challenge actions, and fully customizable block responses — the configuration surface that separates a sophisticated rule set from a blunt allow/block list.

Statements can be combined using AND, OR, and NOT logical operators, and nested to arbitrary depth, letting a single rule express conditions like “block if the request matches a known bad-input pattern AND does not originate from an already-authenticated session cookie” — composability that dramatically reduces both the number of rules needed and the risk of gaps between multiple, independently written simpler rules.

The CAPTCHA and Challenge actions provide a middle ground between outright blocking and passive allowing: rather than immediately rejecting a suspicious but not definitively malicious request, these actions present an interactive or silent browser-based challenge, letting legitimate human users (or genuinely compliant browser clients, for Challenge) pass through while filtering out simple automated bots that cannot complete the verification — a materially better experience for edge-case traffic than an outright block, particularly valuable in layered bot-mitigation strategies.

Custom response bodies let a blocked request receive an application-appropriate error page or JSON payload rather than WAF’s generic default block response, which matters for API-fronting Web ACLs where a consuming client expects a specific, parseable error format even in a blocked-request scenario.

WAF’s own availability inherits directly from whichever service it’s attached to — CloudFront’s global edge network or a regional ALB/API Gateway/AppSync deployment — and the genuine reliability consideration for operators is designing rules so a WAF misconfiguration never becomes an availability incident of its own.

For CloudFront-attached Web ACLs, evaluation happens at CloudFront’s globally distributed edge locations, inheriting that service’s inherent geographic redundancy with no separate multi-region WAF configuration needed. For ALB, API Gateway, and AppSync-attached Web ACLs, evaluation is regional, tied to the availability of the underlying regional service itself, requiring no additional WAF-specific HA configuration beyond whatever multi-AZ design already exists for the protected resource.

The reliability risk genuinely worth designing around is self-inflicted: an overly aggressive or poorly tested blocking rule can functionally take down legitimate traffic just as effectively as an actual outage, and unlike an infrastructure failure, this kind of self-inflicted availability incident is entirely preventable through the count-mode validation discipline from Chapter 3 — advanced WAF operators treat every new blocking rule change with the same caution as a production infrastructure deployment, not as a purely security-team configuration change with no availability blast radius.

Every rule, statement, and managed rule group consumes a measured amount of Web ACL Capacity Units (WCU) against a fixed per-Web-ACL budget, and understanding WCU economics is essential for building sophisticated rule sets without hitting an unexpected capacity ceiling.

Each rule statement type has an associated WCU cost reflecting its actual computational complexity — a simple IP match statement costs relatively little, while a regex pattern match or a nested logical statement combining several conditions costs considerably more, and managed rule groups declare their own aggregate WCU cost as a bundled unit. A Web ACL has a fixed total WCU capacity, meaning advanced rule-set design genuinely involves budgeting: prioritizing which managed rule groups and custom rules to include, and how to structure logical statements efficiently, to stay within that ceiling while maximizing actual protection coverage.

WAF’s evaluation itself scales transparently with request volume — there is no separate throughput-based scaling configuration for the customer to manage, since the service scales automatically alongside the CloudFront distribution or regional resource it protects. The genuine capacity planning conversation in WAF is about rule complexity budget (WCU), not raw request throughput.

WAF’s security value comes from layering several distinct, purpose-built protection categories together, since no single rule group or rule type covers the full range of application-layer threats an internet-facing service actually faces.

The Core Rule Set managed rule group provides broad protection aligned with common OWASP Top 10 categories — SQL injection, cross-site scripting, and similar well-established web application vulnerability classes — serving as a genuinely solid baseline for nearly any web application. Layered on top, specialized rule groups for bot control and account-takeover-prevention address threats that signature-based detection alone can’t catch: bot control specifically distinguishes automated traffic (search engine crawlers, legitimate monitoring tools, versus scraping and credential-stuffing bots) using behavioral and fingerprinting signals, while account-takeover-prevention specifically monitors login endpoints for credential-stuffing patterns and compromised-credential usage.

WAF provides both a lightweight sampled-request view and a full, detailed logging pipeline, and advanced operators use the two together — sampled requests for quick investigation, full logs for rigorous rule tuning and compliance evidence.

Sampled requests, available directly in the console with no additional configuration, provide a rolling window of recent requests matched by each rule, including which specific rule and action applied — the fastest way to quickly sanity-check whether a rule is behaving as expected during initial rollout. For comprehensive, complete request logging (every single request, not a sample), WAF streams logs to Amazon Kinesis Data Firehose, from which they can be delivered to S3, further analyzed, or fed into a SIEM — the necessary foundation for rigorous false-positive analysis, compliance audit trails, and post-incident forensic investigation that sampled requests alone cannot fully support.

The durable WAF configurations deliberately layer broad managed protection with narrow, validated custom rules, and treat every blocking change with genuine deployment rigor — the recurring anti-patterns almost always involve skipping that validation discipline.

WAF trades the genuine complexity of correctly ordering and validating a multi-layered rule set for continuously updated, deeply integrated application-layer protection that would be extremely costly to build and maintain independently.

Nearly every advanced WAF incident traces back to a rule deployed straight to block mode without validation, a priority-ordering mistake, or an availability impact caused by treating a security rule change as lower-stakes than an infrastructure change.

Advanced WAF deployments consistently cluster around e-commerce bot mitigation, API-fronting security, and DDoS-adjacent volumetric protection paired with AWS Shield.