AWS announced Kubernetes-as-a-Service at re:Invent in November 2017: Elastic Container Service for Kubernetes (EKS). Since yesterday, EKS is generally available. I discussed ECS vs. Kubernetes before EKS was a thing. Therefore, I’d like to take a second attempt and compare EKS with ECS.

Before comparing the differences, let us start with what EKS and ECS have in common. Both solutions are managing containers distributed among a fleet of virtual machines. Managing containers includes:

Monitoring and replacing failed containers.

Deploying new versions of your containers.

Scaling the number of containers based on load.

What are the differences between EKS and ECS?

Load Balancing

Usually, a load balancer is as the entry point into your AWS infrastructure. Both EKS and ECS offer integrations with Elastic Load Balancing (ELB).

On the one hand, Kubernetes - and therefore EKS - offers an integration with the Classic Load Balancer. Support for the Application Load Balancer and Network Load Balancer are available as beta releases. When creating a service Kubernetes does also create or configure a Classic Load Balancer for you.

The client sends a request to ELB. ELB distributes the request to one of the nodes also known as EC2 instances. A proxy running on the node is forwarding the request to one of the pods providing the service.

On the other hand, ECS provides an integration with the Application Load Balancer (ALB), the Network Load Balancer (NLB) as well as the Classic Load Balancer (CLB). When using the ALB, the flow for each incoming request needs only two instead of three steps.

The client sends a request to the ALB. ALB forwards request to one of the tasks providing the service.

The following figure illustrates the difference.

The proxy running on each node is distributing requests randomly or based on the round robin algorithm among all pods running in the cluster. Doing so increases the network traffic between EC2 instances and between AZs which consumes network capacity and adds latency.