For what is worth, here is what AI gave me, but I would 100% check with either your local SE or Account services, or both.
Hi — great questions. CloudGuard WAF licensing can be confusing because it’s metered in “HTTP/HTTPS requests”, but the key detail is where the request gets measured.
1) What typically “counts” as a request in CloudGuard WAF?
For CloudGuard WAF (especially WAF-as-a-Service / reverse-proxy style deployments), traffic is routed through Check Point’s service where HTTP requests are intercepted and inspected before being forwarded to your origin.
So, in practical terms, any HTTP/HTTPS request that reaches the CloudGuard enforcement point (SaaS PoP, gateway, agent) is a candidate to be counted. [aws.amazon.com], [waf-doc.in…kpoint.com]
Important nuance: In the Check Point community, people explicitly report that even traffic that is “Prevented/Blocked” can still be counted. In one thread, the author states Googlebot traffic was classified as malicious, prevented, and counted from the license.
That strongly suggests metering happens before the final “allow/block” decision (i.e., at ingestion/processing), not only on “successful/allowed” requests. [community….kpoint.com]
Because licensing terms can vary by SKU/contract, the only authoritative answer is your Check Point account team, but the evidence above indicates “blocked” does not automatically mean “not counted.” [community….kpoint.com], [community….kpoint.com]
2) Your scenarios (what likely happens)
A) “If a custom rule blocks traffic from a specific IP, do these requests count?”
Likely yes, if the requests reach CloudGuard and are evaluated there. The community report shows prevented requests (Googlebot) were still counted. [community….kpoint.com]
How to avoid them counting: block them upstream of CloudGuard (CDN/WAF in front, edge ACLs, load balancer ACLs, network firewall) so they never reach the CloudGuard enforcement point.
B) “If rate limit is in Prevent mode, does exceeding traffic that is dropped count?”
Likely yes, for the same reason: to rate-limit, CloudGuard must first see and count the requests against the threshold. The Rate Limit feature explicitly works by counting requests per URI/time window based on a “source identity,” then enforcing Detect/Prevent when the threshold is reached. [waf-doc.in…kpoint.com]
So, the “excess” traffic may still be processed enough to be metered, even if it’s later dropped by rate limiting.
C) “Is traffic from Google Bots counted? Can we reduce license consumption from those IPs?”
Based on the Check Point community thread: yes—a user reports Googlebot requests were prevented and counted from the license. [community….kpoint.com]
Can you reduce consumption? You have a few options, depending on why Googlebot is consuming requests:
-
Stop false positives / prevent blocks (quality issue):
Community best-practice suggestions include:
- Whitelist known crawlers (with careful validation)
- Tune anti-bot classification
- Put protections into Detect/Learn mode before Prevent to reduce misclassification
- Reduce inspection scope, e.g., exclude static resources (images/CSS/JS) from inspection when appropriate [community….kpoint.com]
-
Reduce metered requests (quantity issue):
- The only guaranteed way is to ensure fewer requests reach CloudGuard (edge caching/CDN, robots rules for crawl behavior, upstream filtering, serve static assets from a separate unprotected hostname, etc.).
- The same community thread suggests “exclude static resources from inspection” to reduce what’s being evaluated. This may reduce metered usage depending on how your contract defines billable requests—so treat it as a likely mitigation, but confirm with Check Point. [community….kpoint.com]
⚠️ Caution on “Googlebot IP allowlisting”: Googlebot can be spoofed via User-Agent. If you allow by IP/UA, do it using a verified bot method (DNS verification or an authoritative bot list) rather than trusting UA strings alone.
3) Practical recommendations (what I’d do)
Step 1 — Determine what’s consuming requests
- Break down by asset, URI, and source (top talkers).
- Identify if the bulk is:
- Real users
- Crawlers (Googlebot/Bing/etc.)
- Attack traffic / scanning
- Static assets being repeatedly fetched
Step 2 — Apply the right control
If it’s attack/scanning traffic: block upstream where possible (CDN/WAF front door / network ACL) so CloudGuard never sees it.
If it’s crawlers:
- Fix false positives (so you don’t waste time and logs), and
- Consider caching/static offload so fewer requests traverse CloudGuard at all.
If it’s static content:
- Offload static to CDN/object storage, or
- Use CloudGuard tuning to exclude static resources from inspection (with security review). [community….kpoint.com]
Step 3 — Validate impact
After changes, watch request volume trends and confirm:
- Total requests reaching CloudGuard
- Requests by URI category (static vs dynamic)
- Prevent/Detect counts
Quick clarifying question (so I can be more specific)
Which CloudGuard WAF deployment model are you using: WAF SaaS (reverse proxy), Gateway, or Agent (e.g., NGINX/VM/container)? Metering and your ability to block “before metering” can differ depending on the enforcement point placement.
