Introduction

Today, AWS announced the availability of a new feature for AWS EKS called “Auto Mode”. With this, AWS focuses on solving some of the challenges that users have been mentioning ever since the release of EKS and Fargate.
In this article, we’ll explore the hits and misses (from my perspective) and where I think that the team still has some work left to do.

Feature TL;DR

EKS Auto Mode makes use of EC2 Managed Instances and simplifies the management of underlying compute resources for EKS clusters. In addition to that, it enables the use of a Karpenter backed, fully k8s API compliant way of scaling EKS data planes. The AWS EKS team takes responsibility of managing not only the infrastruture but also the AMIs that power the k8s cluster.

What changes for EKS Operations Engineers with this change?

With this change, EKS operations engineers will not need to scale EKS clusters in and out anymore. Karpenter scales infrastructure for nodes way faster than EC2 AutoScaling. Operations Engineers can focus on the applications instead of managing the underlying infrastructure.

How does the new feature change the responsibility model for EKS?

With this change, AWS takes on a lot of more responsibility within the EKS space. The EKS team will now manage the underlying AMIs, ensuring that they follow security best practices and are secure to use. AWS will also manage the node rotation and upgrade where required.

How do users interact with the new feature?

The new feature is available through the AWS console, the AWS cli and through infrastructure as code – with CloudFormation and Terraform supported right from the start.

In the AWS console, the new feature also simplifies the set up of a new EKS cluster by allowing a “quick start” mode for EKS. In this mode, the new EKS cluster creation process automatically selects sensible defaults for VPC and other settings.

Hits – where’s the feature good

As far as I have seen the feature finally gives AWS the possibility to have a automatically scaling implemented based on the k8s API standards and definitions. EKS Fargate was always a “try” to allow simplifying interacting with EKS, but due to the nature of the feature – being not compliant to the k8s API – you were missing out on additional possibilities like using a different CNIs, running sidecars, etc.

EKS Auto Mode changes this and simplifies the EKS experience.

The additional responsibility that AWS is taking on managing and securing the underlying infrastructure will also help organizations to build faster.

With the feature, the team also simplifies upgrading the control plane as with taking ownership of the underlying nodes, the team can guarantee compliance of the infrastructure setup with new k8s versions – and this includes some of the addons that are now built into the underlying deployment which is powered by the Bottlerocket OS.

Misses – what did the team miss to simplify?

The team did not simplify the network infrastructure setup. The feature also does not help you to make the management of networking and integrations for the clusters easier.

Other wishes for EKS

As already mentioned, I’m not a fan of the current possibilities for network management and the defaults taken for the EKS networking setup. The troubleshooting experience could also be better.

As a next step, I’d also love the EKS tam to take on additional responsibilities for addon management, empower us to build a real service mesh for east/west traffic management and further out-of-the box integrations with other AWS services or managed service providers.

An example for that could be the possibility of a managed Crossplane service or addon, as this k8s based tool is becoming more popular, not only for k8s but also managing AWS infrastructure.

The possibility to add ArgoCD or FluxCD as a component to your EKS management plane “out of the box” also seems appealing to me.

And then, there is the other thing that is constantely going on my nerves: with the idea of using ephemeral EKS clusters, the importance of “faster” cluster provisioning times rises. This could be achieve by optimizations on the EKS side or by allowing the usage of VClusters on EKS clusters out of the box.

Wrap up

This was my initial take on the newly announced AWS EKS Auto Mode. I’ll need to play around with it a bit more to be able to give a better assessment.

What did I miss, what do you think?

Please let me know and start a conversation, I’m eager to hear your thoughts and feedback!

A first look at AWS EKS Auto Mode – hits, misses and possible improvements