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.
Enable the plugin on a service
Admin API
Kubernetes
Declarative (YAML)
Konnect Cloud
Kong Manager
For example, configure this plugin on a service by
making the following request:
curl -X POST http://{HOST}:8001/services/{SERVICE}/plugins \
--data "name=rate-limiting" \
--data "config.second=5" \
--data "config.hour=10000" \
--data "config.policy=local" \
--data "config.fault_tolerant=true" \
--data "config.hide_client_headers=false"
SERVICE
is 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
fault_tolerant: true
hide_client_headers: false
plugin: rate-limiting
Next, apply the KongPlugin resource to a
Service by annotating the
Service as follows:
apiVersion: v1
kind: Service
metadata:
name: {SERVICE}
labels:
app: {SERVICE}
annotations:
konghq.com/plugins: <rate-limiting-example>
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
name: {SERVICE}
selector:
app: {SERVICE}
{SERVICE}
is 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
.
For example, configure this plugin on a service by
adding this section to your declarative configuration file:
plugins:
- name: rate-limiting
service: {SERVICE}
config:
second: 5
hour: 10000
policy: local
fault_tolerant: true
hide_client_headers: false
SERVICE
is the id
or name
of the service that this plugin
configuration will target.
Configure this plugin on a service:
- In Konnect Cloud, select the service on the ServiceHub page.
- Scroll down to Versions and select the version.
- Scroll down to Plugins and click New Plugin.
- Find and select the Rate Limiting plugin.
-
Enter the following parameters, updating the default
or sample values as needed:
- Config.Fault Tolerant: select checkbox
- Config.Hide Client Headers: clear checkbox
- Click Create.
Configure this plugin on a service:
- In Kong Manager, select the workspace.
- From the Dashboard, scroll down to Services and click View for the
service row.
- Scroll down to plugins and click Add Plugin.
-
Find and select the Rate Limiting plugin.
Note: If the plugin is greyed out, then it is not available
for your product tier. See
Kong Gateway tiers.
- If the option is available, select Scoped.
- Add the service name and ID to the Service field if it
is not already prefilled.
-
Enter the following parameters, updating the default or sample values as needed:
- Config.Fault Tolerant: select checkbox
- Config.Hide Client Headers: clear checkbox
- Click Create.
Enable the plugin on a route
Admin API
Kubernetes
Declarative (YAML)
Konnect Cloud
Kong Manager
For example, configure this plugin on a route with:
$ curl -X POST http://{HOST}:8001/routes/{ROUTE}/plugins \
--data "name=rate-limiting" \
--data "config.second=5" \
--data "config.hour=10000" \
--data "config.policy=local" \
--data "config.fault_tolerant=true" \
--data "config.hide_client_headers=false"
ROUTE
is 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
fault_tolerant: true
hide_client_headers: false
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}
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
ROUTE
is 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
.
For example, configure this plugin on a route by
adding this section to your declarative configuration file:
plugins:
- name: rate-limiting
route: <route>
config:
second: 5
hour: 10000
policy: local
fault_tolerant: true
hide_client_headers: false
ROUTE
is the id
or name
of the route that this plugin configuration
will target.
Configure this plugin on a route:
- In Konnect Cloud, select the service from the ServiceHub page.
- Scroll down to Versions and select the version.
- Select the route.
- Scroll down to Plugins and click Add Plugin.
- Find and select the Rate Limiting plugin.
-
Enter the following parameters, updating the default
or sample values as needed:
- Config.Fault Tolerant: select checkbox
- Config.Hide Client Headers: clear checkbox
- Click Create.
Configure this plugin on a route:
- In Kong Manager, select the workspace.
- From the Dashboard, select Routes in the left navigation.
- Click View for the route row.
- Scroll down to plugins and click Add Plugin.
-
Find and select the Rate Limiting plugin.
Note: If the plugin is greyed out, then it is not available
for your product tier. See
Kong Gateway tiers.
- If the option is available, select Scoped.
- Add the Route ID if it is not already prefilled.
-
Enter the following parameters, updating the default
or sample values as needed:
- Config.Fault Tolerant: select checkbox
- Config.Hide Client Headers: clear checkbox
- Click Create.
Enabling the plugin on a consumer
Admin API
Kubernetes
Declarative (YAML)
Kong Manager
For example, configure this plugin on a consumer with:
$ curl -X POST http://{HOST}:8001/consumers/{CONSUMER}/plugins \
--data "name=rate-limiting" \
--data "config.second=5" \
--data "config.hour=10000" \
--data "config.policy=local" \
--data "config.fault_tolerant=true" \
--data "config.hide_client_headers=false"
CONSUMER
is the id
or username
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
fault_tolerant: true
hide_client_headers: false
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}
annotations:
konghq.com/plugins: <rate-limiting-example>
kubernetes.io/ingress.class: kong
CONSUMER
is the id
or username
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
.
For example, configure this plugin on a consumer by
adding this section to your declarative configuration file:
plugins:
- name: rate-limiting
consumer: {CONSUMER}
config:
second: 5
hour: 10000
policy: local
fault_tolerant: true
hide_client_headers: false
CONSUMER
is the id
or username
of the consumer that this plugin
configuration will target.
Configure this plugin on a consumer:
- In Kong Manager, select the workspace.
- From the Dashboard, scroll down to Consumers and click View for the consumer row.
- Select the Plugins tab.
- Click Add Plugin.
-
Find and select the Rate Limiting plugin.
Note: If the plugin is greyed out, then it is not available
for your product tier. See
Kong Gateway tiers.
- If the option is available, select Global.
-
Enter the following parameters, updating the default or sample values as needed:
- Config.Fault Tolerant: select checkbox
- Config.Hide Client Headers: clear checkbox
- Click Create.
Enable the plugin globally
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.
Admin API
Kubernetes
Declarative (YAML)
Kong Manager
For example, configure this plugin globally with:
$ curl -X POST http://{HOST}:8001/plugins/ \
--data "name=rate-limiting" \
--data "config.second=5" \
--data "config.hour=10000" \
--data "config.policy=local" \
--data "config.fault_tolerant=true" \
--data "config.hide_client_headers=false"
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
fault_tolerant: true
hide_client_headers: false
plugin: rate-limiting
For example, configure this plugin using the plugins:
entry in the declarative
configuration file:
plugins:
- name: rate-limiting
config:
second: 5
hour: 10000
policy: local
fault_tolerant: true
hide_client_headers: false
Configure this plugin globally:
- In Kong Manager, select the workspace.
- From the Dashboard, select Plugins in the left navigation.
- Click New Plugin.
-
Find and select the Rate Limiting plugin.
Note: If the plugin is greyed out, then it is not available
for your product tier. See
Kong Gateway tiers.
- If the option is available, set the plugin scope to Global.
-
Enter the following parameters, updating the
default/sample values as needed:
- Config.Fault Tolerant: select checkbox
- Config.Hide Client Headers: clear checkbox
- 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.id
Type: string |
The ID of the Service the plugin targets. |
route.id
Type: string |
The ID of the Route the plugin targets. |
consumer.id
Type: string |
The ID of the Consumer the plugin targets. |
enabled
required
Type: boolean
Default value: true |
Whether this plugin will be applied. |
config.second
semi-optional
Type: number
|
The number of HTTP requests that can be made per second.
|
config.minute
semi-optional
Type: number
|
The number of HTTP requests that can be made per minute.
|
config.hour
semi-optional
Type: number
|
The number of HTTP requests that can be made per hour.
|
config.day
semi-optional
Type: number
|
The number of HTTP requests that can be made per day.
|
config.month
semi-optional
Type: number
|
The number of HTTP requests that can be made per month.
|
config.year
semi-optional
Type: number
|
The number of HTTP requests that can be made per year.
|
config.limit_by
optional
Type: string
Default value: consumer
|
The entity that will be used when aggregating the limits: consumer , credential , ip , service , header , path . If the value for the entity chosen to aggregate the limit cannot be determined, the system will always fallback to ip . If value service is chosen, the service_id configuration must be provided. If value header is chosen, the header_name configuration must be provided. If value path is chosen, the path configuration must be provided.
|
config.service_id
semi-optional
Type: string
|
The service id to be used if limit_by is set to service .
|
config.header_name
semi-optional
Type: string
|
Header name to be used if limit_by is set to header .
|
config.path
semi-optional
Type: string
|
Path to be used if limit_by is set to path .
|
config.policy
optional
Type: string
Default value: cluster
|
The rate-limiting policies to use for retrieving and incrementing the
limits. Available values are:
local : Counters are stored locally in-memory on the node.
cluster : Counters are stored in the Kong datastore and shared across
the nodes.
redis : Counters are stored on a Redis server and shared
across the nodes.
In DB-less and hybrid modes, the cluster config policy is not supported.
For DB-less mode, use one of redis or local ; for hybrid mode, use
redis , or local for data planes only.
In Konnect Cloud, the default policy is redis .
For details on which policy should be used, refer to the
implementation considerations.
|
config.fault_tolerant
required
Type: boolean
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 anyway, 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
required
Type: boolean
Default value: false
|
Optionally hide informative response headers.
|
config.redis_host
semi-optional
Type: string
|
When using the redis policy, this property specifies the address to the Redis server.
|
config.redis_port
optional
Type: integer
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
Type: string
|
When using the redis policy, this property specifies the password to connect to the Redis server.
|
config.redis_timeout
optional
Type: number
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
Type: integer
Default value: 0
|
When using the redis policy, this property specifies the Redis database to use.
|
Note: At least one limit (`second`, `minute`, `hour`, `day`, `month`, `year`) must be configured. Multiple limits can be configured.
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.
Policy |
Pros |
Cons |
cluster |
Accurate, no extra components to support. |
Each request forces a read and a write on the datastore. Therefore, relatively, the biggest performance impact. |
redis |
Accurate, less performance impact than a cluster policy. |
Needs a Redis installation. Bigger performance impact than a local policy. |
local |
Minimal performance impact. |
Less accurate. Unless there’s a consistent-hashing load balancer in front of Kong, it diverges when scaling the number of nodes. |
Two common use cases are:
- Every transaction counts. The highest level of accuracy is needed. An example is a transaction with financial
consequences.
- 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 Subscription 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 datastore to Redis.
This might not be a problem with shortlived 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.