DEV Community

Cover image for Reducing Kubernetes costs using AWS EKS Auto Mode

Reducing Kubernetes costs using AWS EKS Auto Mode

🚀 Introduction

Efficiently managing Kubernetes clusters can be challenging—especially when it comes to cost optimization. Maintaining underutilized instances, manually configuring scalability, and managing node groups requires time and specialized knowledge.

According to recent studies, organizations often overspend on Kubernetes infrastructure due to over-provisioning and poor resource management.
AWS introduced Amazon EKS Auto Mode, a simpler and more cost-effective way to operate Kubernetes clusters.

In this article, you’ll learn how EKS Auto Mode works, why it helps reduce costs, and how to implement it in your environment with practical examples.

🚀 What is EKS Auto Mode?
EKS Auto Mode is a new operational mode for Amazon EKS that completely abstracts away the infrastructure management of Kubernetes nodes.
Launched in November 2024, it is a natural evolution of Karpenter, offering an even more simplified experience.

🧩 Key Features:

- Automatic Provisioning: Nodes are created and removed automatically based on pod demand
- Smart Optimization: Automatically selects instance types, availability zones, and pricing models
- Zero Management: Eliminates the need to create Node Groups or Launch Templates

💰 How EKS Auto Mode Reduces Costs
The main goal of Auto Mode is to avoid over-provisioning and maximize EC2 usage efficiency.

🎯 Pod-Based Intelligent Scaling
Unlike Node Groups that scale based on CPU/Memory metrics, Auto Mode scales based on pending pods. This removes the need for pre-allocated "buffer" resources.

💸 Automatic Spot Instance Optimization
The system intelligently mixes Spot and On-Demand instances, potentially saving up to 90% on interruption-tolerant workloads.

🔁 Elimination of Idle Nodes
Instances are automatically terminated when no pods are running, with a default grace period of 30 seconds.

🤖 Smart Instance Selection
Auto Mode takes multiple factors into account simultaneously:

  • Pod CPU/Memory requirements
  • Instance pricing
  • Availability across AZs
  • Architecture (AMD64/ARM64)

⚙️ EKS Auto Mode Setup
✅ Prerequisites

  • AWS CLI configured
  • kubectl installed
  • Helm 3.x
  • IAM permissions

🧾 Step 1: Clone the Repository

git clone https://github.com/rodrigofrs13/eks-auto-mode.git
cd eks-auto-mode
Enter fullscreen mode Exit fullscreen mode

⚙️ Step 2: Configure the Cluster
Edit the conf-cluster-eks-auto-mode.yaml file with your desired settings for testing.

🚀 Step 3: Create the Cluster
Run the script to set up and enable Auto Mode:

sh setup-cluster-eks-auto-mode.sh
Enter fullscreen mode Exit fullscreen mode

🔌 Step 4: Connect to the Cluster

aws eks --region <region> update-kubeconfig --name <cluster-name>
Enter fullscreen mode Exit fullscreen mode

🔍 Step 5: Verify Resources
Check if Karpenter-related resources were created:

NodePool

kubectl get nodepool
Enter fullscreen mode Exit fullscreen mode

NodeClass

kubectl get nodeclass
Enter fullscreen mode Exit fullscreen mode
  • EC2NodeClass: Defines EC2 configurations (AMI, security groups, subnets, user data)
  • NodePool: Defines scaling policies (instance types, taints, resource limits)

🧠 Advanced Configuration - NodePool for AMD64

For workloads requiring AMD64 architecture, apply:

kubectl apply -f NodePool-AMD.yaml
Enter fullscreen mode Exit fullscreen mode

🧪 Scalability Test
🧱 Apply the Test Deployment

Apply deployment

kubectl apply -f deploy-scaling-SPOT.yaml
Enter fullscreen mode Exit fullscreen mode

📈 Scale to 50 replicas

kubectl scale deployment nginx-arm64-spot --replicas=50
Enter fullscreen mode Exit fullscreen mode

🔎 Monitor in Real Time

Pods

kubectl get pods -w
Enter fullscreen mode Exit fullscreen mode

*NodeClaims *

kubectl get nodeclaim
Enter fullscreen mode Exit fullscreen mode

Worker Nodes

kubectl get nodes --show-labels
Enter fullscreen mode Exit fullscreen mode

Expected Results
⏱️ Response Time: New nodes within 30–45 seconds

💡 Optimization: Auto Spot/On-Demand mix

🧹 Cleanup: Idle nodes deleted after 30s grace period

📊 Cost Monitoring with Kubecost

Install Kubecost

helm repo add kubecost https://kubecost.github.io/cost-analyzer/
helm repo update

helm install kubecost kubecost/cost-analyzer \
  --namespace kubecost \
  --create-namespace \
  --set persistentVolume.enabled=false \
  --set prometheus.server.persistentVolume.enabled=false \
  --set persistentVolume.enabled=false
Enter fullscreen mode Exit fullscreen mode

Check Installation

kubectl get pods -n kubecost
Enter fullscreen mode Exit fullscreen mode
kubectl port-forward --namespace kubecost deployment/kubecost-cost-analyzer 9090
Enter fullscreen mode Exit fullscreen mode

Access the dashboard at: http://localhost:9090
🕒 Wait ~25 minutes for full metric collection.

🔍 Key Metrics:

  • Cost per namespace
  • Efficiency metrics: Usage vs. requests
  • Spot vs On-Demand ratio
  • Hourly cost trends

🧠 Best Practices for Maximum Optimization

  1. Accurate Resource Requests and Limits
resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"
Enter fullscreen mode Exit fullscreen mode
  1. Toleration Separation by Interruption Tolerance
tolerations:
- key: "spot"
  operator: "Equal"
  value: "false"
  effect: "NoSchedule"
Enter fullscreen mode Exit fullscreen mode

Para workloads tolerantes

tolerations:
- key: "spot"
  operator: "Equal"
  value: "true"
  effect: "NoSchedule"
Enter fullscreen mode Exit fullscreen mode
  1. Node Affinity for Spot Optimization
affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      preference:
        matchExpressions:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot"]
Enter fullscreen mode Exit fullscreen mode
  1. Use PodDisruptionBudgets
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app
Enter fullscreen mode Exit fullscreen mode
  1. Cost Monitoring and Alerts

Custom CloudWatch Log Group

aws logs create-log-group --log-group-name /aws/eks/auto-mode/costs
Enter fullscreen mode Exit fullscreen mode

Cost Explorer automation

aws ce get-cost-and-usage \
  --time-period Start=2024-01-01,End=2024-01-31 \
  --granularity MONTHLY \
  --metrics BlendedCost
Enter fullscreen mode Exit fullscreen mode

⚠️ Limitations and When Not to Use
Auto Mode is not suitable for:

  • Custom AMIs: It uses AWS-optimized AMIs
  • Specialized Hardware: GPU, Inferentia, or other special instance types
  • Granular Control Needs: Deeply customized configurations
  • Strict Compliance Environments: Instance type constraints
  • Stateful Workloads: Databases needing persistent local storage

Conclusion
Amazon EKS Auto Mode represents a paradigm shift in Kubernetes cluster operations, offering:

🛠️ Operational Simplicity: Up to 80% management time reduction

💸 Cost Savings: 60–70% lower infrastructure costs

🚀 Instant Scalability: Rapid response to demand changes

🧠 Continuous Optimization: Machine learning–based decisions

For organizations seeking to reduce complexity and costs, Auto Mode is a proven and mature solution.
The combination of smart provisioning, Spot instance optimization, and zero over-provisioning leads to substantial savings.

🔗 Additional Resources

🧹 Environment Cleanup
⚠️ Important: Always clean up unused resources to avoid unwanted charges:

chmod +x cleanup-all.sh
./cleanup-all.sh
Enter fullscreen mode Exit fullscreen mode

Top comments (0)