kops vs EKS: what to choose?

Amet Umerov
Nov 9 · 4 min read

If you run your Kubernetes workloads, probably you use self-managed clusters managed by kops (supports k8s from version 1.4) or Amazon-managed Elastic Kubernetes Service (EKS) which generally available in the US since Jun 5, 2018.

In this article, I’ll describe the differences which I found while using them.

kops vs EKS: what to choose?


In both cases, you use EC2 instances for running workloads (workers, load balancers, VPCs, etc), so AWS doesn’t charge you additionally for nodes. The only difference in pricing between kops and EKS — masters.

The master node in EKS calls Control Plane, it’s a fixed price of $0.2/hour ($144/month).

With kops, you should manage your master nodes yourself (also it’s better to have separate etcd nodes outside the master nodes). For example, you can use 3 t2.medium (or t3, they are cheaper) nodes for masters ($108/month) + etcd nodes (if you want) + small price for EBS volumes.

For running small or even temporary clusters it could be easy to use kops because you don’t have a huge load on master or you can even use spot instances for them. For large production clusters with a high load, it could be profitable to use EKS.

Release cycle

If you read it after October 2019, versions 1.15 and 1.16 could be already supported:

| Vanilla k8s | Official | kops support | EKS support |
| version | release | added | added |
| 1.16 | 18 Sep 2019 | - | - |
| 1.15 | 19 Jun 2019 | - | - |
| 1.14 | 25 Mar 2018 | 01 Oct 2019 | 04 Sep 2019 |
| 1.13 | 04 Dec 2018 | 02 Aug 2019 | 19 Jun 2019 |
| 1.12 | 28 Sep 2018 | 15 May 2019 | 28 Mar 2019 |

From this table, we can see that new version support comes to EKS earlier than kops.

The time gap between official k8s release and EKS support is ~6 months, kops comes ~7–8 months after k8s release. I don’t think that’s a very important parameter, but nevertheless, EKS is the winner here. Usually, kops beta releases are good, so people can usually live with kops beta releases which come earlier than the stable releases.

Cluster management

kops is excellent for the fast cluster creation in an imperative way, for example:

kops create cluster \
--name stage-1 \
--zones eu-west-1a,eu-west-1b,eu-west-1c \
--master-zones eu-west-1a,eu-west-1b,eu-west-1c \
--node-count 3 \
--master-count 3 \
--node-size t3.medium \
--master-size t3.medium \
--ssh-public-key ~/.ssh/k8s-stage-1.pub \
--topology private \
--networking calico \

It creates a pool of resources for you include VPCs, subnets, autoscaling groups, etc.

BTW, there is a tool from Weaveworks called eksctl which also allows us to create a cluster so fast:

eksctl create cluster \
--name prod \
--version 1.14 \
--nodegroup-name standard-workers \
--node-type t3.medium \
--nodes 3 \
--nodes-min 1 \
--nodes-max 4 \
--node-ami auto

kops allows you to export the cluster state to terraform and then modify and deploy a cluster through it or even store cluster configuration in a declarative way.

It is also an available EKS-module for terraform.

Rolling updates


EKS cluster updates master nodes without downtime, it automatically manages the master state, rollbacks or unexpected things related to master’s rolling updates.

EKS’ s control plane

In the case of kops, you should check and monitoring the rolling update process and manually fix issues that come with this operation (for example kill stuck pods, etc).


In both cases, you should control the workers update. The flow is simple, just change the AMI for nodes and start the update (don’t forget to prepare deployments for pods eviction).

For me, EKS is better for master upgrades, you won’t worry about unexpected things during the rolling update.


kops supports many different CNIs, so you can have full access to the corner case in your network infrastructure.

EKS uses VPC ENI networking, it means that you can integrate k8s cluster to the existing networks through the native AWS network, for example, to access to the EC2 instances in the same network. In this case, you have the plain network and you should plan the subnets because you can get the lack of IP addresses in your subnet. BTW, EKS supports Calico which allows us to isolate network segments.


EKS, as we don’t have access to the master we can’t control ApiServer, ControllerManager, etcd, Scheduler. It means that we can’t use such things as:

We still can add external policies to AWS resources, manage instance groups, modify the images for nodes, DNS, etc. Control Plane logging is available in EKS, but it sends logs to CloudWatch.

kops allows us to do what we want, that’s enough. Of course, Amazon is working on additional features, and we will see them in the future, here is a roadmap for it.

Amet Umerov

Written by

DevOps Engineer at preply.com

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade