Exploring AWS EKS Auto-mode | Sample app deployment (Part-1)

Exploring AWS EKS Auto-mode | Sample app deployment (Part-1)

·

9 min read

Welcome back everyone, and Happy new year 2025! 🧨

In this article, I will explore about the new feature introduced in AWS re:Invent 2024, AWS EKS Auto Mode. (You can see the original news post here.)

The main purpose of EKS Auto Mode is to streamline Kubernetes cluster management for compute, storage, and networking, from provisioning to on-going maintenance with a single click. Before the Auto Mode, when we deploy a EKS cluster, it gives us the managed control plane components such as KubeAPI Server, etcd, KubScheduler and KubeController but we have to manually determine and manage worker type nodes, and any other plugins needed for seamless deployment of our applications. For example, we would need:

  • a managed node group, self-managed node group or other solutions like Karpenter and Cluster autoscaler for provisioning and managing worker nodes

  • an Ingress Controller for handling application traffic for our application

  • a networking plugin if we chose not to use VPC CNI plugin provided by AWS

  • an EBS CSI driver plugin for storing persistent volumes

  • an EKS Pod Identity Agent plugin if you want to use pod identity instead of IRSA

  • and many more integrations etc ..

But with the introduction of EKS Auto Mode, we no longer need to consider these specifications and configurations, instead, we can better focus on the application we are building, and other necessary configurations will be taken care by AWS when we first launched a cluster. So, it is easier and less headache for developers to run their containerized applications into Kubernetes environments without much help by dedicated DevOps Engineers.

In this two-part blog series, I will explore into the new feature of EKS Auto Mode in the new region recently announced by AWS (Thailand). AWS announced this new region in early January 2025 named ap-southeast-7 in the Thailand country as fourteenth Region in Asia Pacific, joining existing Regions in Hong Kong, Hyderabad, Jakarta, Malaysia, Melbourne, Mumbai, Osaka, Seoul, Singapore, Sydney, and Tokyo. (You can check out official blog post here.) Moreover, I will test deploy the sample application provided by AWS itself to the auto mode cluster that we created.

Without further ado, lets dive into what this EKS Auto Mode can do and how we can benefit ourselves from this feature..

Pre-requisites

  • First, we want to test out EKS cluster creation in the new region. So, if you have not enabled this new region (ap-southeast-7) in your account, please do so by visiting the Account section in your upper right corner of AWS console.

Next, under Regions section of the Account page, please select our desired AWS region Asia Pacific (Thailand) and click enable.

IMPORTANT: I noticed that EKS AutoMode is not yet available in new ap-southeast-7 region after I enabled in my account. So, we will just test in ap-southeast-1 (singapore) region.

Setting up EKS Cluster

Now that we’ve enabled the new region in our AWS account, we can get going by setting up an EKS cluster in this new region. With EKS Auto Mode, it is now easier than ever to get a production-ready grade cluster in your hand without so many configuration values.

To set up an EKS cluster, there are multiple ways of creating and deploying a cluster to your AWS account:

  • By using Amazon EKS Console

  • By using AWS CLI

  • By using IaC (Infrastructure as code tool) CloudFormation, Terraform etc. (or)

  • By using eksctl command line tool

In this example, I will simply create an EKS cluster in my account using eksctl with a configuration file for demonstration purposes. To do this, you first need to install aws and eksctl tools in your local terminal if you have not done so. You can check this post if you don’t know how to install and configure.

I will simply use AWS CloudShell in this example for simple usage and consistency. Go to AWS CloudShell service, it is not available in newly announced Thailand region so you may need to use in Singapore (ap-southeast-1) region.

What is eksctl ?

First of all, to those who are not familiar, eksctl is a command line utility which helps us to create and configure our EKS clusters to be the way we want it to be. If we don’t provide any configuration values, eksctl will just use some default values such as:

  • exciting auto-generated name, e.g., fabulous-mushroom-1527688624

  • two m5.large worker nodes

  • use the official AWS EKS AMI

  • us-west-2 region and

  • a dedicated VPC for our cluster

So, in some use cases such as you want to explore and learn about EKS and not for Production use cases, this will just do fine. But if you want to intend to shape your cluster in a specific VPC configurations and custom node types, you can also configure by passing a config file to our eksctl create command.

Install eksctl command line utility

Now, let’s look into how to install eksctl in your shell environment. If you’re also using AWS CloudShell as me, it uses Amazon Linux 2023 (AL2023) so you should look at the Unix section of installation guide from eksctl documentation.

ARCH=amd64
PLATFORM=$(uname -s)_$ARCH

curl -sLO "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_$PLATFORM.tar.gz"

You can also check and verify the checksum of your downloaded package in order to make sure that you have a legitimate software in your environment:

curl -sL "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_checksums.txt" | grep $PLATFORM | sha256sum --check

Finally, you can extract the files from your downloaded zip file and move it to the directory under $PATH in your shell so that you can execute as a command:

tar -xzf eksctl_$PLATFORM.tar.gz -C /tmp && rm eksctl_$PLATFORM.tar.gz

sudo mv /tmp/eksctl /usr/local/bin

You can verify eksctl is successfully installed in your environment by using below command:

eksctl version

Create a configuration file for eksctl

We will use a configuration file with eksctl to provide some of the configuration values when creating a cluster in this example. You can also simply just use one command line to initiate a cluster if you have authenticated with sufficient permissions to create an EKS cluster in your AWS account:

eksctl create cluster --name=<cluster-name> --enable-auto-mode

But in this example, I want to show some of the configuration values that we can set if we have previously used EKS service in our account. So, let’s first create a configuration file in our Cloud Shell home directory.

cat <<EOF > example-config.yml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: <cluster-name>
  region: <aws-region>

iam:
  # ARN of the Cluster IAM Role
  # optional, eksctl creates a new role if not supplied
  # suggested to use one Cluster IAM Role per account
  serviceRoleARN: <arn-cluster-iam-role>

autoModeConfig:
  # defaults to false
  enabled: boolean
  # optional, defaults to [general-purpose, system].
  # suggested to leave unspecified
  # To disable creation of nodePools, set it to the empty array ([]).
  nodePools: []
  # optional, eksctl creates a new role if this is not supplied
  # and nodePools are present.
  nodeRoleARN: string
EOF

Let us explore some of the configuration values we can put in our config file for eksctl

  • The first one is our cluster name and region that we’ll be using when we create a cluster under metadata section of config file.

  • The next one is serviceRoleARN field under iam section. If you’ve previously created EKS clusters in your AWS account, you should re-use the service role ARN in that account. But if you don’t provide one, eksctl will automatically create a new one in your account.

  • The other important ones are autoModeConfig section. The auto mode config is set to false by default in the configuration so, you should set true if you want to leverage the benefits of EKS auto mode. You can also specify nodeRoleARN for IAM role of worker nodes and nodePools for worker node pools but AWS recommends to not set the values if you are just experiencing with EKS.

  • eksctl will create a new default nodePool when you don’t specify anything for the nodePools field but you can later create more customized node pools to fit your application needs. (Note: EKS Auto Mode uses Karpenter in the backend to choose appropriate node AMIs and node types)

  • If you specify empty array [] for the nodePools field, eksctl won’t create any default node pools at all. This way you are responsible for creating any worker nodes in order to run your workloads.

By filling all the values for our config file should look something similar like this:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: demo-cluster
  region: ap-southeast-1

autoModeConfig:
  # defaults to false
  enabled: true

Now, you can just create a cluster in new ap-southeast-1 region by using eksctl create cluster -f example-config.yml command. eksctl will create a cluster of version 1.30 by default if you have not specified any version variables. You can also check out the full schema of eksctl config file here.

In our terminal, we should see the status of creating our demo-cluster like this:

When deploying the cluster, eksctl created necessary resources for our EKS cluster to function properly such as:

  • Dedicated VPC for our cluster to reside in, this includes three public subnets and three private subnets with one NAT Gateway for workloads in private subnets to gain internet access.

  • Two IAM roles including one role for service role and one role for worker nodes that will be provisioned by auto mode.

  • Two default node pools named system and general-purpose for hosting workloads in our cluster.

EKS Auto Mode provisioned nodes have a maximum lifetime of 21 days in order to keep the nodes up-to-date with latest patches for security hardening.

Verify and deploy a sample application

After you’ve successfully deployed a cluster in your account, you can view which objects are already deployed in your cluster by using kubectl get all -A command.

For now, it only has two services for kubernetes and eks-extension-metrics-api. As you can see, there is no active nodes found in our cluster when we first deployed our cluster.

Let us test deploy a simple nginx application pod in our cluster by using kubectl run nginx --image=nginx command. This will create a nginx pod in default namspace.

As you can see, after just a few seconds a new node comes up by itself and when the provisioned node is ready, our pod can be scheduled on it.

If we want to test traffic goes to our pod correctly, we will just use simple port forwarding method in this example to test that our pod can accept traffic kubectl port-forward pod/nginx 80:30001.

This means that we can just call port 30001 of our localhost to test the traffic like this:

Conclusion

In this Part-1, we already explored about using eksctl utility to create an EKS cluster in auto mode and tested with simple nginx container in our cluster. In the next Part-2, we will be looking to deploy a fully functional WordPress application in our cluster provided in Kubernetes Documentation.

That way, we can also explore and learn about how the EKS auto mode handles persistent volumes without us needing to install storage plugin additionally. We will also explore how to expose our application traffic using ingress and thanks to the AutoMode, we no longer need to additional deploy AWS Load Balancer Controller in our cluster for managing Application Load Balancers and Network Load Balancers from our EKS cluster.

In my opinion, that is so much useful because we no longer need to manage and maintain additional services rather than eksctl config file. So, let’s test more of the EKS Auto Mode features and its benefits in the next part.

See you all in the next part and cheers 😉

Â