This is an automated email from the ASF dual-hosted git repository.
Yilialinn pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/apisix-website.git
The following commit(s) were added to refs/heads/master by this push:
new 326e5ee6ed3 content: improve GSC-priority on-page SEO (#2107)
326e5ee6ed3 is described below
commit 326e5ee6ed39d355196ec6cb4b5aac17fd510546
Author: Yilia Lin <[email protected]>
AuthorDate: Mon Aug 24 18:07:24 2026 +0800
content: improve GSC-priority on-page SEO (#2107)
---
blog/en/blog/2023/10/18/ingress-apisix.md | 4 +-
.../learning-center/api-gateway-rate-limiting.md | 28 ++++----
website/learning-center/api-gateway-security.md | 52 +++++++--------
website/learning-center/kubernetes-api-gateway.md | 42 ++++++------
.../open-source-api-gateway-comparison.md | 76 ++++++++++------------
website/learning-center/what-is-an-api-gateway.md | 2 +-
6 files changed, 98 insertions(+), 106 deletions(-)
diff --git a/blog/en/blog/2023/10/18/ingress-apisix.md
b/blog/en/blog/2023/10/18/ingress-apisix.md
index 0eec81ff17b..00bb0aabad4 100644
--- a/blog/en/blog/2023/10/18/ingress-apisix.md
+++ b/blog/en/blog/2023/10/18/ingress-apisix.md
@@ -1,5 +1,5 @@
---
-title: "Embrace the Lightweight APISIX Ingress Controller Without etcd
Dependency"
+title: "APISIX Ingress Controller 1.7 Without etcd"
authors:
- name: "Xin Rong"
title: "Author"
@@ -18,7 +18,7 @@ tags: [Community]
image: https://static.apiseven.com/2022/10/19/634f6677742a1.png
---
-> The innovative architecture of the APISIX Ingress Controller eliminates the
dependency on a standalone etcd cluster, greatly simplifying maintenance costs
and system complexity.
+> This article describes the APISIX Ingress Controller architecture introduced
in v1.7.0, which removed the need to operate a separate etcd cluster for the
ingress deployment.
<!--truncate-->
diff --git a/website/learning-center/api-gateway-rate-limiting.md
b/website/learning-center/api-gateway-rate-limiting.md
index 51df5891c4d..940b258b4e5 100644
--- a/website/learning-center/api-gateway-rate-limiting.md
+++ b/website/learning-center/api-gateway-rate-limiting.md
@@ -1,19 +1,19 @@
---
-title: "API Gateway Rate Limiting: Algorithms, Strategies & Configuration"
-description: "Understand API rate limiting at the gateway layer. Covers token
bucket, sliding window, and leaky bucket algorithms with practical
configuration examples."
+title: "API Gateway Rate Limiting: Algorithms"
+description: "Understand gateway rate limiting, including token bucket,
sliding window, leaky bucket, quotas, distributed counters, and client response
guidance."
slug: api-gateway-rate-limiting
date: 2026-04-14
tags: [rate-limiting, traffic-control, api-gateway]
hide_table_of_contents: false
---
-API gateway rate limiting is the practice of controlling how many requests a
client can make to your API within a defined time window. Implemented at the
gateway layer, rate limiting protects backend services from overload, prevents
abuse, ensures fair resource allocation across consumers, and maintains
predictable service quality under variable traffic conditions.
+API gateway rate limiting controls how many requests a client can make within
a defined time window. Enforcing limits at the gateway protects backend
services from overload, constrains abusive traffic, and gives consumers
predictable usage boundaries. Apache APISIX provides dedicated [rate-limiting
plugins and configuration
examples](/docs/apisix/getting-started/rate-limiting/) for common gateway
policies.
## What is Rate Limiting
-Rate limiting enforces a maximum request throughput for API consumers. When a
client exceeds its allowed quota, the gateway returns an HTTP 429 (Too Many
Requests) response instead of forwarding the request to the upstream service.
The response typically includes a `Retry-After` header indicating when the
client can resume making requests.
+Rate limiting enforces a maximum request rate or count for API consumers. When
a client exceeds a configured limit, a gateway can return HTTP 429 (Too Many
Requests) instead of forwarding the request. A server may include `Retry-After`
when it can tell the client when to retry.
-The need for rate limiting has grown alongside API traffic volumes. API
traffic now represents the majority of HTTP requests processed globally, and a
significant portion consists of automated requests, many of which are abusive
or unintentional high-frequency polling.
+Rate limiting helps protect finite backend capacity from accidental loops,
high-frequency polling, credential attacks, and other traffic that exceeds the
service's operating envelope.
Without rate limiting, a single misbehaving client can consume
disproportionate backend resources, degrading performance for all consumers.
Rate limiting is also a contractual tool: it enforces the usage tiers defined
in API monetization plans and SLAs.
@@ -21,11 +21,11 @@ Without rate limiting, a single misbehaving client can
consume disproportionate
Implementing rate limiting at the API gateway rather than in individual
services provides several structural advantages.
-**Single enforcement point.** When rate limits are defined at the gateway,
every request passes through the same throttling logic regardless of which
upstream service handles it. This eliminates the risk of inconsistent
enforcement across a microservices fleet and reduces availability incidents
caused by traffic spikes.
+**Shared enforcement point.** Requests routed through the gateway can use the
same throttling policy regardless of which upstream service handles them. This
can reduce duplicated or inconsistent edge limits across a microservices fleet.
**Reduced backend load.** Rejected requests never reach the upstream service.
This means the gateway absorbs the cost of excess traffic, keeping backend
services operating within their designed capacity.
-**Consistent client experience.** Centralized rate limiting ensures all
consumers receive the same HTTP 429 responses with standardized headers
(`X-RateLimit-Limit`, `X-RateLimit-Remaining`, `X-RateLimit-Reset`), making it
straightforward for client developers to implement backoff logic.
+**Consistent client experience.** Centralized rate limiting can provide
consistent HTTP 429 responses. Additional quota headers such as
`X-RateLimit-Limit`, `X-RateLimit-Remaining`, and `X-RateLimit-Reset` are
implementation-dependent and should be documented for clients.
**Operational visibility.** Gateway-level rate limiting produces unified
metrics on throttled requests, enabling operations teams to identify abusive
clients, undersized quotas, and traffic anomalies from a single dashboard.
@@ -47,7 +47,7 @@ The leaky bucket algorithm processes requests at a fixed
rate, queuing excess re
Leaky bucket is ideal for backends that require strictly uniform request
rates, such as third-party APIs with their own rate limits or services with
fixed connection pools.
-**Pros:** Produces perfectly smooth output, prevents backend overload from
bursts.
+**Pros:** Produces a more uniform output rate and limits how much burst
traffic is forwarded immediately.
**Cons:** Higher latency for bursty traffic due to queuing, queue size
requires tuning.
@@ -116,7 +116,7 @@ This plugin is ideal when you need to smooth traffic to a
uniform rate. It suppo
The [limit-count plugin](/docs/apisix/plugins/limit-count/) enforces a maximum
number of requests within a configurable time window. It supports both fixed
window and sliding window algorithms, with the window size configurable from
one second to one day.
-limit-count is the best choice for implementing API quota plans (e.g., 10,000
requests per day). It returns standard rate limit headers so clients can track
their remaining quota. For distributed deployments, limit-count supports shared
counters via Redis, ensuring accurate enforcement across multiple gateway
nodes. In benchmarks, Redis-backed distributed counting adds less than 1ms of
latency per request at the 99th percentile.
+limit-count is a good fit for implementing API quota plans (e.g., 10,000
requests per day). It returns rate limit headers so clients can track their
remaining quota. For distributed deployments, limit-count supports shared
counters through Redis so multiple gateway nodes can enforce the same quota.
Redis-backed counting adds network and storage overhead, so benchmark it with
the topology and traffic profile you plan to run.
### limit-conn (Concurrent Connection Limiting)
@@ -128,25 +128,25 @@ This plugin is essential for APIs that serve large file
downloads, streaming res
APISIX allows stacking all three plugins on a single route. A typical
production configuration might combine limit-count for daily quotas, limit-req
for per-second smoothing, and limit-conn for concurrent connection caps. The
plugins execute in order, and a request rejected by any plugin does not consume
quota in subsequent plugins.
-This layered approach mirrors industry best practice. Production APIs benefit
from enforcing at least two independent rate limiting dimensions to provide
comprehensive protection.
+Layering can be useful when an API has independent quota, burst, and
concurrency requirements. Choose only the dimensions supported by measured
backend capacity and consumer contracts.
## FAQ
### What HTTP status code should I return for rate-limited requests?
-Return HTTP 429 (Too Many Requests) as defined in RFC 6585. Include a
`Retry-After` header with the number of seconds the client should wait before
retrying. Additionally, include `X-RateLimit-Limit`, `X-RateLimit-Remaining`,
and `X-RateLimit-Reset` headers so clients can proactively manage their request
rate. APISIX's limit-count plugin returns these headers automatically.
+Return HTTP 429 (Too Many Requests) as defined in RFC 6585. When the server
can estimate an appropriate retry time, include a `Retry-After` header.
APISIX's limit-count plugin can also return `X-RateLimit-Limit`,
`X-RateLimit-Remaining`, and `X-RateLimit-Reset` headers so clients can track
the configured quota.
### How do I handle rate limiting in a distributed gateway deployment?
-Use a shared counter store such as Redis. APISIX's limit-count plugin natively
supports Redis and Redis Cluster backends for distributed counter
synchronization. This ensures that rate limits are enforced accurately
regardless of which gateway node processes the request. The trade-off is a
small latency increase (typically under 1ms) for the Redis round-trip on each
request.
+Use a shared counter store such as Redis when gateway nodes need to enforce
one shared quota. APISIX's limit-count plugin supports Redis and Redis Cluster
policies for distributed counters. The added network and storage overhead
depends on Redis topology, load, and network conditions, so benchmark it in the
intended deployment.
### Should I rate limit internal service-to-service traffic?
-Yes, but with different thresholds. Internal rate limiting prevents cascading
failures when one service sends an unexpectedly high volume of requests to
another. Set internal limits based on measured capacity rather than commercial
quotas. Circuit breakers complement internal rate limiting by stopping requests
entirely when a downstream service is unhealthy.
+It can be useful when one service can exceed another service's measured
capacity. Set internal limits from load tests and failure objectives rather
than commercial quotas. Circuit breakers complement rate limiting by stopping
or reducing requests when a downstream service is unhealthy.
### How do I communicate rate limits to API consumers?
-Document rate limits in your API reference and include them in onboarding
materials. Use standard rate limit response headers on every response (not just
429 responses) so clients can monitor their consumption in real time. Provide a
dedicated endpoint or dashboard where consumers can check their current usage
against their quota. For paid tiers, send proactive notifications when
consumers approach their limits.
+Document rate limits, response behavior, and any implementation-specific quota
headers in your API reference and onboarding materials. If consumers need
current quota state, expose it through documented response fields, an endpoint,
or a dashboard. For paid tiers, consider notifications when consumers approach
their limits.
## Related
diff --git a/website/learning-center/api-gateway-security.md
b/website/learning-center/api-gateway-security.md
index fa6711065da..cfc42c23133 100644
--- a/website/learning-center/api-gateway-security.md
+++ b/website/learning-center/api-gateway-security.md
@@ -1,5 +1,5 @@
---
-title: "API Gateway Security: Threats, Best Practices & Implementation"
+title: "API Gateway Security Best Practices"
description: "Learn API Gateway security best practices with Apache APISIX,
including authentication, authorization, rate limiting, WAF, mTLS, and
zero-trust controls."
slug: api-gateway-security
date: 2026-04-14
@@ -7,13 +7,13 @@ tags: [security, api-gateway, best-practices]
hide_table_of_contents: false
---
-API gateway security is the practice of protecting your API infrastructure at
the edge by enforcing authentication, authorization, rate limiting, and traffic
filtering before requests reach backend services. A properly secured gateway
reduces attack surface, prevents data breaches, and ensures compliance across
every API endpoint in your organization.
+API gateway security best practices protect API infrastructure at the edge by
combining authentication, coarse-grained authorization, rate limiting, request
validation, and traffic filtering before requests reach backend services. These
controls reduce the attack surface and provide consistent protection for
traffic routed through the gateway, while backend services remain responsible
for business authorization and resource ownership.
## Why API Gateway Security Matters
-APIs have become the primary attack vector for modern applications. According
to the OWASP API Security Top 10 (2023 edition), broken object-level
authorization and broken authentication remain the two most critical API
vulnerabilities, affecting organizations across every industry. The explosive
growth of API-first architectures has created an equally explosive growth in
API-targeted attacks.
+The OWASP API Security Top 10 (2023 edition) ranks broken object-level
authorization and broken authentication as its first two API risk categories.
As organizations expose more application functionality through APIs, these
interfaces require the same deliberate threat modeling and layered controls as
the services behind them.
-The cost of getting API security wrong is substantial, as breaches involving
API vulnerabilities tend to take longer to identify and contain and carry
significant financial impact. The API gateway sits at a unique vantage point:
it processes every inbound request, making it the single most effective
location to enforce security policies consistently.
+The cost of getting API security wrong can be substantial. An API gateway sits
at a useful enforcement point because it processes traffic routed through it
and can apply common edge policies consistently, while application services
continue to enforce their own authorization and data-protection rules.
## Common API Threats
@@ -29,7 +29,7 @@ SQL injection, NoSQL injection, and command injection remain
persistent threats.
### Broken Authentication
-Weak or improperly implemented authentication mechanisms allow attackers to
assume legitimate user identities. Common failures include missing token
validation, weak password policies, credential stuffing vulnerabilities, and
improper session management. Credential stuffing attacks account for billions
of login attempts monthly across the internet.
+Weak or improperly implemented authentication mechanisms allow attackers to
assume legitimate user identities. Common failures include missing token
validation, weak password policies, credential stuffing vulnerabilities, and
improper session management.
### Excessive Data Exposure
@@ -37,7 +37,7 @@ APIs frequently return more data than the client needs,
relying on the frontend
### Rate Limit Bypass
-Without proper rate limiting, attackers can launch brute-force attacks,
denial-of-service campaigns, and credential enumeration at scale. Automated bot
traffic constitutes a significant portion of all internet traffic, and much of
it targets API endpoints specifically.
+Without appropriate traffic controls, automated clients can increase the rate
of brute-force attempts, credential enumeration, or resource-exhaustion traffic
against an API.
## Security Layers at the Gateway
@@ -45,15 +45,15 @@ A defense-in-depth approach applies multiple security
controls at the gateway la
### Authentication
-The gateway should verify identity before any request reaches a backend
service. Common mechanisms include JWT validation, OAuth 2.0 token
introspection, API key verification, and [mutual TLS
(mTLS)](/learning-center/what-is-mutual-tls/) for service-to-service
communication. Centralizing [API gateway
authentication](/learning-center/api-gateway-authentication/) reduces the risk
of inconsistent enforcement across individual services.
+For routes that require identity, the gateway can verify credentials before
forwarding a request. Common mechanisms include JWT validation, OAuth 2.0 token
introspection, API key verification, and [mutual TLS
(mTLS)](/learning-center/what-is-mutual-tls/) for service-to-service
communication. Centralizing [API gateway
authentication](/learning-center/api-gateway-authentication/) can reduce
inconsistent edge enforcement, while explicitly public routes remain
unauthenticated by design.
### Authorization
-Beyond verifying identity, the gateway must enforce access control. Role-based
access control (RBAC), attribute-based access control (ABAC), and scope-based
authorization ensure that authenticated users can only access resources and
operations they are permitted to use. Fine-grained authorization at the gateway
prevents BOLA vulnerabilities at scale.
+Beyond verifying identity, the gateway can enforce route-, consumer-, role-,
attribute-, or scope-based access policies before forwarding a request. These
gateway-level checks complement rather than replace authorization in the
application: backend services must still verify resource ownership and other
business rules to prevent BOLA.
### Rate Limiting and Throttling
-Rate limiting protects backend services from abuse and ensures fair resource
allocation. Effective rate limiting operates at multiple granularities: per
consumer, per route, per IP address, and globally. A substantial share of
traffic on the average website comes from bots, and rate limiting is the first
line of defense against automated abuse.
+Rate limiting protects backend services from abuse and helps allocate capacity
fairly. Effective rate limiting can operate at multiple granularities,
including per consumer, per route, per IP address, and globally. It should be
combined with authentication, request validation, and other controls when
defending against automated abuse.
### IP Restriction
@@ -61,40 +61,40 @@ IP allowlists and denylists provide coarse-grained access
control. While not suf
### WAF and CORS
-A Web Application Firewall (WAF) at the gateway layer inspects request
payloads for known attack patterns. CORS policies prevent unauthorized
cross-origin requests from browser-based clients. Together, they address both
server-side injection attacks and client-side cross-origin abuse.
+A Web Application Firewall (WAF) at the gateway layer can inspect requests for
configured attack patterns. CORS controls which origins browser code may read
responses from; it is enforced by browsers and does not stop non-browser
clients from sending requests. Use these controls for their distinct purposes
rather than treating either as a complete authorization or injection defense.
### TLS Termination
-TLS termination at the gateway ensures that all client-to-gateway traffic is
encrypted. The gateway handles certificate management, cipher suite
configuration, and protocol version enforcement, relieving backend services of
this operational burden. The vast majority of web traffic now uses HTTPS, and
TLS is considered a baseline requirement for any production API.
+TLS termination at the gateway encrypts client-to-gateway traffic when HTTPS
is required. The gateway handles certificate management, cipher suite
configuration, and protocol version enforcement, while teams should separately
decide whether to re-encrypt traffic from the gateway to upstream services. TLS
is a baseline requirement for production APIs that carry sensitive or
authenticated traffic.
### Request Validation
-Schema-based request validation rejects malformed or oversized payloads before
they reach backend services. Validating request structure, data types, and
content length at the gateway prevents injection attacks and reduces the attack
surface of downstream services.
+Schema-based request validation can reject malformed, unexpected, or oversized
payloads before they reach backend services. This reduces invalid input, but it
does not by itself prevent injection; applications still need safe query
construction, output handling, and business-level validation.
## Zero-Trust API Architecture
-Zero-trust architecture assumes that no request is inherently trustworthy,
regardless of its origin. Every API call must be authenticated, authorized, and
validated, whether it arrives from the public internet, an internal service, or
a trusted partner.
+Zero-trust architecture does not grant trust from network location alone.
Protected API calls should be evaluated against identity, authorization, device
or workload context, and other policy signals appropriate to the resource.
-At the gateway layer, zero-trust principles translate into several concrete
practices. Every request carries verifiable identity credentials. Authorization
is evaluated per request rather than per session. Network location (internal
vs. external) does not confer implicit trust. All traffic is encrypted,
including east-west service-to-service communication.
-The API gateway enables zero-trust by serving as a policy enforcement point.
It validates tokens, checks permissions, and applies security policies
uniformly across all traffic, creating a consistent security boundary
regardless of the underlying network topology.
+At the gateway layer, zero-trust principles can include validating credentials
on protected routes, evaluating common access policy per request, and requiring
encryption according to the threat model. Network location alone does not
confer implicit trust.
+The API gateway can serve as one policy enforcement point for traffic routed
through it. Application services and other infrastructure controls remain
responsible for resource authorization, data protection, and traffic that does
not pass through the gateway.
## Security Best Practices
The following practices represent a comprehensive approach to API gateway
security that organizations should adopt incrementally based on risk profile.
-1. **Enforce authentication on every endpoint.** No API route should be
accessible without verified identity. Use JWTs with short expiration times and
validate signatures on every request.
+1. **Define authentication per route.** Require verified identity for
protected APIs, validate credentials on every protected request, and expose
public routes only by explicit design. Choose token lifetimes and
authentication methods according to the client and risk model.
2. **Implement least-privilege authorization.** Grant the minimum permissions
required for each consumer. Default to deny and require explicit grants for
sensitive operations.
-3. **Apply rate limiting at multiple levels.** Configure per-consumer,
per-route, and global rate limits. Use sliding window algorithms to prevent
burst abuse while accommodating legitimate traffic spikes.
+3. **Apply rate limits where they address a measured risk.** Combine only
independent dimensions justified by the abuse model and backend capacity, such
as per-consumer, per-route, global, or concurrency limits. Select the algorithm
and burst behavior for the workload.
4. **Validate all request inputs.** Enforce request schema validation at the
gateway. Reject payloads that exceed expected sizes, contain unexpected fields,
or fail type checks.
-5. **Use mutual TLS for service-to-service calls.** Encrypt and authenticate
all internal traffic. Rotate certificates automatically and enforce certificate
validation on every connection.
+5. **Use mutual TLS where service identity is required.** Encrypt internal
traffic according to the threat model, validate certificates, and automate
certificate rotation where practical.
6. **Enable WAF rules for known attack patterns.** Deploy rulesets targeting
SQL injection, XSS, and command injection. Update rules regularly to address
emerging attack vectors.
-7. **Log and audit all security events.** Capture authentication failures,
authorization denials, rate limit triggers, and WAF blocks. Feed security logs
into a SIEM for correlation and alerting.
+7. **Log and audit relevant security events.** Capture authentication
failures, authorization denials, rate limit triggers, and WAF blocks without
recording credentials or sensitive payloads. Feed appropriate security logs
into a SIEM for correlation and alerting.
8. **Rotate credentials and secrets regularly.** Automate API key rotation,
certificate renewal, and token signing key rotation. Never embed secrets in
client-side code or version control.
@@ -104,17 +104,17 @@ The following practices represent a comprehensive
approach to API gateway securi
## How Apache APISIX Secures APIs
-Apache APISIX provides a comprehensive set of security plugins that implement
each layer of the defense-in-depth model described above.
+Apache APISIX provides security plugins that can implement several gateway
layers in the defense-in-depth model described above.
For **IP-based access control**, the [ip-restriction
plugin](/docs/apisix/plugins/ip-restriction/) supports allowlists and denylists
at the route level, enabling fine-grained control over which addresses can
reach specific endpoints.
-**Cross-origin resource sharing** is managed through the [CORS
plugin](/docs/apisix/plugins/cors/), which configures allowed origins, methods,
and headers to prevent unauthorized cross-origin requests from browser clients.
+**Cross-origin resource sharing** is managed through the [CORS
plugin](/docs/apisix/plugins/cors/), which configures the origins, methods, and
headers that browser code may use when reading cross-origin responses. CORS is
not a substitute for authentication or authorization.
-**CSRF protection** is available through the [CSRF
plugin](/docs/apisix/plugins/csrf/), which generates and validates CSRF tokens
to prevent cross-site request forgery attacks on state-changing API operations.
+**CSRF protection** is available through the [CSRF
plugin](/docs/apisix/plugins/csrf/), which generates and validates CSRF tokens
to mitigate cross-site request forgery on state-changing operations.
-For **mutual TLS**, APISIX supports [mTLS configuration](/docs/apisix/mtls/)
for both client-to-gateway and gateway-to-upstream connections, ensuring
encrypted and mutually authenticated communication at every hop.
+For **mutual TLS**, APISIX supports [mTLS configuration](/docs/apisix/mtls/)
for client-to-gateway and gateway-to-upstream connections when both encryption
and peer authentication are required.
-APISIX also supports JWT authentication, key authentication, OpenID Connect,
rate limiting with multiple algorithms, and request body validation. The plugin
architecture enables security policies to be composed per route, allowing teams
to apply exactly the controls each endpoint requires without over- or
under-securing traffic.
+APISIX also supports JWT authentication, key authentication, OpenID Connect,
rate limiting with multiple algorithms, and request body validation. Its plugin
architecture lets teams compose gateway policies per route while retaining
application-level authorization and validation in the services that own the
data.
## FAQ
@@ -124,11 +124,11 @@ API security is the broad discipline of protecting APIs
across their entire life
### Should I terminate TLS at the API gateway or at the backend service?
-Terminate TLS at the gateway for client-facing connections. This centralizes
certificate management and offloads cryptographic processing from backend
services. For traffic between the gateway and upstream services, use mTLS to
maintain encryption and mutual authentication throughout the request path. This
approach balances operational simplicity with end-to-end security.
+TLS can terminate at the gateway when centralized certificate and edge-policy
management fit the architecture. Re-encrypt gateway-to-upstream traffic when
the network and data threat model requires confidentiality, and use mTLS when
upstream services also need to authenticate the gateway. TLS passthrough or
service-side termination may be more appropriate for some protocols or
ownership boundaries.
### How many rate limiting layers should an API gateway enforce?
-Apply at least three layers: a global rate limit to protect overall
infrastructure capacity, a per-consumer limit to prevent any single client from
monopolizing resources, and per-route limits for endpoints with expensive
backend operations. Use sliding window or leaky bucket algorithms rather than
fixed windows to provide smoother throttling behavior and prevent burst abuse
at window boundaries.
+Choose rate-limit dimensions from measured capacity and the abuse model. A
service may combine global, per-consumer, per-route, or concurrency limits when
those controls address distinct risks. Select the algorithm and burst behavior
that match the backend and client contract rather than enforcing a universal
number of layers.
## Related
diff --git a/website/learning-center/kubernetes-api-gateway.md
b/website/learning-center/kubernetes-api-gateway.md
index 973083d32f3..956210bd356 100644
--- a/website/learning-center/kubernetes-api-gateway.md
+++ b/website/learning-center/kubernetes-api-gateway.md
@@ -1,21 +1,21 @@
---
-title: "Kubernetes API Gateway: Gateway API, Ingress Controllers & Best
Practices"
-description: "Compare Kubernetes Gateway API vs Ingress, understand ingress
controllers, and learn how to deploy an API gateway on Kubernetes with Apache
APISIX."
+title: "Kubernetes API Gateway: Gateway API & Ingress"
+description: "Compare Kubernetes Gateway API vs Ingress, understand controller
architecture, and evaluate Apache APISIX deployment patterns for Kubernetes."
slug: kubernetes-api-gateway
date: 2026-04-14
tags: [kubernetes, ingress-controller, gateway-api]
hide_table_of_contents: false
---
-A Kubernetes API gateway is the component that manages external traffic
entering a Kubernetes cluster and routes it to the appropriate services. It
translates Kubernetes-native resource definitions (Ingress resources or Gateway
API resources) into routing rules, handling TLS termination, path-based
routing, authentication, and traffic policies at the cluster edge.
+A Kubernetes API gateway manages external traffic entering a cluster and
routes it to the appropriate Services. An ingress or Gateway API controller
translates Kubernetes resources into gateway routing and policy configuration.
Apache APISIX can also use [Kubernetes service
discovery](/docs/apisix/discovery/kubernetes/) when a route needs to resolve
changing backend endpoints without static upstream addresses.
## What is a Kubernetes API Gateway
Kubernetes does not include a built-in data plane for external traffic
management. The platform defines APIs (Ingress, Gateway API) that describe how
traffic should be routed, but the actual implementation is delegated to
third-party controllers. These controllers run as pods within the cluster,
watch for resource changes, and configure their underlying proxy accordingly.
-This design reflects Kubernetes' philosophy of extensibility. With Kubernetes
now the dominant container orchestration platform, the choice of API gateway is
one of the most consequential infrastructure decisions a platform team faces.
+This extensibility lets platform teams choose a controller and data plane that
match their routing, policy, and operating requirements.
-The Kubernetes gateway landscape has evolved significantly. The original
Ingress resource, introduced in Kubernetes 1.1 (2015), provided minimal routing
capabilities. The newer Gateway API, which reached GA for core features in
2023, offers a far richer model with support for traffic splitting,
header-based routing, and role-oriented configuration. Adoption of Gateway API
resources in new Kubernetes deployments has grown rapidly since its GA release.
+The original Ingress resource provides a deliberately limited HTTP routing
model. The newer Gateway API offers a richer, role-oriented model with support
for traffic splitting, header-based routing, and additional protocols, with
feature maturity varying by resource and implementation.
## Kubernetes Ingress vs Gateway API
@@ -25,7 +25,7 @@ The Ingress resource is Kubernetes' original API for defining
external HTTP rout
Ingress is simple but limited. It supports only HTTP and HTTPS traffic, has no
native concept of traffic splitting, and lacks a standard way to express
advanced routing (header matching, query parameter routing, request mirroring).
To work around these limitations, every ingress controller defines its own
annotations, creating vendor lock-in and configuration inconsistency.
-Despite its limitations, Ingress remains widely deployed. Most Kubernetes
clusters still have at least one Ingress resource defined, though many
organizations are migrating to Gateway API for new workloads.
+Ingress remains supported, while Kubernetes recommends Gateway API as its
successor for teams that need its expanded model. Migration timing depends on
controller conformance and the policies a workload uses.
### Gateway API
@@ -38,7 +38,7 @@ The Gateway API is a collection of Kubernetes custom
resources that provide a mo
Gateway API's role-oriented design separates infrastructure concerns (managed
by platform teams via GatewayClass and Gateway) from application routing
(managed by service teams via HTTPRoute). This separation mirrors real
organizational structures where platform engineers control the gateway
infrastructure and application teams define their own routes.
-Gateway API implementations generally process configuration changes faster
than equivalent annotation-based Ingress configurations because the structured
resource model eliminates the need for annotation parsing and interpretation.
+Gateway API replaces many controller-specific annotations with structured
resources and fields, improving portability for capabilities included in the
specification and supported by the chosen implementation.
### Comparison Table
@@ -63,37 +63,37 @@ An ingress controller is a Kubernetes controller that
watches Ingress (and optio
Every ingress controller uses a different underlying proxy technology. APISIX
Ingress Controller uses Apache APISIX. NGINX Ingress Controller uses NGINX.
Traefik and Kong act as both the controller and the proxy. The choice of
controller determines the available features, performance characteristics, and
operational model.
-The ingress controller market has consolidated around several primary options:
NGINX Ingress Controller (legacy standard), Apache APISIX Ingress Controller
(feature-rich, high performance), Traefik (developer-friendly, auto-discovery),
and Kong Ingress Controller (API management focus).
+Common options include NGINX Ingress Controller, Apache APISIX Ingress
Controller, Traefik, and Kong Ingress Controller. Compare their supported
Kubernetes APIs, policy models, release lifecycles, and operational
requirements against your cluster needs.
## Choosing an Ingress Controller
### Apache APISIX Ingress Controller
-APISIX Ingress Controller pairs a Kubernetes-native control plane with the
high-performance Apache APISIX data plane. It supports both Ingress resources
and Gateway API, allowing gradual migration. Key differentiators include a rich
plugin ecosystem (80+ plugins), dynamic configuration without restarts, and
sub-millisecond routing latency.
+APISIX Ingress Controller pairs a Kubernetes-native control plane with the
Apache APISIX data plane. It supports Ingress resources and Gateway API,
allowing gradual migration. Its differentiators include dynamic configuration
without gateway restarts and access to APISIX traffic, security, and
observability plugins.
-APISIX is built on NGINX and LuaJIT, delivering throughput exceeding 20,000
requests per second per core in benchmarks. Its plugin architecture means that
authentication, rate limiting, request transformation, and observability can be
configured through Kubernetes custom resources without modifying application
code.
+APISIX is built on NGINX and LuaJIT. Its plugin architecture means that
authentication, rate limiting, request transformation, and observability can be
configured through Kubernetes custom resources without modifying application
code. Measure throughput and latency with the plugin chain, TLS settings, and
traffic profile intended for production.
### NGINX Ingress Controller
-The NGINX Ingress Controller is the most widely deployed option. It is stable
and well-documented but relies heavily on annotations for advanced
configuration, which creates verbose and hard-to-maintain manifests as
complexity grows.
+NGINX Ingress Controller uses NGINX as its data plane and supports annotations
and other project-specific configuration for features beyond the core Ingress
API. Teams should account for the lifecycle and configuration model of the
specific NGINX controller distribution they choose.
### Traefik
-Traefik provides automatic service discovery and integrates with multiple
orchestrators beyond Kubernetes. Its middleware system offers a plugin-like
model for cross-cutting concerns. Traefik is popular for smaller deployments
and developer environments. Its Go-based architecture makes it lightweight but
limits per-core throughput compared to NGINX-based controllers.
+Traefik provides provider-based service discovery and integrates with multiple
orchestrators beyond Kubernetes. Its middleware system offers a model for
cross-cutting concerns such as authentication, headers, and rate limiting.
### Kong Ingress Controller
-Kong pairs its API gateway with a Kubernetes controller and offers a path to
Kong's commercial API management platform. It provides a plugin ecosystem
comparable to APISIX's but uses a PostgreSQL or Cassandra database for
configuration storage, adding operational complexity compared to APISIX's
etcd-backed approach.
+Kong pairs its API gateway with a Kubernetes controller and supports
PostgreSQL-backed, DB-less, and hybrid deployment modes. Available plugins and
management capabilities vary by Kong edition and deployment mode.
## How Apache APISIX Works as a Kubernetes API Gateway
-The [APISIX Ingress Controller](/docs/ingress-controller/overview/) deploys
Apache APISIX as the data plane and a Kubernetes controller as the control
plane within the cluster.
+The [APISIX Ingress Controller](/docs/ingress-controller/overview/) uses
Apache APISIX as its data plane and acts as the Kubernetes control plane. Teams
can install the controller and data plane together or connect the controller to
a separately managed APISIX deployment.
### Architecture
The control plane watches Kubernetes resources (Ingress, Gateway API, and
APISIX custom resources) and translates them into APISIX routing configurations
via the Admin API. The data plane (APISIX instances) handles actual traffic
processing. This separation allows the data plane to scale independently based
on traffic volume.
-A typical production deployment runs 2-3 APISIX data plane replicas behind a
cloud load balancer, with a single controller replica (plus a standby) managing
configuration. The data plane stores active configuration in shared memory,
enabling sub-millisecond routing decisions without external lookups per request.
+A production deployment normally runs multiple APISIX data-plane replicas
behind a load balancer and separately manages controller availability. Choose
replica counts, disruption budgets, and autoscaling thresholds from
availability objectives and load tests rather than a universal sizing rule.
### Gateway API Support
@@ -107,7 +107,7 @@ Beyond standard Kubernetes APIs, APISIX Ingress Controller
provides custom resou
### Plugin Configuration
-APISIX's 80+ plugins can be configured through Kubernetes custom resources.
For example, enabling JWT authentication on a route requires adding a plugin
reference to the ApisixRoute resource. The controller translates this into
APISIX plugin configuration automatically. Plugin configurations can be shared
across routes using ApisixPluginConfig resources, reducing duplication.
+APISIX plugins can be configured through Kubernetes custom resources. For
example, enabling JWT authentication on a route requires adding a plugin
reference to the ApisixRoute resource. The controller translates this into
APISIX plugin configuration automatically. Plugin configurations can be shared
across routes using ApisixPluginConfig resources, reducing duplication.
## Deployment Patterns
@@ -117,16 +117,12 @@ The simplest pattern deploys APISIX as the sole ingress
point for a single Kuber
### Multi-Cluster with Shared Gateway
-For organizations running multiple Kubernetes clusters (multi-region,
staging/production, or domain-separated), a shared APISIX deployment can route
traffic across clusters. APISIX's upstream configuration supports endpoints
outside the local cluster, enabling cross-cluster routing. Many organizations
now operate multiple production Kubernetes clusters, making cross-cluster
traffic management a common requirement.
+For organizations running multiple Kubernetes clusters (multi-region,
staging/production, or domain-separated), a shared APISIX deployment can route
traffic to configured upstream endpoints across clusters. This pattern requires
explicit network connectivity, service discovery, health checks, and
failure-domain planning.
### Gateway Per Namespace
Large organizations with multiple teams sharing a cluster may deploy separate
APISIX instances per namespace or per team. Each team manages its own gateway
configuration through Gateway API resources scoped to their namespace.
ReferenceGrant resources control cross-namespace access. This pattern provides
strong isolation between teams while sharing cluster infrastructure.
-### Sidecar Gateway
-
-For latency-sensitive workloads, APISIX can be deployed as a sidecar alongside
the application pod. This eliminates the network hop to a centralized gateway
but increases resource consumption and operational complexity. This pattern is
uncommon and typically reserved for specialized use cases where every
millisecond of latency matters.
-
## FAQ
### Should I use Ingress or Gateway API for new Kubernetes deployments?
@@ -135,7 +131,7 @@ Use Gateway API for new deployments. Gateway API provides a
richer feature set,
### How does APISIX Ingress Controller compare to the NGINX Ingress Controller?
-APISIX offers dynamic configuration without reloads, a richer plugin ecosystem
(80+ plugins vs annotation-based configuration), native support for Gateway
API, and higher throughput per core. NGINX Ingress Controller has broader
community adoption and more third-party documentation. If your requirements
include advanced authentication, rate limiting, or request transformation,
APISIX provides these as native plugins rather than custom annotations.
+APISIX offers dynamic configuration without gateway reloads, Gateway API
support, and plugins for authentication, rate limiting, and request
transformation. NGINX controller capabilities and configuration mechanisms vary
by distribution. Compare the exact Gateway API conformance, policy surface,
release lifecycle, and benchmark results for the versions you plan to deploy.
### Can I run multiple ingress controllers in the same Kubernetes cluster?
@@ -143,7 +139,7 @@ Yes. Kubernetes supports multiple ingress controllers
differentiated by IngressC
### What is the resource overhead of running APISIX in Kubernetes?
-A production APISIX data plane replica typically requests 500m CPU and 256Mi
memory, handling 10,000-20,000 requests per second depending on plugin
configuration. The controller replica requests 200m CPU and 128Mi memory. For
most clusters, two data plane replicas and one controller replica provide
sufficient capacity and redundancy. These resource requirements are comparable
to other Kubernetes ingress controllers and negligible relative to the
application workloads they protect.
+Resource requirements depend on request and response size, TLS, enabled
plugins, logging, upstream latency, and availability targets. Start with
explicit resource requests and limits, then load-test the intended policy chain
and tune replica counts or autoscaling from observed CPU, memory, latency, and
saturation. Size the controller separately from the data plane because
configuration churn and request traffic create different load profiles.
## Related
diff --git a/website/learning-center/open-source-api-gateway-comparison.md
b/website/learning-center/open-source-api-gateway-comparison.md
index 69c012abe35..86e75bf7f06 100644
--- a/website/learning-center/open-source-api-gateway-comparison.md
+++ b/website/learning-center/open-source-api-gateway-comparison.md
@@ -1,6 +1,6 @@
---
-title: "Open Source API Gateway Comparison: APISIX vs Kong vs Envoy vs Traefik"
-description: "Compare the leading open-source API gateways. Feature-by-feature
analysis of Apache APISIX, Kong, Envoy, and Traefik covering architecture,
plugins, Kubernetes support, and community."
+title: "Open Source API Gateway Comparison"
+description: "Compare Apache APISIX, Kong, Envoy, and Traefik across
architecture, extensibility, Kubernetes support, operations, and community."
slug: open-source-api-gateway-comparison
date: 2026-04-14
tags: [comparison, api-gateway, open-source]
@@ -8,78 +8,74 @@ hide_table_of_contents: false
faq:
- q: "Is Apache APISIX production-ready for enterprise workloads?"
a: >-
- Yes. Apache APISIX is an Apache Software Foundation top-level project
used in production by organizations worldwide. The etcd-backed architecture
provides high availability without single points of failure when deployed with
an etcd cluster.
+ Apache APISIX is an Apache Software Foundation top-level project.
Production readiness still depends on designing APISIX, etcd, upstream
services, and surrounding infrastructure for the required availability,
capacity, and recovery objectives.
- q: "Can I migrate from Kong to APISIX without downtime?"
a: >-
- A zero-downtime migration is achievable using a canary deployment
approach: run both gateways in parallel behind a load balancer, gradually
shifting traffic from Kong to APISIX as you validate route-by-route
equivalence. APISIX supports most Kong plugin equivalents natively, and the
Admin API allows automated route provisioning during migration.
+ A parallel or canary migration can reduce interruption, but it cannot
guarantee zero downtime. Inventory routes and plugins, translate configuration,
validate behavior and observability, shift traffic gradually, and keep a tested
rollback path.
- q: "How do open-source API gateways compare to cloud-managed options like
AWS API Gateway?"
a: >-
- Cloud-managed gateways trade control for convenience. They handle
infrastructure operations but impose vendor lock-in, per-request pricing that
grows with traffic volume, and limited plugin customization. Open-source
gateways like APISIX provide full control over the data plane, support
multi-cloud and hybrid deployments, and eliminate per-request platform fees.
+ Cloud-managed services take on more infrastructure operation, while
self-managed open-source gateways provide more control over deployment and
extension. Pricing, portability, customization, and operational responsibility
vary by provider and architecture, so compare them against the same workload
and support requirements.
- q: "Which gateway has the best Kubernetes support?"
a: >-
- All four gateways support Kubernetes, but the depth varies. APISIX and
Kong offer dedicated ingress controllers with CRD-based configuration. Envoy
integrates through the Kubernetes Gateway API and service mesh deployments.
Traefik auto-discovers Kubernetes services natively. The emerging Kubernetes
Gateway API standard is supported by all four projects to varying degrees, and
is becoming the recommended approach for new deployments.
+ There is no universal winner. Compare the maintained controller or
integration for each project, its Gateway API conformance, supported policies
and custom resources, upgrade lifecycle, and the operational model required by
your platform.
---
-An open-source [API gateway](/learning-center/what-is-an-api-gateway/) sits
between clients and backend services, handling routing, authentication, rate
limiting, and observability. Apache APISIX, Kong, Envoy, and Traefik are among
the most widely adopted options, each with distinct architectural decisions
that affect performance, extensibility, and operational complexity.
+This open-source [API gateway
comparison](/learning-center/what-is-an-api-gateway/) evaluates Apache APISIX,
Kong, Envoy, and Traefik across architecture, extensibility, Kubernetes
integration, and day-two operations. Each project can route and protect service
traffic, but its control plane, extension model, and deployment assumptions
create different tradeoffs for platform teams.
## Why the Choice of API Gateway Matters
-Organizations running microservices at scale route millions of requests per
day through their gateway layer. The gateway you choose determines your latency
floor, plugin flexibility, and how much operational overhead your platform team
absorbs.
+The gateway you choose affects request processing, extension options,
configuration workflows, and how much operational responsibility the platform
team owns.
-Choosing poorly means rearchitecting under pressure. Choosing well means a
gateway that scales with your traffic for years without becoming a bottleneck.
+Evaluate candidates with the policies, deployment topology, failure modes, and
traffic profile you expect to operate rather than selecting from a feature
count alone.
## Feature Comparison Table
| Feature | Apache APISIX | Kong | Envoy | Traefik |
|---|---|---|---|---|
| Language | Lua (NGINX + LuaJIT) | Lua (NGINX + LuaJIT) | C++ | Go |
-| Configuration Store | etcd | PostgreSQL / Cassandra | xDS API (control
plane) | File / KV stores |
-| Admin API | RESTful, fully dynamic | RESTful | xDS gRPC | REST + dashboard |
-| Hot Reload | Yes, sub-millisecond | Partial (DB polling) | Yes (xDS push) |
Yes (provider watch) |
-| Plugin Count | 100+ built-in | 60+ bundled (more in Hub) | ~30 HTTP filters
| ~30 middlewares |
+| Configuration Model | etcd-backed dynamic or standalone file-based |
PostgreSQL, DB-less, or hybrid | Static files or xDS | Files and provider
integrations |
+| Management Interface | Admin API | Admin API or declarative configuration |
Admin interface and xDS APIs | File/providers and dashboard/API |
+| Dynamic Updates | Yes | Mode-dependent | Yes with xDS or dynamic files | Yes
through provider watches |
+| Extension Model | Built-in and external plugins | Plugin Hub and custom
plugins | HTTP/network filters | Middleware and plugins |
| Plugin Languages | Lua, Java, Go, Python, Wasm | Lua, Go (PDK) | C++, Wasm |
Go (middleware) |
| gRPC Proxying | Native | Supported | Native | Supported |
-| HTTP/3 (QUIC) | Supported | Experimental | Supported | Supported |
-| Dashboard | Built-in (APISIX Dashboard) | Kong Manager (Enterprise) | None
(third-party) | Built-in |
| License | Apache 2.0 | Apache 2.0 (OSS) / Proprietary (Enterprise) | Apache
2.0 | MIT |
-Note: Feature details are based on each project's official documentation as of
early 2026. Check the respective project sites for the latest status.
+Note: Feature details change across releases and editions. Verify required
capabilities against each project's current documentation before selecting a
gateway.
## Detailed Breakdown
### Apache APISIX
-Apache APISIX is built on NGINX and LuaJIT, using etcd as its configuration
store. This architecture eliminates database dependencies on the data path:
route changes propagate to every gateway node within milliseconds without
restarts or reloads.
+Apache APISIX is built on NGINX and LuaJIT. Its traditional mode uses etcd to
distribute route and plugin configuration dynamically, while standalone mode
loads declarative configuration from a local file.
-The [plugin ecosystem](/plugins/) includes over 100 built-in options spanning
authentication (JWT, key-auth, OpenID Connect), traffic management (rate
limiting, circuit breaking), observability (Prometheus, Zipkin, OpenTelemetry),
and transformation (request/response rewriting, gRPC transcoding). Developers
can write custom plugins in Lua, Go, Java, Python, or WebAssembly, making it
one of the most polyglot gateway runtimes available.
+The [plugin ecosystem](/plugins/) spans authentication (JWT, key-auth, OpenID
Connect), traffic management (rate limiting, circuit breaking), observability
(Prometheus, Zipkin, OpenTelemetry), and transformation (request/response
rewriting, gRPC transcoding). APISIX also supports several external plugin
runners and WebAssembly extensions in addition to native Lua plugins.
-APISIX supports the Kubernetes Ingress Controller pattern natively. The
[APISIX Ingress Controller](/docs/ingress-controller/overview/) watches
Kubernetes resources and translates them into APISIX routing configuration,
enabling declarative GitOps workflows while preserving the full plugin surface.
+The [APISIX Ingress Controller](/docs/ingress-controller/overview/) watches
supported Kubernetes resources and translates them into APISIX routing and
plugin configuration.
As an Apache Software Foundation top-level project, APISIX is
community-governed and vendor-neutral.
### Kong
-Kong is the longest-established open-source API gateway, with a mature
commercial ecosystem. It shares the NGINX + LuaJIT foundation with APISIX but
relies on PostgreSQL or Cassandra as its configuration store. This
architectural choice introduces a database dependency for configuration
storage, which adds operational complexity for HA deployments.
+Kong shares the NGINX and LuaJIT foundation with APISIX and supports
PostgreSQL-backed, DB-less, and hybrid control-plane/data-plane deployment
modes. These modes differ in how configuration is persisted and distributed, so
teams should compare them against their availability and change-management
requirements.
-Kong's plugin hub offers approximately 60 bundled plugins in the open-source
edition, with additional enterprise-only plugins for advanced features like
OAuth2 introspection and advanced rate limiting. The Go Plugin Development Kit
(PDK) allows extending Kong in Go, though Lua remains the primary plugin
language.
+Kong's Plugin Hub includes open-source and commercial plugins, and its
extension options include Lua plugins and external plugin servers. Availability
varies by gateway edition, deployment mode, and plugin.
Kong has a strong enterprise support ecosystem with commercial offerings (Kong
Gateway Enterprise, Kong Konnect) and a large user community.
### Envoy
-Envoy is a high-performance C++ proxy originally built at Lyft, now a CNCF
graduated project. It excels as a service mesh data plane and is the foundation
for Istio, AWS App Mesh, and other mesh implementations.
+Envoy is a C++ proxy originally built at Lyft and is now a CNCF graduated
project. It is used as a service-mesh data plane and as an edge or service
proxy.
-Envoy's configuration model uses the xDS (discovery service) API, a gRPC-based
protocol that pushes configuration updates from a control plane. This design is
powerful but means Envoy does not function as a standalone gateway without a
control plane component. Organizations adopting Envoy as an edge gateway
typically pair it with a control plane like Gloo Edge or similar tools.
+Envoy can start with fully static listeners, routes, and clusters, so it does
not require an external control plane for a small or stable configuration. For
dynamic management, Envoy uses the xDS discovery APIs to receive configuration
from files or a management server. Edge deployments that change frequently
often pair Envoy with a separate control plane or gateway product.
-The filter chain model supports around 30 built-in HTTP filters. Custom
extensions require C++ or WebAssembly, raising the barrier for teams without
C++ expertise. Envoy is most commonly deployed as a sidecar proxy within a
service mesh, though it is also used as an edge proxy.
+Envoy's filter-chain model provides built-in HTTP and network filters and
supports native or WebAssembly extensions. It is commonly used as a
service-mesh data plane and can also operate as an edge proxy.
### Traefik
-Traefik is written in Go and designed for automatic service discovery. It
integrates natively with Docker, Kubernetes, Consul, and other orchestrators,
automatically detecting new services and generating routes without manual
configuration. This auto-discovery model makes Traefik popular for development
environments and smaller-scale production deployments.
+Traefik is written in Go and uses provider integrations for environments such
as Docker, Kubernetes, and Consul. Those integrations can watch service changes
and update routing configuration.
-Traefik includes built-in Let's Encrypt integration for automatic TLS
certificate provisioning, a feature that requires additional tooling in other
gateways. Its middleware system offers approximately 30 built-in options
covering authentication, rate limiting, headers manipulation, and circuit
breaking.
-
-Traefik has a large community and is widely used in Docker-native environments.
+Traefik includes ACME certificate-resolver integration for automated TLS
certificate provisioning. Its middleware system covers capabilities such as
authentication, rate limiting, header manipulation, and circuit breaking.
## Performance Considerations
@@ -87,22 +83,22 @@ Performance varies significantly based on configuration,
plugin chains, TLS term
Key factors that affect gateway performance:
-- **Architecture**: C++ and LuaJIT-based gateways (Envoy, APISIX, Kong)
generally achieve lower latency than pure Go implementations
-- **Configuration store**: Gateways that avoid database queries on the data
path (APISIX, Envoy) tend to have more consistent latency
+- **Runtime and filters**: Implementation language alone does not predict
end-to-end performance; active filters and request processing matter more than
language labels
+- **Configuration model**: Check whether configuration distribution or storage
introduces work on the request path
- **Plugin overhead**: Each active plugin adds processing time. Test with your
actual plugin chain enabled
-- **Connection handling**: The NGINX event-driven model (APISIX, Kong) handles
high concurrency efficiently
+- **Connection handling**: Compare connection reuse, keepalive, protocol,
buffering, and concurrency behavior under the intended workload
We recommend benchmarking the specific gateways you are considering with a
representative workload on hardware similar to your production environment.
## When to Choose Which
-**Choose Apache APISIX when** you need a large built-in plugin ecosystem,
fully dynamic configuration without restarts, multi-language plugin support,
and no database dependency. It suits teams building platform-grade API
infrastructure. See the [getting started guide](/docs/apisix/getting-started/)
to evaluate it hands-on.
+**Choose Apache APISIX when** you need broad plugin coverage and external
plugin runners together with either etcd-backed dynamic configuration or a
standalone declarative mode. See the [getting started
guide](/docs/apisix/getting-started/) to evaluate it hands-on.
-**Choose Kong when** you are operating in an enterprise environment with
existing Kong deployments, need commercial support, or require specific
enterprise-only plugins. Kong's maturity means more third-party integrations
and consultants are available.
+**Choose Kong when** you already operate Kong tooling, need its commercial
support options, or require a specific plugin available in the intended Kong
edition.
-**Choose Envoy when** your primary use case is a service mesh data plane, you
need advanced load balancing algorithms, or you are already running Istio or a
similar mesh. Envoy is less suited as a standalone edge gateway due to its
control plane dependency.
+**Choose Envoy when** your primary use case is a service mesh data plane, you
need its proxy and load-balancing capabilities, or you already operate an
xDS-compatible management layer. Static configuration can serve smaller
standalone deployments; dynamic edge-gateway management usually requires an
additional control plane.
-**Choose Traefik when** auto-discovery and zero-configuration routing are
priorities, or you need built-in Let's Encrypt integration without additional
tooling. Traefik excels in Docker-native and small-to-medium Kubernetes
environments.
+**Choose Traefik when** integrated provider discovery and ACME certificate
automation are priorities, particularly in Docker- or Kubernetes-based
environments.
## Migration Considerations
@@ -111,25 +107,25 @@ Migrating between gateways is nontrivial and typically
requires careful planning
- **Plugin compatibility**: Not all plugins have equivalents across gateways.
Audit your active plugins and identify gaps before migrating.
- **Configuration translation**: Each gateway uses a different configuration
format. Automated translation tools can help but manual verification is
essential.
- **Operational tooling**: Monitoring dashboards, CI/CD pipelines, and
alerting rules need updating.
-- **Canary approach**: Running both gateways in parallel behind a load
balancer and shifting traffic gradually is the safest migration strategy.
+- **Parallel validation**: Running both gateways in parallel and shifting
selected traffic gradually is one way to compare behavior and preserve a
rollback path.
## Frequently Asked Questions
### Is Apache APISIX production-ready for enterprise workloads?
-Yes. Apache APISIX is an Apache Software Foundation top-level project used in
production by organizations worldwide. The etcd-backed architecture provides
high availability without single points of failure when deployed with an etcd
cluster.
+Apache APISIX is an Apache Software Foundation top-level project. Production
readiness still depends on designing APISIX, etcd, upstream services, and
surrounding infrastructure for the required availability, capacity, and
recovery objectives.
### Can I migrate from Kong to APISIX without downtime?
-A zero-downtime migration is achievable using a canary deployment approach:
run both gateways in parallel behind a load balancer, gradually shifting
traffic from Kong to APISIX as you validate route-by-route equivalence. APISIX
supports most Kong plugin equivalents natively, and the Admin API allows
automated route provisioning during migration.
+A parallel or canary migration can reduce interruption, but it cannot
guarantee zero downtime. Inventory routes and plugins, translate configuration,
validate behavior and observability, shift traffic gradually, and keep a tested
rollback path.
### How do open-source API gateways compare to cloud-managed options like AWS
API Gateway?
-Cloud-managed gateways trade control for convenience. They handle
infrastructure operations but impose vendor lock-in, per-request pricing that
grows with traffic volume, and limited plugin customization. Open-source
gateways like APISIX provide full control over the data plane, support
multi-cloud and hybrid deployments, and eliminate per-request platform fees.
+Cloud-managed services take on more infrastructure operation, while
self-managed open-source gateways provide more control over deployment and
extension. Pricing, portability, customization, and operational responsibility
vary by provider and architecture, so compare them against the same workload
and support requirements.
### Which gateway has the best Kubernetes support?
-All four gateways support Kubernetes, but the depth varies. APISIX and Kong
offer dedicated ingress controllers with CRD-based configuration. Envoy
integrates through the Kubernetes Gateway API and service mesh deployments.
Traefik auto-discovers Kubernetes services natively. The emerging Kubernetes
Gateway API standard is supported by all four projects to varying degrees, and
is becoming the recommended approach for new deployments.
+There is no universal winner. Compare the maintained controller or integration
for each project, its Gateway API conformance, supported policies and custom
resources, upgrade lifecycle, and the operational model required by your
platform.
## Related
diff --git a/website/learning-center/what-is-an-api-gateway.md
b/website/learning-center/what-is-an-api-gateway.md
index 128888d3f8e..422dfaa2f98 100644
--- a/website/learning-center/what-is-an-api-gateway.md
+++ b/website/learning-center/what-is-an-api-gateway.md
@@ -25,7 +25,7 @@ faq:
An API gateway is a server that sits between clients and backend services,
acting as an entry point for the APIs placed behind it. It accepts incoming
requests, applies policies such as authentication, rate limiting, and
transformation, then routes each request to the appropriate upstream service
and returns the response to the caller.
-In practice, an API gateway consolidates cross-cutting concerns that would
otherwise be duplicated across every microservice: access control, traffic
shaping, observability, and protocol translation. Instead of embedding this
logic in each service, teams centralize it at the gateway layer, reducing code
duplication, simplifying deployments, and giving platform teams a single
control plane for governing API behavior at scale.
+The main benefits of an API gateway are consistent edge policy enforcement,
less duplicated infrastructure logic, and a stable entry point as backend
services change. Teams can centralize access control, traffic shaping, and
gateway-level observability while leaving business authorization and
service-specific behavior in the applications that own them.
## How Does an API Gateway Work?
