[EKS] [request]: Allow single zone clusters

[dgilbert82]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Tell us about your request
Either allow the creation of single availability zone clusters or restrict control plane traffic to same zone.

Which service(s) is this request for?
EKS

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
We are facing significant costs due to interzone-in traffic from the EKS control plane. All of our nodes are in a single availability zone as they consume and process large amounts of data from databases in that same zone. Previously we had to move the database clusters to be in the same zone due to interzone traffic costs related to replication.

We have over 400 autoscaling nodes which are spot instances with limited availability - so the churn is also high - consuming thousands of pods per hour and over a 1 hour sample period, there was 1TB of inbound traffic coming from the EKS control plane, with approx 66% coming from the unused (as in no nodes in that zone) availability zone

What outcome are you trying to achieve, ultimately, and why is it hard/impossible to do right now? What is the impact of not having this problem solved? The more details you can provide, the better we'll be able to understand and solve the problem.

Remove the interzone traffic costs as the workload is not spread across availability zones, so there is no benefit in this use case from the enforced multi-az approach. EKS requires a minimum of 2 availability zones so it is impossible to provision in one.

Are you currently working around this issue?
No workaround available other than replacing EKS with another solution.

Additional context
AWS support recommended raising an issue here

Attachments