Fargate Pricing in Context
Updated for the Jan 2019 Fargate price reduction
On Jan 7, 2019 AWS released a major price reduction for Fargate, reducing prices 35-50%. This is great news for a service that had relatively high costs as one of its only downsides. If you have a legacy app for which it isn’t feasible to rearchitect into serverless, there are very few good excuses to not moving it to Fargate.
So of course, we’ve updated the below analysis to reflect these new prices (as well as recent changes to EC2 instance types and pricing, to keep a fair fight). Here was our conclusion with the old pricing:
Perhaps most important are the upper and lower bounds. On the lower end, it is unlikely that you will find material savings on infrastructure cost alone when switching to Fargate: break-even does not happen until under 30-50% reservation rate in most cases.
On the upper end, if you cluster is fully utilized, Fargate will at least double your current compute costs, perhaps triple them if you have a very high container reservation rate and reserve all of your EC2 instances.
The story is dramatically improved with these new price reductions… price savings with Fargate are now a very realistic possibility! Break-even between Fargate & EC2 now happens in the 60-80% reservation rate, so if your cluster is only 50% utilized you might see a 10-20% cost reduction with Fargate! At the high end Fargate will increase your costs by 50-100% for a very tightly packed cluster with heavy EC2 Reserved Instances. The case for Fargate is much harder to ignore now: Having a reservation rate above 60-80% is challenging in an environment with dynamic load, and even if you can accomplish it, does the management overhead warrant it?
In a recent post I discussed how AWS’s newer container management service Fargate, while a compelling alternative to container cluster management, doesn’t deliver on most of the benefits that are the hallmark of “Serverless”.
That said, as much as we are serverless cheerleaders at Trek10 we recognize that all workloads can’t immediately move to this paradigm. Check out one of our recent Think FaaS podcasts where we dive deeper into some of these cases.
If you are in this situation and looking at containers, you may be weighing the options of Fargate vs other container management options on AWS like ECS, EKS, or a DIY cluster. Of course, Fargate isn’t for everyone: You may have very specific requirements that force you to host-level customization. Or maybe you are at a scale where compute costs dwarf the TCO of cluster management. But for the vast majority of companies the lower management overhead of Fargate can be compelling; however it needs to be carefully weighed against the added cost of Fargate in relation to EC2.
In this post we’ll try to provide some context to that pricing comparison. In other words, what will Fargate cost you, and will that (likely extra) cost be worth doing away with cluster management?
Fargate costs more per GB of RAM and vCPU, however costs are directly metered off of provisioned container RAM & CPU (each variable is metered independently) and you are never paying for unused cluster capacity. Therefore the key variable in comparing Fargate pricing to EC2 is cluster reservation rate.
Each time a container is deployed on the cluster, the cluster manager is reserving the specified RAM & CPU for that container. Reservation rate is the sum of the reserved RAM or CPU of deployed containers divided by total available in the cluster.
If you have 24 vCPUs in your cluster and Docker containers have 16 of those reserved, your CPU reservation rate is 67%. (Soft limits for RAM make this analysis more complicated so we will ignore that for now, feel free to try to factor it in if your analysis doesn’t show a clear winner.)
Like we did in our popular Lambda pricing post, we’ll try to put this pricing comparison in the context of some real-world scenarios. Consider an ECS cluster of 10 m5a.xlarge instances, which gives you 40 total vCPU and 160 GB of RAM. If you have placed 30 containers on your cluster, each with 1 vCPU and 4 GB of RAM, your CPU and RAM reservation rates are both 75%. In the case of Fargate, your cost is calculated from those 30 vCPU and 120 GB of RAM of deployed containers. If you place 5 more containers, in Fargate your cost will go up by 1/6th, while in that EC2 cluster your costs stay flat and your reservation rate goes to 87.5%.
Remember that we’re talking about average reservation rate: the dynamic nature of reservation rate matters. This line of thought harkens back to the classic analysis of EC2 autoscaling vs on-premise. Because cluster auto-scaling can never perfectly match container auto-scaling, you will be always paying for some extra EC2 as you try to keep your cluster near but just above your provisioned container capacity. This pushes down average reservation rate further in highly dynamic environments.
Using us-east-1 pricing and ignoring ELBs & storage, this chart shows the percent cost of Fargate below or (usually) above the cost of the EC2 cluster for the m5a.xlarge scenario described above, given various CPU & RAM reservation rates along the X & Y axes.
As you can see, around the 70-80% reservation rate, Fargate costs are about even to EC2. At the high end of 90-100% reservation, Fargate will start to cost about 35% more.
This point is worth re-emphasizing: In the above comparison, it will cost more running on EC2 unless you can keep your reservation rate above 70-80%, and if you ECS cluster is perfectly packed, Fargate will cost you 35% more.
How do EC2 reserved instances change this? Here is how it looks if 100% of instances are reserved: