Hi everybody. At previous 2 parts (part 1, part 2), we spoke about Fargte Spot, Saving Plans and CPU architectures. At that lecture we will make a summary of cost’s optimization strategies and discuss when AWS Fargate is a good choice and when it is not. Here is summary table of cost ratios for different configuration scenarios we have past:
The summary from that table is the next – if we want to be cost effective, the fluctuation of traffic should be enough to compensate the current ratio. What I mean here – better to view all with concrete example.
Let’s assume that you have some EC2 cluster that consists of 3 t3a.micro servers, which also use some docker orchestration tool, e.g docker swarm.
Such architecture allows us to stay HA and process existing overloading. Let’s assume that we migrated our app to Fargate. If fluctuation in traffic is present and average number of containers within 24 hours would be 1.5, e.g we have 1 container rather often at low traffic, and only sometimes 3 at high peaks, and sometimes 2 containers – then we are at home.
If we divide 3 EC2 instances at 1.5 fargate containers - our ration will be 2. In case we are using spot option - it will completely cover EC2 cost. Generally speaking I would say that even arm option would be acceptable . Yes - it is a little bit more expensive than to be staying at EC2, but remember that operational cost for EC2 support also exist - somebody need to perform security updates of all used packages at server, in case Fargate - AWS makes that job. If we also need to scale EC2 from time to time - it is even more strong argument to stay at Fargate with accepting some little extra pay.
There is one more essential thing I would like you to pay attention to. Combinations matrix:
Strive to lower capacities at your low overloading. Let me explain in details what I mean. Below you can see at slide – at red, the areas with low overloading are present:
let’s assume that at current areas it is enough to have one container and your application needs 0,7 CPU – you need to strive to go down to the 0.5 configuration. Why?
Firstly, during low traffic times, you would be using resources more effectively. Secondly, the combination unit you choose will become your base building block. It is easy to add more blocks in Fargate; it doesn’t matter if Fargate brings 3 or 5 containers during peak times. If there is a possibility to use base building blocks with lower resource parameters, use it. This approach may lead to significant cost reduction. In such cases, it is worth making every effort to optimize the application itself. Believe me, in most cases, there is almost always room for such optimization.
So, here is some final list of recommendations for Fargate usage:
- choose applications, where fluctuation of traffic/loading will compensate Fargate extra cost in comparison to EC2. In case deviation in traffic/loading is ~2 – then you have a good candidate for Fargate migration. The higher loading deviation – the better for the app to be moved at Fargate;
- use spot and arm 64 architecture to optimize Fargate cost;
- autoscale wisely, test different options, e.g. maybe step autoscaling would be better in your exact case as it can allow to scale down and up faster.
So, when AWS Fargate is a bad choice:
- app is cpu heavy but has small memory requirements
- app loading is almost stable within a whole day and most days in a year
- app has no stable and predictable autoscaling metric within a stable amount of load. In that case AWS would not be able to correctly scale your task count to adjust the autoscling metrics in the right direction.
That’s all, thank you for your attention. If you want to know more about AWS Fargate autoscaling, then welcome to my Udemy Course: AWS Fargate DevOps: Autoscaling with Terraform at practice. Here you can find coupon with discount, which I am updating regularly in the middle of every month.
