Recommended Envoy Deployment Types for Service Mesh Scenarios

Envoy can be used in many scenarios, and it is most useful when deploying a mesh across all hosts in a cross‑infrastructure environment. This section introduces three recommended deployment types of increasing complexity.

Service‑to‑Service

The simplest deployment uses Envoy as the communication bus for all internal traffic in a service‑oriented architecture (SOA). Envoy exposes several listeners for local traffic and service traffic.

Service‑to‑Service outbound listener

This listener is the port applications use to talk to other services in the infrastructure, e.g., http://localhost:9001. It handles HTTP/1.1 or HTTP/2 requests, using host or authority headers to route to remote clusters, and provides service discovery, load balancing, rate limiting, etc.

Service‑to‑Service inbound listener

This listener receives incoming requests from remote Envoys, e.g., http://localhost:9211, and routes them to local services on configured ports. It can support multiple application ports for HTTP and gRPC, and performs buffering, circuit breaking, and other traffic management functions.

By default the configuration uses HTTP/2 for all messenger communication, offering better performance through long‑lived connections and explicit reset notifications.

Optional external service outbound listener

Each external service that a local service talks to can be assigned a dedicated outbound port, e.g., http://localhost:9250 for DynamoDB, to avoid relying on host‑header overrides. Consistent local‑port routing is recommended.

Service discovery integration

It is recommended to use an external discovery service for cluster lookup, giving Envoy detailed information for load balancing and statistics collection.

Configuration templates

The source distribution includes example service configuration templates that closely resemble Lyft’s production setup. See the linked resources for details.

Service with Front‑Proxy

This deployment adds an Envoy front‑proxy in front of the service cluster, acting as an HTTP L7 edge reverse proxy. The front‑proxy terminates TLS, supports HTTP/1.1 and HTTP/2, provides full L7 routing, and forwards traffic to the service cluster using standard entry ports and discovery service for host lookup.

Configuration templates for the front‑proxy are also provided.

Service‑to‑Service with Front‑Proxy and Double‑Proxy

This pattern runs another Envoy cluster as a front‑proxy in a double‑proxy architecture. TLS termination and client connection handling occur at the edge proxy, after which connections are multiplexed onto long‑lived HTTP/2 connections to the data‑center cluster.

In the illustrated setup, the front‑proxy in region 1 authenticates to the front‑proxy in region 2 using mutual TLS and pinned certificates, allowing the region 2 proxy to trust normally untrusted inbound requests (e.g., X‑Forwarded‑For headers).

Configuration templates for the double‑proxy are included in the source distribution.