RateBasedStatement

Class

Search: Entire Site Articles & Tutorials Documentation Documentation - This Product Documentation - This Guide Release Notes Sample Code & Libraries

A rate-based rule counts incoming requests and rate limits requests when they are coming at too fast a rate. The rule categorizes requests according to your aggregation criteria, collects them into aggregation instances, and counts and rate limits the requests for each instance.

If you change any of these settings in a rule that's currently in use, the change resets the rule's rate limiting counts. This can pause the rule's rate limiting activities for up to a minute.

You can specify individual aggregation keys, like IP address or HTTP method. You can also specify aggregation key combinations, like IP address and HTTP method, or HTTP method, query argument, and cookie.

Each unique set of values for the aggregation keys that you specify is a separate aggregation instance, with the value from each key contributing to the aggregation instance definition.

For example, assume the rule evaluates web requests with the following IP address and HTTP method values:

• IP address 10.1.1.1, HTTP method POST

• IP address 10.1.1.1, HTTP method GET

• IP address 127.0.0.0, HTTP method POST

• IP address 10.1.1.1, HTTP method GET

The rule would create different aggregation instances according to your aggregation criteria, for example:

• If the aggregation criteria is just the IP address, then each individual address is an aggregation instance, and WAF counts requests separately for each. The aggregation instances and request counts for our example would be the following:

  • IP address 10.1.1.1: count 3

  • IP address 127.0.0.0: count 1

• If the aggregation criteria is HTTP method, then each individual HTTP method is an aggregation instance. The aggregation instances and request counts for our example would be the following:

  • HTTP method POST: count 2

  • HTTP method GET: count 2

• If the aggregation criteria is IP address and HTTP method, then each IP address and each HTTP method would contribute to the combined aggregation instance. The aggregation instances and request counts for our example would be the following:

  • IP address 10.1.1.1, HTTP method POST: count 1

  • IP address 10.1.1.1, HTTP method GET: count 2

  • IP address 127.0.0.0, HTTP method POST: count 1

For any n-tuple of aggregation keys, each unique combination of values for the keys defines a separate aggregation instance, which WAF counts and rate-limits individually.

You can optionally nest another statement inside the rate-based statement, to narrow the scope of the rule so that it only counts and rate limits requests that match the nested statement. You can use this nested scope-down statement in conjunction with your aggregation key specifications or you can just count and rate limit all requests that match the scope-down statement, without additional aggregation. When you choose to just manage all requests that match a scope-down statement, the aggregation instance is singular for the rule.

You cannot nest a RateBasedStatement inside another statement, for example inside a NotStatement or OrStatement. You can define a RateBasedStatement inside a web ACL and inside a rule group.

For additional information about the options, see Rate limiting web requests using rate-based rules in the WAF Developer Guide.

If you only aggregate on the individual IP address or forwarded IP address, you can retrieve the list of IP addresses that WAF is currently rate limiting for a rule through the API call GetRateBasedStatementManagedKeys. This option is not available for other aggregation configurations.

WAF tracks and manages web requests separately for each instance of a rate-based rule that you use. For example, if you provide the same rate-based rule settings in two web ACLs, each of the two rule statements represents a separate instance of the rate-based rule and gets its own tracking and management by WAF. If you define a rate-based rule inside a rule group, and then use that rule group in multiple places, each use creates a separate instance of the rate-based rule that gets its own tracking and management by WAF.

Namespace: Amazon.WAFV2.Model
Assembly: AWSSDK.WAFV2.dll
Version: 3.x.y.z