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

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.

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.

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.

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

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

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

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.

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.