Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

AWS WAF protects supported AWS application resources by inspecting HTTP(S) requests forwarded to them. You associate a web access control list (web ACL)—called a protection pack in AWS’s newer console experience—with CloudFront, an Application Load Balancer (ALB), or an API Gateway REST API, then configure rules to allow, block, count, or otherwise respond to matching requests.

The important implementation choices are where the protected resource sits, which requests actually pass through it, how rules are tuned, and what request data AWS WAF can inspect. “API servers” is not a blanket target: API Gateway REST APIs are supported, but arbitrary servers or API implementations are not automatically protected by AWS WAF.

What AWS WAF protects—and what it does not

AWS WAF is a managed request-inspection layer for HTTP(S) traffic sent to supported AWS resources. It evaluates requests against rules in an associated web ACL, allowing you to define which request patterns should be permitted, blocked, counted, or handled with another documented action. See AWS’s overview of AWS WAF.

The supported targets relevant to this guide are CloudFront distributions, Application Load Balancers, and API Gateway REST APIs. AWS also lists AppSync GraphQL APIs and other services, including Cognito user pools, App Runner, Bedrock AgentCore Gateway, Verified Access, and Amplify. For ECS workloads, AWS describes protection by routing HTTP(S) traffic through an AWS WAF-enabled ALB. This does not mean every API implementation or an arbitrary EC2-hosted server can be attached directly; the traffic must pass through a supported resource or integration. See AWS WAF’s supported services and deployment guidance.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Choose the right placement and AWS Region

AWS WAF applies at the resource you associate with the web ACL. Requests must reach that protected resource for its rules to inspect them. Choose the placement that corresponds to the traffic path you intend to govern; attaching a web ACL to one resource does not automatically cover separate entry points.

Protected target WAF scope and Region What the association covers
CloudFront distribution Global in effect; create the web ACL and its WAF resources in US East (N. Virginia), us-east-1. HTTP(S) requests forwarded to the associated distribution.
Application Load Balancer Regional; use the target’s AWS Region, subject to AWS WAF availability there. HTTP(S) requests forwarded to the associated load balancer.
API Gateway REST API Regional; use the target’s AWS Region, subject to AWS WAF availability there. Requests forwarded to the associated REST API.

CloudFront’s global scope does not change the Region requirement for its WAF configuration: create the web ACL in us-east-1. Regional targets use regional WAF resources in the target Region. Consult AWS’s resource and scope guidance before creating or associating a web ACL.

Build rules, then tune them before enforcement

A rule matches properties of an HTTP(S) request and applies its configured action. AWS WAF supports allowing or blocking traffic and a Count action; AWS’s overview also describes challenge-style responses. A rule’s action determines how matching requests are handled, so review the action and match conditions together rather than treating a match as a block by default.

Use Count to observe proposed rules

For a new rule, Count lets you see which requests would match without changing their traffic handling. Review the resulting logs and metrics, refine the match conditions, and only then choose an enforcement action if the observed matches are appropriate. This staged approach can reveal overly broad conditions before they affect legitimate requests.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Use rate-based rules for request volume

A rate-based rule groups requests according to configured aggregation keys, evaluates them over a time window, compares the count with a request limit, and applies an action when the configured criteria are met. A scope-down statement can limit which requests the rule tracks—for example, to a relevant subset of traffic—instead of counting every request covered by the web ACL.

Each rate-based rule instance maintains its own tracking. Identical settings copied into separate web ACLs do not create a single shared counter. AWS Shield Advanced’s application-layer guidance describes a default evaluation window covering the prior five minutes and blocking IP addresses that exceed the configured threshold until their rate falls. That is the default described for that guidance, not a guarantee for every configuration; check the rule’s current settings and set a threshold above normal traffic expected from one source IP during the relevant five-minute window. See AWS Shield Advanced’s rate-based rule guidance.

Check body-inspection limits and oversize handling

Request-body inspection limits depend on the protected resource. AWS’s quotas documentation states that ALB and AppSync body inspection is limited to 8 KB. For CloudFront, API Gateway, Cognito, App Runner, Verified Access, and Bedrock AgentCore Gateway, the default body inspection limit is 16 KB and can be increased up to the documented maximum for applicable resources. These are AWS technical limits, not performance measurements. Check the current AWS WAF quotas documentation for the resource and configuration you use.

When a request body is larger than the configured inspection limit, do not assume a body-match rule evaluates the bytes AWS WAF did not inspect. Review the oversize-handling option for the relevant statement and decide explicitly how a request with an oversized body should be treated. AWS WAF also has quotas for associations and rule resources; deployments covering many applications should check the current quotas during design.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Understand optional protections, management, and cost

WAF and Shield Advanced address different layers

AWS documents using WAF web ACLs and rate-based rules with Shield Advanced for application-layer protections on CloudFront and ALB. Shield Advanced is a separate service with additional charges. AWS WAF alone should not be treated as providing every network- or transport-layer DDoS protection. See AWS’s DDoS protection overview and its Shield Advanced guidance.

Centralize administration when needed

For organizations managing protections across multiple accounts or resources, AWS Firewall Manager can administer protections such as WAF centrally. Central management adds an operational layer for policy administration; the web ACL still needs to be associated with the resource being protected. See AWS Firewall Manager documentation for AWS WAF.

Check how optional features are billed

AWS states that intelligent threat mitigation features incur costs beyond basic WAF charges. CloudFront flat-rate plans package WAF with other capabilities and require a valid associated web ACL to remain attached. Actual spend depends on current pricing and configuration; check AWS’s current pricing and plan terms before choosing a setup. No deployment-specific price follows from the service mechanics described here. See AWS WAF pricing and CloudFront pricing.

Implementation checklist

  1. Identify the traffic path. Decide whether requests reach CloudFront, an ALB, or an API Gateway REST API, and associate protection with the supported resource receiving the traffic.
  2. Create the web ACL in the correct scope. For CloudFront, use us-east-1; for regional targets, use the target’s Region, subject to service availability.
  3. Define request matches and actions. Specify the request properties to match and whether a match should be allowed, blocked, counted, or handled with another supported action.
  4. Observe before enforcing where appropriate. Run proposed rules in Count mode and review logs or metrics before switching to an action that changes traffic handling.
  5. Configure rate controls deliberately. Select aggregation keys, time window, threshold, action, and any scope-down statement; account for each rule instance tracking independently.
  6. Review body inspection and oversize behavior. Confirm the resource’s inspection limit and decide how the rule handles bodies exceeding it.
  7. Check operational and cost requirements. Review current AWS quotas, regional availability, optional feature charges, and any CloudFront plan association requirements.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.