Managing Kubernetes: AWS EKS vs. ECS vs. Fargate
Running Kubernetes on AWS? In this article, you'll learn how to choose between AWS EKS vs. ECS vs. Fargate to find the optimal managed Kubernetes service.
Join the DZone community and get the full member experience.Join For Free
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 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.
- 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%.
- 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).
- You’re charged for the EC2 instances running 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.
- 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
- ECS + Fargate supports only one networking mode—awsvpc—which limits your control over the networking layer (and you might need that in some scenarios).
- 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 cost 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 do you choose the best VM type? Consider your selection across these four dimensions:
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
|Pricing||ECS is free of charge and you only pay for the compute costs
A good match for those who are starting to explore microservices and containers
|$0.1 per hour per Kubernetes cluster (c. $74 per month) + compute costs
Pick it if you’re ready to handle the scalability level of Kubernetes
|Deployment||Simple to deploy
No control plane
Configuration and deployment directly from the AWS management console
Requires less expertise and operational knowledge
|More complex deployment
Configure and deploy pods via Kubernetes first
Requires expert configuration
|Multi cloud portability||AWS proprietary technology
Potential risk of vendor lock-in
Full portability between different clouds
|Networking||Limited number of ENIs per instance
Might not be enough to support all the containers you want running on a particular instance
You can share an ENI between multiple pods and place more pods per instance.
|Community support||Limited community assistance
Corporate AWS support
|Plenty of community support
Resources and community-maintained tools
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.
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.
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 into 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 Choose 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.
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.
Published at DZone with permission of Vito Clover. See the original article here.
Opinions expressed by DZone contributors are their own.