API Gateway Architectures in 2025, Envoy Gateway and Kong Compared

API Gateway Architectures in 2025, Envoy Gateway and Kong Compared

July 21, 2025 · 8 min read · by Muhammad Amal programming

TL;DR — Envoy Gateway 1.3 is the Gateway API native option with first-class gRPC support and a tighter Kubernetes integration. Kong 3.9 wins on plugin breadth and a battle-tested data plane. The choice usually comes down to whether your team prefers declarative CRDs or a richer GUI plus plugin marketplace.

I’ve stood up half a dozen production gateways in the last three years. The same conversation happens every time: someone insists on benchmarking RPS, someone else wants a feature matrix, and the actual decision ends up being driven by what the platform team can operate at 3 a.m. on a Sunday. This post tries to skip the benchmark theater and focus on the dimensions that matter.

Envoy Gateway and Kong are the two mainstream options I’d shortlist in 2025 for a Kubernetes-first organization. Apollo Router and AWS API Gateway have their places, but they’re solving different problems (federated GraphQL and managed-only, respectively). I’ll touch on both briefly at the end.

Before we get into the comparison, if you’re choosing a gateway primarily to expose internal gRPC services to the outside world, the patterns in streaming gRPC for real-time data and gRPC deep dive 2025 inform what your gateway needs to do well. Streaming support and protocol translation are where these gateways differ most.

1. The Shape of an API Gateway in 2025

Strip the marketing and an API gateway is doing four things:

Terminate inbound TLS, present a stable hostname
Route requests to upstream services based on path/host/header
Apply cross-cutting concerns (auth, rate limit, logging, retries)
Translate protocols where needed (HTTP/1.1 to HTTP/2, gRPC-Web to gRPC)

                            +-----------+
client (HTTPS, gRPC) ---->  | Gateway   |  ----> upstream A (gRPC)
                            | TLS term  |  ----> upstream B (HTTP/1.1 JSON)
                            | routing   |  ----> upstream C (HTTP/2)
                            | auth      |
                            | rate lim  |
                            | observ.   |
                            +-----------+

Every gateway worth running does all four. The differences are in how you express the configuration, where the policy lives, and what extension points exist.

2. Envoy Gateway 1.3

Envoy Gateway is the project the Envoy maintainers built to make Envoy operable as a Kubernetes Gateway API implementation. The Gateway API CRDs (Gateway, HTTPRoute, GRPCRoute) are the only configuration surface. There’s no separate config file format.

2.1 Install

helm install eg oci://docker.io/envoyproxy/gateway-helm \
  --version v1.3.0 \
  -n envoy-gateway-system --create-namespace

That’s it. The controller watches Gateway API resources and reconciles them into Envoy data plane pods.

2.2 A Minimal Gateway

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: eg
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: public
  namespace: edge
spec:
  gatewayClassName: eg
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            name: public-tls
    - name: grpc
      protocol: HTTPS
      port: 8443
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            name: public-tls

And a route:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: orders
  namespace: edge
spec:
  parentRefs:
    - name: public
      sectionName: https
  hostnames: ["api.example.com"]
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1/orders
      backendRefs:
        - name: orders
          namespace: prod
          port: 80

For gRPC, you use GRPCRoute:

apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
  name: orders-grpc
  namespace: edge
spec:
  parentRefs:
    - name: public
      sectionName: grpc
  hostnames: ["grpc.example.com"]
  rules:
    - matches:
        - method:
            service: orders.v1.OrderService
      backendRefs:
        - name: orders
          namespace: prod
          port: 9090

2.3 Policies as CRDs

Envoy Gateway extends Gateway API with policy CRDs. Rate limiting:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: BackendTrafficPolicy
metadata:
  name: orders-rl
  namespace: edge
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: orders
  rateLimit:
    type: Global
    global:
      rules:
        - clientSelectors:
            - headers:
                - name: x-api-key
                  type: Distinct
          limit:
            requests: 100
            unit: Minute

Auth via JWT validation:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: jwt-auth
  namespace: edge
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: orders
  jwt:
    providers:
      - name: my-idp
        issuer: https://idp.example.com/
        remoteJWKS:
          uri: https://idp.example.com/.well-known/jwks.json

2.4 Where Envoy Gateway Shines

gRPC and streaming first-class. GRPCRoute knows what a service and method are. Bidi streams pass through cleanly.
All-CRD config. Reviewable in PRs, diffable in GitOps, no separate UI required.
One Envoy. Same data plane as Istio and a thousand internal proxies. You can hire for it.

2.5 Where It’s Rough

Plugin ecosystem is thin. You get the policies Envoy Gateway ships, plus EnvoyFilter for raw Envoy config (powerful, brittle).
No GUI. That’s a feature for SRE teams and a blocker for some API product teams.
Custom Lua/Wasm filters require care. Doable but not the smooth path Kong gives you.

3. Kong 3.9

Kong has been the workhorse gateway in many organizations for years. Version 3.9 (released April 2025) sharpens the gRPC story and the Konnect SaaS control plane, but the core model is unchanged: routes, services, plugins, consumers.

3.1 Install (Kong on Kubernetes)

helm repo add kong https://charts.konghq.com
helm install kong kong/kong --version 2.41.0 -n kong --create-namespace \
  --set ingressController.installCRDs=false \
  --set proxy.type=LoadBalancer

3.2 Kong Gateway API Support

Kong 3.9 supports both its own CRDs (KongIngress, KongPlugin, etc.) and the upstream Gateway API. I recommend Gateway API for new work; the Kong-native CRDs are still supported but feel legacy.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: orders
  namespace: edge
  annotations:
    konghq.com/plugins: rate-limit-100
spec:
  parentRefs:
    - name: kong
  hostnames: ["api.example.com"]
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1/orders
      backendRefs:
        - name: orders
          namespace: prod
          port: 80
---
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rate-limit-100
  namespace: edge
plugin: rate-limiting
config:
  minute: 100
  policy: redis
  redis_host: redis.cache

3.3 Plugin Catalog

This is Kong’s competitive moat. The hub ships ~100 plugins: auth (JWT, OAuth, OIDC, mTLS, key-auth, LDAP, ACL), rate limiting, transformations (request/response body and header rewrites), logging (Datadog, Splunk, Loki, syslog), security (bot detection, IP restriction), and so on. Most production needs map to a plugin that already exists.

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: jwt-auth
plugin: jwt
config:
  key_claim_name: iss
  claims_to_verify: ["exp"]

3.4 Where Kong Shines

Plugin breadth. When a product team says “we need to add a request signature header for the partner API,” there’s usually a plugin.
Konnect. The SaaS control plane gives you a GUI, RBAC, and analytics out of the box.
Hybrid mode. Run control plane in Konnect, data plane in your cluster. Convenient for multi-cluster setups.

3.5 Where It’s Rough

gRPC streaming is OK, not great. Unary works fine. Bidi has edge cases around metadata propagation that Envoy handles cleaner.
Custom plugins in Go/Lua. Lua is fine if your team writes Lua. Go plugins exist but the dev loop is slower than Envoy’s Wasm story.
Cost. OSS Kong is free; Konnect and Enterprise plugins are not.

4. Decision Framework

If you can answer “yes” to most of these, lean Envoy Gateway:

You’re already running Envoy or Istio
gRPC and streaming are central to your traffic
Your team prefers declarative GitOps over GUI ops
You’re comfortable writing the occasional EnvoyFilter

If you can answer “yes” to most of these, lean Kong:

You need a wide plugin catalog with minimal in-house dev
Product or API-management teams want a GUI
Traffic is mostly REST or unary RPC
You’re willing to pay for Konnect or Enterprise

For multi-tenant SaaS platforms with rich auth requirements, Kong’s plugin ecosystem usually wins. For backend platform teams running gRPC meshes, Envoy Gateway usually wins.

5. Common Pitfalls

5.1 Putting Auth in Both the Gateway and the Service

You end up validating tokens twice, with subtly different settings, and the second validation eventually drifts. Pick one place — usually the gateway for coarse auth and the service for fine-grained authorization — and document it. See securing internal microservices with JWT and SPIFFE for the internal half of this picture.

5.2 Treating the Gateway as a Service Mesh

Gateways do north-south. Service meshes do east-west. Trying to do both with one tool means you’ll bend whichever side fits worse. Envoy Gateway plus Istio (or Linkerd) is fine; Kong plus a mesh is fine; just don’t ask the gateway to mesh.

5.3 No Per-Route Timeouts

Default Envoy stream timeout is 15 minutes. Default Kong upstream timeout is 60 seconds. Both can be too long or too short depending on the route. Set per-route timeouts explicitly.

5.4 Ignoring Connection Draining on Deploys

Both gateways support graceful drain, but you have to configure it. Without it, a rolling deploy drops in-flight requests. Look up the chart values: Envoy Gateway uses terminationGracePeriodSeconds and preStop hooks; Kong has --graceful-shutdown flags.

5.5 Underestimating CRD Drift

Both projects evolve CRDs faster than your platform team will be comfortable with. Pin chart versions. Test upgrades in staging. Don’t auto-upgrade.

6. Troubleshooting

6.1 `503 no healthy upstream`

Envoy default. The upstream cluster has zero endpoints with passing health checks. Check Kubernetes service endpoints (kubectl get endpointslices), then health-check config. If endpoints exist, the gateway is filtering them — look for outlier detection ejecting backends.

6.2 gRPC Calls Get HTTP 200 With Empty Body

Almost always content-type confusion at the gateway. application/grpc got rewritten to application/grpc-web somewhere. Check transformation plugins or BackendTLSPolicy settings.

6.3 Rate Limiting Doesn’t Count Across Pods

Local rate limiting in Envoy counts per-pod. Global rate limiting needs the Envoy ratelimit service or Redis. Kong’s policy: local has the same trap; switch to policy: redis.

7. Apollo Router and AWS API Gateway, Briefly

Apollo Router 1.55 is the answer if you’re doing federated GraphQL across many subgraphs. It’s not a general-purpose API gateway; it’s a GraphQL composer that happens to terminate at the edge. Pair it with one of the above for REST/gRPC, don’t try to make it do double duty.

AWS API Gateway and similar managed offerings are great when you need an edge in front of Lambdas with zero infrastructure. They get expensive at scale, lack first-class Kubernetes integration, and don’t do gRPC well. Reasonable for small surfaces, not for the bulk of a microservices fleet.

8. Wrapping Up

Both Envoy Gateway 1.3 and Kong 3.9 are credible choices in 2025. The “right” one depends on your team’s operating model, not on a feature matrix. Take whichever your platform team can run confidently, and design your services so the gateway choice is reversible (no leaking gateway-specific extensions into your contracts).

The Gateway API spec is worth reading regardless of which gateway you pick; both implementations are converging on it, and your config will be more portable for the effort. Next up in the series, we look at how schema-first development with buf keeps your contracts honest across gateway boundaries.