access now open

AWS WAF log enrichment and automated deny workflows that run inside your own AWS account.

WAFGuard is FraudGuard's product for teams that want better blocked-request triage, repeat-attacker detection, and safer AWS WAF automation. Like TrailGuard, it deploys into your AWS environment via CloudFormation, runs as a Lambda inside your account, reads WAF attack logs from S3, and enriches hostile IPs with FraudGuard intelligence.

Request Access See TrailGuard View API Docs
WAFGuard workflow summary
Deployment In-account Lambda-based processing deployed via CloudFormation into the customer's AWS account.
Input WAF logs Reads blocked-request log data stored in the customer's S3 environment.
Enrichment FraudGuard API Adds risk, attacker history, infrastructure context, and repeat-attacker signals.
Action IP sets Supports workflows that can add high-confidence repeat attackers into AWS WAF IP sets.

Private focus

WAFGuard is currently accepting testers who already run AWS WAF and want stronger post-blocking visibility, repeat-attacker workflows, and automation with review controls.

Why teams want it

AWS WAF can block the request, but teams still need context on who is hitting them repeatedly, which sources deserve durable deny treatment, and how to operationalize that safely.

AWS-native deployment WAFGuard runs in the customer's AWS account, not in a shared SaaS execution layer.
Blocked-request enrichment Turn raw blocked-request logs into analyst-ready intelligence with FraudGuard risk and attacker context.
Repeat-attacker logic Correlate repeat abusive sources so the same hostile infrastructure does not keep reappearing as isolated noise.
Automation with control Design deny workflows for high-confidence attackers without forcing every blocked source into immediate permanent enforcement.

Why WAFGuard is useful beyond a simple WAF block

Blocking a request is only the first step. Security teams still need to understand whether the source is a scanner, a bot, a repeat attacker, anonymous infrastructure, a campaign participant, or an IP that now deserves durable deny treatment across future requests.

Clean blocked-request triage

Enrich blocked WAF events with FraudGuard intelligence so analysts can sort routine noise from infrastructure that is genuinely worth actioning.

Repeat-attacker detection

Highlight sources that recur over time instead of treating every blocked event as a one-off log line with no longer-term memory.

Stateful deny workflows

Move from observation to enforcement by designing workflows that can add high-confidence repeat attackers into AWS WAF IP sets.

Safer automation posture

Keep room for review thresholds, confidence gates, and environment-specific policy logic before a source is escalated into a deny list.

How the deployment model works

WAFGuard follows the same high-trust deployment philosophy as TrailGuard. It is designed to live inside the customer's AWS account, deployed with CloudFormation, and executed through AWS Lambda so log processing stays close to the environment that generated the WAF events.

Instead of asking teams to export blocked-request decisions into a separate always-inline product, WAFGuard works from the AWS WAF log stream already being written into S3. From there it can enrich blocked attacker IPs through the FraudGuard API and attach the context teams need for triage, reporting, investigation, and enforcement decisions.

That architecture is especially useful for organizations that want AWS-native controls, account-level ownership, straightforward deployment review, and a practical bridge between WAF logs, threat intelligence, and deny-list workflows.

CloudFormation deployment

Deploy into the customer's AWS account using an AWS-native packaging model that can be reviewed, versioned, and approved internally.

Lambda execution inside your environment

WAFGuard logic runs in the customer's own AWS account instead of requiring a separate execution environment for log handling.

S3-based WAF log processing

Read AWS WAF attack log data from S3 and transform blocked events into enriched operational records.

FraudGuard intelligence in the loop

Use FraudGuard risk, infrastructure, and repeat-attacker context to determine whether a source should remain a log entry or become a deny candidate.

From blocked request to durable deny candidate

WAFGuard is built around turning noisy blocked-request data into a cleaner, stateful workflow that teams can reason about and automate carefully.

Step 1

Read WAF logs from S3

WAFGuard processes blocked-request log data already generated by the customer's AWS WAF deployment.

Step 2

Enrich attacker IPs

Blocked sources are enriched through the FraudGuard API with risk, geography, anonymity, and attacker-history context.

Step 3

Detect repeat hostile infrastructure

Repeated or higher-confidence sources can be separated from routine one-off WAF noise for analyst review or automation.

Step 4

Drive deny workflows

Design workflows that can add qualified repeat attackers to AWS WAF IP sets with the safety controls your environment requires.

What WAFGuard can add to blocked-request analysis

WAF logs tell you that a request was blocked. WAFGuard is about adding the surrounding intelligence needed to decide what should happen next.

FraudGuard risk context

Enrich blocked IPs with FraudGuard risk, infrastructure, geography, and threat context instead of reviewing raw source IPs in isolation.

Repeat-attacker visibility

Spot sources that reappear over time so repeat abusive infrastructure can be escalated beyond a single blocked request.

Anonymous infrastructure traits

Understand whether blocked traffic is linked to proxies, VPNs, hosting providers, scanners, or other infrastructure that changes enforcement confidence.

Analyst-friendly triage

Give security teams cleaner operational context for blocked-request review, tuning decisions, and post-incident investigation.

Deny-candidate workflows

Support workflows that separate routine blocks from sources that merit longer-lived deny handling in AWS WAF IP sets.

Environment-specific controls

Adapt automation and review to the customer's own request patterns, false-positive tolerance, and AWS governance requirements.

Best-fit users

WAFGuard is currently best suited for teams already invested in AWS WAF who want to improve blocked-request analysis and explore controlled deny automation without moving core execution outside their own AWS environment.

High-volume WAF operators

Teams dealing with large blocked-request volumes that need better triage, repeat-attacker visibility, and faster filtering of unimportant noise.

Security teams building stateful controls

Organizations that want to move from simple block events to longer-lived deny workflows based on confidence and repeat behavior.

AWS-native infrastructure teams

Customers who prefer CloudFormation deployment, Lambda execution, and AWS-account ownership instead of handing WAF workflow processing to an outside execution layer.

Apply for the WAFGuard

We are currently accepting testers. If you already use AWS WAF and want FraudGuard-powered blocked-request enrichment, repeat-attacker detection, and automated deny workflows inside your own AWS account, WAFGuard is ready for the right pilot environments.

Request Access Compare Plans See TrailGuard