AWS WAF Logs: What Each Field Means and What to Query

Last verified on Nov 8, 2026.

An AWS WAF web ACL sits in front of CloudFront, a load balancer, API Gateway or another supported resource and decides what happens to each request. Its logs record that decision. They are the most direct view of who is probing your edge and which rules are doing the work.

What a WAF log entry contains

Each entry is JSON. The fields below come from the AWS WAF log field reference:

• action is the terminating action: allow, block, CAPTCHA or challenge.
• terminatingRuleId names the rule that ended inspection. When nothing terminated the request, the value is Default_Action.
• terminatingRuleType is REGULAR, RATE_BASED, GROUP or MANAGED_RULE_GROUP.
• nonTerminatingMatchingRules lists rules that matched without ending inspection, such as rules in count mode.
• rateBasedRuleList lists the rate-based rules evaluated against the request, with fields like limitKey and maxRateAllowed.
• labels holds labels applied by rules during evaluation.
• httpRequest carries clientIp, country, uri, args, httpMethod, headers and requestId.
• httpSourceName says what the web ACL is attached to: CF for CloudFront, ALB, APIGW and others.
• webaclId identifies the web ACL, and timestamp is in milliseconds.

One detail matters for reading logs. AWS WAF stops at the first terminating rule, so the request may contain other problems that the log entry does not mention.

What to look for

• Blocks by rule. Group action equal to block by terminatingRuleId. A rule that blocks nothing may be misordered, and a rule that blocks everything may be too broad.
• Count mode before enforcement. Search nonTerminatingMatchingRules to see what a new rule would have caught before you switch it to block.
• Concentrated sources. Group by httpRequest.clientIp or httpRequest.country and look for one address responsible for most of the volume.
• Rate-based matches. Search rateBasedRuleList for entries whose rateBasedRuleId equals terminatingRuleId. Those requests were stopped by the rate limit.
• Probing URIs. Search httpRequest.uri and httpRequest.args for paths your app does not serve.
• Allowed traffic that looks wrong. Requests allowed by Default_Action that hit a login route are worth a sample read.

Example: a blocked request

This is an abbreviated example entry. The IDs and the address are placeholders and the argument string is a typical probe.

{
  "timestamp": 1731070000000,
  "webaclId": "example-web-acl-id",
  "terminatingRuleId": "block-sqli-probes",
  "terminatingRuleType": "REGULAR",
  "action": "BLOCK",
  "httpSourceName": "ALB",
  "rateBasedRuleList": [],
  "nonTerminatingMatchingRules": [],
  "httpRequest": {
    "clientIp": "203.0.113.9",
    "country": "US",
    "uri": "/login",
    "args": "user=admin'--",
    "httpMethod": "POST",
    "requestId": "1-example-request-id"
  }
}

The rule that stopped the request is block-sqli-probes, the target was /login and the source was one address. Next, count how many entries share that clientIp and whether any were allowed. If the same address got Default_Action on other routes, your rule covers one path and the attacker moved to another.

How Sazabi reads WAF logs

According to the Sazabi docs, you send web ACL logs to a CloudWatch Logs log group and connect your AWS account. Sazabi then sets up a CloudWatch subscription filter on each WAF log group you select. It uses the same cross-account IAM role and pipeline as the CloudWatch source.

Details to check before you start:

• The log group name must start with aws-waf-logs-. The picker lists only those groups.
• CloudFront web ACLs log in us-east-1. Regional web ACLs log in their own region. Your Sazabi project must be in that region.
• AWS WAF allows one logging destination per web ACL, so switching to CloudWatch Logs replaces S3 or Firehose logging.
• CloudWatch Logs bills every logged request. A logging filter, for example keeping only blocked and counted requests, limits volume.

Each record's body is the WAF log entry, with fields such as action, terminatingRuleId, httpRequest.clientIp and webaclId.

Pair it with the other AWS sources

WAF shows requests that reach your edge. API Gateway access logs record wafResponseCode for the same requests, which lets you match an edge decision to an API outcome. CloudTrail covers changes to the web ACL itself. The complete list is on the AWS integration page, and plans are on the pricing page.