How we saved 90% of costs by moving from AWS Lambda to AWS Fargate

Before starting this interesting story, let’s take a quick look at what we had before and what it cost.

The system’s first architecture

We have a system that makes calculations based on certain actions to understand and interpret user behaviors. To make this happen, we need to send user actions through our Web SDK.

The first part of the system is called the “web server”. It consists of two components with Amazon API Gateway as the entry point for the actions.

Amazon API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. APIs act as the “front door” for applications to access data, business logic, or functionality from your backend services.

Then the first Lambda was to put actions into the stream.

AWS Lambda is a serverless, event-driven compute service that lets you run code for virtually any type of application or backend service without provisioning or managing servers. You can trigger Lambda from over 200 AWS services and software-as-a-service (SaaS) applications and only pay for what you use.

After carrying actions to the stream, the second part of the system is on the game. It retrieves actions from the stream in order to make calculations and write them down in DynamoDB.

The Problem

The greatest common factor was the cost. Even though the second part of the system had a predictable usage and cost, we were not able to have the same control on the “web server”.

In addition to this, usage has increased over the quarters and we saw spikes during peak seasons.

Since the rest of this story is about the “web server”, let’s take a look at how it performs:

• The Web SDK sends over 4K requests per minute to the API Gateway.
• The client makes a pre-flight request to the server in order to complete the CORS procedure(you can find more detail here).
• The average duration of the Lambda was 100 ms.
• In the end, RPM was ~8K. The cost of API Gateway REST API + Lambda integration was ~1200 USD.

You can find more details on Amazon API Gateway pricing and AWS Lambda pricing. Also, you can see estimated costs on the AWS Pricing Calculator.

Even though the cost was the first problem, we had another problem with Lambda and API Gateway account limitations.

During peak seasons, we’ve started to see throttled invocations on the Lambda dashboard which blocks other Lambda functions. We were able to increase this quota via AWS support but it is not a permanent solution. You can find more details about Lambda quotas here.

If you have multiple APIs that are running on a shared account, the same problem can happen with API Gateway as well. One of the APIs can block others due to incorrect integration or a spike. You can find more details about API Gateway quotas here.

The Solution

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.

Since our Lambda does not have that much business logic, we were able to dockerize it easily. We prefer Express as a web framework and PM2 as a process manager to keep the server alive.

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:

The final architecture of the system

The Result

It is time to compare costs between the old and new “web server” for the last 4 months.

Cost Comparison

The result is incredible! ✨

Even though our computing cost doubled, we saved 90% with this transition! 🏦

The Conclusion

API Gateway REST API + Lambda integration is being promoted as a charming and quick solution to deploy applications. It is a fact, nobody can deny it.

Nevertheless, you should be aware of the costs and limitations as well. It would not create a noticeable cost in the beginning, but, you should always keep an eye on it if you don’t want to have a surprisingly large bill.

If you are about to make a decision about your career, please take a look at How I become a Software Engineer in my late 20s while working a full-time job post by Samat Tolkunbekov, Software Engineer at Insider.

Also, don’t forget to follow Insider Engineering Blog to see more articles ✍️

You can reach me on LinkedIn 📥