L3/L4 filter architecture: At its core, Envoy is an L3/L4 network proxy. A pluggable  chain mechanism allows filters to be written to perform different TCP proxy tasks and inserted into the main server. Filters have already been written to support various tasks such as raw ,, , etc.

HTTP L7 filter architecture: HTTP is such a critical component of modern application architectures that Envoy  an additional HTTP L7 filter layer. HTTP filters can be plugged into the HTTP connection management subsystem that perform different tasks such as , ,, sniffing Amazon’s , etc.

First class HTTP/2 support: When operating in HTTP mode, Envoy  both HTTP/1.1 and HTTP/2. Envoy can operate as a transparent HTTP/1.1 to HTTP/2 proxy in both directions. This means that any combination of HTTP/1.1 and HTTP/2 clients and target servers can be bridged. The recommended service to service configuration uses HTTP/2 between all Envoys to create a mesh of persistent connections that requests and responses can be multiplexed over. Envoy does not support SPDY as the protocol is being phased out.

HTTP L7 routing: When operating in HTTP mode, Envoy supports a  subsystem that is capable of routing and redirecting requests based on path, authority, content type,  values, etc. This functionality is most useful when using Envoy as a front/edge proxy but is also leveraged when building a service to service mesh.

gRPC support:  is an RPC framework from Google that uses HTTP/2 as the underlying multiplexed transport. Envoy  all of the HTTP/2 features required to be used as the routing and load balancing substrate for gRPC requests and responses. The two systems are very complementary.

MongoDB L7 support:  is a popular database used in modern web applications. Envoy L7 sniffing, statistics production, and logging for MongoDB connections.

DynamoDB L7 support:  is Amazon’s hosted key/value NOSQL datastore. Envoy L7 sniffing and statistics production for DynamoDB connections.

Service discovery:  is a critical component of service oriented architectures. Envoy supports multiple service discovery methods including asynchronous DNS resolution and REST based lookup via a .

Health checking: The  way of building an Envoy mesh is to treat service discovery as an eventually consistent process. Envoy includes a  subsystem which can optionally perform active health checking of upstream service clusters. Envoy then uses the union of service discovery and health checking information to determine healthy load balancing targets. Envoy also supports passive health checking via an  subsystem.

Advanced load balancing:  among different components in a distributed system is a complex problem. Because Envoy is a self contained proxy instead of a library, it is able to implement advanced load balancing techniques in a single place and have them be accessible to any application. Currently Envoy includes support for , ,  via an external rate limiting service, , and . Future support is planned for request racing.

Front/edge proxy support: Although Envoy is primarily designed as a service to service communication system, there is benefit in using the same software at the edge (observability, management, identical service discovery and load balancing algorithms, etc.). Envoy includes enough features to make it usable as an edge proxy for most modern web application use cases. This includes  termination, HTTP/1.1 and HTTP/2 , as well as HTTP L7 .

Best in class observability: As stated above, the primary goal of Envoy is to make the network transparent. However, problems occur both at the network level and at the application level. Envoy includes robust  support for all subsystems.  (and compatible providers) is the currently supported statistics sink, though plugging in a different one would not be difficult. Statistics are also viewable via the  port. Envoy also supports distributed  via thirdparty providers.

Dynamic configuration: Envoy optionally consumes a layered set of . Implementors can use these APIs to build complex centrally managed deployments if desired.