Using Envoy Gateway with an AWS ALB or NLB Load Balancer

Envoy Gateway Is the Load Balancer

When deploying Envoy Gateway (EG), you want to be sure you’re using the best architecture, to get the most out of it, and the lowest latency and highest reliability for your users. As I work on Tetrate Enterprise Gateway for Envoy (TEG), Tetrate’s enterprise-ready distribution of Envoy Gateway, I’m often asked how to best use it alongside the familiar AWS load balancer products, especially the ALB.

This will be a pretty short post, because the answer is: you don’t need an ALB. Envoy Gateway uses the Envoy proxy to handle the requests coming into your clusters. Envoy is a layer 7 proxy—i.e., it understands the HTTP (or gRPC, etc.) layer of the requests, and can route on their properties, like HTTP paths, in addition to providing per-path observability and so forth. Thus, it provides many of the features of an ALB (probably all the ones you use), and more besides. In addition, it’s an open-source, community-led, CNCF project, which runs under your control in your own clusters.

Bridge the Gap

We still need a load balancer (LB) of some sort, to bridge the gap from the internet into our clusters, so that requests can get to EG. (From a technical point of view: there’s a Service targeting the EG proxy Pods, of type: LoadBalancer – we do still need a cloud provider LB to be made to satisfy this.) But all that’s needed is the minimal, cheapest, and fastest LB, which is definitely not an ALB.

If you configure nothing special, and just leave your cluster’s cloud controller (built-in if you use EKS) to make the LB, you’ll get the older AWS Classic Load Balancer, which is better than an ALB. However ideally, we’d use the newer low-level (layer three) LB, a NLB or Network Load Balancer. I’ve written a previous blog about how to set this up.

Get in Touch

While I’m here, if there are any ALB features you’re using that aren’t in upstream EG or provided yet by TEG, please get in touch and let us know about your use case.