EC2 or AWS Fargate?

There are two main compute options for running containers with Amazon Elastic Container Service:

• EC2 (Deploy and manage your own cluster of self managed virtual machine instances that can each run one or more containers)
• AWS Fargate (Run containers directly, without any virtual machines to think about)

Both are completely valid techniques for operating your containers in a scalable and reliable fashion. Which one you pick depends on which factors you want to optimize for.

Pricing

When you use EC2 instances as capacity, it means your bill is based on the cost of the underlying EC2 instances. It is your responsibility to make sure that you pick the right size of EC2 instance and the right number of EC2 instances, to ensure that the containers you are running are are densely packed onto EC2 instances. If you don’t efficiently use your EC2 instances you will be wasting money.

With the AWS Fargate launch type billing is based on how many CPU cores, and gigabytes of memory your application task reserves, per second. You can size a Fargate task all the way down to one quarter of a CPU and only 512 megabytes of memory, to minimize how much it costs.

When comparing AWS Fargate tasks and EC2 instances side by side it will appear that AWS Fargate is slightly more expensive per hour for the same amount of compute. However, its important to realize that this assumes perfect density of containers on hosts, as well as perfect utilization. In many real world scenarios you can typically acheive better utilization and better overall cost with small AWS Fargate tasks that are sized to your application’s true needs, compared to launching large EC2 instances that end up partially utilized.

Performance

Because there are many EC2 instance types you can choose a specific EC2 instance that is perfect for your application, depending on what your application needs the most of: CPU, memory, networking, etc. There are a lot of choices of EC2 instances, from burstable instances all the way to high power bare metal instances.

AWS Fargate has fewer choices. You can choose the CPU size and memory size that your container will get, but you can not choose processor or hardware generation, or any other details.

On the one hand this means that AWS Fargate automatically manages upgrades to newer hardware transparently behind the scenes. You can continue running your workloads, and they will get better and faster over time automatically. However this also means that you can’t be guaranteed to run on the latest hardware as soon as it launches. In many cases you can launch a more powerful EC2 instance at a cheaper price/performance ratio as soon as it becomes available after the re:Invent announcement, compared to AWS Fargate hardware, which is not always on the latest generation right away.

If your workload is especially performance sensitive this may be a factor in your choice.

Administrative Overhead

Have you ever used SSH to login to an EC2 instance and seen messages like this?

1
2
3

Uptime: 343 days
57 package(s) needed for security, out of 98 available
Run "sudo yum update" to apply all updates.

Keeping infrastructure updated is a constant overhead effort. You need to make sure your servers are patched, secure, and updated to the latest version of Docker and the ECS agent, plus underlying operating system updates.

If you don’t want to deal with any of this, then AWS Fargate can be a great choice. For example when the Spectre / Meltdown vulnerability was announced customers that were running on EC2 had to make sure they patched and upgraded, while customers running AWS Fargate were protected automatically behind the scenes by AWS engineers who patched the underlying infrastructure.

When using AWS Fargate you just get an automated email message like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

A software update has been deployed to Fargate which
includes CVE patches or other critical patches. No action
is required on your part. All new tasks launched automatically
use the latest software version. For existing tasks, your
tasks need to be restarted in order for these updates to apply.
Your tasks running as part of the following ECS Services will
be automatically updated beginning June 19, 2023 00:00:00 UTC.
After June 19, 2023 00:00:00 UTC, the ECS scheduler will
gradually replace these tasks, respecting the deployment settings
for your service.

This allows you to just focus on building your application. You still need to update the version of any software that you are distributing inside of your container image. However you no longer need to worry about the infrastructure that runs your containers.

Demand Variability

If your workload is small with the occasional burst, such as a website that has traffic during the day but low traffic at night, then AWS Fargate is a fantastic choice. You can scale down to one tiny container at night, costing very little, but still scale up during the day, while only paying for the CPU cores, and gigabytes of memory that your task requires.

For a small, ephemeral test environment AWS Fargate is a perfect fit. It’s generally wasteful to run a tiny test environment on an EC2 instance because the EC2 instance is too powerful, and you will have a hard time getting a good percentage of utilization.

Last but not least if your workload consists of periodic tasks, such as a cron job that runs once an hour, or occasional jobs that come from a queue then AWS Fargate is a perfect fit. Instead of paying for an EC2 instance, and having to start and stop it between uses you can just ask AWS Fargate to run your container when you need to, and stop paying when your container stops.

Where EC2 instances are best

If your workload has a consistent demand for many thousands of CPU cores and terabytes of RAM, and you want to optimize for price you should consider running a cluster of EC2 instances. You will be responsible for maintaining this cluster and optimizing it, but you will be able to run a larger cluster, that can handle more requests per second, at a cheaper overall cost.

Keep in mind that the balance point is different for every organization. In many cases the savings from running directly on EC2 instances are not worth the increased cost of ownership, but if you are in a situation where you need thousands of vCPU cores worth of total capacity you can start to benefit from looking at options for lowering your cost per core, as the potential savings will start to become significant at that point.

Deploy a web container on EC2 Capacity

Where AWS Fargate is best

If you are working in a startup that has not yet acheived product market fit then the most important thing for engineers to be working on is new features, and iterating on new features. Spending significant effort on infrastructure is wasteful and can reduce your chance of finding that crucial product market fit. In this situation AWS Fargate is better than using EC2 capacity.

Additionally, even if you have acheived product market fit, if the most expensive part of the infrastructure is still the paychecks for your engineers, then AWS Fargate is also a good choice, as it reduces the burden on your engineers, allowing them to focus on other high value things which grow the business.

Deploy a web container on AWS Fargate