Rate Limiting

Rate limit how many HTTP requests can be made in a given period of seconds, minutes, hours, days, months, or years. If the underlying Service/Route (or deprecated API entity) has no authentication layer, the Client IP address will be used; otherwise, the Consumer will be used if an authentication plugin has been configured.

Tip: The Rate Limiting Advanced plugin provides the ability to apply multiple limits in sliding or fixed windows.

Configuration Reference

This plugin is partially compatible with DB-less mode.

In DB-less mode, you configure Kong Gateway declaratively. Therefore, the Admin API is mostly read-only. The only tasks it can perform are all related to handling the declarative config, including:

• Setting a target's health status in the load balancer
• Validating configurations against schemas
• Uploading the declarative configuration using the /config endpoint

The plugin will run fine with the local policy (which doesn’t use the database) or the redis policy (which uses an independent Redis, so it is compatible with DB-less).

The plugin will not work with the cluster policy, which requires writes to the database.

Example plugin configuration

curl -X POST http://localhost:8001/services/SERVICE_NAME|SERVICE_ID/plugins \
    --data "name=rate-limiting"  \
    --data "config.second=5" \
    --data "config.hour=10000" \
    --data "config.policy=local"

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rate-limiting-example
config: 
  second: 5
  hour: 10000
  policy: local
plugin: rate-limiting

apiVersion: v1
kind: Service
metadata:
  name: SERVICE_NAME|SERVICE_ID
  labels:
    app: SERVICE_NAME|SERVICE_ID
  annotations:
    konghq.com/plugins: rate-limiting-example
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: SERVICE_NAME|SERVICE_ID
  selector:
    app: SERVICE_NAME|SERVICE_ID

plugins:
- name: rate-limiting
  service: SERVICE_NAME|SERVICE_ID
  config: 
    second: 5
    hour: 10000
    policy: local

curl -X POST http://localhost:8001/routes/ROUTE_NAME|ROUTE_ID/plugins \
  --data "name=rate-limiting"  \
    --data "config.second=5" \
    --data "config.hour=10000" \
    --data "config.policy=local"

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rate-limiting-example
config: 
  second: 5
  hour: 10000
  policy: local
plugin: rate-limiting

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ROUTE_NAME|ROUTE_ID
  annotations:
    kubernetes.io/ingress.class: kong
    konghq.com/plugins: rate-limiting-example
spec:
  rules:
  - host: examplehostname.com
    http:
      paths:
      - path: /bar
        backend:
          service:
            name: echo
            port:
              number: 80

plugins:
- name: rate-limiting
  route: ROUTE_NAME
  config: 
    second: 5
    hour: 10000
    policy: local

curl -X POST http://localhost:8001/consumers/CONSUMER_NAME|CONSUMER_ID/plugins \
  --data "name=rate-limiting"  \
    --data "config.second=5" \
    --data "config.hour=10000" \
    --data "config.policy=local"

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rate-limiting-example
config: 
  second: 5
  hour: 10000
  policy: local
plugin: rate-limiting

apiVersion: configuration.konghq.com/v1
kind: KongConsumer
metadata:
  name: CONSUMER_NAME|CONSUMER_ID
  annotations:
    konghq.com/plugins: rate-limiting-example
    kubernetes.io/ingress.class: kong

plugins:
- name: rate-limiting
  consumer: CONSUMER_NAME|CONSUMER_ID
  config: 
    second: 5
    hour: 10000
    policy: local

curl -X POST http://localhost:8001/plugins/ \
  --data "name=rate-limiting"  \
    --data "config.second=5" \
    --data "config.hour=10000" \
    --data "config.policy=local"

apiVersion: configuration.konghq.com/v1
kind: KongClusterPlugin
metadata:
  name: <global-rate-limiting>
  annotations:
    kubernetes.io/ingress.class: kong
  labels:
    global: \"true\"
config: 
  second: 5
  hour: 10000
  policy: local
plugin: rate-limiting

plugins:
- name: rate-limiting
  config: 
    second: 5
    hour: 10000
    policy: local

Parameters

Here's a list of all the parameters which can be used in this plugin's configuration:

Headers sent to the client

When this plugin is enabled, Kong sends additional headers to show the allowed limits, number of available requests, and the time remaining (in seconds) until the quota is reset. Here’s an example header:

RateLimit-Limit: 6
RateLimit-Remaining: 4
RateLimit-Reset: 47

The plugin also sends headers to show the time limit and the minutes still available:

X-RateLimit-Limit-Minute: 10
X-RateLimit-Remaining-Minute: 9

If more than one time limit is set, the header contains all of these:

X-RateLimit-Limit-Second: 5
X-RateLimit-Remaining-Second: 4
X-RateLimit-Limit-Minute: 10
X-RateLimit-Remaining-Minute: 9

When a limit is reached, the plugin returns an HTTP/1.1 429 status code, with the following JSON body:

{ "message": "API rate limit exceeded" }

Warning: The headers RateLimit-Limit, RateLimit-Remaining, and RateLimit-Reset are based on the Internet-Draft RateLimit Header Fields for HTTP. These could change if the specification is updated.

Implementation considerations

The plugin supports three policies.

Two common use cases are:

1. Every transaction counts. The highest level of accuracy is needed. An example is a transaction with financial consequences.
2. Backend protection. Accuracy is not as relevant. The requirement is only to protect backend services from overloading that’s caused either by specific users or by attacks.

Note: Enterprise-Only: The Kong Community Edition of this Rate Limiting plugin does not include Redis Sentinel support. Only Kong Gateway Enterprise customers can use Redis Sentinel with Kong Rate Limiting, enabling them to deliver highly available primary-replica deployments.

Every transaction counts

In this scenario, because accuracy is important, the local policy is not an option. Consider the support effort you might need for Redis, and then choose either cluster or redis.

You could start with the cluster policy, and move to redis if performance reduces drastically.

Do remember that you cannot port the existing usage metrics from the data store to Redis. This might not be a problem with short-lived metrics (for example, seconds or minutes) but if you use metrics with a longer time frame (for example, months), plan your switch carefully.

Backend protection

If accuracy is of lesser importance, choose the local policy. You might need to experiment a little before you get a setting that works for your scenario. As the cluster scales to more nodes, more user requests are handled. When the cluster scales down, the probability of false negatives increases. So, adjust your limits when scaling.

For example, if a user can make 100 requests every second, and you have an equally balanced 5-node Kong cluster, setting the local limit to something like 30 requests every second should work. If you see too many false negatives, increase the limit.

To minimise inaccuracies, consider using a consistent-hashing load balancer in front of Kong. The load balancer ensures that a user is always directed to the same Kong node, thus reducing inaccuracies and preventing scaling problems.

Fallback to IP

When the selected policy cannot be retrieved, the plugin falls back to limiting usage by identifying the IP address. This can happen for several reasons, such as the selected header was not sent by the client or the configured service was not found.

Changelog

Kong Gateway 2.8.x

• Added the redis_username configuration parameter.

Kong Gateway 2.7.x

• Added the redis_ssl, redis_ssl_verify, and redis_server_name configuration parameters.