How we saved 90% of costs by moving from AWS Lambda to AWS Fargate
Although replacing API Gateway with Application Load Balancer as a Lambda Trigger seems to be a quick solution, it does not solve our throttling problem. That’s why we’ve started to looking another solution in terms of cost, performance, limitations, and scalability.
There are lots of solutions for implementation to cover all the things I mentioned earlier, but since this is not a comparison post about solutions, I will skip that part.
After lots of research and long discussions, we’ve decided to move on with AWS Fargate. The key criteria of this decision were;
- being able to make this transition as quickly as possible 🚀
- not taking responsibility for maintenance, it should be a managed service ⚒️
- cost 💸
AWS Fargate is a technology that you can use with Amazon ECS to run containers without managing servers or clusters of Amazon EC2 instances as a must. With Fargate, you no longer have to provision, configure, or scale clusters of virtual machines to run containers. This removes the need to choose server types, decide when to scale your clusters, or optimize cluster packing.
Furthermore, the Lambda function was not a resource monster. We could run tasks with minimum resources (1 vCPU and 2 GB memory).
Also, AWS Fargate comes with plenty of features:
- The provisioning time of the task is under 10 seconds. It enables us to scale up/down your services quickly — It may change based on the image, but since we have a lightweight image it does not take that much time.
- Enhanced monitoring.
- Autoscaling policies based on various metrics — Even though we were having and will have spikes during peak seasons, it is not a problem anymore. AWS support center has a good article about auto-scaling — Configure Amazon ECS Service Auto Scaling on Fargate
Here is the current architecture after the transition: