Achieving 40% reduction in AWS costs

Epsilon Delta has been working on optimizing the cost of the cloud based architecture since some time. This brief write-up talks about how we went about achieving 40% reduction in our Amazon Web Services (AWS) bills in a period of 3 months.

Holistic cost analysis

As a cost-conscious bootstrapped startup, we always look for our daily and monthly cost of cloud architecture running on Amazon Web Services cloud (AWS). Our primary architecture is always based on open source technologies and only a handful AWS specific technologies were used. Thus, primarily we are being billed for virtual machines, load balancers, CloudFront CDN, disk storage, snapshots and the bandwidth. We have been doing the standard necessary cost optimizations based on instances type reduction, auto scaling, auto shutdown machines, just sufficient disk sizes, surrendering unused disks and machines etc and have managed to keep our AWS cost at a reasonable level. However with the exchange rate slide, we needed to do something extra to improve the fixed cost.

1.????Moving from Amazon MQ back to own RabbitMQ.

Amazon MQ is a fantastic technology. It is a fully managed message broker based on ActiveMQ and RabbitMQ. It supports single instance or clustered instances for better availability. Ours was the single instance of RabbitMQ running on mq.m5.large instance having the most basic configuration. While it provided great support for configuration and available MQ APIs, the cost for this configuration was quite high compared to our total billing.

In order to save cost, we decided to move from Amazon MQ and have our own RabbitMQ. We moved to m6a based large instance and deployed our own RabbitMQ on a standalone machine virtual machine. By doing so, we are now getting billed only for the m6a.large instance and the attached smaller disk. With reserved instance pricing, we have saved significant amount on the final pricing. We had to work extra to have similar API features available by using CloudWatch based monitoring and using CloudWatch APIs.

2.????Savings bundles with CloudFront

With more and more traffic getting on boarded on Gemini, the cost of our CDN was increasing many fold. While there are always options available to move to different cheaper CDNs, but the risk of moving and getting locked to a new CDN is much higher.

Fortunately, AWS launched CloudFront savings bundle in February 2021, where one can save up to 30% cost on CloudFront by wisely selecting your minimum commitment for 1 year and then getting 30% additional quota on CloudFront. AWS has also provided a feature which recommends the savings bundle which you can self-subscribe. This resulted in up to 30% savings in our CloudFront billing.

3.????Moving to AMD based architecture.

Traditionally we have been using mostly T2 based architecture and occasionally using T3 burstable instances. It was our mistake that we did not refer to the usually published AWS technology news where launch of new instances families was published regularly. However, with the need to save costs, we started looking at different families. We came across Graviton based and AMD based architecture. While Graviton is completely different architecture, the AMD based is X86 architecture. So, migration from Intel based X86 to AMD based X86 is straight forward as compared to Graviton. While Graviton is much efficient, but the migration would require some efforts. Moving to AMD resulted into about 50% savings as compared to T2 families. While we still have some earlier T2 based reserved instances to be active. But once they expire, we will see the full benefit of this migration.

Cost of on demand t2.medium (Intel architecture) ?= USD 0.0496 per hour

Cost of on demand t3a.medium (AMD architecture) = USD 0.0246 per hour

Cost of on demand t4g.medium (Graviton architecture) = USD 0.0224 per hour

4.????Bandwidth Savings.

With increase in the architecture, we were now facing increase in the total bandwidth cost. Because of the high availability concept, we had used deployment across various availability zones in the same data center. E.g. We were deployed in 1a, 1b and 1c availability zones of Mumbai data center of AWS.

We recently figured out that AWS also charges bandwidth between inter availability zones. Again, it was our mistake to not know the cost implication here. That bandwidth was costing us significant amount of USD.

We moved our servers to only one availability zones and thus saved significant costs on the inter availability zones transfer bandwidth.

Conclusion

Together with all these changes, we are now saving close to 40% of our billing in USD. Our learning from the experience is that, keep looking for the new launches happening on AWS. If you miss one, you miss the chance to save the cost. Our second learning is, unless absolutely required, we prefer using the open-sourced self-managed technologies as compared to AWS proprietary technologies, as it helps to save the cost as of now.

If you are interested to know more details about our exercise, please contact us. We will be happy to help.