Advanced Rate Limiting Just Got Better

Today we’re launching a new advanced rate limiting user experience with the intent of simplifying rate limiting while also extending the capabilities and improving observability.

Fastly’s rate limiting experience with the Next-Gen WAF just got better and easier to use. We believe that security should be extremely effective and as simple to implement as possible. When we heard from customers that it took them a little bit of time to realize the power of our rate limiting and implement it effectively, we knew we could do something to make it better. We want our customers to experience an “aha” moment with every part of the product, and ideally right away! We consistently hear about “aha” moments during onboarding when new customers realize that we support many more flexible deployment options than they could have imagined, and also after enabling the WAF and realizing that our SmartParse technology allows them to get into blocking mode faster than with any other product. We’re excited to release this improvement so we can start hearing those “ahas” for rate limiting as well. 

Usability Improvements

While we made several updates, the biggest change is we have removed the requirement of using an “action signal” to rate limit requests and have introduced a new dropdown labeled “Match type”. This field defines which requests from the client should be blocked or logged after the threshold has been reached.

Previously, you could get the behavior of “Rule conditions”, which rate limits requests from clients that match the defined rate limit rules defined conditions by setting the counting or threshold signal to the same as the “action signal”. You will find that using the match type “Rule conditions” will fit your needs for general rate limiting use cases.

However, we do believe that it is also important to allow you to rate limit requests from a client that do not match the defined rule conditions and has another signal attached (this helps with scenarios such as detecting credit card validation attempts). Our documentation has a great example of configuring that. For this use case, you are able to use the match type “Other signal” and at this point, you will have the ability to select the “action signal”, which will be used to rate limit requests from the client who have matched the original rule conditions and surpassed the threshold.

We also heard from customers that after a client matches the defined rule conditions and exceeds a threshold they’d like to rate limit all requests from that client. Previously, this was possible but required implementing multiple rules to make it happen. We’ve simplified the workflow by introducing the match type “All requests”.

Better observability

Defining rate limit rules is only one part of implementation. Next, you need an easy way to be able to see what requests would be or are being rate limited. To aid with this, first, we allow you to set an advanced rate limit rule to “log” or “block”. After you have that defined you are now able to view a stacked time series graph to see which requests are being counted towards rate limiting thresholds and which have actually surpassed the threshold and are either eligible for being rate limited or are actually being rate limited.

We’ve also simplified the way in which you search the Requests log to find requests that have been rate limited. Previously, if you wanted to see a request that was being rate limited by a specific rule you had to use a filter that included the rule ID. In some cases, it may not be clear how to find that rule ID. Now, you are able to search for requests just by using the search filter ratelimited:site.threshold-signal. Here’s a snippet of what that would look like if my threshold signal was named site.normal-ratelimit

Next steps

If you are a Premier package customer you have the new advanced rate limiting user experience and observability improvements available to you right away. If you’re not a customer, reach out to us to see how our rate limiting capabilities can stop abusive traffic from impacting your sites and APIs.

As mentioned above we are always working to improve the product based on customer feedback so stay tuned for future updates. If there’s something you’d like to see in the product please reach out and let us know.