Overview

Discover how CloudZero helps engineering and finance get on the same team — and unlock cloud cost intelligence to power cloud profitability

Learn more Arrow Arrow

Explore CloudZero

Discover the power of cloud cost intelligence


Why Change Icon
Why Change?

Give your team a better cost platform

Services Icon
Services

Give engineering a cloud cost coach

About Icon
About

Learn more about CloudZero and who we are

Pricing Icon
Pricing

Learn more about CloudZero's pricing

Tour Icon
Tour

Take a customized tour of CloudZero

Features

Explore CloudZero by feature


Cost Anomaly Detection Icon
Cost Anomaly Detection

Build fast with cost guardrails

Budgeting Icon
Budgeting And Forecasting

Drive accountability and stay on budget

Discount Dashboard Icon
Discount Optimization Dashboard

Manage all your discounts in one place

Dimensions Icon
CloudZero Dimensions

Organize spend to match your business

By Use Case


Cost Per Customer
Cost Per Customer Analysis

Understand your cloud unit economics and measure cost per customer on AWS

Kubernetes Cost Analysis
Kubernetes Cost Analysis

Discover and monitor your real Kubernetes and container costs

Unit Cost Analysis
Unit Cost Analysis

Measure and monitor the unit metrics that matter most to your business

Cost Allocation
Tagging And Cost Allocation

Allocate cost and gain cost visibility even if your tagging isn’t perfect

SaaS COGS
SaaS COGS Measurement

Identify and measure your software COGS

Engineering Cost Awareness
Engineering Cost Awareness

Decentralize cost decisions to your engineering teams

Cloud Cost Optimization
Cloud Cost Optimization

Automatically identify wasted spend, then proactively build cost-effective infrastructure

Migration Cost Monitoring
Migration Cost Monitoring

Monitor your AWS cost and track progress in real-time as you move to the cloud

By Role


All Your Cloud Spend, In One View

CloudZero ingests data from AWS, GCP, Azure, Snowflake, Kubernetes, and more

View all cost sources Arrow Arrow

Learn

Discover the best cloud cost intelligence resources


Resources Icon Resources

Browse helpful webinars, ebooks, and other useful resources

Blog Icon Blog

Discover the best cloud cost intelligence content

Case Study Icon Case Studies

Learn how we’ve helped happy customers like SeatGeek, Drift, Remitly, and more

Events Icon Events

Check out our best upcoming and past events

Cost Assessment Icon Free Cloud Cost Assessment

Gauge the health and maturity level of your cost management and optimization efforts

Featured

CloudZero Advisor

Compare pricing and get advice on AWS services including EC2, RDS, ElastiCache, and more

Learn more Arrow Arrow

How SeatGeek Measures Cost Per Customer

Discover how SeatGeek decoded its AWS bill and measures cost per customer

Read customer story orangearrow arrow-right

How Skyscanner Creates A Cost-Aware Culture

Learn how Skyscanner decentralized cloud cost to their engineering teams

Read customer story orangearrow arrow-right

How Malwarebytes Measures Cost Per Customer

Learn how Malwarebytes measures cloud cost per product

Read customer story orangearrow arrow-right

How Remitly Shifts Cloud Costs Left

Learn how Remitly built an engineering culture of cost autonomy

Read customer story orangearrow arrow-right

How Ninjacat Combines AWS And Snowflake Spend

Discover how Ninjacat uses cloud cost intelligence to inform business decisions

Read customer story orangearrow arrow-right

How Smartbear Uses Cloud Cost To Inform GTM Strategies

Learn Smartbear optimized engineering use and inform go-to-market strategies

Read customer story orangearrow arrow-right
arrow-left arrow-right
View all customer stories

AWS ECS Vs. EKS Vs. Fargate: Which One Should You Use?

Want to choose the best Amazon container service for your applications? Here’s an in-depth comparison of EKS, ECS, and AWS Fargate.

Is your current cloud cost tool giving you the cost intelligence you need?  Most tools are manual, clunky, and inexact. Discover how CloudZero takes a new  approach to organizing your cloud spend.Click here to learn more.

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

How To Compare ECS Vs. EKS Vs. Fargate

To understand how EKS, ECS, and Fargate differ, consider how AWS's container services are organized.

  • AWS Registry services enable you to store and manage container images. Amazon Elastic Container Registry (ECR) is in this category.
  • AWS Orchestration services let you manage where and when your containers run. The two services in this category are Amazon ECS and Amazon EKS.
  • AWS Compute services power your containers. AWS provides two such services: AWS Fargate and Amazon Elastic Compute Cloud (EC2).

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 EKS vs ECS 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. 

What Is Amazon EKS?

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.

how amazon eks works

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.

What Is Amazon ECS?

Amazon Elastic Container Service (ECS) is Amazon's Docker-based container scheduling and orchestration system that the AWS team built from scratch. 

how amazon ecs works

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:

CloudZero Advisor

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.

What is 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).

How Fargate Works

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:

EC2 vs fargate

The difference between EC2 launch type and Fargate launch type for ECS containers — Digital Cloud

Amazon ECS Vs. EKS: 15 Major Differences

These are some of the notable differences between EKS and ECS, as we promised earlier:

 

Amazon ECS

Amazon EKS

What’s the smallest deployable unit?

An ECS Task 

An EKS pod

Containers supported

Docker containers


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 potentially 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 easeir 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.

Amazon EKS Vs. ECS Vs. AWS Fargate: Use Cases

These services have different best use cases. Here are some examples: 

When to use Amazon EKS

  • Your workload runs on Kubernetes but you want a managed K8s service to simplify management
  • Controlling your tooling, including integrating open-source tools, has benefits
  • You need more networking nodes on-demand 
  • If you plan to migrate your containerized application to AWS, GCP, Azure, or another K8s-compatible service
  • You already have the time and expertise to deploy, run, and optimize containers on Kubernetes
  • Your containerized apps are complex, enterprise-level, and will continue to expand
  • You have a robust Kubernetes cost analysis and optimization solution to prevent overspending
  • Having more control of container placement is important to you
  • You are ready to pay a little extra each month for EKS alone

When to use Amazon ECS

  • Most of your workloads run on the AWS ecosystem, and you want to run containers at scale with an opinionated AWS solution.
  • You need deep integration with AWS services, including Code Pipeline and ECR, as well as tools for monitoring and optimizing costs.
  • A relatively easy learning curve, high performance, and accelerated development are all things you need right away
  • You have limited time and expertise to learn, migrate, and maintain your container workload in Kubernetes
  • You want to reduce container management costs, including using ECS on EC2 Spot instances or Fargate Spot instances
  • Kubernetes seems overkill for your small deployment
  • Using Docker containers and Docker Compose is your best choice over Kubernetes
  • Using it as a learning platform for future large-scale K8s deployments
  • If you want to further simplify running containers at scale with AWS Fargate

When to use AWS Fargate:

  • Your existing workload is running on serverless technologies or you plan to do so in the future
  • A minimal server management strategy is crucial to your productivity, cloud costs, etc. Whenever your workload requires it, Fargate automatically adds new, pre-configured servers 
  • You only need container-level permissions and customizations for optimal performance
  • Using Docker or Kubernetes-based containers is mostly irrelevant to you
  • Running your own components is important to you
  • You don't have a problem using only one networking mode; AWS VPC
  • You want heterogeneous clusters with tasks that can run on both Fargate and EC2 instances
  • Pay only for computing time, not underlying EC2 instances

Let’s break that down a little further, especially between ECS and EKS. 

In Our View

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 maybe 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.

Amazon ECS On Fargate Or Amazon EKS On Fargate?

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.

EKS On Fargate Vs. ECS On Fargate: What Are The Trade-offs?

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.

Limited features

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:

  • disableNetworking
  • dnsSearchDomains
  • dnsServers
  • dockerSecurityOptions
  • extraHosts

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.

Higher cost

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.

How To Monitor, Reduce, And Optimize Costs Of Containerized Applications In AWS

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.

Kubernetes complete cost

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:

  • See the true cost of each service in your application.
  • Get a weekly and monthly cost change summary for each service.
  • Receive timely cost anomaly alerts if costs change negatively. You’ll have real visibility into your cloud architecture to uncover which services cost you the most and are lowering your margins.
  • View granular costs such as cost per customer, cost per environment, cost per project, cost per software feature, cost per team, cost per deployment, etc.

Picture this:

CloudZero Explorer

Better yet, this:

Dashboard

CloudZero cost per customer view

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. 

Request a demo today to discover how CloudZero can help you untangle your cloud costs.

STAY IN THE LOOP


Join thousands of engineers who already receive the best AWS and cloud cost intelligence content.