Skip to content

Elastic IP for EKS Private endpoint

0

We have a requirement to connect EKS cluster endpoints from a centralized vpc privately through transit gateway. But at the same time, we want to enable public endpoint as well for employees to connect eks clusters with ofcourse restricted cidr range. The problem is to connect to an eks cluster privately from a different vpc which is not eks deployed vpc and the available options are

  1. To use Route53 resolver to forward DNS requests specific to eks cluster endpoint to eks vpc, so the response is private IP address
  2. use a route53 private hosted zone and associate it with centralised vpc with records of eks endpoints mapped to a private ip address

The 2nd option requires additional effort to accommodate the changes to IP addresses of eks endpoint during upgrades or maitenance either from AWS or our side which might not be feasible in a real time scenario where there are hundreds of clusters

The 1st option involves creation of inbound and outbound endpoints. For each cluster, there needs to be an inbound endpoint and with minimum 2 IP address for reliability, it is gonna cost $6 per day($0.125/ENI/Hour * 24 * 2) which is actually higher than eks cluster base price itself at around $2. So for every cluster, it is going to be $180 additional charge for this.

So, is there a 3rd option available with reliability but not as costly as 1st option like assigning an elastic ip for eks private endpoint

2 Answers
1

When creating an Amazon EKS cluster, you have several options for configuring endpoint access, but there isn't a direct way to assign an Elastic IP to an EKS private endpoint.

Here are your available options for connecting to EKS clusters from a centralized VPC:

  1. Public and Private Endpoint Configuration: You can configure your EKS cluster with both public and private endpoints. This allows Kubernetes API calls within your cluster's VPC to use the private VPC endpoint while still allowing restricted public access. You can limit the CIDR blocks that can use the public endpoint for your employees, while internal traffic remains within your VPC.

  2. AWS PrivateLink: You can use AWS PrivateLink to create a private connection between your centralized VPC and Amazon EKS. This allows you to access EKS as if it were in your VPC, without requiring internet gateways or NAT devices. PrivateLink creates interface endpoints with network interfaces in each subnet you enable.

  3. VPC Lattice: For a more centralized approach, you could implement VPC Lattice to create centralized private endpoints. This would allow multiple spoke VPCs to access services through a single set of endpoints in a central VPC, potentially reducing costs compared to having individual Route 53 Resolver endpoints for each cluster.

For your specific concern about costs with Route 53 Resolver endpoints, the VPC Lattice approach might be more cost-effective when dealing with many clusters, as it allows you to centralize the endpoint management.

When using the private endpoint option, all traffic between worker nodes and the Kubernetes API will go through the cross-account ENIs that are provisioned in your cluster VPC when the control plane is created.
Sources
VPC and Subnet Considerations - Amazon EKS
Centralized Private Endpoint using VPC Lattice | AWS re:Post
Access Amazon EKS using AWS PrivateLink - Amazon EKS
Identity and Access Management - Amazon EKS

answered 10 months ago
EXPERT
reviewed 10 months ago
  • VPC Lattice is not an option here as it is used to have endpoints for specific targets groups like lambda, ec2, PODS but not to EKS API server endpoint. And private link will only use private IP address of eks api server only when it is enabled with private only access, otherwise it will use public ip address. The requirement in my case is that, eks should have both public and private endpoint enabled and service to service communication should happen only through private IP address considering those two VPC's are connected through transit gateway

0
Accepted Answer

After couple of iterations we dropped the idea of exposing eks on public IP and put used VPN for ops engineers to connect to private only endpoint eks clusters. Though AWS VPN is not costly, we still think it will be better to expose eks api endpoint as a vpc endpoint, so the communication can happen with in aws network rather than going to internet with PublicIP address.

answered 9 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.