If we want to use a specific deployment strategy for each service, it would be great if this is done very close to the service (like in the service’s definition itself!). The problem with this setup is we have the power of an API Gateway, but it’s far away from our cluster and our services. We could as well benefit from WAF support for the managed API Gateway.
That would be a correct setup for the AWS API Gateway on EKS. With the support of NLB in Kubernetes 1.9+, we can create a Kubernetes service of type LoadBalancer With an annotation indicating that It’s a Network load balancer ³. So the user is responsible for creating an NLB which serves the traffic to the EKS cluster. The VpcLink is here to direct the traffic to a Network Load Balancer (NLB). The Private VpcLink is a great way to provide access to HTTP(S) resources within our VPC without exposing them directly to the public internet.īut that’s not all. Thanks to AWS documentation, we know that we can use API Gateway private integrations ¹ to get the traffic from the API Gateway’s VPC to our VPC using an API Gateway resource of VpcLink ². AWS API Gateway for the API Gateway layer, by the authorįirst of all, AWS API Gateway is a fully managed service and runs in its own VPC: so we don’t know what’s happening between the scenes or any details about the infrastructure.
0 kommentar(er)
