Welcome to the second blog of our new series #TechTalks where we shine a light on the various ways your organization can optimize its AWS cost month on month. In the first introductory blog, we provided a brief background about Nium’s AWS cost-saving journey. We also provided a quick primer on the different cost-saving factors that we identified and leveraged. In case you missed it, here is our intro blog on How you can reduce your AWS bill by 40% or more
In this post, we will show you how to read and analyze the details of your AWS bill.
But that sounds ridiculously boring! Why do I even need to analyze the bill? I’m sure AWS doesn’t make mistakes!
Yes, we admit the bills generated by AWS can be a reasonably tedious task. It requires quite a bit of critical thinking to decipher one’s use and utility of services and come up with intelligent ways to optimize your current practices to yield better results. But nonetheless it is the starting point of any savings or optimization you hope to achieve for your company. Your simple AWS bill is also where a number of hidden cost-saving gems and levers reside. So if you can understand these levers and take full advantage of them to save your company some bucks, wouldn’t you want to know more about them?!
Here’s what your AWS bill probably looks like:
Image: Different line items of bill, categorizing biggest contributor towards your bill.
Now, how do you read it to identify the biggest cost-saving levers, and then work on them to reduce the size of your bill?
How to find cost-saving levers in your AWS Bill
The first thing you need to do is to find the biggest component of the bill. In other words, where are you spending the biggest bucks? For most organizations, the biggest expense would be their Elastic Compute Cloud (EC2) or RDS backend (depends on which backend your company is using).
- Elastic Compute Cloud (EC2)
Image: Highlighting overall cost incurred by EC2
Now that you know your EC2 cost, you can do a deep-dive into each layer to find if there are any cost-saving possibilities under it. We will be covering the details of each EC2 item in a different blog. But for now, you need to know the high level details only.
- OS and Region for your instances
So, if we continue with EC2 as our example, we first need to understand under which region our EC2 is residing. We also need to understand if we are running any EC2 in some other region by mistake and also, what kind of Operating System we are currently using to run it. In Nium’s case, once we started this analysis, we realized that we were using RHEL, and we didn’t even know it!
Image: This view explains the different regions where your EC2 is spread, OS they consume, and cost associated with them
While RHEL is quite a well known licensed operating system operated by Red hat that is known for stable, infrequent and security focused releases, our scenario and use case was quite different. In all honestly, our choice of RHEL was more of a reactive one without evaluating other obvious alternatives. So, this was as good a time for us to revaluate our choice and go for a more cost-optimal solution that can serve us equally well. We realized that Amazon Linux offers tight integration that provides a development team with up-to-date security releases and bleeding edge tools to maximize performance on EC2 – that too at a fraction of the cost that RHEL was making us incur. It also allowed our teams to use a linux server operating system that evolves with innovations, offers constant upgrades on functional and security related features and helps us keep pace with our scaling needs.
Instead of RHEL we used Amazon linux, which turned out to be a more cost effective alternative that yielded us about 60% lesser on spends.
- Discount for upfront commitment
Next, we need to look at whether the instance is using a reserved set of hours, or whether it is using a savings plan, or whether you have an on-demand instance. If you find that your instance is on-demand, then you have the perfect contender for cost reduction. We will be covering these strategies in more detail in coming blogs.
- Instance types
So now that we know that we have a few (or many) on-demand instances, and a few reserved saving plan-based instances – We need to now check what kind of instances contribute to the bulk of the total, and whether we are optimally utilizing those. Your bill will actually give you a high-level hint of how many of each type of instances your org is using.
Of course, you will need to ask yourself if all your servers need m4 instance, or t3 or t2 – and this can be a bit of a challenging endeavor. You also need to ask if you can operate with a lower category of server (yes, it’s entirely possible!). If your answer is Yes, then you need to park this issue for a separate deep-dive analysis to figure out which server or app is the best contender to be downgraded.
- Reserved instances
Here, a special mention must be made in case of reserved instances. Make sure that you focus on the amount of hours reserved versus the amount of hours consumed. If you find that your consumed hours are way lower than the amount of hours reserved, you are leaking money, and you now have a great opportunity to plug the leak. This analysis will also tell you that you have reserved much more capacity – unnecessary in this case – than the capacity you are consuming.
But keep in mind that optimizing under this section must not be viewed as a one-shot activity of equating reserved hours to consumed hours. In all probability, your company might have kept higher reserve hours for a few reasons that would need to be uncovered. For all practical purposes, you should start by taking a look at each line item and try optimizing or reducing excess reserved hours month by month rather than doing so at one point in time. This would allow you to monitor any impact that can arise due to such a reduction while aimining towards achieving a balanced ratio.
Image: First section shows how much hrs are reserved, and second section shows how much hrs consumed, difference is where we need to act upon.
Apart from EC2, RDS also allows you to creatively curtail your AWS bill in many ways. Keep reading to know more.
- RDS (Relational Database Service)
Now,let’s shift our direction to RDS, which can be another major contributor. Like EC2, in RDS also, our first focus should be on ensuring that we are consuming all the instances listed. Remember – there should not be any instances running due to an oversight, resulting in the instances not being used.
- Database and reserved hours
Next, just like EC2, we need to evaluate our database, specifically whether we are consuming all the reserved instance hours. Have we reserved more than what we consume? Or are we under-reserved, i.e. reserving less than what we consume. Fixing that should be the first item we need to take care of. Second, we need to see if we are using the right size db instance, like t2, m4, single or Multi AZ (availability zone).
Image: Different instance type of RDS used along with reservation details
- Use of AWS resources for Internal testing purposes We also got smart on using AWS for our internal test environment to bring about meaningful savings. More on this in our next blog post
It’s important to know what each AWS product does, and what its advantages and disadvantages are. Knowledge is power. Knowledge is also money! Paying attention to each of these items in your AWS bill will yield a lot of additional insights, as to whether you’re right sizing your resources, and optimizing your AWS budget. If you find that you’re falling behind in either aspect, it may indicate that your company might have front-loaded a lot of services, without giving much thought towards your actual scaling needs and the utilization of these services to achieve them. This results in wastage and a heftier AWS bill than you should have to pay. The good news is that just by tuning a few levers, every organization that uses AWS can start saving real money!
Build your career by transforming the payments landscape with Nium