AWS provides a number of useful services for managing and deploying containers, three among them being Amazon Elastic Compute (ECS), Elastic Kubernetes Service (EKS), and Fargate.
Making the right choice between these services is not always easy because, while they might look similar on the surface (and are all equally popular), they each have unique characteristics, advantages, and disadvantages.
In this article, we’ll give a detailed comparison of the three services and the best use cases to help you make the right choice depending on your business needs.
Table of Contents
To appreciate the differences between these services, you need a general understanding of how container services are organized in AWS.
Amazon classifies its container management tools into three categories: registry, orchestration, and compute.
From the classification above, it’s clear that we can only directly compare Amazon ECS and EKS because Amazon Fargate is a different type of service (one that can work with either ECS or EKS). Instead, the right comparison would be:
ECS using Fargate vs. EKS using Fargate
Amazon Elastic Kubernetes Service (EKS) is Amazon’s Kubernetes as a Service solution that allows you to run and manage Kubernetes applications in AWS or on-premise.
Kubernetes is a favorite tool in the DevOps community. One of its most important requirements is an underlying elastic cloud computing provider. While it is possible to run Kubernetes in your own data center, you get the best results when Kubernetes is run in a cloud environment. Naturally, AWS is one of the top choices. In fact, over 80% of Kubernetes workloads run on AWS.
Running Kubernetes in the cloud means managing, provisioning, and doing all the hard work of maintaining the Kubernetes environment. Unsurprisingly, there’s a lot of overhead involved in those activities.
One of the main reasons for the overhead is that Kubernetes is notoriously difficult to manage and requires a high level of operational excellence.
The reality is that, for many other businesses, managing and maintaining native Kubernetes is a time suck. Amazon recognizes this and provides a service that allows customers to outsource the cumbersome part of Kubernetes management. Amazon EKS is simply Kubernetes run and maintained by Amazon.
EKS gives you access to all native Kubernetes features; you can configure some of the details of Kubernetes and use all your favorite Kubernetes tools whether open source or customized without being locked into the AWS platform.
With EKS, you simply outsource the boring and difficult parts of maintaining Kubernetes. In exchange for giving up a little flexibility and access to bleeding-edge features, Amazon provides you with a much more stable environment for building your applications.
Amazon Elastic Container Service (ECS) is Amazon's container scheduling and orchestration system that was built from the ground up by the AWS team. It is a fully managed container orchestration service that allows you to focus on building and managing your applications instead of your infrastructure.
With Amazon ECS, you do not need to install, operate, and scale your own cluster management infrastructure — Amazon takes care of all that. Specifically, ECS supports Docker containers and is often called Amazon’s Docker as a Service.
One benefit of Amazon ECS is that it is more tightly coupled with the broader AWS ecosystem.
For example, if you’re really into the Amazon ecosystem, you may want to build an event-driven system that can signal containers to run within ECS or an Amazon system that sends events through Amazon Event Bridge or SNS, or other types of components.
If you then want to attach that infrastructure to ECS or find a bridge to connect parts of the application with ECS, you’ll have a lot of configuration options in ECS compared to EKS.
You can very easily pass data and orchestrate work between serverless Lambda functions, calling ECS functions, feeding data back into Lambda, or feeding data to other services with AWS. This way, you can create a really nice ecosystem of AWS products.
So, if you are building containerized systems where the containerized part is just one piece of a broader AWS ecosystem, ECS is the logical choice. If you’ve built a system using a lot of AWS platform services, such as RDS, SNS, S3, SQS, Eventridge, DynamoDB, and need some additional capabilities, you may want to use ECS.
However, if you’re trying to isolate all your applications, logic, and systems so that you have maximum portability, then EKS is the tool to consider.
Companies often choose EKS over ECS because they fear cloud lock-in. And they believe that if they build their applications using only the building blocks provided by Kubernetes, that they will have maximum portability. In other words, if there’s an issue with their cloud provider, they can pick up all their containers and move to a different cloud provider.
However, the most cost-effective, efficient, and well-architected systems are the ones that instead treat the cloud provider as the operating system and they make a clear commitment to the platform.
Making this definitive choice will save the team a lot of engineering time that would have been otherwise spent on pursuing a multi-cloud strategy. The time saved would allow them to build functionality faster and deliver more features to market. See this blog for a more detailed look comparing multi-service and multi-cloud strategies.
So, if you’ve embraced a multi-service strategy with AWS as your anchor cloud provider, ECS is almost certainly a better choice. The only challenge with ECS is that it’s harder to find and hire talent because ECS is not as universal as Kubernetes or EKS.
However, in general, ECS is easier to learn than Kubernetes. If you were starting from scratch at a point of zero-knowledge, in our view, you could become an ECS expert in half the time it would take you to become a Kubernetes expert.
AWS Fargate is a serverless compute service for containers that can be used to run both Amazon ECS and EKS. Both services (ECS and EKS) manage how your containers run, but you still need a compute layer.
For example, if you are running native Kubernetes, the entire burden of maintenance and management rests with you. If you switch to EKS, you relieve some of that responsibility.
You don’t have to maintain all your Kubernetes infrastructure, but you do need to configure Kubernetes. While there’s considerably less investment in time in terms of managing that pool of compute, there’s still something you have to manage.
In other words, whether you are using either ECS or EKS alone, your compute is still visible to you and you have to manage it — a feat that could be significant work, depending on your goals. This is where Fargate comes in.
With Fargate, you don’t have to worry about managing the underlying compute because Amazon takes care of it. You don’t need to be aware of what’s going on behind the scenes. The only thing you manage is how Kubernetes is configured or how your Docker containers are configured in the case of ECS.
Overall, in terms of control, effort, and overhead on the part of the DevOps manager, native Kubernetes offers maximum configurability and maximum effort. EKS offers reduced effort for maintaining Kubernetes while ECS offers reduced effort for maintaining Docker containers. However, both require the same effort to maintain compute infrastructure.
EKS on Fargate offers minimum effort to maintain both Kubernetes and the underlying infrastructure. Likewise, ECS on Fargate offers the least effort to maintain both Docker containers and the underlying infrastructure.
While running EKS or ECS on Fargate offers the most time-saving benefits over managing your own compute, it is not without limitations. Two major ones are limited features and cost.
When using EKS or ECS on Fargate, you give up some configurability and advanced features. For example, with EKS on Fargate, you cannot run certain types of workloads such as Daemonsets or Privileged pods. See the full list of limitations here.
Similarly, with ECS on Fargate, some task definitions, such as the following, are not supported:
See the full list of invalid tasks here.
These limitations mean that EKS or ECS on Fargate may not be an option if you need these prohibited services or invalid tasks.
Depending on your workload structure, you may find that, while it’s easy to configure EKS or ECS on Fargate, it may be more expensive than managing your own compute.
A common misconception, however, is that Fargate is far more expensive than when EKS or ECS run on EC2 compute.
This is becoming increasingly not true. When Fargate was first launched, it was indeed more expensive than managing your own compute. However, over time as Amazon improved Fargate, it has become less and less so. See this article for a breakdown of Amazon Fargate pricing.
One of the major challenges when using containers is understanding cost at a granular level. The most granular level that you can imagine within a containerized world is to get down to your cost per pod. Understanding the cost of your containerized workloads at this level, either at a point in time or overtime, is difficult.
This is because adding an extra layer of infrastructure — whether it's just EKS or ECS on EC2 or ECS or EKS on Fargate — obscures a lot of the cost data so that your billing becomes misaligned with the actual cost of running your infrastructure. And it becomes very hard to understand the costs of the different components of your infrastructure. This is where CloudZero comes in.
CloudZero is a cost intelligence tool that helps you understand how your costs really break down, whether you’re running EKS, ECS on Fargate, or EKS, ECS on EC2. With CloudZero, you’ll gain better visibility into your cloud costs in order to make informed decisions as you're building products, leveraging these new kinds of infrastructure.
A common use case is understanding the true cost of each service when implementing a microservice architecture on EKS or ECS. CloudZero cloud cost intelligence enables you to group all resources that make up a service like EKS pods or ECS tasks with the data sources owned but that service Amazon RDS or AWS DynamoDB, together as a “Cost Context.”
This grouping allows you to see the true cost of each service in your application. CloudZero delivers a weekly and monthly cost change summary for each service — and anomaly detection if cost changes negatively. You’ll have real visibility into your cloud architecture to uncover which services cost you the most and are lowering your margins.
To learn more about how CloudZero helps you accurately monitor and manage your container costs, request a demo here.