DEV Community

Àlex Serra
Àlex Serra

Posted on

AWS EKS cost efficient 🤑

Running a Kubernetes cluster at some of the clouds providing that service has become a great option for lowering costs on those teams that have the capacity to develop and maintain such thing. In our case we have opted for EKS, the native implementation of Kubernetes for AWS.

Before going deeper it's important to understand the key concepts on how EKS manages nodes attached to the cluster.

One of the reasons why Kubernetes has expanded so quick on the most used cloud providers is because that platforms developed different integrations for letting k8s manage the amount of nodes attached to the cluster based on the performance metrics. For EKS, AWS offers us two different controllers for delivering on them the responsibility to adjust the amount of EC2 machines and their instance class that needs to be running under the different preconfigured scenarios.


Enough chatter, let's spend the money. An interesting starting point would be to create two types of pools within our cluster. One pool will be made up of ON_DEMAND nodes and the other one will be using SPOT type.

Compute section inside EKS service

To summarize, we can say that an EC2 instance pool in SPOT mode guarantees us the type and number of instances desired at the time for a finite time, at which point the instance will be replaced by an identical one. As you can imagine, this causes inconvenience to our cluster, having to move the resources from the replaced node to those that are available. That is why it is the cheapest option with discounts of up to 72%. On the other hand, ON_DEMAND instances mean a guarantee that that specific EC2 instance is reserved for us for as long as we want without being replaced.

This is where the main post theme comes in. SPOT instances cannot get more discounts, but the other type can. Since it is a better service, the ON_DEMAND type pool can get discounts of up to 37% depending on the time and type of payment under which we reserve said instances.

Actual saving plan for ON_DEMAND instances

The current market price for t4g.xlarge instances is about $0.15, but we are paying $0.0967 for them for one year. If we increase the reservation period to three years or the payment type to upfront, either partial or complete, we would obtain an even greater discount.


But what happens if I change my mind after signing the contract? 😱

There is a market (no shady stuff) where we can sell the reservation. We will have previously been able to choose whether to make a convertible reservation in the future, this will give us more room to maneuver, but a less succulent discount.

Other options to explore would be Saving plans, in which it is not necessary to specify even the smallest detail of the type of instance to be booked. Again, with lower discounts as they offer greater flexibility.


How can I see the price improvements that have been applied to me?

In the following section "Billing and Cost Management" you can find all the details of the savings achieved.

Image description

If we have the autoscaling of replicas within the cluster well configured and we ensure a minimum cost for them, we ensure that we are generating interesting savings with an investment of time that makes up for it.

I hope you found it useful, and if you want to donate some of the money you've saved, you can do so.

Be good guys, bye!

Top comments (0)