WAF and Edge Security

Web ACLs and rule groups, rate and bot controls with logging, and where Shield fits

Web ACL = rules + default actionAllow/Block terminate, Count does not
Rate-based rules act on volumethe aggregation key need not be the IP
Enable WAF logging firsta blocked request never reaches your app logs
Shield Standard is automatic and freelayer 7 floods still need WAF rules

1.Web ACLs, Rules, and Rule Groups

AWS WAF inspects HTTP(S) requests before they reach your application. You write a web ACL — a list of rules, each with inspection criteria and an action — and associate it with a resource such as a CloudFront distribution, an Application Load Balancer, or an API Gateway REST API. That resource forwards each request to AWS WAF first, and the web ACL decides whether the request goes through.

Key features

A web ACL holds rules and one default action (allow or block) applied to requests that no rule already allowed or blocked
Rule actions are Allow, Block, Count, or a CAPTCHA / silent browser Challenge check
Rules live directly in the web ACL or in reusable rule groups (yours, AWS Managed Rules, or Marketplace) — a rule is not a standalone AWS resource, but web ACLs and rule groups are
Web ACL capacity units (WCUs) meter how much processing the rules require, and bound how much you can put in one web ACL
Protected resource types: CloudFront distribution, API Gateway REST API, Application Load Balancer, AppSync GraphQL API, Cognito user pool, App Runner service, Bedrock AgentCore Gateway, Verified Access instance, and AWS Amplify
Scope is CLOUDFRONT or REGIONAL — for CloudFront you must use the US East (N. Virginia) endpoint (`--scope=CLOUDFRONT --region=us-east-1`)

Rule actions and what they do to evaluation

Rule actions and what they do to evaluation
Action	Effect on the request	Effect on remaining rules
Allow	Sent on to the protected resource	Terminating — no further rules run
Block	Rejected, by default with HTTP 403 or a custom response	Terminating — no further rules run
Count	Nothing; the match is only tallied	Non-terminating — evaluation continues
CAPTCHA	A puzzle is served unless a valid, unexpired token is present	Continues when the token is valid; otherwise terminates with the CAPTCHA response
Challenge	A silent browser check is run unless a valid token is present	Continues when the token is valid; otherwise terminates with the challenge

A request through a web ACL

arrives atforwarded forinspectionevaluates toallowedrequests only

Client request

Protected resource

CloudFront / ALB / API Gateway

Web ACL

rules in priority order

Allow / Block / Count / CAPTCHA

first terminating match wins

Your application

Signature

web ACL { rules[priority] → Allow | Block | Count | CAPTCHA | Challenge, default action } → protected resource

A web ACL = rules (each with criteria + an action) plus one default action, attached to a protected resource. Allow and Block are terminating; Count only tallies. Rule groups make rules reusable — AWS Managed Rules is the usual starting point. CloudFront-scoped web ACLs live in us-east-1.

2.IP Sets, Rate-Based Rules, Bot Control, and Logging

Signature rules catch requests that look malicious. The rules in this concept catch requests that are individually fine but wrong in aggregate — too many from one address, or coming from an automated client pretending to be a browser. IP sets match known addresses, rate-based rules count requests per key over a time window, and Bot Control identifies and labels automated traffic. WAF logging is what tells you which of them fired and on what.

Key features

An IP set is a reusable list of addresses or CIDR ranges a rule can reference, so an allow-list or block-list is edited in one place
A rate-based rule counts requests matching its scope per aggregation key over a sliding window and acts once the count crosses your limit
The aggregation key does not have to be the source IP — it can be a header, a cookie, a query argument, a label, or a combination, which is what makes per-tenant or per-API-key limits possible
Bot Control and the other intelligent threat mitigation rule groups label requests (verified crawler, likely automated client) so later rules can act on the label; CAPTCHA and Challenge issue a token so the check is not re-run on every request in a session
WAF logs record the matched rule, the action, and the request attributes, and can be delivered to CloudWatch Logs, S3, or Kinesis Data Firehose
Behind CloudFront, evaluate IP and rate rules at the CloudFront distribution — an ALB behind it sees the edge address, not the viewer's

Which control answers which abuse pattern

Which control answers which abuse pattern
Pattern	Control	Why the others do not fit
A known bad address range	IP set referenced by a Block rule	A rate rule would only act after the abuse volume arrives
Credential stuffing on POST /login	Rate-based rule scoped to that URI	Each individual request is a valid login attempt
One tenant exhausting a shared API	Rate-based rule keyed on the API-key header	Keying on IP groups a whole office behind one NAT address
A scraper imitating Chrome	Bot Control rule group, acting on its labels	The requests are well-formed and come from many addresses
Automated traffic with no session state	Challenge action	Blocking outright also refuses legitimate clients from that network

Signature

IP set (known addresses) · rate-based rule (volume per key) · Bot Control (labels) · logs → CloudWatch Logs | S3 | Firehose

IP sets match known addresses; rate-based rules act on volume per aggregation key (which does not have to be the IP); Bot Control labels automated traffic so other rules can act on it. Enable WAF logging first — a blocked request leaves no trace in your application logs.

3.DDoS Protection and the Role of Shield

A DDoS attack floods a target from many compromised systems so real users cannot get through. AWS Shield defends against that, in two tiers: Shield Standard is on automatically for every AWS customer at no extra charge, and Shield Advanced is a paid subscription adding deeper application-layer protection and support. Shield handles the flood; AWS WAF is what expresses the application-specific rules underneath it.

Key features

Shield protects against DDoS at the network and transport layers (layers 3 and 4) and at the application layer (layer 7)
Shield Standard is provided automatically at no extra charge when you use AWS; Shield Advanced is a paid subscription
Network volumetric attacks (layer 3) try to saturate network capacity; network protocol attacks (layer 4), such as a TCP SYN flood, exhaust connection state; application layer attacks (layer 7) flood you with individually valid requests
AWS documents Shield as covering known and zero-day attack vectors — detection is designed to work on threats not explicitly known at the time
Layer 7 floods are made of valid requests, which is why AWS WAF rate-based rules — not raw bandwidth defenses — are the tool that shapes them
Terminating traffic at the edge (CloudFront, Route 53, Global Accelerator) is itself a DDoS design choice: the absorbing capacity is AWS's, not your origin's

Shield Standard vs Shield Advanced

Shield Standard vs Shield Advanced
Aspect	Shield Standard	Shield Advanced
How you get it	Automatic for every AWS customer	Paid subscription you opt into
Cost	No extra charge	A monthly subscription plus data transfer
Coverage	Common layer 3 and 4 attacks	Adds deeper detection and mitigation, including layer 7 for protected resources
Support	Ordinary AWS support	Access to the AWS Shield Response Team and attack diagnostics
Typical fit	Every workload, by default	Public workloads where an outage has direct revenue or safety cost

What defends against what

Layer 3 — volumetric flood

Saturates network capacity · absorbed by Shield

Layer 4 — protocol abuse

TCP SYN flood exhausting connection state · absorbed by Shield

Layer 7 — request flood

Individually valid HTTP requests · shaped by AWS WAF rate-based rules

Application logic

Your handlers, your database — the thing being protected

Command

text

# The layered shape of a DDoS-resistant public entry point
Route 53  ->  CloudFront (+ web ACL: managed rules, rate-based rules)
          ->  ALB in private subnets
          ->  application

Shield Standard is automatic and free and handles common layer 3/4 floods. Shield Advanced is a paid subscription with deeper layer 7 protection and response-team access. A layer 7 flood is valid requests, so the actual control is an AWS WAF rate-based rule at the edge.

Spotted a mistake on this page? Tell us.

Read Sheet