Discover how CloudZero helps engineering and finance get on the same team — and unlock cloud cost intelligence to power cloud profitability
Learn moreDiscover the power of cloud cost intelligence
Give your team a better cost platform
Give engineering a cloud cost coach
Learn more about CloudZero and who we are
Learn more about CloudZero's pricing
Take a customized tour of CloudZero
Explore CloudZero by feature
Build fast with cost guardrails
Drive accountability and stay on budget
Manage all your discounts in one place
Organize spend to match your business
Understand your cloud unit economics and measure cost per customer
Discover and monitor your real Kubernetes and container costs
Measure and monitor the unit metrics that matter most to your business
Allocate cost and gain cost visibility even if your tagging isn’t perfect
Identify and measure your software COGS
Decentralize cost decisions to your engineering teams
Automatically identify wasted spend, then proactively build cost-effective infrastructure
CloudZero ingests data from AWS, GCP, Azure, Snowflake, Kubernetes, and more
View all cost sourcesDiscover the best cloud cost intelligence resources
Browse webinars, ebooks, press releases, and other helpful resources
Discover the best cloud cost intelligence content
Learn how we’ve helped happy customers like SeatGeek, Drift, Remitly, and more
Check out our best upcoming and past events
Gauge the health and maturity level of your cost management and optimization efforts
Compare pricing and get advice on AWS services including EC2, RDS, ElastiCache, and more
Learn moreDiscover how SeatGeek decoded its AWS bill and measures cost per customer
Read customer storyLearn how Skyscanner decentralized cloud cost to their engineering teams
Read customer storyLearn how Malwarebytes measures cloud cost per product
Read customer storyLearn how Remitly built an engineering culture of cost autonomy
Read customer storyDiscover how Ninjacat uses cloud cost intelligence to inform business decisions
Read customer storyLearn Smartbear optimized engineering use and inform go-to-market strategies
Read customer storyWant to choose the best Amazon container service for your applications? Here’s an in-depth comparison of EKS, ECS, and AWS Fargate.
Amazon Web Services (AWS) provides more than 200 services. Among those, Amazon Elastic Compute Service (ECS), Elastic Kubernetes Service (EKS), and AWS Fargate help deploy and manage containers.
Choosing between these services can be challenging. They seem similar on the surface (and are all popular). But each offers unique benefits and limitations.
In this guide, we compare the three services, discussing the best use cases for each, and helping you choose the best fit for your business.
Table of Contents
To understand how ECS vs. EKS vs. Fargate differ, consider how AWS's container services are organized.
As you can see, the only real comparison we can make here is between Amazon ECS and Amazon EKS. Amazon Fargate is an entirely different type of service, which you can use with either ECS or EKS. But we’ve got a way.
Now, before we compare ECS vs. EKS side-by-side, and then discuss when to use ECS, EKS, or Fargate, here’s some background.
Kubernetes (K8s) is a favorite container orchestration tool in the DevOps community.
Although you can deploy Kubernetes in your data center, you get the best results when you run it in the cloud. According to Nucleus Research, about 82% of cloud-hosted K8s workloads run on AWS.
Yet, Kubernetes can be notoriously challenging to configure, provision, and manage continuously. It requires a high level of operational excellence — often time-consuming, with a lot of overhead involved.
That is where ECS and EKS, and Fargate, come in.
Amazon Elastic Kubernetes Service (EKS) is Amazon’s fully managed Kubernetes-as-a-Service platform that enables you to deploy, run, and manage Kubernetes applications, containers, and workloads in the AWS public cloud or on-premise.
Credit: How Amazon EKS works
Using EKS, you don't have to install, run, or configure Kubernetes yourself. You just need to set up and link worker nodes to Amazon EKS endpoints.
Then AWS handles all your Kubernetes control plane admin tasks, including patching, upgrades, replacing unhealthy instances, security configurations, and scaling your K8s containers across multiple AWS Availability Zones.
Amazon EKS scales backend persistent layers and API servers as well. One more thing. Because Amazon EKS is Certified Kubernetes-Compatible, it is also seamlessly compatible with the applications you run on upstream Kubernetes.
With Amazon EKS, you get a simplified K8s platform that is also stable, highly scalable, and natively secure for building Kubernetes apps.
Amazon Elastic Container Service (ECS) is Amazon's Docker-based container scheduling and orchestration system that the AWS team built from scratch.
Credit: How Amazon ECS works
ECS is a fully managed container service that enables you to focus on improving your code and service delivery instead of building, scaling, and maintaining your own Kubernetes cluster management infrastructure.
Amazon ECS is often called Amazon’s Docker-as-a-Service platform while Amazon ECS Anywhere is the on-premises version.
Amazon ECS defines containers in a task definition, which you use to run individual tasks or tasks within services. A service here refers to a setup you can use to execute a specified number of tasks in a cluster simultaneously.
A unique feature of Amazon ECS is that you can use two launch types or compute (CPU, RAM, and storage) services to run your containers:
Launch ECS with Amazon EC2
With this option, you are able to choose, configure, and run your containers on specific EC2 instances. You have the most flexibility and control over the performance of your containers with this option, even though it requires the most work (choosing instances, provisioning, scaling, etc.).
You can use a robust tool like CloudZero Advisor to choose the best AWS instance types for your specific AWS service, budget, resource type, region, workload, and more. Here’s a quick look:
Launch ECS with AWS Fargate
With this option, you can run those tasks and services on serverless infrastructure. Thus, you manage minimal ECS tasks while AWS Fargate does the majority. Here's a look at how Fargate works.
Key takeaway: Organizations with adequate and experienced engineers launch ECS with EC2 instances while companies determined to simplify container management the most use the AWS managed Fargate route.
We've summarized the two launch types below in the section on AWS Fargate.
AWS Fargate is a fully managed serverless compute service. In exchange for giving up some level of control, Fargate automates the vast majority of container management tasks.
For example, it lets you set resource parameters and access controls, but it won't let you choose which specific AWS instance types to use or when and how to scale your ECS resources. AWS Fargate manages these last two aspects on your behalf using algorithms.
Fargate is primarily a Container-as-a-Service (CaaS) solution. It works as an operational mode in ECS (Docker-based containers) and EKS (Kubernetes-based containers).
Something else. AWS Fargate runs each EKS pod or ECS task on its own isolated, dedicated runtime environment, thereby securing them.
Here’s a quick look at launching ECS on Fargate vs. deploying on EC2 instances now that we've covered Fargate:
The difference between EC2 launch type and Fargate launch type for ECS containers — Digital Cloud
These are some of the notable differences between ECS vs. EKS, as we promised earlier:
|
Amazon ECS |
Amazon EKS |
What’s the smallest deployable unit? |
An ECS Task |
An EKS pod |
Containers supported |
Supports Docker Compose in its CLI |
Kubernetes based containerized apps |
Fully managed or self-managed? |
Fully managed container orchestration service |
Fully managed Kubernetes control plane |
Cluster management |
A simple API eliminates complexity while using Route 53 and Elastic Load Balancer further eases management. Also, restricts moving container instances to another cluster or changing instance types after deployment. But supports hundreds of containers because you can duplicate environments with AWS SDK/CLI calls |
The control plane adds a layer of abstraction, plus the concept of namespaces isolates workloads running in the same cluster, adding complexity. Limits replicating up to three masters in different Availability Zones (requires you to raise a ticket to get more) and up to five control plane security groups |
Scalability |
Highly available and scalable. Also supports both manual configuration and automated scaling without running out of control |
Highly scalable and available. But requires manual configuration of parameters, requests, and Horizontal Pod Autoscaler. Or, you need to add AWS Autoscaler separately |
Identity and access management (IAM) support |
Supports deep integration with IAM natively, allowing IAM roles down to the task or container level |
Requires some add-ons (like KIAM) to enable deep integration with IAM at the pod level, increasing complexity and potential costs |
Ease of use |
Doesn’t require a control plane as it is a native offering, and is designed to run with minimal resource provisioning |
Requires a fair amount of configuration and experience to set up and run although its easier than managing upstream K8s |
Is it open-source? |
ECS is a proprietary AWS product with limited extensibility |
EKS is based on open-source Kubernetes APIs, native tooling, and a lot of supported add-ons, boosting extensibility |
Support included? |
Support plans, documentation, and training available from AWS's technical team |
Community-based support system |
What’s the networking limit? |
Assigns an Elastic Network Interface (ENI) to a task with Amazon VPC mode. Then runs up to 120 tasks per EC2 instance (higher with special prerequisites) |
Assigns a dedicated network interface with a public IP address to K8s pods. Then runs up to 750 pods per instance and shares ENI between pods |
Does it support multi-cloud integration? |
It’s specific to AWS |
Supports public and private cloud integration |
Compatibility and portability |
It’s natively compatible with most AWS services — not third-party systems, limiting portability |
It's a managed K8s service you can run on any infrastructure — cloud or on-premises, increasing portability between vendors and lowering vendor-lock in |
Does it work with the AWS Fargate serverless compute service? |
Yes |
Yes |
Monitoring |
Built-in monitoring with AWS CloudWatch, Container Insights, and supports third-party monitoring tools, providing insights into the health and performance of your tasks |
AWS CloudWatch, Container Insights, and CloudTrail support built-in monitoring while GuardDuty adds extra K8s audit logs analysis |
What is its pricing model? |
Pay for only the resources you run your containers on |
Same as EKS, but with an additional $0.10 per hour per EKS cluster you run. Launching complementary resources, like EBS volumes, costs extra |
These services have different best use cases. Here are some examples:
Let’s break that down a little further, especially between ECS and EKS.
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 more configuration options in ECS compared to EKS.
Also, 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 Amazon ECS.
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, and DynamoDB, and need some additional capabilities, you might want to consider ECS.
However, if you’re trying to isolate all your applications, logic, and systems so that you have maximum portability, then EKS may be more ideal.
Companies often choose EKS over ECS because they fear cloud vendor lock-in.
They believe that if they build their applications using only the building blocks provided by Kubernetes, 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 otherwise gone into 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. However, it may be harder to find and hire talent because ECS is not as universal as Kubernetes or EKS.
Finally, in general, ECS is easier to learn than Kubernetes. If you were starting from scratch at a point of zero knowledge, you could become an ECS expert in half the time it would take you to become a Kubernetes expert.
EKS on Fargate simplifies running Kubernetes on AWS, while ECS on Fargate simplifies managing Docker containers.
Still, maintaining compute infrastructure requires the same amount of effort. A notable difference here is ECS on Fargate uses Spot instances, which are the most cost-effective instances available on AWS.
Something else. EKS on Fargate is ideal for running a serverless app that requires more than a single networking mode (awsvpc). ECS on Fargate is suitable for running ad hoc jobs with variable usage.
While running EKS or ECS on Fargate saves you time over managing your own compute, it is not without its limitations. Features are limited and costs are high, for example.
Using EKS or ECS on Fargate sacrifices some configurability and advanced features. As one example, you cannot run Daemonsets or Privileged pods with EKS on Fargate. See the full list of limitations here.
Similarly, ECS on Fargate does not support the following task definitions:
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.
It may be more expensive to use EKS or ECS on Fargate than managing your own compute, depending on your workload structure.
A common misconception, however, is that Fargate is far more expensive than when EKS or ECS run on EC2 compute.
This is increasingly untrue. Fargate was initially more expensive than managing your own compute. As Amazon has improved Fargate, that has changed. See this AWS Fargate pricing guide for more details.
That said, many organizations we talk to say they find it challenging to monitor and optimize costs in containerized infrastructure. Is this also your experience?
The following is a way to increase visibility and reduce cloud costs associated with running containers on Amazon Web Services.
Understanding costs at a granular level is often challenging — cost per pod, either at a point in time or overtime.
It's because adding an extra layer of infrastructure, whether it's EKS or ECS on EC2 instances, or EKS or ECS on AWS Fargate, masks a lot of the cost data, so your billing is misaligned with the actual cost.
This makes it very difficult to understand the costs of your infrastructure components. Here's where CloudZero comes in.
First, CloudZero Advisor offers recommendations for AWS instance types based on your service, region, resource configuration, budget, and more. This simplifies things if you prefer to use ECS instead of EKS for greater control and customizability.
Second, CloudZero’s cloud cost intelligence approach empowers you to see how your costs really break down, whether you’re running EKS, ECS on Fargate, or EKS, ECS on EC2 instances.
We see customers using CloudZero to reveal the true cost of each service, microservice, or container, down to the hour, pod, namespace, and cluster levels.
For example, CloudZero groups all the resources that make up a service like EKS pods or ECS tasks with the data sources owned by that service, Amazon RDS, or AWS DynamoDB, together as a “Cost Context.”
This grouping helps you:
Besides, CloudZero combines containerized and non-containerized infrastructure costs within a single platform for granular analysis and breakdown. No cost allocation tags are required.
No need to manage multiple cost tools because CloudZero delivers cost insights across AWS, Azure, GCP, New Relic, Databricks, and Snowflake.
to discover how CloudZero can help you untangle your cloud costs.
Here are answers to the FAQs you may have.
Amazon ECS is an AWS-owned service for managing Docker containers. The Amazon EKS service manages Kubernetes-based containers on the AWS public cloud, while AWS Fargate is a serverless compute service that can run containers on ECS or EKS.
You can use AWS Fargate to run containers on either EKS or ECS.
This depends on your needs. Amazon EKS delivers a fully managed service for Kubernetes containers while Amazon ECS is ideal for running Docker containers.
With Amazon ECS, you pay only for compute capacity to run your containers. The EKS service is not free and costs $0.1 per hour per Kubernetes cluster, or $74 per month, on top of the compute costs.
If you want significant control over your container runtime and performance, use Amazon EC2 instead.
With Fargate, you let AWS handle management tasks such as provisioning, configuring, and scaling clusters of virtual machines to run your containers, saving you time and resources. All that manual management is required when using EC2 instances.
Cody Slingerland, a FinOps certified practitioner, is an avid content creator with over 10 years of experience creating content for SaaS and technology companies. Cody collaborates with internal team members and subject matter experts to create expert-written content on the CloudZero blog.
CloudZero is the only solution that enables you to allocate 100% of your spend in hours — so you can align everyone around cost dimensions that matter to your business.