Envoy Proxy

Definition

Envoy Proxy is an open-source, high-performance proxy designed for cloud-native applications, originally built to handle service-to-service communication in large microservices architectures. It operates at both the network and application layers, providing load balancing, service discovery, observability, and traffic management capabilities that are commonly used as the data plane underneath service meshes and API gateways, independent of the language or framework each service is written in.

Overview

Envoy was created at Lyft to solve networking problems that emerged as the company decomposed a monolithic application into many independently deployed microservices. As service counts grew, ad hoc approaches to load balancing, retries, and observability between services became unmanageable, and Envoy was built as a dedicated, out-of-process proxy that every service could rely on for consistent network behavior, regardless of what language or framework the service itself was written in. That language independence was central to its design, since a polyglot microservices environment could not rely on networking logic embedded separately inside each service's own codebase. Mechanically, Envoy is typically deployed as a sidecar process running alongside each application instance, intercepting inbound and outbound traffic so the application does not need to implement networking concerns like retries, circuit breaking, or TLS termination itself. It exposes rich configuration through both static files and a dynamic configuration API, allowing a central control plane to push routing and policy updates to a fleet of Envoy proxies at runtime without restarting them. Envoy also emits detailed metrics, logs, and distributed tracing data by default, giving operators visibility into service-to-service traffic that would otherwise require instrumenting every individual application. Envoy's architecture as a configurable, control-plane-driven proxy made it the foundation for several service mesh projects, most notably Istio, which pairs Envoy sidecars with a control plane to manage traffic policy across a Kubernetes cluster. This distinguishes Envoy from simpler proxies like Nginx or Caddy, which are typically configured more statically and are less oriented toward dynamic, per-service microservices traffic management. Envoy is also used standalone as an API gateway or edge proxy, independent of any full service mesh. In practice, organizations use Envoy as the sidecar data plane within a service mesh like Istio, as a standalone edge proxy handling ingress traffic into a cluster, and as a foundation for building custom traffic management and observability tooling through its extensive filter and extension system. Its widespread adoption has also made its dynamic configuration API, xDS, a de facto standard that other proxies and control planes implement for interoperability. The trade-off is that Envoy's flexibility comes with configuration complexity; its full feature set and dynamic API are considerably more involved to operate directly than a simple static proxy configuration. Running Envoy as a sidecar in every pod also adds per-instance resource overhead across a cluster, which is part of why some newer approaches, including eBPF-based networking, aim to reduce or eliminate the need for a sidecar in every pod.

Key Features

• High-performance proxy operating at both network and application layers
• Commonly deployed as a sidecar alongside each service instance
• Dynamic configuration API (xDS) for runtime updates without restarts
• Built-in load balancing, retries, and circuit breaking
• Detailed metrics, logging, and distributed tracing emitted by default
• Extensible filter chain for custom traffic processing
• Foundation for service mesh data planes including Istio

Use Cases

Alternatives

Frequently Asked Questions

Related in DevOps