# Cost Effectively Scaling Your EKS Cluster with Karpenter | PointFive Blog Canonical: https://www.pointfive.co/blog/cost-effectively-scaling-your-eks-cluster-with-karpenter PointFive shares how they migrated from static EKS Managed Node Groups to Karpenter for dynamic, cost-optimized Kubernetes node provisioning -- covering architecture decisions, configuration details, and lessons learned. By: Gabriel Yahav Published: 2024-09-12 [Back to Blog](https://www.pointfive.co/blog) # Cost Effectively Scaling Your EKS Cluster with Karpenter Gabriel Yahav September 12, 2024 8 min read \_Update: AWS ended support for EKS-optimized Amazon Linux 2 AMIs in November 2025; use Amazon Linux 2023 or Bottlerocket for new node groups.\_ Correction, September 23, 2026: this post previously said kube-proxy stayed on the managed node group; kube-proxy is a DaemonSet that runs on every node, including Karpenter-managed nodes. Running production Kubernetes workloads in a cloud-native SaaS environment demands scalable infrastructure that adapts to changing demands. Manual node scaling quickly becomes impractical as workloads grow, making automated solutions essential for sustainable infrastructure management. ## The Starting Point PointFive initially deployed EKS with a single Managed Node Group using Amazon Linux 2 AMI nodes. This group handled both application pods and Kubernetes add-ons (CoreDNS, kube-proxy, and similar system components). As the pod population expanded with increasing memory and CPU requirements, the limitations of this static approach became clear. The team established two priorities for the next iteration: - Scaling with Simplicity -- efficient worker node scaling without manual instance type management - FinOps Focus -- cost-effective instance selection while maintaining the performance characteristics workloads required ## Karpenter vs. Kubernetes Cluster Autoscaler Karpenter and Cluster Autoscaler both automate node capacity, but use different provisioning models. Provisioning: Karpenter selects capacity within NodePool requirements. On AWS, Cluster Autoscaler changes the size of configured node groups; mixed-instance groups are supported, with documented requirements for consistent scheduling assumptions. Scale-down: Cluster Autoscaler can remove nonempty, underutilized nodes when their pods can be rescheduled and applicable constraints allow it. It is not limited to empty nodes. Karpenter consolidation can remove nodes or replace capacity, subject to scheduling constraints and disruption controls. Performance and cost: Provisioning latency and savings depend on workload requirements, available capacity, configuration, and disruption tolerance. Neither architecture guarantees a faster start or the lowest price in every environment. Sources: [Cluster Autoscaler FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md) and [Karpenter disruption documentation](https://karpenter.sh/docs/concepts/disruption/) , checked September 17, 2026. ## Implementation Architecture ### Dedicated Scheduling Strategy The team adopted a split-responsibility approach: - Cluster add-on Deployments such as CoreDNS remained on the EKS Managed Node Group for stability (DaemonSets such as kube-proxy run on every node) - Application workloads were delegated entirely to Karpenter-managed nodes This separation ensures that system-critical components run on predictable, stable infrastructure while application pods benefit from Karpenter's dynamic scaling and cost optimization. ### NodePool Configuration A single primary NodePool defined the provisioning blueprint. Key configuration parameters included: - Consolidation Policy: WhenEmptyOrUnderutilized -- Karpenter identifies and disrupts nodes that are empty or not efficiently packed - Resource Limits: 1000 CPU and 1000Gi memory as upper bounds for the NodePool - Architecture: arm64 for cost efficiency - Instance Categories: c (compute), m (general purpose), and r (memory-optimized) families, generation 2 and above - Availability Zones: us-east-1a, us-east-1b, us-east-1c for distribution ## Key Lessons and Best Practices ### Minimize NodePools A single NodePool can serve multiple teams and workloads effectively. Additional NodePools should only be created when there are concrete requirements for billing isolation, specific hardware constraints, or distinct disruption policies. ### Set Node Expiration Configuring an expireAfter value ensures regular node cycling. Replacement nodes use the AMI selected by the node configuration; expiration alone does not guarantee the latest patched image. Maintain and validate that configuration separately. ### Maintain a Broad Instance Type Range Keeping instance type requirements flexible allows Karpenter to select the most cost-effective and available options that match workload demands. Overly constraining instance types defeats the purpose of dynamic provisioning. ### Enable Consolidation The WhenEmptyOrUnderutilized consolidation policy permits consideration of underutilized nodes. Choose disruption settings around workload availability requirements and validate the resulting cost and reliability changes. ## Scaling Up Without Scaling Out of Control Karpenter is an evolving tool that continues to add capabilities. For organizations running EKS at scale, it provides a path to efficient, cost-optimized Kubernetes infrastructure that adapts dynamically to workload demands. The combination of automatic instance selection, active consolidation, and simplified configuration means teams can focus on their applications rather than managing node groups manually. --- Source: the public page above. Product screenshots and illustrative interfaces are examples, not live customer data.