Kubernetes has revolutionized container orchestration, but managing production-grade clusters can be complex and time-consuming. Amazon Elastic Kubernetes Service (EKS) is a managed Kubernetes service that simplifies running containerized applications on AWS. It eliminates the need for users to operate their own Kubernetes control plane.
Even with EKS, users have had to configure many tooling and cluster components themselves to create “production-ready” setups. EKS Auto Mode aims to simplify Kubernetes operations by automating and abstracting away many aspects of cluster and tooling management.
What we’ll cover in this article:
- What is EKS Auto Mode?
- EKS Auto Mode vs other EKS deployment options
- Key features of EKS Auto Mode
- Benefits of Using EKS Auto Mode for Kubernetes clusters
- Tutorial: deploying Kubernetes with EKS Auto Mode
- Best practices and considerations for using EKS Auto Mode
- Limitations of EKS Auto Mode
If you are new to Kubernetes, check out Spacelift’s Kubernetes blogs and tutorials to learn more.
EKS Auto Mode is a new deployment option in Amazon Elastic Kubernetes Service (EKS) that automates infrastructure provisioning and scaling. It eliminates the need to manage EC2 nodes by using serverless compute, similar to AWS Fargate but optimized for Kubernetes workloads.
In this configuration, EKS Auto Mode incorporates many Kubernetes capabilities directly into infrastructure managed by AWS rather than treating them as add-ons. This includes features like compute autoscaling, networking for pods and services, load balancing for applications, cluster DNS, block storage, and GPU support, which makes it ideal for teams that want to focus on application logic rather than cluster management..
The beauty of EKS Auto Mode is that it doesn’t require you to be a Kubernetes guru. It selects the best compute instances, scales resources on the fly, constantly optimizes costs, manages essential add-ons, patches operating systems, and integrates with AWS security services.
Compared to customer-managed infrastructure in regular EKS clusters, AWS takes on a broader operational role in Auto Mode. They’re not just handling the EKS control plane anymore — they’re configuring, managing, and securing the AWS infrastructure your applications need to run in EKS clusters.
This approach lets you hit the ground running, boost performance, and reduce overhead. Instead of getting overloaded with cluster management tasks, you can pour your energy into building innovative applications.
EKS Auto Mode is also convenient for generative AI workloads. It streamlines acquiring and running cost-effective GPU-accelerated instances, ensuring your workloads have the right capacity when needed.
Who should use EKS Auto Mode?
EKS Auto Mode is designed for users who want to run Kubernetes workloads without managing the underlying compute infrastructure. It automatically provisions and scales compute capacity based on application demand.
This makes it suitable for teams prioritizing operational simplicity, dynamic scaling, and cost optimization. It is particularly relevant for variable or bursty workloads that benefit from automated resource management.
Let’s compare EKS Auto Mode to other deployment options, such as AWS Fargate and EKS Manages Node Groups.
What is the difference between EKS Auto Mode and Fargate?
EKS Auto Mode and AWS Fargate both aim to simplify Kubernetes, but they do so in fundamentally different ways.
Auto Mode still relies on EC2 instances for the compute layer, giving you more flexibility to run various workloads, including those needing DaemonSets or stateful storage. Fargate, on the other hand, is serverless, meaning you don’t manage any underlying nodes at all.
However, this comes with limitations on workload types and networking configurations and lacks support for DaemonSets. Ultimately, Auto Mode gives you a managed instance experience, while Fargate offers a completely serverless approach to Kubernetes.
What is the difference between EKS Auto Mode and EKS Managed Node Groups?
EKS Auto Mode and EKS Managed Node Groups share some characteristics. Both aim to simplify node management for EKS environments. However, they also differ significantly in their scope and level of automation.
EKS Auto Mode abstracts away node management entirely by provisioning and scaling AWS Fargate-based serverless compute, making it ideal for users who want a fully hands-off experience. EKS Managed Node Groups, on the other hand, provide managed EC2 instances as worker nodes, offering more control over instance types, configurations, and performance tuning.
Auto Mode is simpler and reduces operational overhead, while Managed Node Groups give you flexibility and cost optimization through EC2 choices. This distinction helps teams choose between convenience and customization based on workload needs.
EKS Auto Mode introduces a set of built-in features designed to streamline Kubernetes operations with minimal user configuration:
- Automated cluster management – EKS Auto Mode manages cluster infrastructure, allowing AWS to set up and manage components crucial for smooth workload operation. This includes built-in support for pod IP assignments, network policies, DNS services, GPU plugins, and storage solutions.
- Streamlined Kubernetes operations – It simplifies Kubernetes operations by treating core infrastructure as a managed service rather than a manual setup. Instead of requiring users to configure foundational components, it automates key elements such as cluster controllers, EC2 compute provisioning, load balancing via ELB, and persistent storage using EBS. It also integrates natively with AWS services, following cloud infrastructure best practices and reducing operational overhead.
- Dynamic scaling and resource optimization – Leveraging Karpenter, EKS Auto Mode continuously monitors for unschedulable pods and deploys new nodes as needed. It also terminates unused instances and consolidates workloads, optimizing resource usage and costs.
- Enhanced security measures – Auto Mode employs immutable AMIs with locked-down software, SELinux mandatory access controls, and read-only root file systems. Nodes have a configurable lifetime, after which they’re automatically replaced with new ones, enhancing overall security posture.
- Automated upgrades and patching – EKS Auto Mode keeps clusters, nodes, and related components up-to-date with the latest patches while respecting configured Pod Disruption Budgets. This ensures clusters remain secure and current without manual intervention.
- Cost optimization – EKS Auto Mode supports Spot, On-Demand, and Savings Plans. It auto-selects instance types for the best price/performance fit.
- Security and compliance – Auto Mode leverages managed node isolation and IAM roles for pods, and it integrates with AWS security services.
EKS Auto Mode reduces operational overhead, accelerates deployment cycles, and improves scalability — key advantages for growing cloud-native teams.
1. Reduced operational overhead
EKS Auto Mode reduces operational overhead by automating key components of Kubernetes cluster management.
EKS Auto Mode can handle:
- Infrastructure provisioning – Automatically sets up the underlying compute and networking resources
- Node lifecycle management – Handles creation, scaling, and termination of nodes
- Component updates – Manages updates for Kubernetes control plane components
- Security patching – Applies patches without manual intervention
- OS upgrades – Keeps operating systems up to date across all nodes
- Cluster scaling – Adjusts resources dynamically based on workload demand
By automating these tasks, EKS Auto Mode enables engineering teams to focus on high-value development and optimization efforts rather than routine maintenance.
2. Improved application availability
EKS Auto Mode dynamically adjusts compute resources in response to real-time workload demands. It continuously monitors the cluster for unschedulable pods and automatically provisions new nodes when needed. When demand decreases, it efficiently scales down by terminating unused instances.
This proactive resource management approach helps maintain application availability, responsiveness, and overall performance with minimal manual intervention.
3. Cost optimization
EKS Auto Mode continuously optimizes compute costs through intelligent capacity provisioning and dynamic scaling. It selects the optimal mix of EC2 instances, eliminates unused resources, and consolidates workloads to improve cost efficiency.
The service supports cost-saving features like Spot Instances and Savings Plans, further enhancing cost-optimization efforts.
4. Focus on application development rather than infrastructure
By offloading cluster operations to AWS, EKS Auto Mode enables development teams to concentrate on building and improving applications instead of managing infrastructure.
This shift in focus accelerates innovation and allows organizations to leverage their engineering resources more effectively for business-critical tasks. Auto Mode’s streamlined management process reduces the time and effort required for routine cluster maintenance, enabling faster application deployment and iteration.
In this section, we will show how easy it is to start with EKS Auto Mode.
Step 1: Create an EKS Auto Mode cluster
You can create an EKS Auto Mode cluster in the AWS Management Console by going to the EKS service with the Quick configuration:
Set the cluster name and Kubernetes version, and, if you haven’t already, opt to automatically create the recommended IAM roles for the clusters and EC2 nodes. Select your VPC configuration and click “Create Cluster.”
Step 2: Authenticate with the EKS Cluster
Let’s examine our existing cluster. For this tutorial, we will use AWS CloudShell, a browser-based, pre-authenticated shell that you can launch directly from the AWS Management Console.
In CloudShell, run this command to connect to the EKS cluster. Update the region and cluster name accordingly:
aws eks update-kubeconfig --region region-code --name my-cluster
Step 3: Examine the Karpenter node pool
Now that we are authenticated with the cluster, let’s examine the default general-purpose
Karpenter node pool configured for us.
kubectl describe nodepool general-purpose
Name: general-purpose
Namespace:
Labels: app.kubernetes.io/managed-by=eks
Annotations: karpenter.sh/nodepool-hash: 4012513481623584108
karpenter.sh/nodepool-hash-version: v3
API Version: karpenter.sh/v1
Kind: NodePool
Metadata:
Creation Timestamp: 2025-02-12T15:11:20Z
Generation: 1
Resource Version: 319962
UID: abc403cb-8f61-4cee-8933-68ed72378ced
Spec:
Disruption:
Budgets:
Nodes: 10%
Consolidate After: 30s
Consolidation Policy: WhenEmptyOrUnderutilized
Template:
Metadata:
Spec:
Expire After: 336h
Node Class Ref:
Group: eks.amazonaws.com
Kind: NodeClass
Name: default
Requirements:
Key: karpenter.sh/capacity-type
Operator: In
Values:
on-demand
Key: eks.amazonaws.com/instance-category
Operator: In
Values:
c
m
r
Key: eks.amazonaws.com/instance-generation
Operator: Gt
Values:
4
Key: kubernetes.io/arch
Operator: In
Values:
amd64
Key: kubernetes.io/os
Operator: In
Values:
linux
Termination Grace Period: 24h0m0s
The general-purpose
node pool is built into EKS Auto Mode and includes reasonable defaults for general workloads such as web apps.
For example, we can see that Karpenter Consolidation for cost optimization is enabled. We also notice that this node pool provisions EC2 on-demand nodes from the “c”, “m”, or “r” EC2 family types, but only the newer generations (older than v4).
Then, let’s examine our nodes:
$ kubectl get nodes
No resources found
We just started the cluster, and we have no deployed applications, so we have no nodes yet.
Step 4: Deploy a sample application
Let’s deploy a sample application. Check the following deployment, save it locally as inflate.yaml
, and upload it to CloudShell:
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate
spec:
replicas: 1
selector:
matchLabels:
app: inflate
template:
metadata:
labels:
app: inflate
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
containers:
- name: inflate
image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
resources:
requests:
cpu: 1
securityContext:
allowPrivilegeEscalation: false
Note the eks.amazonaws.com/compute-type: auto
selector, which instructs the workload to be deployed on an Amazon EKS Auto Mode node.
Step 5: Apply the deployment
Next, apply the deployment:
$ kubectl apply -f inflate.yaml
deployment.apps/inflate created
The deployment pod is currently in a Pending
state because we have no nodes to schedule the pod:
kubectl get pods
NAME READY STATUS RESTARTS AGE
inflate-b6b45f8d4-kwgfc 0/1 Pending 0 17s
After a few seconds, Karpenter automatically creates a node, and the pod goes into “Running” state.
kubectl get nodes
NAME STATUS ROLES AGE VERSION
i-0301d8f857e80cb93 Ready <none> 84s v1.31.4-eks-0f56d01
Step 6: Update the deployment file
Next, let’s edit the deployment file and change the replica value from 1 to 20. Apply the deployment again kubectl apply -f inflate.yaml
.
Again, our pods are in a Pending
state because we don’t have enough capacity.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
inflate-b6b45f8d4-4th2m 0/1 Pending 0 10s
inflate-b6b45f8d4-66dh9 0/1 Pending 0 10s
inflate-b6b45f8d4-9pgz8 0/1 Pending 0 10s
inflate-b6b45f8d4-bctqf 0/1 Pending 0 10s
inflate-b6b45f8d4-cktt5 0/1 Pending 0 10s
inflate-b6b45f8d4-csvdd 0/1 Pending 0 10s
inflate-b6b45f8d4-dfrwj 0/1 Pending 0 10s
inflate-b6b45f8d4-gjctw 0/1 Pending 0 10s
inflate-b6b45f8d4-jlq86 0/1 Pending 0 10s
inflate-b6b45f8d4-kh4j8 0/1 Pending 0 10s
inflate-b6b45f8d4-kj5hd 0/1 Pending 0 10s
inflate-b6b45f8d4-kwgfc 1/1 Running 0 2m59s
inflate-b6b45f8d4-mpq92 0/1 Pending 0 10s
inflate-b6b45f8d4-nt6m6 0/1 Pending 0 10s
inflate-b6b45f8d4-p5k2r 0/1 Pending 0 10s
inflate-b6b45f8d4-qpwd5 0/1 Pending 0 10s
inflate-b6b45f8d4-r285s 0/1 Pending 0 10s
inflate-b6b45f8d4-rn2hl 0/1 Pending 0 10s
inflate-b6b45f8d4-vwbpm 0/1 Pending 0 10s
inflate-b6b45f8d4-whm5w 0/1 Pending 0 10s
Karpenter will start creating nodes to host your pods in a few seconds. You can check your nodes with kubectl get nodes
or go to the EKS Console in your cluster and check the Compute
tab.
Similarly, if we need to deploy an application that requires a load balancer or leverages EBS volumes, the EKS Auto Mode cluster will automatically provision these for us. To see these in action, follow the guides Deploy a Sample Load Balancer Workload to EKS Auto Mode and Deploy a Sample Stateful Workload to EKS Auto Mode.
Furthermore, enabling the EKS Auto Mode on existing clusters is possible in different scenarios. Check the guides Migrate from Karpenter to EKS Auto Mode using kubectl and Migrate from EKS Managed Node Groups to EKS Auto Mode, depending on your specific use case.
Before you adopt Auto Mode, carefully configure resource requests for workloads to maximize cost-efficiency. Accurate workload-level resource requests are crucial for Auto Mode’s cost optimization features, which Karpenter powers.
EKS Auto Mode simplifies Kubernetes cluster management by handling infrastructure provisioning and scaling. However, to use it effectively, consider the following best practices:
- Set pod resource requests and limits: Always specify
resources.requests
andresources.limits
in pod specs to ensure proper scheduling and allow Auto Mode to allocate capacity efficiently. - Isolate workloads using different profiles: Use multiple Auto Mode profiles to separate workloads by environment, team, or application type. This enables better resource control, scaling behavior, and access policies.
- Tag Auto Mode resources for cost tracking: Apply AWS cost allocation tags consistently across pods, namespaces, and Auto Mode profiles to enable detailed cost visibility and reporting.
Although EKS Auto Mode offers significant benefits, its managed nature means it also has limitations users should consider. EKS Auto Mode treats nodes as immutable appliances, preventing direct access via SSH or SSM according to modern best practices. If you need to SSH into nodes, Auto Mode might not be the best fit for you.
EKS Auto Mode has pre-defined and pre-configured AMIs (Amazon Machine Images) for your compute nodes. Users cannot choose or customize the operating system, or AMI used for nodes. This restriction may pose challenges for workloads requiring specific OS configurations or software packages.
Lastly, EKS Auto Mode comes with many opinionated defaults that will satisfy most cases. Still, organizations with deep Kubernetes expertise and specific operational requirements may find the automated approach too restrictive.
Spacelift takes cloud automation and orchestration to the next level. It is a platform designed to manage infrastructure-as-code tools such as OpenTofu, Terraform, CloudFormation, Kubernetes, Pulumi, Ansible, and Terragrunt, allowing teams to use their favorite tools without compromising functionality or efficiency.
Spacelift provides a unified interface for deploying, managing, and controlling cloud resources across various providers. Still, it is API-first, so whatever you can do in the interface, you could do via the API, the CLI it offers, or even the OpenTofu/Terraform provider.
The platform enhances collaboration among DevOps teams, streamlines workflow management, and enforces governance across all infrastructure deployments. Spacelift’s dashboard provides visibility into the state of your infrastructure, enabling real-time monitoring and decision-making, and it can also detect and remediate drift.
You can leverage your favorite VCS (GitHub/GitLab/Bitbucket/Azure DevOps), and executing multi-IaC workflows is a question of simply implementing dependencies and sharing outputs between your configurations.
With Spacelift, you get:
- Policies to control what kind of resources engineers can create, what parameters they can have, how many approvals you need for a run, what kind of task you execute, what happens when a pull request is open, and where to send your notifications
- Stack dependencies to build multi-infrastructure automation workflows with dependencies, having the ability to build a workflow that, for example, generates your EC2 instances using Terraform and combines it with Ansible to configure them
- Self-service infrastructure via Blueprints, or Spacelift’s Kubernetes operator, enabling your developers to do what matters – developing application code while not sacrificing control
- Creature comforts such as contexts (reusable containers for your environment variables, files, and hooks), and the ability to run arbitrary code
- Drift detection and optional remediation
If you want to learn more about Spacelift, create a free account today or book a demo with one of our engineers.
EKS Auto Mode represents a significant leap forward in Kubernetes management on AWS, offering many benefits that streamline operations and enhance productivity.
In this blog post, we explored how automating cluster management tasks such as infrastructure provisioning, scaling, and maintenance dramatically reduces operational overhead for EKS Auto Mode clusters.
With built-in security features like immutable AMIs and automatic node replacement, EKS Auto Mode keeps workloads protected by default. Smart scaling and capacity management optimize costs, and high availability and hands-off operations free up your team to focus on building infrastructure rather than babysitting it.
Manage Kubernetes easier and faster
Spacelift allows you to automate, audit, secure, and continuously deliver your infrastructure. It helps overcome common state management issues and adds several must-have features for infrastructure management.