Understanding AWS WAF WCU: Capacity Limits vs. Real Cost Drivers

AWS WAF has a small concept that confuses almost everyone the first time they see it in the console: WCU, short for Web ACL Capacity Units. The screen makes it look like a usage meter, and the values beside managed rule groups can feel like they are directly tied to billing. Most of the time, they are not. WCU is best understood as a sizing system. It tells you how “heavy” a rule or a managed rule group is in terms of inspection complexity, and it determines whether your full set of protections can fit inside a single Web ACL.

A Web ACL is the container that holds your AWS WAF rules. Each rule you add consumes some capacity, and AWS assigns that consumption in WCU. Managed rule groups also come with a predefined WCU value, because AWS already knows roughly how much processing is required to evaluate those signatures and conditions per request. When you attach multiple managed rule groups and custom rules to one Web ACL, AWS sums the WCUs and enforces a maximum. In many deployments, that maximum is commonly 1500 WCU by default. In practical terms, WCU answers one question: can this rule set fit into this Web ACL.

This is why, when you look at a Web ACL that includes rule groups like the Amazon IP Reputation list, the Common Rule Set, and the Known Bad Inputs rule set, you see different WCU values next to each of them. The values reflect relative complexity. A reputation list is lightweight because it is mostly matching against IP intelligence. A broad common protections set is heavier because it covers a wide range of exploit patterns and request anomalies. When you add them together, you get a total. That total matters operationally because it governs what you are allowed to enable together in one place.

The natural next question is cost, because the console shows WCU prominently. The key point is that WCU is not a pricing unit in the normal sense. Under AWS WAF’s base pricing, you do not pay “per WCU,” and WCU does not scale your bill as it rises. Instead, AWS prices WAF based on how many Web ACLs you run, how many rules you configure in those Web ACLs, and how many requests are inspected. A managed rule group is counted as a rule for billing purposes, even though it may internally contain many individual signatures. This is why two Web ACLs with the same WCU total can still cost different amounts if they differ in request volume, number of Web ACLs, or which paid managed protections are enabled.

This also answers the common question of whether there is no cost until you reach 1500 WCU. There is not. The 1500 figure is a capacity ceiling, not a free tier threshold. If you have a Web ACL deployed and receiving traffic, you can incur WAF charges even if you are using a small fraction of the available capacity.

Conversely, you could design a Web ACL that approaches the capacity limit and still see your cost primarily governed by request volume and paid managed protections, not by the WCU total.

So what happens if someone needs more than 1500 WCU worth of protections. When you exceed capacity, AWS does not bill you more simply because you are heavier; it prevents you from adding more into that same Web ACL. At that point you solve it as a design problem. Sometimes you reduce capacity consumption by removing overlapping protections and keeping the most valuable managed groups. Sometimes you tune by disabling specific noisy sub-rules where the managed group supports it, or by scoping rules to only the paths and hosts where they matter. Sometimes you request an increase through AWS Support, depending on what is available for your deployment scope. Sometimes you split protections across layers, such as applying a smaller set of broad edge rules at CloudFront and placing application-specific rules closer to the origin, like on an ALB or API Gateway. That last approach can work well, but it can also change cost because you may now have more than one Web ACL in use and you may be evaluating traffic through more than one WAF layer.

At this point it is important to call out one nuance that trips up experienced teams as well. While WCU is primarily a capacity concept, AWS can apply an additional per-million-requests charge when a Web ACL uses more than 1500 WCUs, in increments above that default allocation. In other words, below 1500 WCU you are firmly in the “WCU is just capacity” world, but beyond 1500 WCU there can be a per-request surcharge specifically tied to exceeding that capacity band. That surcharge is still not “WCU-based billing” in the sense of paying for WCU itself; it is an additional request processing charge that applies because the Web ACL is operating above the default capacity allocation.

This leads directly to the last question: how to calculate cost based on WCU. You cannot compute WAF cost from WCU alone because WCU does not map cleanly to pricing. The way you estimate WAF cost is by building it around the billing drivers. You identify how many Web ACLs you are running and where they are attached. You estimate the monthly request volume that will be inspected. You list which managed rule groups and advanced features are enabled, because some of those can introduce their own charges. Then you apply the published pricing for Web ACLs, rules, requests, and any add-ons. Only if your Web ACL exceeds 1500 WCU do you additionally account for the per-request surcharge associated with operating above that capacity band.

If you want a simple way to keep your mental model correct, treat WCU as the packing limit for a suitcase, not the price tag on the suitcase. The suitcase can be expensive or cheap regardless of how full it is. If you overpack, the problem is that it will not close, not that the airline charges you more because you used a heavier zipper. With WAF, if you exceed capacity, the Web ACL will not accept the extra rules, and in some cases the service can apply an incremental request processing charge above the default 1500 WCU capacity. The bill itself is still about how many Web ACLs you run, how many rules you configure, how many requests are inspected, and whether you paid for advanced protections.

Reach out to PalaviTech to strengthen your security across AWS, web and mobile applications, and red team readiness with clear, actionable findings and practical remediation guidance.

https://palavi.tech | Email: contact@palavi.tech