Skip to main content
In this lesson we’ll cover AWS Web Application Firewall (WAF): what it is, how it evaluates requests, how it integrates into your architecture, and common use cases and best practices.

​
What is a Web Application Firewall?

AWS WAF is a Layer 7 (application layer) firewall that sits in front of your web-facing endpoints and inspects incoming HTTP(S) requests for malicious or unwanted traffic. Because WAF understands HTTP, it can detect and mitigate common web exploits such as SQL injection (SQLi) and cross-site scripting (XSS), enforce request-size and header checks, and apply rate-based limits to reduce abusive traffic patterns. Key capabilities:
  • Deep inspection of HTTP requests (headers, URI, query string, body, size).
  • Multiple rule actions: allow, block, count, CAPTCHA, or return a custom response.
  • Support for managed rule groups (AWS-managed or third-party) plus custom rules you define.
  • Rate-based rules and geo match conditions for volume and geographic controls.
  • Integration points: CloudFront, Application Load Balancer (ALB), API Gateway, and App Runner.
A labeled diagram of a WebACL showing a firewall icon on the left and three service icons on the right. Between them is a large WebACL box containing multiple rule blocks (Conditions and Actions) organized as Rules 1–3 and a Rules Group.

​
Web ACLs and rules

A Web ACL (web access control list) is a container of rules. Each rule specifies:
  • Conditions to inspect (IP addresses, headers, URIs, query strings, request body contents, method, or request size).
  • A rule action to take when a request matches those conditions.
  • A priority to determine evaluation order.
Common rule actions Rules can be:
  • Custom rules you author (statements, managed rule groups, or rate-based rules).
  • AWS Managed Rules or third-party managed rule groups (pre-built protections for common threats).
  • Rate-based rules that automatically track request rates per IP to help mitigate abusive spikes.
  • Geo match rules that allow or block traffic from specific countries.

​
Example rule JSON

Here is an example rule object (simplified) that blocks SQL injection attempts against the URI path. Use this as a reference when authoring rules via the API/CLI/CloudFormation:

​
How rule evaluation works

When a request arrives, AWS WAF evaluates the rules in the Web ACL in priority order (lowest numeric priority value first). WAF checks each rule sequentially until one rule matches the request — then WAF immediately applies that rule’s action and stops further evaluation. If no rule matches, the Web ACL’s default action is applied (typically Allow or Block, depending on your configuration).
Remember: rule priority matters — WAF evaluates rules in order and stops at the first matching rule. Use a Count rule for testing or place allow rules ahead of block rules to avoid accidentally blocking desired traffic.

​
How WAF fits into your architecture

The request flow is consistent across integration points: client → WAF → (if allowed) protected resource (CloudFront, ALB, API Gateway, etc.) WAF evaluates requests before they reach the protected resource, letting you stop malicious traffic at the edge. This reduces backend load and prevents exploitable requests from ever reaching your compute, serverless functions, or APIs. Example deployment patterns:
  • CloudFront + WAF for global CDN protection and low-latency blocking.
  • ALB + WAF for web applications hosted on EC2/ECS/EKS behind a load balancer.
  • API Gateway + WAF to protect REST and HTTP APIs, including serverless backends (Lambda).
A cloud architecture diagram titled "Web Application Firewall (WAF)" showing user traffic routed through a WAF into a Virtual Private Cloud (VPC) containing an Availability Zone and Private Subnet. It also shows downstream components like a load balancer and an AWS Lambda icon.

​
Use cases for AWS WAF

  • Protect web applications from common web attacks: SQL injection, XSS, header/parameter tampering.
  • Secure public APIs by filtering requests, enforcing size limits, and blocking suspicious IPs.
  • Protect serverless applications (API Gateway + Lambda) with application-layer rules.
  • Enforce granular application-layer filtering based on HTTP methods, headers, URIs, and body content.
  • Implement rate-based defenses to throttle abusive traffic or mitigate simple DDoS spikes.
  • Combine with AWS Shield Advanced and centralized logging for comprehensive, monitored protection.
A presentation slide titled "WAF – Use Cases" showing five numbered cards with colorful icons listing use cases: protection against common web attacks, API security, protection for serverless applications, application-layer firewall, and integration with other AWS services.

​
Best practices

  • Test rules in Count mode first, then switch to Block after validating behavior.
  • Use AWS Managed Rules as a baseline, then add custom rules for application-specific logic.
  • Keep a clear rule priority strategy (e.g., explicit allows → specific protections → generic blocks).
  • Log Web ACL matches to Amazon Kinesis Data Firehose / CloudWatch / S3 for forensic analysis and dashboards.
  • Combine WAF with AWS Shield for more robust DDoS protection where required.
  • Monitor metrics and set alerts on rule match spikes and rate-based triggers.
Important: Do not deploy blocking rules directly to production without testing. Start with Count to measure impact and ensure you do not unintentionally block legitimate users or services.
Use these resources when designing rules, testing configurations, or extending protection with managed rule groups and logging integrations.

Watch Video