AWS EKS vs. ECS vs. Fargate: Where to manage your Kubernetes?

We all love containers for their scalability. But it might easily become your overhead if you end up managing a large cluster.

This is where container orchestration comes in. When operating at scale, you need a platform that automates all the tasks related to the management, deployment and scaling of container clusters.

There’s a reason why almost 90% of containers are orchestrated today.

If you’re using Kubernetes on AWS, there are several options you can choose from:

• Elastic Container Service (ECS),
• Elastic Kubernetes Service (EKS),
• AWS Fargate.

Read on to find out which one is a better match for your workloads.

And if you know what’s what in the world of AWS Kubernetes, you could still probably use a few best practices to reduce your cloud bill.

What you’ll find inside:

• What is Elastic Container Service (ECS)?
• What is Elastic Kubernetes Service (EKS)?
• What is AWS Fargate?
• AWS EKS vs. ECS – Similarities
• AWS EKS vs. ECS – Differences

1. Pricing
2. Deployment
3. Multi cloud portability
4. Networking
5. Community

• When to choose EKS?
• When to go for ECS?
• Wrap up

What is Elastic Container Service (ECS)?

AWS ECS stands for AWS Elastic Container Service. It’s a scalable container orchestration platform owned by AWS. It was designed to run, stop, and manage containers in a cluster. The containers themselves are defined here as part of task definitions and driven by ECS in the cloud.

You can use ECS with EC2 instances (best for long-running tasks) or AWS Fargate (good for serverless tasks). Let’s take a closer look at these two options:

ECS with EC2 instances

In this model, containers are deployed to EC2 instances (VMs) created for the cluster. ECS managed them together with tasks that are part of the task definition.

Pros:

You have full control over the type of EC2 instance used here. For example, you can use a GPU-optimized instance type if you need to run training for a machine learning model that comes with unique GPU requirements.
You can take advantage of Spot instances that reduce cloud costs by up to 90%.

Cons:

You’re the one responsible for security patches and network security of the instances, as well as their scalability in the cluster (but thankfully, you can use Kubernetes autoscaling for that).

Cost: You’re charged for the EC2 instances run within your cluster and VPC networking.

ECS with AWS Fargate

In this variant, you don’t need to worry about EC2 instances or servers anymore. Just choose the CPU and memory combo you need and your containers will be deployed there.

Pros:

No servers to manage.
AWS is in charge of container availability and scalability. Still, better select the right CPU and memory – otherwise, you risk that your application becomes unavailable.
You can use Fargate Spot, a new capability that can run interruption-tolerant ECS Tasks at up to a 70% discount off the Fargate price

Cons:

ECS + Fargate supports only one networking mode – awsvpc – which limits your control over the networking layer (and you might need that in some scenarios).

Cost: You’re charged based on the CPU and memory you select. The amount of CPU cores and GB determines the cost of running your cluster.

What is Elastic Kubernetes Service (EKS)?

EKS is a service that provides and manages a Kubernetes control plane on its own. You have no access to the master nodes on EKS since they’re under a special AWS account.

To run a Kubernetes workload, EKS establishes the control plane and Kubernetes API in your managed AWS infrastructure and you’re good to go.

At this point, you can deploy workloads using native K8s tools like kubectl, Kubernetes Dashboard, Helm, and Terraform.

Advantages of AWS EKS

• You don’t have to install, operate, and maintain your own Kubernetes control plane.
• EKS allows you to easily run tooling and plugins developed by the Kubernetes open-source community.
• EKS automates load distribution and parallel processing better than any DevOps engineer could.
• Your Kubernetes assets integrate seamlessly with AWS services if you use EKS.
• EKS uses VPC networking.
• Any application running on EKS is compatible with one running in your existing Kubernetes environment. You can migrate to EKS without applying any changes to code.
• Supports EC2 spot instances using managed node groups that follow spot best practices and allow some pretty great costs savings.

What is AWS Fargate?

Usually, a container management platform reworks a server’s CPU and memory to allocate them to your workloads better. But the underlying server is still there – just divided in a different way. And it might become a burden in managing your systems.

AWS solves this problem with Fargate, by taking over the management of that underlying server.

Instead of doing all the tasks yourself – from booting a server and installing the agent to making sure that it’s up-to-date – you can simply create a cluster and add your workload to it. AWS will add pre-configured servers to the “pool” automatically to support your requirements.

Today, 32% of AWS container environments run on Fargate.

Here are a few things you should know about Fargate before jumping on the Fargate-managed bandwagon:

• It’s not a good fit for highly regulated environments where companies use dedicated tenancy hosting.
• The combination of ECS and Fargate supports only one networking mode (awsvpc) that comes with limitations if you need to have deep control over the networking layer.
• Fargate allocates resources automatically, but you can set few controls over how it works. This can easily lead to uncontrolled cost rise if you fail in close monitoring (for example, in R&D environments). One way to deal with that is through self-hosting and creating limited-capacity clusters.

AWS EKS vs. ECS – Similarities

1. They both have a layer of abstraction

EKS and ECS come with a layer of abstraction for containers called deployments (EKS) or tasks (ECS).

Their functionalities are quite similar. Both ECS and EKS have an abstraction called cluster – a combination of all the working components.

2. They allow a mix of AWS compute platforms

Whether you’re running your containers with ECS and EKS, you can choose one or more AWS compute options:

• EC2 Instances – virtual machines that offer a wide range of options and capacities.
• AWS Fargate – for serverless applications.
• AWS Outposts – a fully managed service that offers the same AWS infrastructure, services, APIs, and tools to data centers or on-premises facilities to make hybrid setups consistent. Great for workloads that need low latency access to on-premises systems or local data processing.
• AWS Local Zones – a kind of AWS infrastructure deployment that locates compute, storage, database, and other services closer to a specific population, industry, or IT centers. Perfect for applications that you want running closer to the end-users.

• AWS Wavelength – this infrastructure is optimized for mobile edge computing applications that help to avoid the latency resulting from application traffic having to go through multiple hops across the Internet to reach the destination. A great pick for low-latency, mobile edge applications.
  How to choose the best VM type? Consider your selection across these four dimensions:

• performance,

• cost,

• availability,

• reliability.

Understanding the differences between all these options essential because they come with different financial commitments and complexity in management.

3. You don’t need to monitor or operate them

These managed services eliminate the effort in operating services and allow your teams to focus on core applications.

You can easily assume that they’re reliable and highly available at all times. The Kubernetes control plane and API will be up and running no matter what – even when updating to the latest release (naturally, this happens automatically as well).

4. They share the approach to security

To access services and resources securely, AWS provides the Identity and Access Management (IAM) solution. You can create users (and user groups) – and then assign permissions to them.

This control system is available in both ECS and EKS. For example, you can use IAM to limit who can access ECS tasks or Kubernetes workloads.

AWS EKS vs. ECS – Differences

1. Pricing

In general, if you run ECS and EKS clusters on EC2 instances, you’ll be paying on compute costs that depend on the instance type you pick and its running time.

ECS doesn’t come with any additional charges, but EKS does.

EKS will charge you $0.1 per hour per Kubernetes cluster. This amounts to c. $74 per month, which doesn’t seem like a lot. But the costs might add up quickly depending on your setup.

If you’re just exploring microservices and containers, ECS is a better option. And if you’re ready to handle the scalability level of Kubernetes, the $74 extra on your bill isn’t going to make much difference against your overall compute costs.

• Check this out too: Kubernetes cost estimation: 4 problems and how to solve them

2. Deployment

You can set up both EKS and ECS from the AWS management console. But then things start looking different.

ECS is really simple to deploy. After all, it was designed to be a simple API for creating containerized workloads without any complex abstractions. You get no control plane, so once your cluster is set up, you can configure and deploy tasks directly from the AWS management console.

Deploying clusters on EKS is a bit more complex and requires expert configuration. You need to configure and deploy pods via Kubernetes first because EKS is just another layer for creating K8s clusters on AWS.

So, you need more expertise and operational knowledge to deploy and manage applications on EKS when compared to ECS.

3. Multi cloud portability

The ideal scenario is when you can move your workloads from one cloud provider to another with minimal disruption. This is what portability is all about. To achieve it, you need interoperability among cloud services.

While ECS is an AWS proprietary technology, EKS is based on Kubernetes which is open-source.

Kubernetes in EKS allows you to package your containers and move them to another platform quickly. ECS might lock you in.

So if you build an application in ECS, you’re likely to encounter a vendor lock-in issue in the long run. And if you choose to design your application on Kubernetes, you can basically run it on any other Kubernetes cluster – from clouds to on-premises.

4. Networking

When using ECS, you use the awsvpc network that receives an elastic network interface (ENI) attached to the container instance hosting it. You’ll be looking at default limits to the number of network interfaces that can be attached to an EC2 instance (the primary network interface counts as one). Just to give you an idea, a c5.large instance may have up to 4 ENIs attached to it by default.

In ECS, the maximum number of ENIs you can assign varies by EC2 type. Even though AWS increased the limits, this might not be enough to support all the containers you want running on that particular instance.

Note that ECS supports launching container instances with larger ENI density using specific EC2 instance types. When you pick such an instance type and opt in to the awsvpcTrunking account setting, you’ll get some additional ENIs on newly launched container instances. So, you can place more tasks using the awsvpc network mode on every container instance.

With EKS, you can assign a dedicated network interface to a pod to improve security. All the containers inside that pod will share the internal network and public IP.

You can share an ENI between multiple pods, which allows you to place more pods per instance.

5. Community support

The open-source Kubernetes rules over proprietary ECS here. The latter offers limited community assistance, so you can only count on the corporate support of AWS.

When running Kubernetes in EKS, you get:

• community support (Stack Overflow, Github issues),
• resources (from official training to online courses),
• community-maintained tools like kubectl extensions, Helm Charts, or Kubernetes Operators.

When to choose EKS?

For some teams, ECS proves to be too simple and comes with limitations that EKS doesn’t have. So, when should you select EKS?

• When you need granular control over container placement – ECS doesn’t have a concept similar to pods. So, if you need fine-grained control over container placement better go somewhere else.
• When you need more networking modes – ECS has only one networking mode available in Fargate. If your serverless app needs something else, EKS is a better choice.

• When you want more control over your tooling – ECS comes with a set of default tools. For example, you can use only Web Console, CLI, and SDKs for management. Logging and performance monitoring is carried out using CloudWatch, service discovery through Route 53, and deployments via ECS itself. If you don’t like any of these tools, go for EKS.
  

  When to go for ECS?

  Some teams might benefit from ECS more than EKS thanks to its simplicity. Here’s when selecting ECS makes the most sense:

• When you have limited DevOps resources – ECS comes with a gentle learning curve so if you’re not prepared to re-architect your applications around Kubernetes concepts, ECS will be easier to adopt.

• When you don’t have time or resources to pick and choose add-ons – Kubernetes and EKS by extension is a far more flexible tool. You can choose from many different add-ons available in the system. But each of them requires time, resources, and maintenance to make the most of it. ECS has only one option in each category – if it works for you, you’re good to go.

• When Kubernetes is too much – If adopting K8s all at once is a little too much for you, ECS could be a good first step. It allows you to try your hand at containerization and move your workloads into a managed service without huge upfront investment.

Wrap up

If flexibility of moving across different cloud vendors isn’t that important to you and you’re happy to put all of your eggs in the (AWS) basket), ECS makes sense.

But if you’d like to have the freedom to integrate with the open-source Kubernetes community, putting in the energy and time to make EKS is worth it.

Whichever tool you choose, you still need to find a way to analyze and optimize cloud costs.

If you’re looking to make your journey with EKS smoother, we might have something for you. Use our EKS cost analyzer to check your cluster costs for free, set cost policies, and reduce your cloud bill. Try CAST AI.