Struggling to understand the difference between AWS ECS on EC2 vs Fargate? This is the blog post for you.
Since 2013, Docker has changed the way we think about and deploy software. Leveraging containers, Docker Images have allowed developers to write operating system agnostic software that runs in virtualized environments. Consistent no matter what OS they are hosted on, containers are a powerful paradigm that are here to stay.
On AWS, there are many options for running your container based applications. ECS or Elastic Container Service is an AWS orchestration service that helps you launch and manage Docker contains into the cloud.
But how does running your containers compare when running them on EC2 vs Fargate? More importantly, when should you use one option versus another? We’re going to answer this and more in this blog post.
First, lets quickly overview the difference between running on EC2 via ECS versus using Fargate.
What is ECS on EC2 and Fargate?
ECS is a container management service. Its main purpose is to facilitate the management of Docker containers for your application. In terms of compute infrastructure to launch your infrastructure on, there are two main options: EC2 and Fargate.
Launching on EC2 involves you setting the corresponding launch mode as part of your launch parameters. You can either use existing EC2 instances that you have lying around, or set up autoscaling groups to automatically deploy more instances as required.
When you select EC2 as your launch option, ECS installed as sidecar process called an ECS Agent alongside your EC2 machines. This agent is responsible for coordinating its instructions with the ECS service that is managing your application. This can include steps like starting, stopping, restarting, health checks, and many more behind the scenes workflows.
Fargate on the other hand does not involve any infrastructure that you directly manager. Instead, AWS managers infrastructure behind the scenes that your service utilizes when needing to launch new Docker containers in your application. This is the primary difference between these two options – self-managed infrastructure (EC2) vs AWS managed infrastructure (Fargate).
Part of the appeal of Fargate is that its so easy to setup, and largely set it and forget it. You don’t need to get bogged down with thinking about infrastructure and configuration.
Before we move further discussing more about Docker on EC2 vs Fargate, we need to define some key ECS terms.
ECS Terminology
Task – A task is the lowest level building block of ECS. I like to think of these as runtime instances of your docker images.
Task Definition – A task definition is a template for Task. It is the specification that defines the memory, cpu, and networking requirements of your task executable. In the task definition, you also specify the Docker image that you’d like to run. Typically, most folks using ECS rely on ECR or Elastic Container Registry to source their images.
Cluster – A cluster is just a logical grouping of Tasks or services. Clusters only really make sense in the context of EC2 machines (since you run your cluster on 1 or more machines), however they are also required when using fargate.
Service – A service is managed component of ECS that allows you to run a number of Tasks over long periods of time. You define the Task Definition that you’d like to use to form the service, and the number of Tasks you’d like running at any time. You can also set up autoscaling with Services to respond to fluctuating workloads to support even higher scale.
EC2 vs Fargate – Fitting it all together
The image below provides a fantastic visual representation of how containers and tasks / clusters fit together using either EC2 or Fargate.
When using EC2, you specify the EC2 infrastructure that you’d like to use to launch your tasks. You can think of each Container Instance as a EC2 machine. EC2 machines have fixed resources in terms of cpu and memory depending on the type you provision.
Depending on the specs of your EC2 machine, you can run 1 or more ECS Tasks within it.
For example – if I had a EC2 machine with 2 vCPUs and 2048MB of memory, I can potentially run at most 2 tasks that required 1 vCPU and 1024MB each.
You may enjoy this article on AWS EC2 vs ECS vs Lambda – Whats the Difference?
You basically just slice your EC2 up into resource partitions. Using this approach, you can have many tasks running concurrently on the same EC2 machine / container.
Fargate on the othe rhand performs a lot differently. In Fargate, there is no notion of hardware – users just define the number of Tasks they would like to deploy based on a Task Definition. Behind the scenes, AWS maintains a set of machines capable of running your Tasks, and leverages them to do so.
In the Fargate model, you don’t need to care about where your Tasks run, you only need to care about how many and when you want them to run.
Clusters in this context are just pools of resources. Keep in mind that when you create a cluster, you must specify either EC2 or Fargate as your launch type – you cannot use both. You can also use the same cluster to host applications for multiple different services. Keep in mind in this case, you may run out of resources to run your Tasks if one service hogs all the capacity.
So far, we’ve learned a bit about ECS and the difference between running your Images on EC2 vs Fargate – but how do you choose one over the other? We address this in our next section.
EC2 on ECS vs Fargate – When to Choose What?
The image below summarizes the high level talking points for this section.
The EC2 option is great if you already have existing hardware that you’d like to leverage to run your containers. This is especially applicable for those of you that purchase reserved instances that have long term ownership commitments.
EC2 on ECS is also another great option for sustained or predictable workloads that have high utilization. This is true because the the primary cost component of ECS with EC2 is the EC2 infrastructure itself – there would be no additional charges for using ECS if you bring your own EC2 instances to the table.
EC2 is also great for those of you wanting a high level of control over your machines OS. This can be due to company policies or other stipulations.
The case for Fargate is around Flexibility. In the Fargate model, you dont need to care about the details of your infrastructure and all the setup details that are included in provisioning it. Instead, you can rely on AWS to automatically provision and launch the required hardware whenever the need arises.
Fargate is also great for those of you with variable workloads. Since you pay for the duration of your instances and the amount of resources you provision (note: actual usage does not matter, you are billed on the provisioned resources), they are a perfect fit for short lived tasks such as batch processing.
Fargate is also great in terms of flexibility. You have no long term commitment to the resources you are provisioning. Although you do pay a premium for ‘pay as you go’ availability offered through Fargate, its great from a flexibility perspective.
Summary
In this post we learned a bit about the details of ECS, as well as how running your Docker Images on EC2 + Fargate vs ECS compare.
All in all, I would recommend EC2 to those of you running services, or those of you that have hardware lying around that youd like to utilize as part of your ECS/Docker ecosystem.
For those of you running adhoc jobs and index on Flexibility, Fargate is the right choice.
Hope you enjoyed this article – let me know your thoughts down in the comments section below.