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
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. |
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 is used when aggregating the limits. Available values are:
If the entity value for aggregating the limits cannot be determined, the system falls back to |
config.header_name
semi-optional Type: string |
Header name to be used if |
config.path
semi-optional Type: string |
Path to be used if |
config.policy
optional Type: string Default value: local
|
The rate-limiting policies to use for retrieving and incrementing the limits. Available values are:
In DB-less and hybrid modes, the In Konnect, the default policy is 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 data store. If |
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 |
config.redis_port
optional Type: integer Default value: 6379
|
When using the |
config.redis_username
optional Type: string |
When using the This requires Redis v6.0.0+. The username cannot be set to This field is referenceable, which means it can be securely stored as a secret in a vault. References must follow a specific format. |
config.redis_password
optional Type: string |
When using the This field is referenceable, which means it can be securely stored as a secret in a vault. References must follow a specific format. |
config.redis_ssl
required Type: boolean Default value: false
|
When using the |
config.redis_ssl_verify
required Type: boolean Default value: false
|
When using the |
config.redis_server_name
optional Type: string |
When using the |
config.redis_timeout
optional Type: number Default value: 2000
|
When using the |
config.redis_database
optional Type: integer Default value: 0
|
When using the |
config.error_code
optional Type: number Default value: 429
|
Set a custom error code to return when the rate limit is exceeded. |
config.error_message
optional Type: string Default value: rate limit exceeded
|
Set a custom error message to return when the rate limit is exceeded. |
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
, andRateLimit-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 | |
---|---|---|---|
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. | |
cluster |
Accurate, no extra components to support. | Each request forces a read and a write on the data store. 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. |
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 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 3.1.x
- Added the ability to customize the error code and message with
the configuration parameters
error_code
anderror_message
.
Kong Gateway 2.8.x
- Added the
redis_username
configuration parameter.
Kong Gateway 2.7.x
- Added the
redis_ssl
,redis_ssl_verify
, andredis_server_name
configuration parameters.