AWS ECS vs. EKS: Comparison and Recommendations

Containers are the preferred way to run applications these days, and container orchestrators are the best way to manage containers. Orchestrators allow you to manage hundreds or even thousands of containers easily. They take care of tasks like autoscaling, ensuring high availability, and enabling auto-healing. In addition, log management, alert management, and deployment all become easier because all the containers are managed using a centralized control plane. 

Two AWS services used for container orchestration are AWS Elastic Container Service (ECS) and AWS Elastic Kubernetes Service (EKS). ECS is a proprietary service offered by AWS that launched in 2015 for managing containers. EKS is a managed offering of Kubernetes that AWS launched in 2017.

Both ECS and EKS are world-class container orchestrators provided by AWS. This article explains AWS Elastic Container Service and Elastic Kubernetes Service and discusses the differences between them to help you make an informed choice about which to use for your application.

Executive summary

Here is a summary of the differences between ECS and EKS at a high level.

What is ECS?

AWS Elastic Container Service is a container orchestration tool that AWS launched in 2015 to manage containers on AWS. 

To run containers on ECS, it is necessary to give all the information to AWS on how to run the container in what is called a task definition. This definition includes various parameters, such as the name of the container, the environment variables that need to be set for it, its port mappings, filesystems that need to be mounted into the container, and resources it needs to have provisioned. 

Once the task definition is given to AWS, a service can be created in the AWS ECS Dashboard, where containers from the task definition can be launched. You can specify the number of replicas that need to be created and the auto scaling parameters that are required. ECS takes care of running the containers based on what was specified in the task definition, including restarting the containers if they fail. It also takes care of exposing the containers behind a load balancer.

An ECS service can run in two modes on the cloud: on EC2 instances or AWS Fargate. For AWS EC2 instances, AWS runs the container inside virtual machines within the user’s AWS account. In the case of AWS Fargate, AWS takes responsibility for running the containers without launching any servers in the account. You can think of AWS Fargate as a serverless platform for running containers.

What is EKS?

AWS Elastic Kubernetes Service is a managed Kubernetes offering that launched in 2017 and is built on top of the open source Kubernetes. In EKS, AWS takes responsibility for running the control plane for Kubernetes, while the containers can run on virtual machines in the user’s AWS account or on AWS EKS Fargate, just like with ECS. 

To run services on EKS, you can make use of standard Kubernetes resources like Deployments, Services, Ingresses, and StatefulSets. To integrate Kubernetes into the AWS ecosystem, AWS has made an effort to create controllers. For example, the AWS Load Balancer Controller, once deployed on the cluster, integrates the AWS Load Balancing Service with Kubernetes Ingresses and Services. 

The IAM roles for service accounts make it easy to provide for fine-grained access control to the pods running on AWS, allowing pods to access AWS resources based on the permissions specified in an IAM role. EKS also integrates well with the AWS auto scaling service, allowing it to scale up when resource requirements increase.

If you are familiar with the open source version of Kubernetes, it is quite easy to run your containers on EKS. You need to create a Kubernetes deployment and give it to EKS, which then creates the pods and runs them.

Differences between ECS and EKS

The table above laid out a summary comparison of the differences between AWS ECS and EKS. Let’s dive into the details in this section. 

Getting Started

ECS is quite easy to get started with if you are familiar with the basics of AWS since it is so well integrated into the AWS ecosystem. It makes use of AWS EC2 instances or Fargate to run the containers and AWS auto scaling groups to scale the number of EC2 instances. It uses Cloudwatch for alerting and logging and AWS load balancers and target groups to send traffic to the containers. It employs AWS Elastic Container Registry (ECR) to maintain images of the container. All of these integrated services mean that the effort required to set up a production-ready ECS system is modest.

On the other hand, getting started with EKS requires some effort. The first requirement is familiarity with Kubernetes. You need to use a tool like eksctl or terraform to set up EKS because it is important to get all the security group rules and IAM roles right; otherwise, the cluster won’t come up, and it can be difficult to diagnose why. 

Once the cluster comes up, you need to set up monitoring, logging, and alerting. You also need to install various third-party services on the cluster so that they can integrate with AWS. For example, you need to install AWS Load Balancer Controller, which takes care of creating a load balancer on AWS when you create an Ingress or a Service on Kubernetes. You also need to install Cluster Autoscaler on the cluster, which takes care of spinning up and removing EC2 instances whenever the Kubernetes control plane requests it. EKS also requires running the Cloudwatch agent on the cluster or an alternative solution to aggregate logs and metrics. 

On ECS, if you need to grant the workloads access to AWS resources like S3, then it is very straightforward to give the permissions to the role and attach the role to the workload. In contrast, on EKS, if you want to give access to AWS resources to your containers without hardcoding any credentials, you need to set up “IAM roles for service accounts,” where the pods are given temporary credentials whenever requested. This requires some additional effort compared to ECS.

Pricing

ECS and EKS charge the same amount for the compute and memory resources provisioned for applications to run. 

Beyond the cost of the virtual machines, AWS ECS charges only for any other AWS resources you provision, such as a load balancer. There are no additional costs associated with running ECS.

AWS EKS charges a fixed cost of approximately $70 per month to run the Kubernetes control plane. AWS EKS also requires a number of controllers and agents to run on the cluster for activities like autoscaling, load balancer integration, and aggregation of logs and metrics.

Vendor lock-in vs. open source

AWS ECS is built on proprietary AWS constructs like the task definition and AWS ECS Service, which means that it is locked to AWS as the vendor. EKS is built on top of the open source Kubernetes platform, making it easy to change vendors as required.

Community support

AWS ECS has been around for longer than EKS, and AWS is by far the largest cloud provider, so there is a lot of community support available for it. That said, EKS is built on top of Kubernetes, which, as an open source product, has even more community support.

A quick search of Stack Overflow shows that Kubernetes had 12 times more questions than ECS at the time of writing this article. While community support for ECS is significant, Kubernetes is one of the most actively developed software projects in the world, and the range of open source tools, blogs, video courses, and general documentation is far greater than what is available for ECS.

Maintenance

Maintaining an ECS cluster is easier than maintaining an EKS cluster. AWS EKS requires updating the Kubernetes control plane version annually (assuming that you are using the latest EKS version when you deploy), which requires some testing and effort.

A fair amount of expertise is also required to understand and work with various aspects of Kubernetes, like networking and security. In contrast, ECS builds upon the networking and security aspects of AWS; it only requires updating the container agent, which happens quite easily by rolling out new nodes and terminating the old ones. 

Open source support

Because Kubernetes is an open source product, there are a number of open source tools like Helm, Flux, and Kustomize available for doing deployments on Kubernetes. These tools can be used in isolation or in combination. Helm allows you to build manifests for Kubernetes and deploy them anywhere as a package. You can share these packages in your organization or as an open source product. For example, packages for databases like MySQL and Postgres have been created by the community, which anyone can use to deploy a production-grade MySQL or Postgres cluster on top of Kubernetes in minutes. Flux allows you to use a git repository to declare the desired state of your cluster. Any change to the git repository will instantly reflect on the cluster.

ECS does not offer these capabilities. At most, one can use tools like Cloudformation and Terraform to manage deployments on ECS, which, when coupled with CI/CD tools, can provide for push-based declarative gitops.

One of the biggest benefits of working with Kubernetes is the huge library of open source Helm charts available, which make it very easy to deploy commonly used applications. This feature can be a key factor in choosing EKS over ECS. These Helm charts allow you to deploy any open source application, like Elasticsearch, MySQL, Kafka, or RabbitMQ, using a single command. This capability is not available on ECS.

Monitoring and Logging

Since ECS is proprietary to AWS, it is quite well integrated with Cloudwatch for both alerting and monitoring. It is very easy to set up because metrics automatically end up in Cloudwatch. Based on those metrics, alerts can be created in Cloudwatch alarms. 

For logs, ECS is quite well integrated with Cloudwatch; they are very easy to set up and require minimal configuration. ECS can also integrate with tools like Datadog, Prometheus, and Grafana, but this requires more effort and expertise than when using EKS.

EKS requires additional effort and expertise to set up logging, monitoring, and alerting. There are many open source tools like Prometheus and Grafana available for setting up monitoring and alerting. You can also deploy AWS’s own Cloudwatch agent to get data in container insights on AWS, though this can get quite expensive due to the amount of data and metrics EKS generates. It is also possible to easily integrate with tools like Datadog or NewRelic when working on Kubernetes by deploying their agents.

There is also a lot of flexibility for setting up logging on EKS. You can deploy a variety of agents based on your requirements to send data to destinations like Elasticsearch, Splunk, Cloudwatch Logs, or any other third-party tool. Compared to ECS, it is very easy to set up these on EKS because of the availability of Helm charts; if you are familiar with Helm, setting up these tools for production becomes very easy.

ECS/EKS Anywhere and Outposts

AWS offers two options for operating containers outside the AWS platform while still including them within the AWS governance and orchestration purview: Anywhere and Outposts. Both EKS and ECS support these features. 

EKS/ECS Anywhere allows you to run containers on your on-premises infrastructure (hardware that is built by you). When working with ECS Anywhere, you need to install the ECS container agent and SSM Agent on your nodes to connect to the ECS control plane in the cloud. When working with EKS Anywhere, AWS will provide the distros for the machines as well as the control plane that you can run on your own infrastructure. 

Both EKS and ECS support running on AWS Outposts (which is hardware shipped by AWS running in your data center) as well as Anywhere (where you provide the hardware). 

Recommendations

ECS is recommended if you are just getting started with running containers in general, don’t have any expertise with Kubernetes, don’t want to run commonly deployed applications, and don’t want to get into a lot of ops. If you have expertise with Kubernetes and will be running a lot of workloads, there are benefits to setting up a Kubernetes cluster. 

If you run a lot of open source databases like Kafka, RabbitMQ, or Elasticsearch and don’t want to deal with the pain of setting them up on virtual machines, then running an EKS cluster might be a good choice due to it being open source. 

If you are looking to stick with AWS services like Cloudwatch for considerations like logging and monitoring, then ECS might be a good option. However, if you want flexibility in setting up your alerting, monitoring, and logging stack without having a lot of knowledge and expertise in the logging and monitoring area, then EKS should be your choice because of the availability of Helm charts, which make deploying third-party tools very easy.

If you want the best deployment strategies, there are a plethora of tools available for use with EKS that provide a number of ways to make deployments based on your use case. For example, features like Gitops and Helm Charts make life a lot easier while ensuring that there are fewer bugs. However, with EKS’s flexibility comes considerable complexity. If you’d like to keep things simple, ECS should be the better choice. 

Here are a few additional guidelines:

• If you are trying to avoid vendor lock-in, EKS is a better choice than ECS. 
• If you’d like to keep your costs low, ECS might be a better choice. 
• For running containers on-premises, you can choose either EKS or ECS since both support multiple ways of doing so.

Conclusion

In this article, we learned about container orchestration and the two ways to orchestrate containers on AWS: ECS and EKS. We then looked into what ECS and EKS are and discussed the details of the differences between them. Here are some important points you can take away from this article:

• ECS is simple to get started with and should be the choice for simple workloads.
• EKS has a lot of features because it is based on Kubernetes, which provides considerable flexibility. However, running it requires more expertise, resources, and effort, which can make it quite expensive and time consuming.
• EKS has a number of different open source projects available to solve different problems via community support. These help in tackling problems such as quickly setting up a production-grade MySQL or Elasticsearch cluster.