When should I choose Fargate (over EC2) to host my containers?
AWS Fargate is a serverless container hosting service that customers can use to run their containers in ECS Tasks or EKS Pods, without worrying about manging the underlying infrastructure. But when should you use AWS Fargate over Amazon EC2 to host your containers?
AWS Fargate was announced and launched at re:Invent 2017 . Fargate is a container hosting service that allows you to run your containers ‘serverlessly’, and by doing so, focus your efforts on your containers and the applications running within them, rather than the underlying infrastructure supporting them. Initially, Fargate was only available to those using AWS’s own container orchestrator, Amazon ECS.
Amazon EKS on AWS Fargate was announced and launched at re:Invent 2019 , and rolled out to four new regions in April 2020, taking the total regions with EKS on Fargate to eight. You can now use Fargate to run your pods in EKS in Virginia, Ohio, Oregon, Dublin, Frankfurt, Singapore, Sydney, and Tokyo.
One of the questions I’m asked most often in my day job is: “When should I use Fargate instead of EC2 to host my containers?”. Or, put another way, “What workloads are best suited to run on Fargate?”
Most horizontally-scaled, stateless applications will work well on Fargate, so the best practice here is simply to try it out and see. On ECS, using Fargate is as simple as setting the Launch Type to Fargate (by changing
requiresCompatibilities in your Task Definition from
FARGATE). WIth EKS, you simply need to create a Fargate Profile on your EKS cluster, specify a namespace and optionally some labels, and launch your pods into the namespace you defined in the Fargate Profile.
Of course, there are some situations where Fargate won’t be a good match for your workloads, so it may make sense to not bother testing those. These include:
- If you run daemonsets for monitoring, logging, auditing, or other purposes, and these daemonsets cannot easily be reconfigured to run as sidecars, or would be too expensive to run this way
- If you run containers that require state to be written to a local file system or shared storage (although you can now launch Fargate Tasks using ECS and mount EFS filesystems into them)
- If you need access to the underlying host operating system (OS), for example to harden the OS
- If you need the storage attached to the underlying container hosts to be encrypted
- If you run COTS (Commercial Off-The-Shelf) software where you don’t have any ability to make changes to the underlying source code to suit the hosting environment
- If you run containers that require Privilege Mode
If your containerised applications currently meet one or more of these criteria, you should check out the AWS Containers Roadmap . Make sure you +1 any issues that are relevant to you, and subscribe to receive updates via email.
Many customers I speak to are concerned about the cost of Fargate compared to the cost of running their containers on EC2. In January 2019, AWS cut Fargate prices by up to 50% , making it much more cost effective. When I speak to customers, I typically find that those customers with a good idea of the TCO (Total Cost of Ownership) of running their EC2 instances see the financial benefit of Fargate more readily, as they have a loaded cost on top of the EC2 compute costs that they include in their comparison. For those customers who don’t know their TCO for EC2, they tend to just start comparing the raw compute costs, and in this situation Fargate can appear more expensive, although there’s still more to it than that.
When you are running a large number of containers, each of your container hosts will be running a large number of containers (single digit to many tens of containers). As your application scales up, you need to add more instances to your cluster, and each EC2 instance produces a scaling ‘step’, where you receive a fixed amount of additional resource for a fixed amount of money per period of time. But what if you’ve had to add another instance to your cluster just to run a single container? You may have an m5.xlarge instance running a container that needs 1 vCPU and 4GB of RAM, which isn’t very cost effective at all.
With Fargate, every time you launch a new container (as an ECS Task or an EKS Pod), you specify the amount of CPU and memory you need, and you pay for just that amount. So you no longer have to worry about the efficiency of your overall cluster; just about right-sizing your application containers.
I have found the following simple method to be very effective at comparing the costs of running your containers on EC2 and Fargate. Take the average level of utilization across your cluster instances, multiple that by the number of CPUs and GB of memory on one node, and you have your ‘average’ Fargate resource size. For example:
- A cluster running m5.xlarge instances (4 vCPUs and 16GB RAM) runs at 75% utilisation
- 75% of 4 vCPUs = 3 vCPUs
- 75% of 16GB RAM = 12GB RAM
- This converts to a Fargate resource of 3 vCPUs and 12GB RAM
If you’re running larger instance types, e.g. m5.12xlarge (48 vCPUs and 192GB RAM), you may need to sub-divide your average utilisation into multiple Fargate resources, e.g. 75% utilisation of m5.12xlarge translates to 36 vCPUs and 144GB RAM, which is bigger than the largest Fargate resource can be. But you can split this into 18 Fargate resources with 2 vCPUs and 8GB RAM each.
The pricing of Fargate vCPU and memory resources is linear (per vCPU or per GB per hour), so now we can do some simple maths to find the average utilisation point where Fargate becomes more cost effective than EC2:
In our example above for the Ireland region, an m5.xlarge on-demand instance costs $0.214/hr, and an equivalently sized Fargate resources costs (4 x $0.04048) + (16 x $0.004445) = $0.23304/hr. That gives an average utilisation of ~92%; so if you are running your cluster instances at anything less than 92% efficiency, Fargate should be more cost effective for your workload.
An m5.12xlarge instance costs $2.568/hr, and an equivalently sized Fargate resource costs 18 x ((2 x $0.04048) + (8 x $0.004445)) = $2.09736/hr. This gives an average utilisation of ~122% - which means Fargate will always be more cost effective for your workload, which of course we can see by the fact that the Fargate costs for 100% equivalent of an EC2 instance are lower than the cost of the EC2 instance itself.
Note: there’s a slight complication here: Fargate doesn’t offer a configuration with 3 vCPUs, so as soon as you go over 2 vCPUs you jump straight to 4 vCPUs, which changes the average utilisation a bit. On the m5.xlarge instances, this means the average utilisation of clusters instances can reduce to ~76% before Fargate becomes more cost effective.
We can now easily summarise a comparison of the hourly costs between different average utilisation levels of the m5.xlarge EC2 cluster instances and equivalent amounts of resource on Fargate:
|Compute Type||EC2 On Demand||Fargate|
|Low Utilisation (25%)||$1.28||$0.35|
|Medium Utilisation (50%)||$1.28||$0.35|
|High Utilisation (75%)||$1.28||$1.29|
|Perfect Utilisation (100%)||$1.28||$1.40|
|EC2 Utilisation Target||n/a||92%|
Comparison of costs of using m5.xlarge EC2 instance and Fargate to host containers.
The example above assumes all your containers are homogeneous (i.e. use the same amount of CPU and memory) and can be placed anywhere in the cluster. Heterogeneous containers or placement rules that limit where containers can be placed will increase the complexity of your price comparison, and will most likely increase the overall utilisation level you need to run your EC2 instances at (making Fargate a more favourable candidate in most situations, all other things remaining equal). It also assumes a TCO of $0 for managing your EC2 instances, which is almost never true. This will only increase the effective cost of the EC2 instances, and increase the average utilisation your cluster instances must reach before Fargate becomes more cost effective.
There are lots of other levers you can pull to change the cost of your compute resources of course. Reserved Instances, Savings Plans and Spot Instances can all reduce the cost of EC2 instances. Fargate Savings Plans and Fargate Spot can also drive down the cost of Fargate (not currently available on Amazon EKS). But that further increases the complexity of the comparison, so that’s a post for another day!