Is using Amazon API Gateway to route requests to workloads running on Amazon EKS a common architecture? I often see examples of API Gateway integrated with Lambda, ECS, or a load balancer, but relatively few discussions about using it with Kubernetes. If EKS is running the microservices, what does the usual request path look like, and when would API Gateway be useful compared with routing directly through a load balancer and Kubernetes ingress?
2 Answers
When a team is already using Kubernetes, an ingress controller often provides the routing, authentication, and other application-facing features they need. It can be managed alongside the Kubernetes resources and deployed with the workloads. A common setup is therefore an NLB pointing at one or more ingress controllers inside the cluster. API Gateway can still be useful for features such as centralized authentication, throttling, request transformation, usage plans, or exposing a consistent API across several backend systems, but it may not add enough value if the ingress layer already covers those requirements.
Yes, this is a common pattern, although it is usually described as API Gateway in front of a load balancer rather than specifically as API Gateway to EKS. API Gateway sends traffic to an ALB or other supported endpoint, and that load balancer can route to an ingress controller and services inside the cluster. API Gateway does not need to know whether the backend is running on EKS, ECS, or somewhere else.
Would putting API Gateway in front of an ALB provide enough value to justify the extra hop? The request path would be Route 53 → API Gateway → ALB → ingress → service. API Gateway could handle authentication and other edge concerns, but removing it would reduce latency and simplify the path.