Cost savings is a pretty important part of working with AWS. Knowing your business plan helps you plan in advance and take advantage of the reserved instances plan from AWS. In a previous post, we discussed the power of reserved instances for compute services, and this case is no different. We will see an example of how a commitment can help to reduce your database expenses.

Although this is not the only way to reduce database costs, it is a quick and effective way to achieve it. In a few steps, you will be able to set it up, and it will be running the next day. To reserve your instances, go to RDS > Reserved Instances > Purchase Reserved DB Instance. This is an example of how the reserved instances look after purchase:

At some point in 2023, we were discussing costs and pagespeed. I quickly pointed out that the slow performance and spike in bandwidth costs were caused by the usage of .gif images. At first, the team was reluctant, but a few days later, I came up with a report provided by the Amazon S3 service, where you can save an access log of the hosted files and later process it using Amazon Athena.

The best way to save money on AWS is by committing to use compute services for a period of 1 to 3 years. There are several options, such as upfront, no upfront, or even partial upfront. Depending on the option selected, you might get from 25% to 55% discount on compute costs.

In this link, you can find a cool wizard to calculate your savings: AWS compute savings

The other day I got a request from our team leader to check why our AWS expenses had shot up unexpectedly the last month. After a few minutes revising the previous months’ billing, I figured out that AWS started collecting taxes, CloudWatch had been increasing as we were implementing a better logging system for our apps, and also AWS started charging us $0.005 per IP address hourly starting in February 2024.

One day, pretty early in the morning, I got a message with a screenshot from the CTO saying:

Any thoughts on how we keep these cleaned up?

A few months earlier, we were discussing the need to deploy feature branch environments as a solution to avoid our delivery process getting stuck, as we were deploying more than the QA team could handle. We created a feature branch deployment pipeline, and it was working great, as every important feature was tested in isolation from the QA environment (no merges until approved by QA). Essentially, we stopped having complaints about our queue to production getting stuck due to defective code or incomplete acceptance criteria.