The Amazon Web Services (AWS) cloud offers multiple approaches to deploying containers. You can use Elastic Container Service (ECS), a custom-managed container platform developed by AWS. Or, you can use Elastic Kubernetes Service (EKS), a managed Kubernetes service.

Which option is better – ECS or EKS? Keep reading for details on comparing the two AWS-managed container service offerings. We'll also touch on using "vanilla" Kubernetes in AWS as an alternative to both ECS and EKS.

What Is Elastic Container Service (ECS)?

Elastic Container Service is a managed container service in the AWS cloud that uses a proprietary orchestrator developed by Amazon.

ECS lets you deploy and manage containers on AWS infrastructure. AWS handles most infrastructure management tasks, meaning you don't need to set up your servers. You mostly have to choose which containers you want to run, and ECS does the rest.

A brief history lesson is warranted to understand why ECS exists. Amazon released the service in 2015. It was not yet clear that Kubernetes would become as massively popular as it is today; there were many competing orchestrators and orchestration services. Amazon created ECS to throw its hat in the ring of the "container orchestration wars." As explained below, it has kept ECS around despite developing a Kubernetes-based container service.

What Is Elastic Kubernetes Service (EKS)?

Elastic Kubernetes Service is a managed container service in the AWS cloud that uses Kubernetes as its orchestration engine.

EKS offers the same core features as ECS. It lets you deploy containers of your choosing with minimal management effort.

EKS became generally available in 2018, by which point it was clear that Kubernetes was going to win the orchestrator wars. Realizing that many customers would want to manage containers using Kubernetes instead of a proprietary orchestration tool, Amazon developed EKS.

Differences Between ECS and EKS

From an end-user experience standpoint, ECS and EKS are not significantly different. As noted above, both services let you deploy containers with minimal effort. Both also support Fargate mode, an optional deployment tool that automatically provisions host infrastructure for your container cluster. (If you don't use Fargate mode, you have to create the host clusters yourself, although you use AWS-based VM instances.)

That said, there are significant differences between the services:

• Access control management: On ECS, you can use the AWS cloud's native IAM tooling to manage roles and permissions. In EKS, you mostly rely on Kubernetes's built-in role-based access control framework.
• Namespace management: You can create Kubernetes namespaces on EKS to segment different workloads. ECS doesn't have a namespace concept. (AWS uses the term in the context of ECS, but it refers to domain names for traffic routing purposes, which is very different from how namespaces function in Kubernetes.)
• Application deployment: On ECS, you can define and deploy applications using proprietary AWS tooling. On EKS, you can use generic Kubernetes deployment specifications.
• Managed node groups: Only EKS offers a managed node group feature, which is one option for automating infrastructure provisioning for a container cluster. (That said, as noted above, both ECS and EKS support Fargate, which provides functionality comparable in many ways to managed node groups.)
• Monitoring and observability: Most third-party monitoring and observability tools that are Kubernetes-compatible can work with EKS. With ECS, however, you are limited primarily to Amazon's built-in tooling. Because ECS is not nearly as popular as Kubernetes, fewer vendors have built solutions that integrate with it.

As you can see, most of these differences result from the fact that EKS derives from Kubernetes and ECS doesn't, meaning EKS is manageable like any other Kubernetes-based environment in most respects. In contrast, ECS requires a unique approach tied to AWS's tooling.

What About Vanilla Kubernetes on AWS?

It's worth noting that you can use Kubernetes on AWS without using EKS. You can create a cluster of servers using EC2, then install Kubernetes on them and manage it yourself.

This approach would give you almost total independence from AWS's Kubernetes tooling. You could deploy and manage your Kubernetes applications generically.

The downside is that setting up and managing your cluster is a lot of work. Most people who want to run containers in the AWS cloud choose either ECS or EKS.

Conclusion

When deciding between ECS and EKS, the main factor is whether you want to use a "Kubernetes-native" approach to managing your workloads or are more comfortable using proprietary AWS tooling. EKS makes more sense in the former case. And if you want total independence from vendor-specific tools, you can run vanilla Kubernetes on a cluster of your creation.

‍