I'm cleaning up some older technologies in our EKS clusters on AWS, as our company has decided to transition from ingress-nginx to Envoy Gateway, which has been a great help so far. However, I'm curious about the implications of being cloud-agnostic in networking when it comes to this transition. Specifically, I'm wondering if Envoy Gateway eliminates the need for the AWS Load Balancer Controller. Is Envoy Gateway's external Network Load Balancer (NLB) supposed to replace the external Application Load Balancer (ALB) provided by the AWS Load Balancer Controller? Just to clarify, we currently use the AWS Load Balancer Controller for setting up an external ALB while Envoy Gateway is used for the internal/external NLB setup.
3 Answers
I believe the controller helps reconcile services of type LoadBalancer to AWS load balancers. It also functions as a semi-ingress controller by exposing ingress rules on an ALB. If you're migrating, I'd recommend utilizing Envoy Gateway with NLB since it supports HTTP/3 with TCP/UDP listeners. Plus, keep an eye out for dynamic modules that are likely coming to Envoy Gateway in future releases for added functionality!
Just to clarify, Envoy Gateway doesn’t replace the AWS Load Balancer Controller; they operate at different layers. The AWS LBC provisions the actual AWS load balancers (ALB/NLB) while Envoy Gateway acts as the ingress controller that manages routing within your cluster.
Envoy Gateway requires a LoadBalancer service type to request a load balancer, which is provisioned by the AWS Load Balancer Controller. They serve different purposes, so you’ll still need the AWS LBC for provisioning the external load balancer that directs traffic to your Envoy Gateway setup.
Definitely look into adding a WAF with something like Coraza WAF, especially for internal traffic. It’s a smart move.