Rate limit how many HTTP requests a developer can make 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.
Note: The functionality of this plugin as bundled
with versions of Kong prior to 0.13.1 and Kong Gateway prior to 0.32
differs from what is documented herein. Refer to the
CHANGELOG
for details.
Configuration Reference
Example plugin configuration
Enable on a service
Enable on a route
Enable on a consumer
Enable globally
The following examples provide some typical configurations for enabling
the rate-limiting
plugin on a
service.
Admin API
Kubernetes
Declarative (YAML)
Konnect Cloud
Kong Manager
Make the following request:
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"
Replace SERVICE_NAME|SERVICE_ID
with the id
or name
of the service that this plugin configuration will target.
First, create a KongPlugin
resource:
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
name: rate-limiting-example
config:
second: 5
hour: 10000
policy: local
plugin: rate-limiting
Next, apply the KongPlugin resource to a
service by annotating the
service as follows:
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
Replace SERVICE_NAME|SERVICE_ID
with the id
or name
of the service that this plugin configuration will target.
Note: The KongPlugin resource only needs to be defined once
and can be applied to any service, consumer, or route in the namespace. If you
want the plugin to be available cluster-wide, create the resource as a
KongClusterPlugin
instead of KongPlugin
.
Add this section to your declarative configuration file:
plugins:
- name: rate-limiting
service: SERVICE_NAME|SERVICE_ID
config:
second: 5
hour: 10000
policy: local
Replace SERVICE_NAME|SERVICE_ID
with the id
or name
of the service that this plugin configuration will target.
You can configure this plugin through the Konnect UI.
From the
Service Hub, select a service version, then set up the plugin:
- In the Plugins section, click Add Plugin.
- Find and select the Rate Limiting plugin.
- Click Create.
You can configure this plugin through the Kong Manager UI.
- In Kong Manager, select the workspace.
- From the Services section, click View for the
service row.
- From the plugin section, click Add Plugin.
- Find and select the Rate Limiting plugin.
- If the option is available, select Scoped.
- Add the service name and ID to the Service field if it
is not already pre-filled.
- Click Create.
The following examples provide some typical configurations for enabling
the rate-limiting
plugin on a
route.
Admin API
Kubernetes
Declarative (YAML)
Konnect Cloud
Kong Manager
Make the following request:
$ 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"
Replace ROUTE_NAME|ROUTE_ID
with the id
or name
of the route that this plugin configuration will target.
First, create a KongPlugin
resource:
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
name: rate-limiting-example
config:
second: 5
hour: 10000
policy: local
plugin: rate-limiting
Then, apply it to an ingress (route or routes)
by annotating the ingress as follows:
apiVersion: networking/v1beta1
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:
serviceName: echo
servicePort: 80
Replace ROUTE_NAME|ROUTE_ID
with the id
or name
of the route that this plugin configuration will target.
Note: The KongPlugin resource only needs to be defined once
and can be applied to any service, consumer, or route in the namespace. If you
want the plugin to be available cluster-wide, create the resource as a
KongClusterPlugin
instead of KongPlugin
.
Add this section to your declarative configuration file:
plugins:
- name: rate-limiting
route: ROUTE_NAME
config:
second: 5
hour: 10000
policy: local
Replace ROUTE_NAME|ROUTE_ID
with the id
or name
of the route that this plugin configuration
will target.
You can configure this plugin through the Konnect UI.
From the
Service Hub, select a service version, then set up the plugin:
- Select a route.
- In the Plugins section, click Add Plugin.
- Find and select the Rate Limiting plugin.
- Click Create.
You can configure this plugin through the Kong Manager UI.
- In Kong Manager, select the workspace.
- Open Routes from the menu, then click View for the
route row.
- From the plugin section, click Add Plugin.
- Find and select the Rate Limiting plugin.
- If the option is available, select Scoped.
- Add the route ID if it is not already prefilled.
- Click Create.
The following examples provide some typical configurations for enabling
the rate-limiting
plugin on a
consumer.
Admin API
Kubernetes
Declarative (YAML)
Kong Manager
Make the following request:
$ 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"
Replace CONSUMER_NAME|CONSUMER_ID
with the id
or name
of the consumer that this plugin configuration will target.
You can combine consumer.id
, service.id
, or route.id
in the same request, to further narrow the scope of the plugin.
First, create a KongPlugin
resource:
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
name: rate-limiting-example
config:
second: 5
hour: 10000
policy: local
plugin: rate-limiting
Then, apply it to a consumer by
annotating the KongConsumer resource as follows:
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
Replace CONSUMER_NAME|CONSUMER_ID
with the id
or name
of the consumer that this plugin configuration will target.
Note: The KongPlugin resource only needs to be defined once
and can be applied to any service, consumer, or route in the namespace. If you
want the plugin to be available cluster-wide, create the resource as a
KongClusterPlugin
instead of KongPlugin
.
Add this section to your declarative configuration file:
plugins:
- name: rate-limiting
consumer: CONSUMER_NAME|CONSUMER_ID
config:
second: 5
hour: 10000
policy: local
Replace CONSUMER_NAME|CONSUMER_ID
with the id
or name
of the consumer that this plugin configuration will target.
You can configure this plugin through the Kong Manager UI.
- In Kong Manager, select the workspace.
- From the Consumers section, click View for the consumer row.
- Select the Plugins tab, then click Add Plugin.
- Find and select the Rate Limiting plugin.
- If the option is available, select Scoped.
- Add the consumer ID if it is not already prefilled.
- Click Create.
A plugin which is not associated to any service, route, or consumer is
considered global, and will be run on every request. Read the
Plugin Reference and the Plugin Precedence
sections for more information.
The following examples provide some typical configurations for enabling
the rate-limiting
plugin globally.
Admin API
Kubernetes
Declarative (YAML)
Kong Manager
Make the following request:
$ curl -X POST http://localhost:8001/plugins/ \
--data "name=rate-limiting" \
--data "config.second=5" \
--data "config.hour=10000" \
--data "config.policy=local"
Create a KongClusterPlugin
resource and label it as global:
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
Add a plugins
entry in the declarative
configuration file:
plugins:
- name: rate-limiting
config:
second: 5
hour: 10000
policy: local
You can configure this plugin through the Kong Manager UI.
- In Kong Manager, select the workspace.
- Open Plugins from the menu, then click New Plugin.
- Find and select the Rate Limiting plugin.
- If the option is available, set the plugin scope to Global.
- Click Create.
Parameters
Here's a list of all the parameters which can be used in this plugin's configuration:
Form Parameter |
Description |
name
required
Type: string |
The name of the plugin, in this case rate-limiting . |
service.name or service.id
Type: string |
The name or ID of the service the plugin targets.
Set one of these parameters if adding the plugin to a service through the top-level /plugins endpoint.
Not required if using /services/SERVICE_NAME|SERVICE_ID/plugins . |
route.name or route.id
Type: string |
The name or ID of the route the plugin targets.
Set one of these parameters if adding the plugin to a route through the top-level /plugins endpoint.
Not required if using /routes/ROUTE_NAME|ROUTE_ID/plugins . |
consumer.name or consumer.id
Type: string |
The name or ID of the consumer the plugin targets.
Set one of these parameters if adding the plugin to a consumer through the top-level /plugins endpoint.
Not required if using /consumers/CONSUMER_NAME|CONSUMER_ID/plugins . |
enabled
Type: boolean
Default value: true |
Whether this plugin will be applied. |
api_id
Type: string |
The ID of the API the plugin targets.
Note: The API Entity is deprecated in favor of Services since CE 0.13.0 and EE 0.32. |
config.second
semi-optional
|
The amount of HTTP requests the developer can make per second. At least one limit must exist.
|
config.minute
semi-optional
|
The amount of HTTP requests the developer can make per minute. At least one limit must exist.
|
config.hour
semi-optional
|
The amount of HTTP requests the developer can make per hour. At least one limit must exist.
|
config.day
semi-optional
|
The amount of HTTP requests the developer can make per day. At least one limit must exist.
|
config.month
semi-optional
|
The amount of HTTP requests the developer can make per month. At least one limit must exist.
|
config.year
semi-optional
|
The amount of HTTP requests the developer can make per year. At least one limit must exist.
|
config.limit_by
optional
Default value: consumer
|
The entity that will be used when aggregating the limits: consumer , credential , ip . If the consumer or the credential cannot be determined, the system will always fallback to ip .
|
config.policy
optional
Default value: cluster
|
The rate-limiting policies to use for retrieving and incrementing the limits. Available values are local (counters will be stored locally in-memory on the node), cluster (counters are stored in the datastore and shared across the nodes) and redis (counters are stored on a Redis server and will be shared across the nodes). In case of DB-less mode, at least one of local or redis must be specified. Please refer Implementation Considerations for details on which policy should be used.
|
config.fault_tolerant
optional
Default value: true
|
A boolean value that determines if the requests should be proxied even if Kong has troubles connecting a third-party datastore. If true requests will be proxied anyways effectively disabling the rate-limiting function until the datastore is working again. If false then the clients will see 500 errors.
|
config.hide_client_headers
optional
Default value: false
|
Optionally hide informative response headers.
|
config.redis_host
semi-optional
|
When using the redis policy, this property specifies the address to the Redis server.
|
config.redis_port
optional
Default value: 6379
|
When using the redis policy, this property specifies the port of the Redis server. By default is 6379 .
|
config.redis_password
optional
|
When using the redis policy, this property specifies the password to connect to the Redis server.
|
config.redis_timeout
optional
Default value: 2000
|
When using the redis policy, this property specifies the timeout in milliseconds of any command submitted to the Redis server.
|
config.redis_database
optional
Default value: 0
|
When using the redis policy, this property specifies Redis database to use.
|
When this plugin is enabled, Kong will send some additional headers back to the client telling how many requests are available and what are the limits allowed, for example:
X-RateLimit-Limit-Minute: 10
X-RateLimit-Remaining-Minute: 9
or it will return a combination of more time limits, if more than one is being set:
X-RateLimit-Limit-Second: 5
X-RateLimit-Remaining-Second: 4
X-RateLimit-Limit-Minute: 10
X-RateLimit-Remaining-Minute: 9
If any of the limits configured is being reached, the plugin will return a HTTP/1.1 429
status code to the client with the following JSON body:
{"message":"API rate limit exceeded"}
Implementation considerations
The plugin supports 3 policies, which each have their specific pros and cons.
policy |
pros |
cons |
cluster |
accurate, no extra components to support |
relatively the biggest performance impact, each request forces a read and a write on the underlying datastore. |
redis |
accurate, lesser performance impact than a cluster policy |
extra redis installation required, bigger performance impact than a local policy |
local |
minimal performance impact |
less accurate, and unless a consistent-hashing load balancer is used in front of Kong, it diverges when scaling the number of nodes |
There are 2 use cases that are most common:
- every transaction counts. These are for example transactions with financial
consequences. Here the highest level of accuracy is required.
- backend protection. This is where accuracy is not as relevant, but it is
merely used to protect backend services from overload. Either by specific
users, or to protect against an attack in general.
NOTE:
Enterprise-Only The Kong Community Edition of this Rate Limiting plugin does not
include
Redis Sentinel support.
Kong Gateway Subscription customers have the option
of using Redis Sentinel with Kong Rate Limiting to deliver highly available primary-replica deployments.
Every transaction counts
In this scenario, the local
policy is not an option. So here the decision is between
the extra performance of the redis
policy against its extra support effort. Based on that balance,
the choice should either be cluster
or redis
.
The recommendation is to start with the cluster
policy, with the option to move over to redis
if performance reduces drastically. Keep in mind existing usage metrics cannot
be ported from the datastore to redis. Generally with shortlived metrics (per second or per minute)
this is not an issue, but with longer lived ones (months) it might be, so you might want to plan
your switch more carefully.
Backend protection
As accuracy is of lesser importance, the local
policy can be used. It might require some experimenting
to get the proper setting. For example, if the user is bound to 100 requests per second, and you have an
equally balanced 5 node Kong cluster, setting the local
limit to something like 30 requests per second
should work. If you are worried about too many false-negatives, increase the value.
Keep in mind as the cluster scales to more nodes, the users will get more requests granted, and likewise
when the cluster scales down the probability of false-negatives increases. So in general, update your
limits when scaling.
The above mentioned inaccuracy can be mitigated by using a consistent-hashing load balancer in front of
Kong, that ensures the same user is always directed to the same Kong node. This will both reduce the
inaccuracy and prevent the scaling issues.
Most likely the user will be granted more than was agreed when using the local
policy, but it will
effectively block any attacks while maintaining the best performance.