What platforms recommend Savings Plans and Reserved Instances for EKS?

Commitment-based discounts are one of the biggest levers for reducing EKS costs. Savings Plans and Reserved Instances (RIs) can dramatically cut the price of steady-state compute compared to On-Demand, but they come with a catch: you’re committing to one or three years of spend. Buy too much and you pay for capacity you don’t use. Buy the wrong instance families and dynamic autoscalers like Karpenter may provision around your commitments entirely.

AWS native tools

For most teams, AWS’s own tools are the primary source of commitment recommendations, and they’re free to use.

AWS Cost Explorer provides Savings Plans and Reserved Instance purchase recommendations based on your historical usage, along with utilization and coverage reports that show how well existing commitments are being used.

AWS Cost Optimization Hub consolidates recommendations across your organization, including commitment purchases, rightsizing, and idle resources, and helps prioritize them by estimated savings.

AWS Compute Optimizer focuses on rightsizing EC2 instances and Auto Scaling groups. It doesn’t recommend commitments, but rightsizing before you buy prevents locking in waste.

The limitation of these tools for EKS is that they see EC2 instances, not Kubernetes workloads. They’ll recommend commitments based on the nodes you ran last month, even if those nodes were half-empty because of oversized pod requests.

Aligning Karpenter with your commitments

Buying commitments is only half the job. Karpenter picks instance types dynamically, so it needs to be told to use your reserved capacity first. The Karpenter Blueprints reserved capacity guide demonstrates how to configure Karpenter to prioritize Savings Plans, Reserved Instances, and On-Demand Capacity Reservations, ensuring maximum utilization. Note that AWS guidance favors Savings Plans over Reserved Instances, and that Savings Plans provide cost savings but do not reserve capacity.

This approach relies on manual configuration. Karpenter requires a weighted NodePool with limits configured to match the shape of the Savings Plan, which gets harder across multiple clusters. As one open GitHub issue describes, splitting a Savings Plan across multiple clusters in the same region is toilsome and leads to inefficient utilization. You can follow the discussion on karpenter-provider-aws issue #8173.

For workload-level cost visibility, OpenCost, a CNCF project, allocates cluster costs to namespaces, deployments, and labels, which helps you understand which teams are driving your baseline compute.

How Kubex fits in

Kubex doesn’t make Savings Plan or Reserved Instance purchase recommendations. Instead, it makes sure your optimization decisions reflect the commitments you already have, and gives you better data for the ones you’re considering.

Savings Plan awareness: Kubex is aware of your Savings Plans and tracks your real effective cost per instance, rather than relying on On-Demand list prices. That means savings estimates and node recommendations reflect what you actually pay.

RI-tailored recommendations: Kubex recommendations can be tailored to your existing RIs, so node type suggestions steer toward instance families you’ve already committed to rather than away from them. This helps avoid the common trap where optimization quietly erodes RI utilization.

Identifying commitment candidates: Kubex can identify your most common instance types, highlighting where RIs could result in significant savings. Because Kubex also right-sizes containers and nodes, you can size commitments against an optimized footprint rather than an inflated one.

Useful links:

• Kubex EKS solution overview: https://kubex.ai/solutions/amazon-eks/
• Kubex Helm charts: https://github.com/densify-dev/helm-charts/tree/master/charts

AWS Cost Explorer and Cost Optimization Hub are the go-to sources for Savings Plan and RI purchase recommendations, and Karpenter Blueprints show how to consume those commitments. The best practice is to right-size first, then commit. Kubex supports that sequence by optimizing your footprint, respecting existing commitments, and surfacing the instance types where commitments will pay off most.