Is using Amazon API Gateway in front of services running on Kubernetes a common architecture? I often see examples of API Gateway connected to Lambda, container services, or a load balancer, but much less discussion about API Gateway connecting to an EKS-based application. If Kubernetes is hosting multiple microservices, what are the usual ways to expose them externally? Are there specific benefits or drawbacks to using API Gateway in front of a load balancer and Kubernetes ingress compared with sending traffic directly to the load balancer?
2 Answers
Yes, it’s a common pattern, but API Gateway normally connects to a load balancer rather than directly to Kubernetes. The load balancer can route to an ingress controller, which then sends traffic to the appropriate services in the cluster. API Gateway generally doesn’t need to know whether the back end is EKS, another container platform, or something else.
Many Kubernetes deployments use an ingress controller as the main entry point, and some teams use a Kubernetes-native API gateway instead. In that setup, an NLB or ALB points to the ingress controller, which routes requests inside the cluster. This is often simpler and may reduce latency and cost compared with adding API Gateway, especially when the API Gateway features are not needed.
The extra gateway layer is mainly justified by its edge and API-management capabilities. If all you need is TLS termination and routing to Kubernetes services, going directly through a load balancer and ingress is usually sufficient.
A typical flow would be Route 53 → API Gateway → ALB or NLB → Kubernetes ingress → service. API Gateway can provide features such as authentication, throttling, request validation, transformations, and usage plans, so it may still be useful even when an ingress controller handles internal routing.