Right-sizing in the Cloud

I have recently been helping clients understand and control their cloud costs and finding some very easy ways to save 20 – 40% of their cloud costs with very little effort. I would really like to hear from others who are implementing applications in the cloud, whether they have observed these opportunities and what they have done to mine them for gold (literally!).

The most important point that most cloud users forget is that while most of the cloud resources are billed by usage, some, like compute instances, are charged based on provisioning. Once you have chosen a region, processor, size, and type, and instantiate it, you start paying for it. No matter what the utilization is, no matter that the application just uses it periodically. When I look at my clients’ cloud invoices, more than 50% of the bill is for compute instances, so this is a good place to look for waste.

There are several ways to save here:

-?????????Compare regions and processor / type to see if there is a price difference that you can exploit without performance hits to your application. Of course, the libraries and components you use need to be compatible with the processor type, but a bit of research and testing here can save a lot of money over time.

-?????????Choose the smallest instance that your application can run on, not the size that was used when it was on-prem. Make sure that auto-scaling is used in your architecture and scale out and back in as the load changes. Test this to ensure that it works. Check to see that utilization is always in the 60 – 70% range for the compute instances you use.

-?????????Talk to the product owner and the sales team to understand the business growth model, translate that into application load and then prepay for the base load expected. This can save you 50% or more, compared to the on-demand cost.?Revisit this on a quarterly basis to make sure that reality and prediction are aligned. This should also be done for the instances that are used and billed under database or middleware tools.

-?????????Every time an instance is created, make sure it is tagged with a unique identifier, the app name, environment (dev, test, prod, DR) and the owner. Other information like department, cost center etc. can be added as tags, or stored in a mapping table from the identifier. This avoids having to retag when re-orgs occur. The tags are essential when looking at costs and usage and ensuring that owners know what resources they have and what they cost.

-?????????For Dev and Test instances included a TTL in the automation used to create them, and at least hibernate them automatically at that time. Daily reports on cost should be emailed to the instance owners so they are aware.

The cloud invoice every month needs to be compared to the previous months, but that is usually at a high level, and to understand what drove an increase or decrease, the usage records need to be analyzed. Fortunately, the cloud providers provide native tools to start you on that journey, and there are third party tools that also help. These should be used to set up daily cost reports. Just like an event is raised when CPU is too high, or a disk too full, cost increases should be ticketed and investigated.

Usage and cost should be examined by the application architects to look for optimization opportunities, especially after each deployment. While cost increase due to increased traffic or sales is a good thing, it needs to be proportional to the increased revenue. If it isn’t, an urgent investigation is warranted before the costs accumulate into the monthly invoice.

There are many ways to keep cloud costs under control, and I have just outlined a few. I would really like to hear from others about successful cloud cost control techniques.

#finops #cloudcostmanagement #rightsizing #lean