Envoy Proxy

What is Envoy?

Envoy is a high-performance, open-source service proxy designed for cloud-native, distributed architectures. Originally built at Lyft and now a graduated CNCF project, it operates at Layer 7 (application layer), understanding HTTP, gRPC, and other protocols, and provides advanced traffic management — routing, load balancing, health checking, retries, circuit breaking, rate limiting — plus deep observability (metrics, tracing, logging) for the traffic flowing through it. Its most important role in modern infrastructure is as the data plane that actually moves and manages requests inside service meshes (like Istio) and many API gateways, making it one of the foundational pieces of cloud-native networking even though most engineers interact with it indirectly.

The sidecar model and control-plane/data-plane split

Envoy’s signature deployment pattern is the sidecar proxy: an Envoy instance runs alongside each service (in Kubernetes, as a container in the same pod), and all network traffic to and from that service flows through its Envoy sidecar. This is powerful because it moves networking concerns — retries, timeouts, circuit breaking, load balancing, mutual-TLS encryption, traffic routing, and telemetry — out of the application code and into the proxy layer, so services get consistent, sophisticated networking behavior without each app reimplementing it, in any language. This is exactly the value proposition of a service mesh, and it rests on the control-plane/data-plane split: Envoy is the data plane (the proxies that do the actual traffic handling), while a control plane (Istio, or others) configures and coordinates all the Envoy proxies centrally — you set policies once in the control plane, and it programs every Envoy. Understanding this split clears up a common confusion: Istio isn’t a competitor to Envoy; Istio uses Envoy as its data plane. Envoy’s dynamic configuration APIs (the xDS APIs) are what let a control plane reconfigure proxies on the fly without restarts, which is central to its design.

Where it fits, and the realities

Envoy is used in several roles: as service-mesh sidecars (its highest-profile use), as an edge/API gateway (Envoy Gateway, Contour, and others build gateways on it; it manages north-south traffic into a cluster), and as a general-purpose L7 load balancer/proxy. It competes/overlaps with older proxies (Nginx, HAProxy) but was purpose-built for dynamic, cloud-native environments — its dynamic configuration, first-class observability, and protocol support (HTTP/2, gRPC, HTTP/3) suit ephemeral, constantly-changing microservice topologies better than proxies designed for static configs. The realities to weigh: Envoy itself is powerful but complex to configure directly — its raw configuration is notoriously verbose and intricate, which is why most people use it through a higher-level system (Istio, a gateway) that generates Envoy config for them rather than hand-writing it; reaching for raw Envoy when a managed layer would do is a common way to sign up for unnecessary complexity. The sidecar model has costs — each sidecar consumes CPU/memory (multiplied across every pod) and adds a small per-hop latency, which at scale is non-trivial, and this overhead is exactly what’s driving the newer “sidecar-less” / ambient mesh approaches (Istio ambient mode) that reduce the per-pod proxy footprint. And a service mesh (with Envoy as data plane) adds real operational complexity, so it’s worth adopting only when you genuinely need its capabilities (mTLS everywhere, fine-grained traffic control, uniform observability across many services) rather than by default for a small system. The recurring mistakes: hand-configuring raw Envoy when a control plane should generate it, adopting a full mesh (and its sidecar overhead) for a system too small to need it, and underestimating the resource cost of sidecars at scale.

What people get wrong

• Configuring raw Envoy directly — its config is famously complex and verbose; it’s designed to be programmed by a control plane (Istio) or gateway, not hand-written for most use cases.
• Confusing Envoy with the mesh: Envoy is the data plane proxy; Istio and others are the control plane that configures it — they’re layers of one system, not competitors.
• Ignoring sidecar overhead — an Envoy per pod multiplies CPU/memory and adds per-hop latency; at scale this is significant, which is why sidecar-less/ambient mesh models are emerging.

Primary source: Envoy documentation