A WAF, or web application firewall, checks incoming requests against rules before they reach the application. Its bill can combine several different charges. Removing a few visible rules may affect only a small part of the total, while removing an important protection.
Start with the charging dimensions and the request path. Identify the component you want to change and what evidence would show that the change is safe. Cost review should end with a testable proposal, not a blanket instruction to inspect less traffic.
1. Split the bill into its components
| Component | What to investigate |
|---|---|
| Web ACL and rules | Which configured items are billed? |
| Requests and capacity | What volume is processed, and which whole-ACL capacity band applies? |
| Premium inspection | Which requests actually reach the paid group? |
| Body inspection, CAPTCHA and Challenge | Which configured features and events add charges? |
| Logging and delivery | Which allowances apply, and what storage or analysis remains payable? |
The AWS WAF pricing page separates base configuration, requests and additional features. Capacity above the included allocation can add a request surcharge. Premium managed inspection and Marketplace subscriptions can introduce other charges; logging needs its own check.
Match each material line to the actual configuration, region or CloudFront scope and period. Check whether a delivery plan includes relevant protection. Do not assume a bundle changes the price of unrelated standalone usage, or that a free request allowance applies more than once.
Keep the workload steady when comparing alternatives. If fewer requests arrived this month, that can explain a lower bill without any configuration improvement. Record total requests and the subset inspected by the paid feature separately.
2. Follow the evaluation order
Rules are evaluated in order. Allow and Block terminate evaluation; Count continues it. AWS explains these distinctions in its rule-action guidance. An early broad Allow can bypass later protections, which makes it a poor shortcut for avoiding inspection charges.
| Stage | If it matches | Consequence |
|---|---|---|
| An earlier Block rule | Terminates evaluation | Later premium group is not reached |
| An observation rule using Count | Continues evaluation | Later paid inspection can still happen |
| Premium group with a scope-down statement | Only in-scope requests enter the group | Excluded traffic loses this group’s inspection |
| Remaining rules and default action | Depend on earlier results | Review final outcomes, not only individual counters |
The fictional table illustrates evaluation, not a production policy. It assumes ordinary Allow, Block and Count behaviour; token-based actions need their own review. Draw the actual sequence and identify which traffic reaches each paid inspection stage.
Changing a premium rule’s result to Count does not mean its inspection stopped. It changes the action taken after a match. Use Count for a deliberate observation plan with suitable existing protection, not as an assumed billing switch.
3. Check scope and capacity separately
A scope-down statement limits the requests evaluated by a managed rule group. AWS documents this in scope-down statements. That can affect paid inspection volume, but it also removes that group’s protection from excluded requests. Identify the replacement control or the accepted exposure before proceeding.
Static assets may already avoid the premium group. If so, excluding them again adds no new saving. Check what the current configuration actually does, including requests rejected earlier, rather than estimating from the total number of page assets.
Web ACL capacity units, or WCUs, describe processing capacity; they are not a count of rules. Use CheckCapacity with the proposed ruleset to assess the whole configuration. Do not assume that summing isolated rule estimates gives the final optimised total.
A small capacity reduction may leave the same billed band in place. Keep rule fees, capacity effects and premium inspection effects in separate calculations. This also prevents the same avoided requests being counted as several independent savings.
4. Write a narrow test plan
Pick one change and record its intended effect. Name the routes affected, the expected legitimate traffic, the attack pattern still covered and the rollback condition. Keep the original configuration available to the person running the test.
Exercise login, checkout, forms, uploads, APIs and trusted webhooks where relevant. Include users without an existing session or challenge token. A successful administrator session is not representative of every visitor.
Use metrics and request evidence together. The AWS WAF metric definitions explain the counters; a sampled request view is not a complete record of every outcome. Preserve enough logging to investigate false positives and unexpected bypasses, with appropriate access and retention.
If a proxy sits in front of the application, establish which client address can be trusted. A user agent or a header supplied by an arbitrary visitor is not proof of identity. Do not build a cost-saving exemption around a spoofable claim.
5. Verify protection and the charge
Compare equivalent traffic periods after the change. Check legitimate completion, unexpected blocks and the volume reaching paid inspection. Then reconcile the relevant billing line, allowing for the part of the period before the change.
Keep an estimated saving labelled as such until the billed usage supports it. If traffic or another rule changed at the same time, record that limitation. A neat percentage without that context is not useful evidence.
What can go wrong?
A broad Allow can skip the rule you meant to keep. A path exclusion can expose an endpoint that merely looks static. Reducing logs can hide false positives. A lower rule count can leave capacity costs unchanged. Each needs a different check; none is resolved by looking only at the total bill.
Proceed, investigate or keep?
- Proceed: a specific charge and narrowly scoped change are understood, protection is retained or explicitly reassessed, and tests pass.
- Investigate: inspected volume, billing eligibility or client identity remains uncertain.
- Keep: the proposed saving removes a required control without an acceptable alternative.
For the related origin boundary, read the guide to restricting an origin behind Cloudflare; its implementation is specific to that proxy, not a universal WAF recipe.
Continue the AWS review
If you are reviewing your website’s hosting, tell AceMedia Host what you need.