Data-Plane Proxies: Envoy & Kong

Before naming the two tools, one distinction organizes everything in this day. In any traffic-handling system the work splits into two layers. The data plane is the part that actually touches every request — receiving it, applying rules, forwarding it, returning the response. The control plane is the part that configures the data plane — it decides the rules, knows which services exist, and pushes that configuration down, but it never sits in the path of an individual request.

The reason this split matters: the data plane must be fast and always up because every request depends on it, while the control plane can be slower and briefly unavailable without dropping traffic — if it dies, proxies keep running on their last-known config. Envoy and Kong are both fundamentally data-plane proxies, but they are paired with different control planes and deployed in different shapes. Keep the two layers separate in your head and the rest of the day falls into place.

Envoy is a high-performance open-source proxy that operates at both L4 (the transport layer — raw TCP/UDP connections) and L7 (the application layer — understanding HTTP, gRPC, and their contents). Originally built at Lyft, it is the data plane behind most modern service meshes, including Istio. Its job is to sit next to your service and handle all network traffic in and out of it, applying policies without your application code knowing.

Envoy's core vocabulary maps directly onto how a request flows through it:

• Listener — a port Envoy listens on for incoming connections. A request arrives at a listener.
• Filter (and filter chain) — the pluggable steps a request passes through: HTTP parsing, authentication, rate limiting, routing decisions. Filters are how Envoy's behavior is composed; you enable and order the filters you need.
• Cluster — a named group of upstream hosts (the instances of a backend service) that Envoy can send traffic to, with its own load-balancing and health-checking.
• Upstream / downstream — downstream is where the request came from (the client); upstream is where it is going (the backend). Envoy always sits between the two.

A request enters a listener, walks the filter chain, and is routed to a cluster, which load-balances it to an upstream host. That is the whole model.

Two Envoy ideas make it fit a service mesh: how it is configured and how it is deployed. Both are what let a mesh manage hundreds of proxies without hand-editing config files.

xDS is Envoy's set of discovery service APIs — the "x" stands for the family (LDS for listeners, CDS for clusters, EDS for endpoints, and so on). Instead of reading a static config file and needing a restart to change, Envoy can ask a control plane over xDS "what listeners should I have? what clusters? which healthy endpoints?" and receive updates live, applying them without dropping connections. This dynamic configuration is what lets a control plane reconfigure a whole fleet of Envoys in seconds as services scale up, move, or fail.

The sidecar model is the deployment shape: an Envoy proxy is deployed next to each service instance — in Kubernetes, as a second container in the same pod — and the application's traffic is transparently routed through its local Envoy. Every service gets its own dedicated proxy.

Because every service has a local Envoy, the mesh can apply retries, timeouts, mutual-TLS encryption, and traffic-shifting to all service-to-service (east-west) traffic — the application code stays oblivious, and the control plane programs every sidecar uniformly through xDS. This is precisely the service mesh the API-gateway day named as the counterpart to the edge gateway.

Kong is an open-source API gateway built on top of nginx (a battle-tested web server and reverse proxy) and OpenResty (nginx extended with the Lua scripting language). Where Envoy is most at home as a fleet of sidecars inside a mesh, Kong is most at home as a centralized gateway at the edge — the single front door from the API-gateway day — through which external client traffic enters your system.

Kong's defining feature is its plugin ecosystem. Cross-cutting concerns are packaged as plugins you enable and configure rather than code: authentication (key-auth, JWT, OAuth2), rate limiting, request/response transformation, logging, caching, and many more. You compose a gateway's behavior by turning on the plugins you need on the routes you choose.

Kong models traffic around a small set of objects: a service (an upstream backend), a route (a rule matching incoming requests to a service), and plugins (attached to services, routes, or globally) that run on matching traffic. This is the API-gateway pattern from the API-gateway day made concrete, with the gateway's responsibilities delivered as configurable plugins.

Both proxies favor declarative configuration — you describe the desired end state and let the tool make it so — rather than issuing imperative commands step by step. For Kong this is often a single YAML file (used in its "DB-less" mode) that defines every service, route, and plugin; you apply the file and Kong's data plane matches it exactly.

_format_version: "3.0"
services:
  - name: user-service
    url: http://user-service:8080
    routes:
      - name: users-route
        paths:
          - /users
    plugins:
      - name: rate-limiting
        config:
          minute: 1000
      - name: key-auth

This one file declares a backend (user-service), a route that sends /users to it, and two plugins — rate limiting at 1000 requests per minute and API-key authentication — active on that route. The whole gateway configuration lives in version control, is reviewed like code, and is applied atomically. Envoy's static config and its dynamic xDS-served config follow the same philosophy: the control plane (or a file) states the desired listeners, clusters, and routes, and the proxy converges to them.

Both tools sit inside the data-plane/control-plane split from the top of the day, but they wear it differently. Understanding each split clarifies when you would reach for one or the other.

Kong ships its own control plane. In its hybrid deployment, Kong runs as separate control-plane nodes (which hold the configuration and admin API) and data-plane nodes (the nginx proxies that handle live traffic). You configure the control plane; it distributes config to the data-plane nodes, which keep serving traffic even if the control plane is temporarily down.

Envoy deliberately ships no control plane of its own — it only implements the xDS APIs and expects some external control plane to program it. Istio is the most common one; it is the brain that discovers services and pushes routing, security, and policy to the fleet of Envoy sidecars.

The essential contrast: Kong is a fairly complete gateway product — control plane plus data plane in one project — while Envoy is a superb data-plane building block that a separate control plane (usually Istio) turns into a mesh. Neither is "better"; they occupy different rungs of the stack.

Envoy and Kong are both L7 proxies that can route, authenticate, rate-limit, and observe traffic, so their capabilities genuinely overlap — you could use either at the edge. They differ most in their center of gravity: the typical deployment shape and the traffic they are built to govern.

The overlap is real: Istio's edge component (its ingress gateway) is itself an Envoy, so Envoy can play the edge role Kong usually plays, and Kong can be deployed closer to services. But the grain of each tool points a clear way — Envoy toward blanketing a service mesh with per-service sidecars, Kong toward a rich, plugin-driven front door.

The choice follows from the traffic you are trying to govern and how much you want to operate. The lead-in rule: match the tool to whether your primary need is the edge (managing external API consumers) or the mesh (securing and controlling internal service-to-service calls).

Pick Kong when:

• Your main need is a classic API gateway at the edge — authenticating external developers, issuing API keys, rate-limiting consumers, transforming requests.
• You want cross-cutting features as ready-made plugins you configure, not infrastructure you assemble.
• You value a single, self-contained product with its own control plane and admin tooling.

Pick Envoy (in a mesh like Istio) when:

• Your main need is governing service-to-service traffic across many internal services — uniform mTLS, retries, timeouts, and traffic-shifting for canary releases.
• You want per-service policy applied by a sidecar next to every workload, programmed centrally.
• You are already on Kubernetes and want the mesh to handle east-west concerns transparently.

And often you use both: an edge gateway (Kong, or an Envoy-based ingress) for north-south client traffic, and an Envoy mesh for east-west service traffic behind it. The two are not rivals so much as neighbors covering different halves of the traffic map. Rule of thumb: edge and API management lean Kong; internal mesh and uniform service-to-service policy lean Envoy.

• Every traffic system splits into a data plane (touches every request, must be fast and always up) and a control plane (configures the data plane, can be slower and briefly down).
• Envoy is a high-performance L4/L7 proxy and the data plane behind service meshes like Istio; its model is listeners → filter chains → clusters → upstream hosts.
• Envoy is configured dynamically over the xDS APIs and deployed as a sidecar next to each service, so a control plane can program a whole fleet live and apply mTLS/retries to all east-west traffic.
• Kong is an API gateway built on nginx/OpenResty, deployed as a centralized edge front door, with cross-cutting concerns delivered as configurable plugins.
• Both favor declarative configuration — Kong via a YAML file of services, routes, and plugins; Envoy via static config or xDS-served desired state.
• Kong ships its own control plane (control-plane and data-plane nodes); Envoy ships none and relies on an external control plane such as Istio.
• They overlap as L7 proxies but differ in center of gravity: Envoy for east-west mesh traffic via sidecars, Kong for north-south edge API management.
• Pick Kong for edge API management, Envoy-in-a-mesh for internal service-to-service policy — and frequently run both, one at the edge and one inside.

• [ ] I can explain the data-plane/control-plane split and why the data plane must stay up if the control plane dies.
• [ ] I can define Envoy and name its core objects: listener, filter, cluster, upstream/downstream.
• [ ] I understand what xDS provides (live dynamic config) and what the sidecar model is.
• [ ] I can define Kong and explain its nginx/OpenResty base and plugin ecosystem.
• [ ] I can read a declarative Kong YAML config and explain what it configures.
• [ ] I can contrast Kong's built-in control plane with Envoy's reliance on an external one (Istio).
• [ ] I can list the main ways Envoy and Kong differ and where they overlap.
• [ ] I can decide when to pick Kong, when to pick Envoy-in-a-mesh, and why you might use both.