GigaOm Benchmark: Kong API Gateway v2

This report, commissioned by Kong and independently conducted by GigaOm’s analysts and engineers, compares Kong Gateway with several leading API gateways across a range of real-world, high-demand environments. The report focuses on performance, scalability, and extensibility—key concerns for technical architects, developers, and engineers responsible for choosing the best gateway for their organization.

APIs power modern business interactions, connecting customers, applications, and back-end systems. They make API performance a foundational concern for developers and architects alike. High-throughput, low-latency APIs are essential to support distributed architectures, microservices, and AI-driven workloads.

The shift toward multicloud and hybrid cloud architectures has amplified the demand for a platform-agnostic API gateway that can operate flexibly across different infrastructures without compromising performance or governance. Kong Gateway meets this challenge by offering superior throughput (as revealed in our testing), native plugin support, and ease of integration with existing infrastructure. Its centralized API governance enables consistent management across platforms, making Kong a strong choice for organizations that want to future-proof their API strategy.

The Need for Centralized API Governance

As enterprises scale their architectures and expand into multicloud or hybrid environments, managing APIs becomes increasingly complex. Without a centralized API governance solution, businesses face the risk of inconsistent security policies, operational silos, and higher costs from maintaining multiple API gateways for each platform.

Many cloud-native API gateways, such as AWS API Gateway and Azure API Management, limit flexibility by tethering businesses to specific platforms. This can hinder multicloud strategies and increase the technical expertise required to operate each solution efficiently. Kong Gateway avoids these pitfalls with its platform-agnostic architecture, offering centralized management for APIs regardless of their deployment location. This approach simplifies API management, reduces operational complexity, and makes security policies more consistent.

Competitors Tested

In this report, we tested Kong Gateway against a variety of API gateway solutions, including both self-managed and cloud-hosted platforms:

• Kong Gateway

• Tyk API Gateway

• MuleSoft Anypoint Flex Gateway

• AWS API Gateway

• Azure API Management (self-hosted and managed)

• Apigee X (failed to perform)*

• Apigee Hybrid (failed to acquire)*

• Gravitee (failed to deploy)*

The purpose of these tests was to assess each solution’s performance in terms of throughput, latency, and scalability, under realistic conditions that reflect enterprise environments.

* Two competitors were incompatible with our test architecture – as Apigee X was only available in Google Cloud, our load generator and upstream used for all other tests was hosted in AWS and this resulted in an excessively long round-trip time and an inconsistent architecture to the rest of the tests. Google does offer a hybrid gateway version of their gateway, Apigee Hybrid, but this is only available to customers on invoiced billing and who consume a minimum of $40,000 per year on GCP, which our tenant did not meet. This prevented us from acquiring Apigee Hybrid. Gravitee’s gateway simply failed to deploy following the publisher’s own deployment guidance and multiple hours of troubleshooting. Our time-boxed testing prevented Gravitee from being included in the performance results.

Test Setup and Rationale

To ensure transparency and repeatability, we used a consistent and reliable setup designed to isolate the performance of each API gateway. Figure 1 shows the test architecture we employed, while Table 1 details the hardware configuration.

Figure 1. Test Architecture

• Upstream API: We used a stateless NGINX node as the upstream service to minimize the impact of the backend and ensure our tests measured only the performance of the API gateway itself.

• Load generation: Grafana K6 was chosen as the load generator for its ability to simulate realistic traffic loads through virtual users (VUs). This allowed us to measure how each API gateway scales with increasing load.

• Observability: Metrics were collected using Prometheus and visualized through Grafana, providing real-time insights into throughput, latency, and system performance.

Table 1. Hardware Configuration

Note that the test infrastructure was deliberately overprovisioned to eliminate bottlenecks in the load generator and upstream API. This allowed us to isolate the true performance of the API gateways without interference from other system components.

Performance Test 1: Maximum Throughput (Basic Proxy)

In this test, we measured the maximum throughput each API gateway could achieve when configured as a basic HTTP proxy. By using this stripped-down configuration, we focused solely on the raw performance of the gateway without any additional features like authentication or rate-limiting enabled.

Kong Gateway outperformed all competitors, processing 151,800 requests per second (rps)—nearly double the throughput of the second-best performer, Tyk, which managed 76,800 rps. AWS API Gateway and Azure API Management (self-managed) were limited by their cloud-native constraints, capping throughput at around 50,000 rps and 24,000 rps, respectively. See Figure 2.

Figure 2. Maximum Requests per Second by API (Basic Proxy)

Gravitee produced deployment issues that prevented us from capturing meaningful performance data. Similarly, Apigee X fell significantly below expectations, processing only 1,890 rps due to architectural complexity and setup challenges.

Performance Test 2: Latency at Maximum Load

Latency plays a critical role in scenarios where low response times are needed to maintain a good user experience. To assess this, we tested each gateway’s latency while operating at maximum throughput. While Tyk had the lowest latency in this test, it’s worth noting that it only achieved this latency at approximately half the throughput of Kong. Kong outperforms each competitor in latency when normalized for throughput, as demonstrated in performance test 3.

Figure 3. Request Latency at Maximum Throughput

Performance Test 3: Throughput-Normalized Latency

In performance test 2, we saw Kong’s overall latency increase to 4.92 milliseconds, while CPU was not completely consumed on any of the pods in our testing cluster. This is likely due to Kong Gateway exceeding the performance of AWS VPC’s packet forwarding ability at the extreme level of request throughput we were able to achieve. In order to demonstrate that Kong Gateway achieves the lowest latency at comparable throughput, we limited our load generation to match the capabilities of the next-best competitor, Tyk’s 76,800 requests per second. This results in a P99 latency of 1.12 ms and a p95 latency of 0.55 ms. At the same throughput, Kong demonstrated 5.4x lower latency on the same hardware.

Figure 4. Latency at Normalized Throughput

In Figure 4, it’s important to contextualize the relationship between latency and throughput. As an API reaches its maximum throughput, latency will increase as the system’s CPU, memory, and network stack become more and more taxed. Each of these APIs can perform with lower latency than demonstrated here, but also lower throughput. As the range of throughput is so great here, there isn’t a reasonable equivalent comparison between the APIs to demonstrate responsiveness across the whole lineup, however we can draw a simple conclusion: Kong Gateway has the lowest latency at the maximum throughput any competitor could achieve.

Performance Test 4: Rate-Limited with Key Authentication

Unsecured APIs demonstrate the baseline performance of a gateway’s underlying tech stack, but they aren’t a great real-world example of a secure API. To test the performance impact of enabling authentication plugins, we benchmarked each API with key authentication and rate-limiting enabled. The rate limit was set above the maximum throughput threshold to identify its performance impact without arbitrarily limiting the throughput itself.

Kong Gateway led in throughput once again, handling 127% more requests than AWS API Gateway and 136% more than Tyk under comparable configurations.

Table 2. Results with Key Authentication Enabled

Figure 5. Performance with Plugins Enabled

Figure 5. Shows that Kong Gateway maintains its performance advantage even with key authentication enabled, supporting nearly 120,000 requests per second, more than double the next closest competitor, and higher still than any competitor’s unauthenticated throughput.

Competitor Retrospective

Kong Gateway outperforms its competitors in every test; it provides the lowest latency, highest throughput, and most flexible deployment options. Each of the competitors came with a series of limitations:

• AWS API Gateway: Only compatible with AWS-native workloads in organizations that don’t plan on hosting hybrid or multicloud workloads. Its performance is limited by rate caps, and its reliance on external hooks like Lambda to handle basic features like authentication introduces latency and operational overhead.

• Azure API Management: Only compatible with small, Azure-only workloads. While the self-hosted version of the Azure API gateway supports flexible deployment options, it is limited in throughput and would require a fleet of API instances to match the same throughput as a single Kong instance.

• Apigee Hybrid and Apigee X: Only compatible with organizations exclusively operating on GCP with no plans to deploy workloads to other clouds. We were unable to acquire Apigee Hybrid as it was the only solution that required a multi-year commitment and invoiced billing through Google, which comes with a minimum spend of $40,000 per year on GCP. Testing Apigee X with our AWS-based load generator and upstream API resulted in abysmal performance that would not be a fair comparison.

• Tyk API Gateway: Performed well against cloud-native offerings; however, there was still no contest for the raw throughput achieved using Kong Gateway.

• MuleSoft Anypoint Flex Gateway: Tightly integrates with the Salesforce ecosystem, but its throughput and latency performance are middle of the road compared to other solutions.

Gravitee: We spent multiple days troubleshooting our deployment of Gravitee’s gateway and could not get it to run our tests. Our time-boxed testing prevented Gravitee from being included in the performance results.

For organizations seeking to manage high-performance APIs in multicloud or hybrid environments, Kong Gateway clearly leads the pack. Its scalability, platform-agnostic nature, and native plugin architecture make it a superior choice for technical architects and engineers tasked with maintaining both performance and governance across distributed infrastructures.

Kong’s throughput, low latency, and seamless integration with existing systems make it the most capable solution for enterprises with mission-critical API workloads.

Observability

Our load generation and observability host is configured using the following Docker Compose configuration:

# docker-compose.yaml
networks:
k6:
services:
prometheus:
image: prom/prometheus:latest
command:
- --web.enable-remote-write-receiver
- --enable-feature=native-histograms
- --config.file=/etc/prometheus/prometheus.yml
networks:
- k6
ports:
- "9090:9090"
grafana:
image: grafana/grafana:10.1.2
networks:
- k6
ports:
- "80:3000"
environment:
- GF_AUTH_ANONYMOUS_ORG_ROLE=Admin
- GF_AUTH_ANONYMOUS_ENABLED=true
- GF_AUTH_BASIC_ENABLED=false
volumes:
- ./grafana:/etc/grafana/provisioning/
- ./grafana/dashboards:/var/lib/grafana/dashboards

We can then access Grafana through our observability host’s public IP on port 80. Once inside Grafana, we navigate to Connections > Data Sources and add a Prometheus data source using the docker-internal IP of our Prometheus container. We can find this using `sudo docker inspect observability-prometheus-1’.

Once the Prometheus data source is configured, we add the Prometheus (Native Histograms) dashboard using its Grafana dashboard ID of 19665. https://grafana.com/grafana/dashboards/19665-k6-prometheus/

Upstream API

We installed NGINX on our upstream API server with the following configuration modifications:

# /etc/nginx/nginx.conf
worker_processes auto;
…
access_log off;
…
http {
include /etc/nginx/conf.d/*.conf;
…
}
# /etc/nginx/conf.d/default.conf
server {
listen 80;
location / {
return 200 ’Success’;
}
location ~ /$ {
return 200 ’Success’;
}
}

With these configurations in place, the upstream API will respond with a 200 status code for any http request to any path.

Load Generation

We leverage a Docker Compose script to invoke a K6 container with a number of environment variables.

# docker-compose.yaml
networks:
observability_k6:
external: true
services:
k6:
image: grafana/k6:latest
networks:
- observability_k6
ports:
- "6565:6565"
command: run -o experimental-prometheus-rw /scripts/${API:-direct}.js --tag testid=${API}-${K6_VUS:-100}-${AUTH:-false}
environment:
- K6_PROMETHEUS_RW_SERVER_URL=http://172.18.0.2:9090/api/v1/write
- K6_PROMETHEUS_RW_TREND_STATS=p(95),p(99),min,max
- K6_PROMETHEUS_RW_TREND_AS_NATIVE_HISTOGRAM=true
- K6_VUS=${K6_VUS:-100}
- K6_DURATION=${K6_DURATION:-120s}
- AUTH=${AUTH:-false}
volumes:
- ./scripts:/scripts/

We can invoke K6 for a given API using this example command on the observability/load generation host:

AUTH=true API=kong docker compose run k6

We organized our K6 scripts into a folder with a JavaScript file defined for each target API, as some APIs have unique configurations beyond a URL change.

This example would run an example Kong test script with 100 virtual users (VUs) for 2 minutes and include an authorization token.

# ./scripts/kong.js
import http from 'k6/http';
import { check } from 'k6';
import encoding from 'k6/encoding';
const config_size = __ENV.ENTITY_CONFIG_SIZE || 1;
let url = 'http://10.0.0.27:8000/test/';
export const options = {
vus: __ENV.K6_VUS || 400,
duration: __ENV.k6_DURATION || '120s',
summaryTrendStats: ['avg', 'min', 'med', 'max', 'p(90)', 'p(95)', 'p(99)', 'count'],
};
export default function () {
if (__ENV.AUTH == 'true')
{
let res = http.get(url, { timeout: '180s', headers: {'Authorization':'<token>'} });
check(res, {
'Kong Proxy with Auth: 200': (r) => r.status === 200,
});
}
else
{
let res = http.get(url, { timeout: '180s' });
check(res, {
'Kong Proxy: 200': (r) => r.status === 200,
});
}
}

Note that for non-authorized requests, the APIs themselves must be configured out-of-band from the load generation utility to enable plugins and/or policies for rate limiting and authorization.

We can also execute tests that run multiple stages by configuring the const_options block, like so:

export const options = {
stages: [
{ duration: '5s', target: 300 },
{ duration: '900s', target: 1000 },
],
thresholds: {
http_req_failed: ['rate<0.01'],
http_req_duration: ['p(99)<50'],
},
summaryTrendStats: ['avg', 'min', 'med', 'max', 'p(90)', 'p(95)', 'p(99)', 'count'],

Howard Holton is an analyst at GigaOm. He has worked in IT for three decades, the last half in executive leadership, as a CIO and CTO. He has been an engineer, an architect, and a leader in telecom, health care, automotive, retail, legal, and technology.

In the last decade, Howard focused on cloud technology and economics, data analytics, and digital transformation. As CTO of Hitachi Vantara, he spent his time developing digital transformation, IT, and data strategies for Fortune 1000 companies and global governments.

His years at Rheem Manufacturing, Hitachi Vantara, and others provided the experience that helped him develop a mind for leadership—the successful execution of vision and culture to inspire. Successful leadership is all about maximizing your team’s potential, as Howard has demonstrated over the course of his career.

Howard is also a technologist at heart; passionate about how data science and new technologies can be used to accelerate time-to-market and better serve the customer, now and in the future. Howard has been a trusted advisor and agent of change to a number of organizations, bringing vision and successful execution to internal and external customers alike.

GigaOm provides technical, operational, and business advice for IT’s strategic digital enterprise and business initiatives. Enterprise business leaders, CIOs, and technology organizations partner with GigaOm for practical, actionable, strategic, and visionary advice for modernizing and transforming their business. GigaOm’s advice empowers enterprises to successfully compete in an increasingly complicated business atmosphere that requires a solid understanding of constantly changing customer demands.

GigaOm works directly with enterprises both inside and outside of the IT organization to apply proven research and methodologies designed to avoid pitfalls and roadblocks while balancing risk and innovation. Research methodologies include but are not limited to adoption and benchmarking surveys, use cases, interviews, ROI/TCO, market landscapes, strategic trends, and technical benchmarks. Our analysts possess 20+ years of experience advising a spectrum of clients from early adopters to mainstream enterprises.

GigaOm’s perspective is that of the unbiased enterprise practitioner. Through this perspective, GigaOm connects with engaged and loyal subscribers on a deep and meaningful level.

© Knowingly, Inc. 2025 "GigaOm Benchmark: Kong API Gateway" is a trademark of Knowingly, Inc. For permission to reproduce this report, please contact sales@gigaom.com.