How to reduce your AWS cost — Part 3
This is part 3 of this article series. Links to the previous 2 articles are given above.
In this article, I am going to discuss some non-obvious cost-saving methods for RDS and lambda.
Saving your RDS cost
To me, RDS is the second most important service provided by AWS next to EC2. Using RDS itself will reduce some costs. There are many other optimizations discussed in AWS documentation and other places on the internet. In the below section, I am going to point out some of my own learnings which can further help to reduce your costs.
- Use burstable types whenever possible
Databases are resource-intensive applications. But that does not mean you have to use a beefed-up database server always. If you are running a small DB using a burstable instance type like t3 will save you a lot of costs. Also, you can use burstable types for your non-prod RDS instances unless you need a production-like environment. Something I usually do is using the burstable types in non-prod and change it to a production-like type when we are doing a performance test or something like that. After the test, we can scale down to the previous state.
2. Use Graviton based RDS instance types
In part 1 of this series, I explained about AWS graviton. Almost all the open-source RDS flavors such as Postgres support Graviton-backed instance types. These types are much cheaper compared to their non-graviton counterparties.
Further reading: https://aws.amazon.com/blogs/aws/new-amazon-rds-on-graviton2-processors/
The beauty of Graviton backed RDS instances is you do not need to do any application changes. You can specify a graviton-based instance type when you are launching the RDS server.
A running Graviton supported DB such as Postgres can be easily changed from non-Graviton based type to a graviton-based type with a few clicks from the console.
This is one of the easiest ways to significantly reduce your RDS budget if your DB flavor supports Graviton based instances (Any instance type which ends with ‘g’ e.g t4g is Graviton based) using those types should be a no-brainer. Oracle and MSSQL do not support Graviton based instances (not sure whether this will change in the future).
See a sample cost comparison in the following screenshots.
AWS claims that their Graviton based instances perform better than the regular ones. So that is another bonus with the cost savings.
3. Use multi-AZ only when it is really needs
Enabling multi-AZ roughly doubles the cost of a database server. So for non-prod workloads disabling it might be a good idea if you can afford a downtime or a data loss which happens very very rarely.
4. Do not over-provision the storage and use storage auto-scaling to reduce the risk of going out of space.
Some admins provide an unnecessary amount of space since they are afraid that space might run out due to some unexpected situation. That is something DBAs cannot afford for a production workload. But RDS supports storage auto-scaling. So you can provision the optional amount of space and configure storage auto-scaling to mitigate the above risk.
5. Use an open-source database type
Do not use licensed DBs like Oracle or MS SQL only if there is a proper reason. An example is an application built on top of Oracle Apex. Such an application will require an Oracle DB so there won’t be any other option. But if you have the freedom of choosing any database go for an open-source one like Postgres or MySQL. As an example, a microservice written in Java can use any DB as a backend.
Lambda
- Use your programming language wisely
Some of the programming languages require more computing resources than others. Java is famous for this. Lambda is billed for the execution time and the resources it is using.
So if you have a logic that can be written using both Java and Python I would use Python instead of Java since it is faster and less resource-intensive (there can be some exceptional scenarios that this is not true. But this is fairly accurate most of the time).
Sometimes developers use what they personally prefer once the freedom is given. But when using Lambda we should use the technology which would be most efficient and less resource-intensive. This should be especially evaluated if your lambda function is going to be executed in large volumes.
2. Spend time to make your logic efficient as much as possible
We give optimization problems in interviews and exams. But we do not pay much attention to these in the actual world. But writing a lambda function is a situation where we should spend time to optimize the program as much as possible due to the same reasons as the previous point.
3. Graviton again
Graviton was discussed in part 1 as well as in the RDS section of this article. To keep things simple, Labda also supports Graviton-based runtimes for your code. This is a way you can easily get more performance for a low price.
If your code is written in a cross-platform language like Java or Javascript you can change your runtimes to Graviton based ones without any code changes.
4. Is Lambda is the correct choice?
Lambda is not a silver bullet. Lambda suites well when your functions are executed in lower volumes without a predictable pattern. Also, it suits well for scheduled actions (crons) or handling events from another AWS service.
But if you have a workload that is executed in large volumes in a predictable manner, implementing a regular service using a platform like ECS, Elastic Beanstalk or even EC2 could be much more cost-effective. The same applies if your code is very resource-intensive.
Some architects try to use Lambda for everything. But you need to use it only when it is the best choice.