How cloud cost optimisation saves money and increases efficiency

Cost-saving on the cloud
A quick Google search will reveal a number of resources stating the ‘top ten ways to cost save on the cloud’. What’s missing here is how we actually do this; what tools are available; how we approach the problem; what effort is involved; what the risks are and, of course, the return on investment (ROI).

We’re going to look at this from a retrospective angle, i.e. considering a company that already hosts in the cloud. In this fictional example, AWS costs have been steadily growing and they are now becoming a concern. We’ll look at medium to large system, made up of standard ec2 deployments of a three-tiered application (webserver, app server, db)…

Our fictional company
Aaron Credit History is a b2b business, offering credit history to businesses doing background checks. They deliver APIs, back-office solutions to customers and administration systems for their employees.

Reserved instances
We have a number of options to make savings from procuring reserved instances. With AWS, it depends on how much you want to pay upfront and how long you’re willing to sign a contract for (the more you pay upfront and the longer you are willing to sign a contract for, the more savings you’ll make).

There is a number of factors you should take into consideration when choosing your reserved instance agreement…
If Aaron Credit History was to decide to convert all the largest instances (t3.xlarge) to one-year reserved instances, their monthly savings would be approximately US$14,788.47 – so annually, that would be $177,462.64. But they have a one-off fee of $97,200.00, so the savings are actually $80,262.64 or $6,888.55 per month. Aaron Credit History was spending $922,311.36, so this equates to a saving of 8.70%.

This seems like a very quick win, but it raises a few questions: Are any of these workloads planned for decommission? Are these workloads correctly sized? Has a PO been raised for $97,200.00? It looks like a straightforward change but there are some implications that need to be looked at, prior to implementation.

 

The biggest cost
RDS, at $24,993.00 per month or 299,916.00 annually, is 33% of TCO. At present, they are utilising db.r4.xlarge, which could be correct but is questionable, based on the set-up and the volumes of I/O (you can capture these metrics from cloud watch and make sure the trend is not going upward).

In this example, we modify all instances – but this is not advisable. It’s better to start small, with a single workload, and measure the impact as well as understand what service disruption is caused by the downsizing. Based on our analysis, Aaron Credit History believe that the right size for their workloads is db.r4.large. By making this change, we see a significant cost reduction, from $24,993.00 per month, to $12549.00 per month. This alters annual spend from $922311.36 to $762,530.40, which represents a 17.5% reduction in TCO.

Aaron Credit History TCO – rightsized DBs
It’s important to understand that rightsizing is not a one-off exercise. Systems evolve and so does usage, so continually measuring and ensuring rightsizing throughout the life of your systems is an exercise in good cloud hygiene and could keep costs from spiralling out of control. For AWS, you can look at the AWS Compute Optimizer to help measure usage and continually find underused workloads.

When a resource is less than 40% of utilisation, it doesn’t have peaks that exceed 70% utilisation, and there is no upward trend in utilisation, so I would downsize as soon as possible. Let’s say it’s at 50% utilisation but has an upward curve, so two weeks ago it was at 45% and the week before it was 40%: This could mean the application could eventually become over-utilised, based on the upward trend. So, you should be thinking about how this resource will scale. It’s also useful to look at peaks and troughs to see whether minimal utilisation is very low, as this could be an opportunity to utilise elasticity to meet demand and scale down to avoid long periods of under-utilisation.

Let’s look at an option where IT can make all the necessary changes and the finance department can simply see a drop in monthly spend…

Rather than utilise reserved instances with an upfront cost, let’s look at three options:

• Rightsizing
• Elasticity
• No upfront reserved

Here is the TCO calculator where we’ve applied the RDS rightsizing but where we’re using on-demand EC2 with a monthly spend of $63,544.20:

• 100 x t3.xlarge instances, where the set-up is two instances per service with 1 ALB or 50 services.
• The same goes for the 100 m4.large instances, so 50 services (2 x m4.large instances) and 50 ALBs.

So, let’s say our analysis found that 25 services, or 25% of our services, were under-utilised, 20 m4.medium instances and 30 t3.xlarge, and let’s say the options are to move m4.large to t3.medium and t3.xlarge to t3.large. Let’s use t3.xlarge and m4.medium no upfront cost one-year reserved instances. The monthly spend is now $54,046.20 (without these changes, it was $63,538.95, which is a reduction in monthly spend of $9,492.75). The annual spend would be $648,554.40, down from $762,652.80, which is an annual saving of $114,098.40 – or a 15% reduction in TCO.

Saving costs through elasticity
Elasticity is another means of saving costs. Instead of two t2.xlarge instances, we could have three t2.large instances, where two are active and the other is only introduced when there is a spike in traffic…

Let’s say we found that 10 services, which utilise t2.xlarge greatly in peak times and underutilise in times of low traffic: In terms of moving t2.xlarge instances to two x t2.large instances, but when utilisation exceeds 70%, we spin-up a third instance, which roughly accounts for six hours of the day: the monthly spend would then be $54,046.20, compared to $52,373.61, a saving of $1,672.59 per month, or an annual saving of $20,071.08 – or a 3% reduction in TCO. When you factor in all changes, this represents an approximate 31.9% reduction in TCO, from an annual spend of $922,331.20 to 628,483.32, with annual savings of $293,847.88.

As you’ll note, it’s important to understand your utilisation as well as how it’s evolving: not all right-sizing exercises will result in a cost savings. When utilisation is trending upwards, this will cause an increase in spend as your services grow in demand and hopefully in revenue too.

ARM chipsets for EC2 and RDS
New instance types have been introduced with AWS Graviton2, which uses ARM-based microprocessors. The savings can be as high as 30% but it all depends on the instance types you’re using (if they’re small, there’s unlikely to be an equivalent graviton instance type). The other issue is if you change any of your ec2 instances, you’ll need to update the OS and the configuration and ensure the applications on this instance support ARM-based chipsets. There’s an easy win (RDS) you can upgrade without having to make any configuration changes.

Converting all Aaron Credit History RDS instances from db.r4.large to its equivalent gravitron2 db.r6g.large, sees a reduction in monthly RDS spend from of $12,549.00 to $11,231.50 – giving monthly savings of $1,317.50 or 2.5% of TCO. The overall spend now is $628,483.32, from $922,331.36, which is a 32% reduction in TCO (see calculator for TCO details).

Conclusion

So, in conclusion, what’s the best way to reduce costs on the cloud, whilst guarding against risk? In short, companies should set up a rightsizing strategy – something that can be checked monthly to ensure that resources are not potentially under or over-utilised. TCO can be reduced also through reserved instances and elasticity. It’s important to understand utilisation as well as evolution. Look at how resources will scale and keep an eye on potential peaks and troughs.

Together with the above, the tools below will help you to achieve cost optimisation and simplify cloud financial management:

• AWS CloudTrail
• AWS Compute Optimizer
• Prometheus
• Log aggregation tools like DataDog, ELK Stack etc