Since we originally published this popular article in 2018, we have tried to keep it updated as announcements have changed the landscape and conclusions of ECS vs. EC2 a bit. Below you can see the update we made a year ago, in January 2019. More recently, in November & December 2019, there are have been another series of announcements that affect this analysis:
Of course, there are even more factors… Fargate Spot, EKS Cluster Autoscaler, ECS Spot Auto-draining, new instance types… but we’ll save those for another day!
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 the new fargate pricing vs EC2. 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 costs vs EC2 costs 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.
Using us-east-1 pricing and ignoring ELBs & storage, this chart shows the percent cost of Fargate below or 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 cluster reservation rate above 70-80%, and if you ECS cluster is perfectly packed (100% CPU & RAM utilization), Fargate will cost you 35% more.
For the c5 instance family, the trends are very similar but the break-even points actually even higher. This chart shows a cluster of c5.2xlarge instances compared to Fargate. About 85% reservation rate gives you break even, and for a 100% packed cluster (which is more or less unachievable in a dynamic environment) Fargate will only cost about 16% more.
In the past, we included EC2 Reserved Instances in this analysis, because they applied to EC2 but not Fargate, it gave EC2 a leg up in this comparison. But with the November 2019 introduction of Compute Savings Plans, this advantage goes away... savings plans apply equally to EC2 and Fargate. So by all means, go crazy with Savings Plans... but no need to consider them here.
Perhaps most important are the upper and lower bounds. On the lower end, if you can't keep your ECS cluster reserved at a rate of 80%, you will almost certainly save money moving to Fargate. On the upper end, if you cluster is nearly 100% utilized, Fargate will cost between about 15% and 35% more.
So take those bounds and stop for a minute to consider TCO: How does your EC2 compute cost compare to the time and effort spent on cluster management? Even if you could achieve 100% utilization, is a 15-35% increase is compute cost paid for decreased management overhead?
We can tell you from experience that you should not underestimate cluster management effort. In addition to configuring, securing, and patching the host VMs, you have to deal with scaling at two levels: Container auto-scaling and cluster auto-scaling. Container scaling has been an AWS feature for a few years now, and ECS Cluster Autoscaling was recently introduced to handle the scaling of host instances. But you have to still wrap your head around and configure these services, then monitor and tune them.
Avoiding this additional complexity is one of the most compelling aspects of Fargate. Hopefully with this pricing analysis in hand, you can now weigh those intangible and personnel costs against the hard infrastructure cost and make the decision for your environment.
Is on-demand pricing really ‘serverless’ pricing?
