waf
aws/agent-toolkit-for-aws
Configure AWS WAF to filter web traffic and protect applications from exploits, bots, and fraud.
What is waf?
AWS WAF is a web application firewall that filters HTTP/HTTPS traffic to CloudFront, Application Load Balancers, API Gateway, and AppSync. Use it to protect web applications and APIs from common exploits, bots, credential stuffing, fake-account creation, and HTTP floods at layer 7.
- Create and manage web ACLs (web access control lists) with fixed scope: CLOUDFRONT for CloudFront in us-east-1, or REGIONAL for ALB/API Gateway/AppSync in their respective regions
- Configure AWS Managed Rules in Count mode to detect and tune false positives before enforcement
- Set up rate-based rules to throttle HTTP floods and brute-force attacks
- Create IP set and geographic match rules to allow or block by IP range or country
- Enable Bot Control (Common or Targeted mode) to detect and manage bot traffic with confidence signals
- Protect logins and signups from fraud using Fraud Control (account takeover and account creation fraud prevention)
How to install waf
npx skills add https://github.com/aws/agent-toolkit-for-aws --skill waf- AWS account with appropriate IAM permissions (least-privilege wafv2:* actions, not AWSWAFFullAccess)
- Ephemeral credentials via IAM roles, SSO, or sts assume-role (not long-lived access keys)
- Target resource already created: CloudFront distribution, Application Load Balancer, API Gateway REST API, or AppSync GraphQL API
- CloudTrail enabled on wafv2 management events for audit and change detection
How to use waf
- 1.Determine your task from the routing table (create web ACL, add managed rules, set up logging, enable Bot Control, etc.)
- 2.Read the matching reference file in full before acting—each reference is self-contained with decision tables, constraints, and troubleshooting
- 3.For CloudFront web ACLs: create in us-east-1 with CLOUDFRONT scope; for regional resources: create in the resource's region with REGIONAL scope
- 4.Set up logging and request sampling before tuning anything; Count-mode workflows depend on logs to detect false positives
- 5.Execute commands using the AWS MCP server (sandboxed, audited) or fall back to AWS CLI
- 6.Confirm the web ACL is associated to the resource and its default action (Allow vs Block) matches your intended posture
- 7.Monitor with CloudWatch alarms on BlockedRequests, CountedRequests, and critical configuration changes via CloudTrail
Use cases
- Protect a web application from OWASP Top 10 exploits by deploying AWS Managed Rules in Count mode, then tuning and enforcing
- Throttle credential-stuffing attacks on login endpoints using rate-based rules or Fraud Control account-takeover protection
- Block traffic from specific countries or IP ranges using geographic and IP set match rules
- Detect and mitigate bot traffic on high-value endpoints (login, checkout, signup) using Bot Control with Targeted mode
- Forward WAF signals (bot confidence, fraud scores) to the origin application for adaptive mitigation decisions
- Security engineers and DevOps teams protecting web applications and APIs
- Application owners defending against bots, credential stuffing, and account fraud
- Organizations requiring layer-7 DDoS and exploit protection at scale
- Teams managing multi-region or multi-resource WAF deployments
waf FAQ
WAF is layer-7 (application) protection for exploits, bots, and fraud. Shield Advanced is layer-3/4 DDoS protection. Use Shield Advanced for volumetric DDoS; use WAF for application-layer attacks. Use both together for defense in depth.
Common mode catches self-identifying bots and known-bad IPs only. Targeted mode uses machine learning to detect evasive bots and requires the application integration SDK. Use Targeted for high-value endpoints (login, checkout, signup) facing sophisticated bot threats.
Yes, whenever you forward WAF signals (bot confidence, fraud scores, client IP) to the origin in x-amzn-waf-* headers. Stripping inbound headers prevents attackers from spoofing those signals. This is mandatory for signal-forwarding workflows.
No. Scope is fixed at creation: CloudFront web ACLs must be CLOUDFRONT scope in us-east-1; regional resources (ALB, API Gateway, AppSync) must be REGIONAL scope in their own region. Plan your scope before creating.
Rate-based rules throttle volumetric HTTP floods by blocking IPs that exceed a request threshold. Fraud Control (ATP and ACFP) detects account-based abuse like credential stuffing and fake-account creation, which rate limiting misses. Use both for comprehensive protection.
Full instructions (SKILL.md)
Source of truth, from aws/agent-toolkit-for-aws.
name: waf description: >- Configures AWS WAF to filter web traffic: creating web access control lists (web ACLs) on CloudFront, Application Load Balancers, API Gateway, and AppSync; AWS Managed Rules tuned in Count mode; rate-based rules for HTTP floods; IP set and geographic match rules; Bot Control (Common and Targeted); turning bot labels into a confidence signal; stripping spoofed inbound x-amzn-waf-* headers; recovering the real client IP behind a CDN; Fraud Control (account takeover and account creation fraud prevention); and logging and request sampling. Use when the user wants to protect a web application or API from common exploits, bots, credential stuffing, fake-account creation, or HTTP floods at the application layer (layer 7). Routes to the right per-task procedure in references. Do NOT use for L3/L4 DDoS protection (shieldadvanced skill), multi-account WAF rollout (firewallmanager skill), CloudFront configuration (cloudfront skill), or Route 53 health checks or records (route53 skill). version: 1
AWS WAF
Overview
Domain expertise for configuring AWS WAF, the web application firewall that filters HTTP and HTTPS traffic to CloudFront distributions, Application Load Balancers, API Gateway REST APIs, and AppSync GraphQL APIs. Covers web ACL creation and association, AWS Managed Rules, rate-based rules, match rules (IP set and geographic), Bot Control and the signal-forwarding workflows built on top of it, Fraud Control for logins and signups, AI and LLM crawler management, and the logging that every tuning workflow depends on.
This skill is a router. Each customer task maps to a procedure file under references/. Read the
matching reference in full before acting, then follow its constraints and steps. The reference
files are self-contained: each carries its own decision tables, constraints, procedure, and
troubleshooting.
Execute commands using the AWS MCP server when connected (sandboxed execution, audit logging,
observability). Fall back to the AWS CLI otherwise. A web ACL's scope is fixed at creation: a
CloudFront web ACL must be created in us-east-1 with CLOUDFRONT scope, while a regional web ACL
(Application Load Balancer, API Gateway, AppSync) is created in the resource's Region with
REGIONAL scope.
Which WAF task do you need?
Routing notes
- Logging comes before tuning. Every Count-mode tuning workflow assumes logging and request sampling are on. If the customer has not set up logging, run that reference first; otherwise Count-mode tuning has nothing to read.
- Web ACL scope is fixed at creation. A CloudFront web ACL is
CLOUDFRONTscope inus-east-1; a regional resource needs aREGIONALweb ACL in its own Region. Scope cannot be changed later, so the creating reference settles it before anything is built. - Bot Control is a chain, not one task. Protecting against bots is the on-ramp (turn on, choose Common vs Targeted, observe). Turning labels into a confidence signal, forwarding that signal, and deciding what the application does with it are three separate references that build on it in that order. The header-stripping reference is the mandatory safety companion whenever a signal is forwarded to the origin.
- Common vs Targeted is not a soft choice. Common only catches self-identifying bots and known-bad IPs. For login, checkout, or any high-value endpoint facing evasive bots, Targeted with the application integration SDK is required. The bots reference pushes Targeted for real bot threats rather than presenting it as optional.
- Rate limiting vs Fraud Control. Rate-based rules blunt volumetric HTTP floods. Credential stuffing and fake-account creation are account-based abuse that rate limiting misses; those go to the Fraud Control reference (ATP and ACFP), not the rate-based reference.
- Forwarded headers need the strip rule. Any time the customer forwards a signal or the client
IP to the origin in
x-amzn-waf-*headers, the inbound-header-stripping reference is required to prevent spoofing. The confidence-signal, interpolation, and client-IP references all point at it. - What lives in other skills. L3/L4 DDoS protection and Shield cost-protection credits are the shieldadvanced skill. Multi-account WAF rollout is the firewallmanager skill. CloudFront and Application Load Balancer configuration are their own skills. This skill builds the WAF rules; it does not configure the resources it protects.
Security Considerations
AWS WAF is itself a security control, so misconfiguration directly weakens an application's defenses. Apply these across every reference:
- Least-privilege IAM. You MUST grant only the specific
wafv2:actions a task needs (for examplewafv2:CreateWebACL,wafv2:GetWebACL,wafv2:UpdateWebACL,wafv2:AssociateWebACL,wafv2:PutLoggingConfiguration) rather thanwafv2:*or theAWSWAFFullAccessmanaged policy. - Ephemeral credentials. You MUST use IAM roles with temporary credentials (such as an EC2
instance profile, SSO session, or
aws sts assume-role) rather than long-lived IAM user access keys when running these WAF CLI commands. - Monitor configuration changes. You SHOULD enable AWS CloudTrail on
wafv2management events and set CloudWatch alarms on critical web ACL configuration changes (such asDeleteWebACLandUpdateWebACLrule removals) and on the web ACL'sBlockedRequestsandCountedRequestsmetrics, so rule changes and sudden spikes in blocked or counted traffic are detected. - Misconfiguration opens access. A web ACL that is created but never associated, or one whose
default action is left at
Allowwith no enforcing rules, filters nothing. You MUST confirm the web ACL is associated and that its posture matches the intended default (block vs allow) before reporting setup complete. - Protect log destinations. Logs can capture credentials and session data. You MUST redact
sensitive fields (such as the
authorizationheader andcookie) and MUST enable encryption at rest on the log destination (CloudWatch Logs, Amazon S3, or Amazon Data Firehose). - Header-spoofing risk. Any
x-amzn-waf-*signal forwarded to the origin can be forged inbound. You MUST add the inbound-header-stripping rule whenever a signal or client IP is forwarded (see stripping-inbound-waf-headers-before-trusting-them).
Additional Resources
Related skills
More from aws/agent-toolkit-for-aws and the wider catalog.

agents-build
Extend your AgentCore agent with memory, integrations, VPC, multi-agent patterns, browser tools, payments, and more.

agents-connect
Connect your agent to external APIs, tools, and services via Gateway with Cedar policy control.

agents-debug
Diagnose agent errors, wrong answers, tool failures, and environment issues by reading traces and logs.

agents-deploy
Deploy AgentCore agents to AWS with pre-flight validation, error diagnosis, and rollback support.

marketing-mindset
Professional marketer's operating mindset for growth, positioning, and client acquisition—not tactics.

axiom-alerting
Create and manage Axiom monitors and notifiers via the v2 public API for end-to-end alerting.