API Gateways Compared 2026: Kong vs APISIX vs Envoy Gateway vs Traefik

I get asked to pick an API gateway roughly once a quarter, and the question has changed shape in the last eighteen months. It used to be "which one has the plugin I need?" Now it is "which one will still be open source, still implement Gateway API properly, and still be maintained when ingress-nginx's retirement forces us to touch this again?" This post compares the six options people actually shortlist in 2026: Kong, Apache APISIX, Envoy Gateway, Traefik, Tyk and AWS API Gateway. I cover current versions, what the official Gateway API conformance reports say, the licensing changes that matter, the AI gateway features everyone now ships, and why I don't trust any of the performance numbers you will see on vendor pages.

What is an API gateway in 2026, and how is it different from an ingress controller?

An ingress controller routes HTTP traffic into a cluster. An API gateway does that and then sits on the request path for policy: authentication (API keys, JWT, OIDC), rate limiting, request and response transformation, quotas per consumer, analytics, and increasingly token budgets for LLM traffic. The line blurred once the Kubernetes Gateway API became the standard routing model, now at v1.7.0 (released 29 October 2026). Every gateway in this post except AWS can be driven by Gateway and HTTPRoute objects, and the routing part is portable between them.

The policy part is not. Gateway API standardises matching, header rewrites, redirects, mirroring, weights and timeouts. It deliberately leaves auth and rate limiting to each implementation, which hooks them in through an ExtensionRef filter or a policy attachment CRD. That boundary is where lock-in lives, and it is the single most useful thing to understand before choosing. If you are coming from ingress-nginx, my ingress-nginx retirement post covers the routing side of that move.

The six options at a glance (versions as of November 2026)

I checked every version below against the project's release page on 10 November 2026.

Gateway	Latest release	License	Gateway API controller	AI / LLM features	Source
Kong Gateway	Enterprise 3.16 (15 Sep 2026); OSS 3.9.4 (12 Oct 2026)	OSS 3.9: Apache-2.0; 3.10+ Enterprise only	Kong Operator 2.3.4 (Apache-2.0)	ai-proxy, ai-prompt-guard in OSS 3.9; more in Enterprise	support policy, OSS releases
Apache APISIX	3.19.0 (28 Sep 2026)	Apache-2.0	APISIX Ingress Controller 2.2.0	ai-proxy, ai-proxy-multi, ai-rate-limiting, ai-cache, ai-rag	release, ingress 2.0
Envoy Gateway	v1.10.0 (6 Nov 2026)	Apache-2.0	Built in	Agent Router (formerly Envoy AI Gateway) v1.2.1	release, Agent Router
Traefik Proxy	v3.7.17 (30 Oct 2026); v3.8.0-rc.1	MIT	Built in	Only in commercial Traefik Hub	release, feature matrix
Tyk Gateway	v5.16.0 (27 Oct 2026)	MPL-2.0, except the ee folder	Tyk Operator closed source since Oct 2024	Commercial	release, license
AWS API Gateway	Managed	Proprietary	None (not in cluster)	None native	pricing

Two rows in that table would have looked different two years ago, and both are about licensing.

Is Kong still open source in 2026?

Partly, and the part that is open is frozen. The Kong/kong repository's last minor line is 3.9: patch releases keep arriving (3.9.4 shipped on 12 October 2026), but there is no 3.10 or later community build. Kong's version support policy lists Enterprise 3.10 through 3.16, with 3.14 (April 2026) as the current LTS supported to 2029. A community discussion asking where the OSS 3.10 image went never got an official answer, and the Kong Helm chart for the ingress controller still defaults to app version 3.9.

The other half of the change is the Enterprise image. Kong's 3.10.0.0 changelog says free mode is no longer available and that starting without a license behaves like an expired license. The 3.15 breaking changes then made an expired license turn the Admin API read-only while existing config keeps proxying. Put together: the modern kong/kong-gateway image is a paid product, and the free path is the 3.9 line. Kong's Kubernetes tooling is still Apache-2.0. Kong Operator 2.0 (October 2025) merged the Kong Ingress Controller and Kong Gateway Operator into one project, although standalone KIC 3.5 still gets patches (3.5.14 on 22 October 2026).

None of this makes Kong a bad choice. It has a long-established plugin catalogue (the OSS 3.9 tree alone ships auth, rate limiting, transformation, logging and AI plugins) and a mature consumer model. It does mean you should price it as a commercial product from day one, or accept that you are running a feature-frozen 3.9 data plane. If you want to try the Kubernetes side, my companion guide walks through setting up Kong Gateway on Kubernetes with Gateway API, including the license step people skip.

Tyk and Traefik: open core, with the line in different places

Tyk's gateway is MPL-2.0 except for an ee directory under a commercial license. The bigger change for Kubernetes users happened in October 2024, when the Tyk Operator repository was archived and future releases became closed source for paying customers. So the gateway is open, and the Kubernetes-native way to configure it is not. Tyk also has no Gateway API conformance report in the upstream repository.

Traefik Proxy is MIT and remains the friendliest single binary for small clusters. The commercial line sits at API management: Traefik's own feature comparison lists JWT, OIDC, API key auth, distributed rate limiting, AI gateway and MCP gateway capabilities as Traefik Hub features, not Proxy features. That is honest, but it means "Traefik as an API gateway" usually means Traefik Hub. For the reverse-proxy view of Traefik versus Nginx and Caddy, see Nginx vs Caddy vs Traefik.

Which API gateways pass Gateway API conformance?

This is the one area where you can compare vendors with numbers they did not write themselves. Implementations submit conformance reports to the Gateway API repository. Each report lists which profile it ran (HTTP, gRPC, TLS, TCP, UDP), whether all core tests passed, and which optional "extended" features it claims and passed. I pulled the v1.6 reports and counted the extended features claimed for the HTTP profile.

Three readings matter. Envoy Gateway implements nearly all of the optional HTTP surface, so more of your config stays portable. Kong passes every core test across five profiles (HTTP, gRPC, TCP, TLS, UDP), which is more breadth than most, but it claims only 9 HTTP extended features in its best-case report, so features like request mirroring or redirects go through Kong plugins instead. APISIX and Tyk have not submitted reports at all, which does not mean they fail, only that you are taking their word for it.

How does gateway lock-in actually show up in YAML?

Here is the practical version. The routing below is portable to any conformant gateway. The ExtensionRef filter is not: it points at a Kong KongPlugin. On Envoy Gateway the same rate limit lives in a BackendTrafficPolicy attached to the route, on Traefik in a Middleware, on APISIX in a PluginConfig. Four vendors, four CRDs, one concept.

# Portable part: works on Kong, Envoy Gateway, Traefik, APISIX, NGF (Gateway API v1.6+)
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: orders
  namespace: shop
spec:
  parentRefs:
    - name: public            # your Gateway
  rules:
    - matches:
        - path: { type: PathPrefix, value: /orders }
      filters:
        # Non-portable part: vendor CRD reference. Swap this when you swap gateways.
        - type: ExtensionRef
          extensionRef:
            group: configuration.konghq.com
            kind: KongPlugin
            name: orders-rate-limit
      backendRefs:
        - name: orders
          port: 8080
---
# Check what a gateway really claims before you commit (no cluster access needed)
# gh api "repos/kubernetes-sigs/gateway-api/git/trees/main?recursive=1" \
#   --jq '.tree[].path' | grep 'conformance/reports/v1.6/'

My rule: keep routing in standard HTTPRoute fields, keep every vendor policy object in its own file and directory, and make it a reviewed decision to add a new kind. When you migrate, you rewrite one directory instead of grepping every route. This is ordinary platform hygiene, and it matters more now that coding agents happily generate whichever CRD they saw last in training data.

AI gateway features: what each one actually ships

Every vendor now calls its product an AI gateway. Underneath, the feature is the same: an OpenAI-compatible front door, provider credentials held at the gateway, retries and fallbacks across models, and token-aware rate limits. What differs is where it lives and what it costs.

APISIX ships the most in the open: its 3.19.0 plugin directory includes ai-proxy, ai-proxy-multi, ai-rate-limiting, ai-cache, ai-rag and prompt guard plugins, all Apache-2.0, and the project README now describes APISIX as an AI gateway as well as an API gateway. Kong's OSS 3.9 line includes ai-proxy, ai-prompt-guard, ai-prompt-template and the request and response transformers, while anything added since lands in Enterprise. Envoy's answer is a separate project: Envoy AI Gateway was renamed Agent Router, moved to the Agentic AI Foundation, and kept its CRDs, Helm charts and Apache-2.0 license; it runs on top of Envoy Gateway. Traefik puts AI and MCP gateway features in Hub. AWS API Gateway has nothing LLM-specific.

If LLM traffic is your main reason for buying a gateway, read my AI gateway comparison first. A dedicated LLM gateway is often a better fit than bolting plugins onto your north-south API gateway, and the supply-chain risk of that component deserves its own review.

What do API gateway performance benchmarks actually measure?

Mostly the vendor's best case. The APISIX README claims 18,000 QPS on a single core with under 0.2 ms average latency, and 140,000 QPS on an eight-core AWS server. It publishes the benchmark script, which is more than most do. Envoy Gateway takes a different approach: each release ships a benchmark report that scales from 10 to 1,000 HTTPRoutes while stepping load up from a 100 requests-per-second baseline, with the Envoy Gateway controller capped at one CPU, which tells you how the control plane copes with config growth rather than how fast the proxy can go. Both are useful. Neither answers "which is faster than Kong?" I could not find a neutral, recent benchmark that runs Kong, APISIX, Envoy Gateway, Traefik and Tyk on the same hardware with the same plugin chain, so I won't print a ranking.

What I've seen hold up in general: all of these proxies (OpenResty/Nginx for Kong and APISIX, Envoy, Go for Traefik and Tyk) are fast enough that the gateway is rarely your bottleneck with an empty plugin chain. Latency appears when you add plugins that call out: an OIDC introspection per request, a Redis round trip for a global rate limit, a Lua or Wasm transformation on every body. Benchmark your plugin chain on your payloads. A vendor's "hello world" number tells you nothing about that.

AWS API Gateway: when managed is the right answer

If your backends are Lambda functions or a handful of services and you don't want to operate a gateway, AWS API Gateway is still hard to beat for effort. Pricing in us-east-1 per AWS's pricing page: HTTP APIs cost $1.00 per million requests for the first 300 million a month, and REST APIs cost $3.50 per million for the first 333 million, falling to $2.80 for the next 667 million. REST APIs carry the features people actually want (usage plans, API keys, caching, $0.038 an hour for a 1.6 GB cache), so most real comparisons are against the $3.50 number.

The arithmetic flips at volume. A billion REST requests a month costs roughly $3,000 before data transfer; a pair of self-managed gateway pods costs much less in compute, but you pay in on-call and upgrades. And it doesn't help with east-west traffic inside a cluster at all.

FAQ

Which API gateway is best for Kubernetes in 2026?

For a fully open-source stack with the widest Gateway API coverage, Envoy Gateway is the safest default: Apache-2.0, 36 HTTP extended features in its v1.6 conformance report, and a separate AI router if you need one. Pick APISIX if you want the richest open plugin set, including AI plugins. Pick Kong if you will pay for Enterprise and want its plugin catalogue and consumer model.

Is Kong Gateway free?

The open-source line is Kong 3.9, still patched (3.9.4 in October 2026) but not getting new minor versions. Kong's changelog says free mode was removed in Enterprise 3.10, so current kong-gateway images need a license for full function. Kong Operator itself remains Apache-2.0.

Kong vs APISIX: what is the difference?

Both run on OpenResty and both use a plugin model. APISIX is an Apache Software Foundation project under Apache-2.0 with recent AI plugins in the open build; Kong's newest features are Enterprise-only. Kong has an upstream Gateway API conformance report across five profiles, while APISIX has not filed one.

Do I still need an API gateway if I use Gateway API?

Gateway API handles routing, not policy. If you need per-consumer API keys, quotas, JWT validation or token budgets, you still need an implementation that provides them, through its own CRDs. If you only need routing and TLS, a plain Gateway API implementation is enough.

What I'd do this quarter

If I were starting fresh this quarter, I'd put Envoy Gateway in front of a new cluster and keep policy in its own directory of SecurityPolicy and BackendTrafficPolicy objects. If I already ran Kong, I'd stop pretending the 3.9 OSS line is a long-term plan, decide whether we are buying Enterprise or migrating, and move to Kong Operator either way, since that is where Kong's Gateway API work now happens. I'd also pull the conformance report for whatever we run and check that the features we depend on are actually listed, because that takes ten minutes and replaces a lot of vendor slides.

Related: Ingress NGINX Is Retired: What Replaces It and How to Choose in 2026, How to Migrate From ingress-nginx to Gateway API: Step-by-Step (2026) and Service Mesh in 2026: Istio Ambient vs Linkerd vs Cilium, Do You Need One?.