Envoy Proxy is an open-source, high-performance edge and service proxy designed for modern cloud-native architectures. Originally developed at Lyft by Matt Klein and his team in 2016, Envoy was created to solve network visibility and resilience challenges as monolithic codebases transitioned into microservices. Envoy joined the Cloud Native Computing Foundation (CNCF) in 2017 and graduated in 2018, establishing itself alongside Kubernetes and Prometheus as core infrastructure in modern distributed systems.
Written in C++ for maximum throughput and predictable latency, Envoy functions as a communication bus for microservices. It operates at both Layer 3/Layer 4 (IP and TCP/UDP) and Layer 7 (application protocols such as HTTP/1.1, HTTP/2, HTTP/3, and gRPC). Because Envoy is deployed as an out-of-process architectural component alongside application runtimes, it provides consistent networking, telemetry, and security capabilities regardless of the programming languages used in backend services.
Why Modern Architectures Require Envoy
Traditional monolithic architectures routed ingress traffic through hardware or software appliances, leaving inter-module communication to internal operating system processes or in-memory calls. In distributed microservice deployments, however, network calls replace in-process method invocation. This shift introduces partial failures, unpredictable tail latency, and complex debugging scenarios.
Prior to Envoy, organizations attempted to solve these network concerns by embedding client libraries into each language runtime (for example, Netflix Hystrix or Finagle). This approach suffered from notable limitations:
- Language lock-in: Maintaining feature parity for circuit breaking, retries, and metrics across polyglot stacks (such as Java, Go, Python, and Node.js) required immense developer bandwidth.
- Complex upgrades: Deploying a security patch or algorithmic update to connection pooling required rebuilding and redeploying every application service.
- Fragmented observability: Discrepancies in metric implementations produced inconsistent dashboards and tracing headers across systems.
Envoy solves these challenges by extracting network primitives into an independent, self-contained sidecar process. Applications communicate with their local localhost proxy, which transparently handles service discovery, encryption, routing, and metric emission.
Core Architecture and the Threading Model
Envoy uses a single-process, multi-threaded architectural pattern designed to process high request volumes with minimal resource consumption. It relies on an event-driven, non-blocking asynchronous event loop powered by libevent.
+--------------------------------+
| Main Thread |
| (xDS, Admin, Config Updates) |
+---------------+----------------+
|
+------------------------+------------------------+
| | |
v v v
+-----------------+ +-----------------+ +-----------------+
| Worker Thread | | Worker Thread | | Worker Thread |
| (Event Loop) | | (Event Loop) | | (Event Loop) |
+--------+--------+ +--------+--------+ +--------+--------+
| | |
v v v
Client Conns Client Conns Client Conns
The Main Thread
The main thread coordinates control-plane activities. It initiates startup routines, manages the local administrative HTTP console, processes dynamic configuration updates, handles signals, and maintains global TLS certificate stores. The main thread does not process client network data directly, ensuring administrative overhead never blocks request paths.
Worker Threads
During initialization, Envoy spawns worker threads, typically matching the number of hardware CPU cores available. Each worker thread runs an independent, non-blocking event loop. When a client opens a connection, the operating system assigns the socket to a specific worker thread (often through SO_REUSEPORT kernel load balancing).
Once assigned, that connection remains bound to that single worker thread throughout its entire lifecycle. This design eliminates cross-thread data synchronization and lock contention on the active request path, enabling linear performance scaling across available CPU cores.
The Filter Chain: How Envoy Processes Traffic
Envoy handles data using a pipeline of pluggable filters organized inside listeners. A Listener binds to a local IP address and port to receive inbound connections. When traffic arrives, Envoy executes filters sequentially across three distinct layers:
- Listener Filters: Execute first to extract protocol metadata prior to TLS handshakes (for example, extracting SNI hostnames or evaluating PROXY protocol headers).
- Network (L3/L4) Filters: Operate on raw TCP/UDP byte streams. Examples include TLS termination, raw TCP proxying, and the HTTP Connection Manager.
- HTTP (L7) Filters: Operate when the HTTP Connection Manager handles the stream. These inspect and modify HTTP requests and responses, applying tasks like routing, header transformation, CORS handling, local rate limiting, authentication, and WebAssembly (Wasm) extensions.
# Conceptual Envoy listener snippet with an HTTP filter chain
static_resources:
listeners:
- name: ingress_listener
address:
socket_address:
address: 0.0.0.0
port_value: 10000
filter_chains:
- filters:
- name: envoy.filters.network.http_connection_manager
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
stat_prefix: ingress_http
route_config:
name: local_route
virtual_hosts:
- name: backend_service
domains: ["*"]
routes:
- match:
prefix: "/"
route:
cluster: service_backend
http_filters:
- name: envoy.filters.http.router
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
The terminal filter in an HTTP chain is typically the Router filter, which forwards the request to an upstream Cluster (a named group of backend endpoints sharing load-balancing policies).
Dynamic Configuration via xDS APIs
Early software proxies required file rewrites and process reloads (or restarts) to register new backends or update routes. Under high load, process reloads introduce connection drops and memory spikes.
Envoy introduced dynamic discovery services collectively termed the xDS protocol. Using gRPC streaming APIs, Envoy polls or subscribes to a centralized control plane for real-time updates without restarting the proxy process:
| Discovery Service | Protocol Acronym | Responsibility |
|---|---|---|
| Listener Discovery Service | LDS | Dynamically adds, updates, or deletes listeners and filter chains. |
| Route Discovery Service | RDS | Updates Layer 7 routing tables and HTTP virtual hosts dynamically. |
| Cluster Discovery Service | CDS | Discovers upstream service clusters and their load-balancing settings. |
| Endpoint Discovery Service | EDS | Dynamically updates healthy IP addresses and ports within an upstream cluster. |
| Secret Discovery Service | SDS | Delivers and rotates TLS certificates and cryptographic keys without downtime. |
These discovery services decouple the data plane (the Envoy binary processing packets) from the control plane (the management engine maintaining routing policy, such as Istio, Consul, or custom controllers).
Primary Deployment Topologies
Envoy fits several distinct topologies across enterprise architectures:
1. Ingress and API Gateway
Positioned at network perimeters, Envoy accepts external internet traffic, terminates public TLS, enforces authentication (such as OAuth/OIDC and JWT validation), and routes requests into internal clusters. Projects like Envoy Gateway implement the Kubernetes Gateway API standard directly using Envoy as the underlying data plane.
2. Service Mesh Sidecar
In a service mesh deployment (such as Istio), an Envoy instance is colocated alongside every application container inside the same Kubernetes pod. All inbound and outbound pod traffic flows through the local Envoy sidecar. This enables transparent mutual TLS (mTLS), distributed tracing header propagation, circuit breaking, and Canary deployments across services.
3. Middle Proxy and Internal Load Balancer
For complex VPC environments, Envoy can serve as an internal load-balancing tier between web tiers and internal stateful backends, providing advanced outlier detection, health checking, and gRPC load balancing across availability zones.
Specialized Gateways and Modern Protocol Demands
While Envoy excels at generic Layer 4 and Layer 7 network routing, modern workloads increasingly demand domain-specific intelligence. For example, AI-driven applications relying on Large Language Models (LLMs) introduce operational challenges that standard HTTP proxies were not designed to address: token-based rate limiting, model provider fallbacks, prompt-response caching, and context management protocol support.
Consequently, specialized gateways have emerged to complement general-purpose proxies. Bifrost, an open-source AI gateway written in Go, operates at this layer by providing unified routing across multi-provider AI APIs, streaming token governance, and semantic caching. Beyond routing, Bifrost applies governance and security controls (virtual keys, budgets, guardrails, audit logs) centrally, and Bifrost Edge extends that same governance and security to AI traffic on employee machines, with endpoint enforcement on each device.
In sophisticated architectures, organizations frequently deploy Envoy at the perimeter for network-layer security and ingress TLS, pairing it with specialized application gateways to manage domain-specific protocols internally.
Summary
Envoy Proxy has transformed modern cloud-native networking by turning complex distributed communication into an observable, resilient, and manageable layer. Its single-process multi-threaded architecture, extensible filter chain, and real-time xDS configuration APIs allow engineering teams to operate resilient service meshes and high-throughput API gateways without tying network policies to application runtimes.
Top comments (0)