API Gateway Comparison: Kong vs Envoy Gateway vs Apache APISIX (2026)

Most gateway evaluations still start with a feature checklist and a requests-per-second chart, and both are the wrong place to begin. By late 2026 the three leading open-source-rooted gateways can all terminate TLS, validate a JWT, and rate-limit a route. What separates them is where their configuration lives, what happens when you need something the catalog does not ship, and whether the licence you adopted last year is the licence you will be running next year.

This api gateway comparison looks at Kong Gateway, Envoy Gateway, and Apache APISIX through five lenses: data-plane architecture, Kubernetes Gateway API alignment, extensibility, the cost of operating them, and how each handles the new class of AI and Model Context Protocol (MCP) traffic. Every vendor claim here was checked against official documentation during this run, and anything I could not confirm is flagged rather than guessed.

What this covers: architectures, the Gateway API conformance picture, the same route plus authentication plus rate limit written three ways, AI gateway features, licensing, failure modes, and a decision matrix you can take into a design review.

Context and Background

An API gateway is the policy enforcement point in front of your services: it routes, authenticates, throttles, transforms, and observes north-south traffic. For a decade the category meant a reverse proxy with a plugin system. Two shifts changed the shape of the decision.

The first is Kubernetes. The Ingress resource was too small to express what gateways do, so every vendor invented annotations, and annotations do not port. The Kubernetes Gateway API replaced that with typed, role-oriented resources (GatewayClass, Gateway, HTTPRoute) plus a conformance suite that lets implementations be compared on evidence. If you are still on the retired controller, our ingress-nginx retirement migration playbook covers the move, and Gateway API versus Ingress explains why the resource model matters. That shift also muddies the phrase “Gateway API vs API gateway”: the Gateway API is a specification for configuring a proxy, while an API gateway is the product that adds identity, quota, and developer-facing policy on top. They are complementary layers, not rivals.

The second shift is AI traffic. Calls to large language model providers are long-lived streaming responses billed by token, not by request. Counting requests per minute is the wrong unit, and every gateway vendor has been retrofitting token-aware limits, provider translation, and MCP aggregation.

The three contenders sit in different places on the spectrum:

• Kong Gateway is a commercially backed gateway built on NGINX and OpenResty with a large plugin catalog, a hybrid control plane model, and a managed offering, Konnect.
• Envoy Gateway is a CNCF project that does one thing: translate Gateway API (plus its own policy CRDs) into configuration for Envoy Proxy. It is deliberately a control plane for a proxy you already trust.
• Apache APISIX is an Apache Software Foundation project, also on NGINX and OpenResty, with a dynamic plugin model and a recently rewritten Kubernetes controller.

Traefik and KrakenD are worth a look in some shops, and I mention Traefik’s conformance numbers below, but the three above cover the architectural variety most teams actually choose between.

Reference Architecture: Three Data Planes, Three Philosophies

The short answer: Kong and APISIX are NGINX/OpenResty gateways whose plugins run as Lua inside the request path, while Envoy Gateway is a Kubernetes control plane that programs Envoy Proxy, a C++ filter-chain proxy configured over xDS. The difference decides how you extend, scale, and fail.

Figure 1: Data-plane and control-plane layout of Kong, Envoy Gateway, and Apache APISIX.

The diagram shows three clients-to-upstream paths. Kong’s control plane stores configuration in Postgres or runs DB-less from declarative files; Envoy Gateway pushes xDS to Envoy; APISIX reads from etcd or from a standalone configuration.

Kong: NGINX plus a plugin runtime

Kong Gateway runs on NGINX with OpenResty (LuaJIT). Each request traverses plugin phases (access, header filter, body filter, log), and plugins are mostly Lua written against Kong’s Plugin Development Kit. Kong also supports out-of-process plugin servers and WebAssembly; Kong’s 3.9 documentation includes a Wasm reference page, which is why I list it, though you should confirm which filters your licence tier supports.

Operationally, Kong separates a control plane from data planes in “hybrid mode”. The control plane owns configuration and, in the traditional setup, a Postgres database. Data planes receive configuration and hold it in memory, so they keep serving if the control plane disappears. For Kubernetes, configuration comes from a Kubernetes controller (Kong Ingress Controller, now delivered under the Kong Operator line) that translates Gateway API objects and Kong custom resources such as KongPlugin and KongConsumer.

The trade-off is licensing and surface area. Kong exposes a very large feature catalog; a meaningful slice sits behind a commercial licence, covered in the licensing section below.

Envoy Gateway: control plane only

Envoy Gateway does not process traffic itself. It watches Gateway API resources and its own CRDs, then provisions and configures Envoy Proxy fleets over xDS. Envoy’s model is a listener, a filter chain, and clusters, with filters written in C++ in-tree, or attached at runtime through Wasm, Lua, external processing (ext_proc), and Dynamic Modules. The Envoy Gateway documentation lists all of these in its extensibility section, along with an Extension Server hook and an Envoy Patch Policy escape hatch.

The compatibility matrix tells you how fast the project moves. As of this run, the matrix lists Envoy Gateway v1.9 against Gateway API v1.6.1 and Kubernetes 1.33 to 1.36, with v1.8 supported until 2026-11-08 and v1.7 until 2026-08-05 (so v1.7 is already past end of life as I write on 2026-10-13). That is roughly a quarterly cadence with a short support window, which matters for upgrade planning.

APISIX: etcd-backed or etcd-free

Apache APISIX shares the NGINX/OpenResty base with Kong, but its configuration model differs. In the classic Admin API mode, routes, upstreams, and plugin configurations live in etcd, and each data-plane node watches etcd for changes, so route changes propagate without a process reload. The new Ingress Controller 2.0 documents a second and third mode: standalone, which keeps configuration in memory without etcd, and a standalone API-driven mode that replaces the whole configuration atomically and is mainly intended for use with ADC, the declarative configuration tool.

Plugins are Lua, with external plugin runners for other languages and Wasm support. The latest release I verified is 3.17.0 (published 2026-06-15), which added Amazon Bedrock and native Anthropic Messages API support to the AI plugins, plus a long list of new plugins including saml-auth and oas-validator.

Why the architecture decides the cost

Architecture is not an aesthetic question. It determines three bills you will pay.

The first is the extension bill. If a requirement is not in the catalog, Kong and APISIX ask you to write a Lua plugin that runs inside the worker, where a blocking call stalls an NGINX worker and a memory leak affects every route on that node. Envoy asks you to choose between in-process Wasm, a Lua snippet, or an out-of-process ext_proc gRPC service that sees headers and optionally bodies. Out-of-process is slower per request, but it isolates faults and lets you write in any language.

The second is the upgrade bill. Envoy Gateway’s tight coupling to Gateway API versions means you upgrade CRDs and the control plane as a pair, and the matrix shows the pairs. Kong and APISIX decouple the data plane from the Kubernetes controller, which gives you more freedom and more version combinations to test.

The third is the blast radius. A single shared gateway fleet concentrates every route’s failure modes. All three support running multiple gateway instances; the right sizing is one per trust or latency domain, not one per team.

Gateway API Conformance: What the Evidence Shows

The direct answer: on the published Gateway API v1.5 implementations page, Envoy Gateway v1.8.0 passes Core for HTTPRoute, GRPCRoute, and TLSRoute and is marked partially conformant, Kong passes Core for HTTPRoute and TLSRoute only in one of its two modes, and Apache APISIX does not appear in the tables I retrieved.

That last sentence deserves care. I read the v1.5 implementation page this run, and the figures below come from it. The page itself warns it is under active development.

Project	Version	Route type	Mode	Core	Extended
Envoy Gateway	v1.8.0	HTTPRoute	default	Pass	33 of 35
Envoy Gateway	v1.8.0	HTTPRoute	gateway-namespace-mode	Pass	34 of 35
Envoy Gateway	v1.8.0	GRPCRoute	default	Pass	8 of 10
Envoy Gateway	v1.8.0	TLSRoute	default	Pass	10 of 12
Kong (kong-operator)	v2.2.6	HTTPRoute	expressions	Pass	8 of 35
Kong (kong-operator)	v2.2.6	HTTPRoute	traditional_compatible	Not pass	6 of 35
Kong (kong-operator)	v2.2.6	GRPCRoute	expressions	Not pass	3 of 10
Kong (kong-operator)	v2.2.6	TLSRoute	expressions	Pass	4 of 12
Traefik	v3.7	HTTPRoute	default	Pass	14 of 35

Source: Gateway API v1.5 implementations page, retrieved during this run. Envoy Gateway entries are labelled partially conformant with 2 skipped tests each.

Read this table for what it is. Conformance measures portability of Gateway API behaviour, not product quality. Kong’s lower Extended count mostly reflects that Kong implements many behaviours through its own plugins and annotations rather than through Gateway API extended features. Envoy Gateway’s high count reflects its design goal. If your portfolio is Gateway API manifests that you want to move between controllers, the numbers matter. If your policies live in KongPlugin or APISIX PluginConfig resources, portability is already gone at the policy layer, and conformance only covers routing.

Figure 2: The Gateway API resource chain is shared; policy attachment is where each product diverges.

The shared chain is GatewayClass to Gateway to HTTPRoute to Service. The dotted lines mark the divergence: Kong attaches KongPlugin resources by annotation, Envoy Gateway attaches typed policy CRDs (SecurityPolicy, BackendTrafficPolicy, EnvoyExtensionPolicy) through targetRefs, and the APISIX controller 2.0 introduces PluginConfig, HTTPRoutePolicy, and BackendTrafficPolicy CRDs under apisix.apache.org/v1alpha1. The Envoy approach follows the Gateway API’s own policy attachment pattern, which is why its status reporting and targetRefs feel native. Our policy-as-code comparison of Kyverno and OPA Gatekeeper is relevant here, because an admission policy can enforce that every HTTPRoute carries an authentication policy regardless of which gateway you pick.

APISIX’s Ingress Controller 2.0 added TCPRoute, UDPRoute, GRPCRoute, and TLSRoute support, according to the project’s own announcement. That article does not state a conformance level, and I did not find APISIX in the v1.5 tables, so I will not claim one. If conformance is a hard requirement, ask the project for a submitted report.

Deeper Analysis: The Same Route, Auth, and Rate Limit Three Ways

Abstract comparisons hide the real friction, so here is one requirement implemented in each gateway: route /orders to a service named orders on port 8080, require authentication, and allow a bounded request rate. The authentication method differs per product on purpose, because I only show configuration I could verify against official documentation this run.

Figure 3: Request flow for an authenticated, rate-limited call. Token validation and counter increment both sit on the hot path.

The sequence matters for latency budgeting. Token validation may need a JWKS or discovery fetch, which gateways cache. The counter increment hits Redis on every request when you choose a shared policy, so Redis round-trip time adds directly to your p99.

Kong: HTTPRoute plus KongPlugin resources

Kong’s Kubernetes pattern separates the route from the policy. A KongPlugin declares the plugin and its config; an annotation attaches it; a KongConsumer plus a labelled Secret supplies credentials. The key-auth pieces below match the Kong quickstart documentation:

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: key-auth
plugin: key-auth
---
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rate-limit-5-min
plugin: rate-limiting
config:
  minute: 5
  policy: local
---
apiVersion: v1
kind: Secret
metadata:
  name: alex-key-auth
  labels:
    konghq.com/credential: key-auth
stringData:
  key: hello_world
---
apiVersion: configuration.konghq.com/v1
kind: KongConsumer
metadata:
  name: alex
  annotations:
    kubernetes.io/ingress.class: kong
username: alex
credentials:
- alex-key-auth
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: orders
  annotations:
    konghq.com/plugins: rate-limit-5-min,key-auth
spec:
  parentRefs:
  - name: kong
  rules:
  - matches:
    - path: {type: PathPrefix, value: /orders}
    backendRefs:
    - name: orders
      port: 8080

Two caveats. The Kong quickstart demonstrates the konghq.com/plugins annotation on a Service; applying it on an HTTPRoute is, to my understanding, also supported by the controller, but I did not verify that page this run, so test it. And policy: local keeps counters per node. With six data-plane replicas and a limit of 5 per minute you can admit up to 30 per minute across the fleet, which is the arithmetic that bites teams who assume “5 per minute” is global. Kong’s cluster-wide options use Redis or the database, at the price of an extra hop.

For OpenID Connect, Kong’s openid-connect plugin is, as far as I know, an Enterprise-tier plugin; the OSS catalogue offers jwt, oauth2, and key-auth. I could not confirm the tier boundary from a primary page this run, so verify against your licence before designing around it.

Envoy Gateway: HTTPRoute plus attached policy CRDs

Envoy Gateway keeps the route pure Gateway API and attaches behaviour through targetRefs. OIDC is a first-class field on SecurityPolicy, and the shape below follows the project’s documentation:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: orders
spec:
  parentRefs:
  - name: eg
  rules:
  - matches:
    - path: {type: PathPrefix, value: /orders}
    backendRefs:
    - name: orders
      port: 8080
---
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: orders-oidc
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: orders
  oidc:
    provider:
      issuer: "https://idp.example.com/realms/prod"
    clientID: "orders-gateway"
    clientSecret:
      name: orders-oidc-secret
    redirectURL: "https://api.example.com/orders/oauth2/callback"
    logoutPath: "/orders/logout"
---
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: BackendTrafficPolicy
metadata:
  name: orders-ratelimit
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: orders
  rateLimit:
    global:
      rules:
      - clientSelectors:
        - headers:
          - name: x-user-id
            value: one
        limit:
          requests: 3
          unit: Hour

The rate-limit block is lifted from the documented example, which limits a specific user header to three requests per hour. The documentation states that global rate limiting is built on the Envoy Ratelimit service and requires a Redis instance, configured on the EnvoyGateway resource with a rateLimit.backend.type: Redis URL, followed by a restart of the envoy-gateway deployment. Local rate limiting, documented on a separate page, needs no Redis but has the same per-replica arithmetic as Kong’s local policy.

The OIDC example is cookie-session based, an authorization-code flow for browser users. For machine-to-machine APIs you generally want JWT validation instead; Envoy Gateway’s SecurityPolicy has JWT support too, but I did not pull that page this run, so I do not show it.

APISIX: plugins on a route, in Admin API or CRDs

APISIX configuration is a JSON document per route with a plugins object. The Admin API example below combines the documented limit-count plugin with openid-connect:

curl "http://127.0.0.1:9180/apisix/admin/routes" -X PUT \
  -H "X-API-KEY: ${admin_key}" \
  -d '{
    "id": "orders",
    "uri": "/orders/*",
    "plugins": {
      "openid-connect": {
        "client_id": "orders-gateway",
        "client_secret": "$ENV://OIDC_CLIENT_SECRET",
        "discovery": "https://idp.example.com/realms/prod/.well-known/openid-configuration",
        "scope": "openid email profile",
        "bearer_only": true,
        "realm": "apisix"
      },
      "limit-count": {
        "count": 100,
        "time_window": 60,
        "rejected_code": 429,
        "key_type": "var",
        "key": "remote_addr",
        "policy": "redis",
        "redis_host": "redis.platform.svc",
        "redis_timeout": 1000
      }
    },
    "upstream": {
      "type": "roundrobin",
      "nodes": {"orders.default.svc:8080": 1}
    }
  }'

Both plugins and their attributes (count, time_window, key, policy, rejected_code, redis_host, redis_timeout, bearer_only, discovery) appear in the APISIX plugin documentation. Setting bearer_only to true makes the plugin expect an access token rather than start a browser redirect, which suits API traffic; with it false, the docs say a session.secret is also required. Notice the rejected_code default of 503: unless you set 429 explicitly, clients see a server error rather than a throttle response, a small default that causes real client-side retry storms. The Redis timeout defaults to 1000 ms, which means a sick Redis can add a full second to every request before the plugin gives up.

On Kubernetes, the 2.0 controller exposes the same plugins through PluginConfig and HTTPRoutePolicy CRDs rather than raw Admin API calls. In the 3.17.0 release APISIX tightened several authentication defaults (stricter jwt-auth, key-auth, hmac-auth), so read the breaking-changes list before upgrading a fleet.

Rate limiting arithmetic you should do before choosing

Rate limiting is the feature where the gateways look identical and behave differently. Consider an illustrative service: 8 gateway replicas, a policy of 600 requests per minute per API key, and 2,000 requests per second of aggregate traffic spread evenly.

• Local counters: each replica enforces 600 per minute independently. A single key hitting all eight replicas can legitimately send up to 4,800 per minute. Local limits are a protection for the gateway and upstream, not a billing-grade quota.
• Shared Redis counters: the key is exact, but every request pays a Redis round trip. At an illustrative 0.5 ms in-cluster latency that is a 0.5 ms floor, and at 2,000 requests per second you are asking Redis for 2,000 increments per second, easily handled by one instance but a single point of failure unless you replicate it.
• Failure policy: when Redis is unreachable, does the gateway fail open (admit traffic) or fail closed (reject)? The defaults differ by product and plugin, and the right answer differs by route. A login endpoint should fail closed; a read-only catalogue should fail open.

These figures are illustrative, not benchmarks; measure your own Redis latency.

Extensibility: where the catalog ends

Every team eventually needs one behaviour the catalog lacks: signing requests to a legacy backend, enforcing a bespoke tenant header contract, or calling a policy engine. The options differ sharply.

Need	Kong	Envoy Gateway	APISIX
In-process scripting	Lua plugins via PDK	Lua filter	Lua plugins
Sandboxed code	Wasm (verify tier)	Wasm via EnvoyExtensionPolicy	Wasm plugin
Out-of-process, any language	Plugin servers	ext_proc gRPC service	External plugin runners
Last-resort escape hatch	Custom plugin fork	EnvoyPatchPolicy, Extension Server	Custom plugin

The Envoy Gateway Wasm task confirms the shape: an EnvoyExtensionPolicy with a wasm list whose code is either an HTTP URL with a SHA-256 checksum or an OCI image. The checksum requirement is a good supply-chain default. The same sidebar lists ext_proc, Lua, Dynamic Modules, an Extension Server hook, and an OPA sidecar over a Unix domain socket, which is the cleanest path if you already run Open Policy Agent policies.

My opinion, labelled as such: ext_proc is the right default for business logic and Wasm for small, hot, stateless transforms. Lua inside NGINX workers is fastest to write and easiest to get wrong, because one blocking DNS lookup stalls every concurrent request on the worker. A gateway plugin should never make a synchronous network call without a timeout and a circuit breaker.

Authentication and identity

All three validate JWTs and perform OIDC, but where the work happens differs. Envoy Gateway’s SecurityPolicy handles OIDC authorization-code flows at the proxy and attaches to routes or whole Gateways, so one policy can protect many routes. APISIX’s openid-connect plugin supports both the browser redirect flow and bearer_only token validation, and can read secrets from environment variables with the $ENV:// syntax. Kong separates consumers (identities) from credentials (Secrets labelled by type), a model that maps well to API-key products with plans, and gets more powerful with Enterprise plugins.

The practical rule: use the gateway for coarse authentication (is this token valid, who is the principal) and keep fine-grained authorisation (can this principal edit this order) in the service or a policy engine. Gateways are poor places to encode business authorisation because policies drift from the data they protect.

Observability

Envoy has the richest native telemetry: per-cluster and per-listener statistics, access logs with command operators, and OpenTelemetry tracing. Envoy AI Gateway adds GenAI token metrics on top. Kong and APISIX both ship Prometheus and OpenTelemetry plugins, which means observability is something you enable per route or globally, rather than something that is always present. The cost of a plugin-based approach is that it is easy to forget on a new route; the cost of an always-on approach is metric cardinality. Either way, label by route and status class, not by raw path, or a scanner hitting random URLs will blow up your time series count.

AI Gateway Features and the Token-Aware Future

LLM traffic breaks request-based assumptions. A response can stream for tens of seconds, cost depends on input plus output tokens, and providers have wildly different APIs. For the routing logic that sits beside this, see our post on LLM model routing architecture.

Figure 4: A decision flow for choosing among the three gateways, with AI and licensing as branch points.

Envoy AI Gateway is a separate project that is “an additive layer on Envoy Gateway”, according to its 1.0 announcement (2026-06-23). The announcement lists a v1beta1 control-plane API with a stability commitment, 16 AI providers behind a single OpenAI-compatible endpoint, support for chat, completions, embeddings, images, audio and the OpenAI Responses API, an MCP gateway that aggregates MCP servers with CEL-based authorisation, BackendSecurityPolicy for upstream credentials, OpenTelemetry and OpenInference tracing, and quota-aware rate limiting. It also builds on the Gateway API Inference Extension.

Apache APISIX ships AI features as plugins. The 3.17.0 release notes list ai-proxy with provider-aware max_tokens overrides, max_stream_duration_ms, and max_response_bytes, upstream cancellation on client disconnect, ai-proxy-multi with max_retries and retry_on_failure_within_ms fallback controls, and an expression-based strategy in ai-rate-limiting. New provider coverage includes Amazon Bedrock (including ConverseStream), native Anthropic Messages, and OpenAI Responses. Note the behaviour change: upstream AI timeouts now return 504 instead of 500, which your client retry logic should expect.

Kong has an AI Gateway line of plugins (AI Proxy and related), and its 3.9 documentation includes an AI gateway section with LLM library integration guides. Which of those plugins run without a commercial licence, and which provider versions are current, I could not verify from a primary source this run, so I will not assert a feature matrix. Ask Kong for the entitlement list before you commit.

A design point that applies to all three: token-based limiting needs the response, so it cannot reject up front the way a request counter can. The gateway estimates or reserves tokens from the request, lets the stream run, then debits the actual usage. If your quota must be hard (for chargeback), reserve a worst-case budget from max_tokens and refund the difference. That is why the APISIX max_tokens override and max_response_bytes guards exist: they bound the worst case before the stream starts.

Licensing and Operating Cost

This is the section where evaluations go stale fastest. Verify these points again before signing anything.

Envoy Gateway is part of the Envoy project under CNCF governance, with an Apache 2.0 licence to my knowledge, and Tetrate and Solo publish commercial distributions of it. Apache APISIX is an Apache Software Foundation top-level project under Apache 2.0, with a commercial ecosystem around it. The vendor-neutral governance of both is a real asset: the licence cannot be unilaterally changed by a single company.

Kong is different. Kong’s licensing documentation for 3.9 says Kong Gateway “can be used with or without a license”, with an Enterprise licence unlocking enterprise functionality, validated per node at startup without needing network access. The documented expiry behaviour in 3.9 is instructive: after expiration the Admin API keeps OSS features working, Enterprise features go read-only, and proxy traffic keeps processing, but new DB-less or Kubernetes-controller nodes cannot start. In Kong’s own GitHub discussions, a user quotes the release notes as saying “Free mode is no longer available” from 3.10, with a relayed (not official) reply that the open-source images stop at kong:3.9.1 and the kong/kong-gateway image needs a licence. Kong staff did not publicly answer in the thread I read, so the exact current status of Kong’s open-source binaries is something to confirm with Kong directly. The planning consequence is concrete: pin your decision to a written statement of what runs unlicensed, because new-node startup failures are the kind of surprise that appears during a scale-out incident.

On operating cost, think in terms of people, not licences. Envoy Gateway’s cost is cognitive: Envoy’s configuration surface is huge, and when something misbehaves you debug xDS and Envoy admin endpoints. Kong’s is a mix of database or declarative-config management and licence entitlement tracking. APISIX’s is etcd operations (or the discipline of standalone mode) and a smaller Western-market support ecosystem, though that is changing. A reasonable rule of thumb, again opinion: the cheapest gateway is the one your team already knows how to debug at 3 a.m.

Trade-offs, Gotchas, and What Goes Wrong

No gateway removes risk; each relocates it. These are the failure modes I would design against, in rough order of how often they cause incidents.

Configuration propagation lag and split brain. Every control-plane design has a window where some data-plane nodes hold the old route table and some the new. In Kong hybrid mode and APISIX etcd mode, nodes cache configuration and keep serving if the control plane or etcd is down, which is good for availability and bad for emergency rollbacks that appear not to take effect. Envoy Gateway pushes xDS and reports Accepted and Programmed conditions on Gateway API resources, so check those conditions in your pipeline rather than trusting a successful kubectl apply. Always roll out a route change with a canary route and an explicit verification step.

The shared Redis single point of failure. Shared rate limiting couples every request to Redis. If Redis degrades, latency spreads to every protected route, because APISIX’s default Redis timeout is 1000 ms and the other products have comparable defaults. Set timeouts to a small multiple of normal latency, decide fail-open or fail-closed per route, and alert on the limiter’s error counter, not just on gateway 5xx.

Plugin ordering and priority. Authentication must run before rate limiting if you key limits by consumer, and after it if you want to throttle unauthenticated floods by IP. Kong and APISIX assign each plugin a priority; Envoy orders HTTP filters in the chain. A misordered chain looks fine in testing, then lets anonymous traffic consume an authenticated user’s quota.

Upgrade coupling. Envoy Gateway’s support windows are short: the matrix shows v1.7 reached its documented end of life on 2026-08-05. APISIX 3.17.0 removed the /apisix/plugin/jwe/encrypt endpoint and changed defaults for proxy-cache, ssl_verify in ai-rag, and several auth plugins, so an in-place upgrade can change behaviour without any config change. Kong’s licence behaviour changed across minor versions. Treat gateway upgrades like database upgrades: staged, with traffic replay.

Streaming and buffering. LLM and server-sent-event responses break gateways configured to buffer. Response body buffering, request body size limits, and idle timeouts all need explicit tuning, and the default timeouts are usually tuned for short JSON calls. APISIX 3.17.0 returning 504 for upstream AI timeouts is the sort of detail that changes client retry behaviour.

The portability illusion. Moving HTTPRoute objects between controllers is easy; moving policy is not. A KongPlugin, an Envoy SecurityPolicy, and an APISIX PluginConfig are three different languages. If portability matters, keep policy thin and put authorisation in services or a policy engine such as OPA.

Anti-patterns. Using the gateway as an orchestration layer that calls five services and merges results. Terminating business authorisation in Lua. Running one giant shared gateway for every team. Benchmarking a route with no plugins and then deploying one with six. On that last point, I deliberately give no throughput numbers here: published gateway benchmarks are heavily dependent on hardware, plugin set, TLS settings, and payload size, and I did not find a neutral, reproducible one this run. Run your own load test with your real plugin chain, and compare p99 latency at a fixed request rate rather than peak throughput.

Practical Recommendations

Choose by constraints, not by feature count. If your estate is Kubernetes-native, Gateway API is your standard, and you value vendor-neutral governance, Envoy Gateway is the strongest fit, particularly if AI and MCP traffic is on your roadmap, because Envoy AI Gateway is built directly on it and the conformance numbers are the best of the three on the published page. Accept that you will learn Envoy.

If you need a broad, mature plugin catalogue, a developer portal, and a vendor to call, and you have budget, Kong is the pragmatic choice, but get its licensing and AI plugin entitlements in writing first, and decide whether you are on Konnect, self-managed licensed, or pinned to an older open-source release.

If you want an Apache-governed, open-source-licensed gateway with a rich plugin set, fast dynamic configuration, and fast-moving AI plugins, and your team is comfortable with Lua and etcd or the standalone modes, APISIX is a strong candidate. Ask for a Gateway API conformance report if portability matters.

A checklist for the evaluation:

• Write the same three routes (public, authenticated, AI) in each candidate, using your real identity provider.
• Run a load test with the full plugin chain at a fixed request rate and record p50, p99, and CPU.
• Kill Redis, the control plane, and one data-plane node, and observe each failure.
• Time a rolling upgrade across one minor version, including CRDs.
• Obtain written licence terms for every plugin you rely on.
• Enforce a baseline policy (authentication present on every route) with admission control.
• Confirm streaming behaviour with a 60-second SSE response.

Frequently Asked Questions

What is the difference between the Gateway API and an API gateway?

The Gateway API is a Kubernetes specification: a set of resources (GatewayClass, Gateway, HTTPRoute) that describe how traffic enters a cluster, implemented by controllers. An API gateway is a product that enforces API-level policy such as authentication, quotas, and transformation. Many gateways, including Kong, Envoy Gateway, and APISIX, implement the Gateway API as their Kubernetes configuration surface, and add their own policy resources for the features the specification does not cover.

Is Kong still open source in 2026?

Kong’s documentation says Kong Gateway can be used with or without a licence, and a Kong release-note line quoted in its GitHub discussions says free mode is no longer available from 3.10. Users report open-source images ending at 3.9.1, but I found no official Kong statement in the sources I read. Confirm the current status of the open-source binaries and licence terms with Kong before you adopt it.

Which gateway has the best Gateway API conformance?

On the Gateway API v1.5 implementations page, Envoy Gateway v1.8.0 passes Core for HTTPRoute, GRPCRoute, and TLSRoute, with 33 to 34 of 35 extended HTTPRoute features, and is marked partially conformant. Kong passes Core for HTTPRoute in expressions mode with 8 of 35 extended features. Apache APISIX did not appear in the tables I retrieved. Conformance covers routing portability, not policy quality.

Can these gateways rate-limit LLM traffic by tokens?

Yes in varying degrees. APISIX 3.17.0 lists an ai-rate-limiting plugin with an expression-based strategy. Envoy AI Gateway 1.0 advertises quota-aware rate limiting and token metrics on top of Envoy Gateway. Kong has AI gateway plugins, though I could not verify its token-limiting details or licence tier. Because tokens are known only after the response, hard quotas need worst-case reservation and refunds.

Which is fastest: Kong, Envoy, or APISIX?

There is no honest single answer. Throughput depends on hardware, TLS, payload size, and especially the plugin chain, and I found no neutral, reproducible benchmark to cite. All three are capable of handling very high request rates with minimal plugins. Measure p99 latency at a fixed request rate with your actual authentication and rate-limit plugins, and include failure injection, because tail behaviour under degradation matters more than peak numbers.

Can I run more than one gateway?

Yes, and many large estates do: a Gateway API controller for ingress, plus a separate API management layer for external developers. The risk is duplicated policy. Keep identity and quota ownership in exactly one layer, and use admission policies to prevent routes from bypassing it.

Further Reading

• Kubernetes Gateway API versus Ingress in 2026: the resource model underneath all three gateways.
• Migrating off ingress-nginx to Gateway API: a practical migration playbook.
• LLM model routing architecture: how routing and fallback logic pairs with an AI gateway.
• Kubernetes policy as code with Kyverno and OPA Gatekeeper: enforcing gateway policy through admission control.
• Gateway API implementations: the official conformance tables.
• Envoy Gateway compatibility matrix: supported versions and end-of-life dates.
• Apache APISIX 3.17.0 release notes: AI plugin and breaking-change details.

By Riju – about