Insights

Cost saving for a Critical National infrastructure is mostly thought about as saving from cutting down on resources, postponing programs, or looking for some projects which could help us identify areas to cut costs.

What’s often been neglected in CNIs are the small savings, which, if put together, turn into big savings. Cloud Cost Optimisation is one such area where the cost savings could be achieved without just tending to a new project or different resources. 

This well-worn expression asking us to divert our concentration on the small savings to make large savings is very apt when it comes to Cloud cost optimisation. In the real word, putting efforts towards big chunk of money spend (over $1K per month) and ignore everything under that sounds like the right approach. However, be mindful that $1K per month adds up to $12K per year so it only takes a few of this type of saving to be worth in the +$100K per year.   

Looking at the complex institution of CNI, from recent engagements, we have found quick and easy wins that make huge cost saving without major transformations required: 

1. When using CloudWatch to monitor, we often forget monitoring CloudWatch. It is essential to review what is collected in CloudWatch. The normal cost for CloudWatch should be around 1-2% of the total Cloud spend. If you are spending more than this, then it is worth investigating the reason behind it.

The most common reasons include Kinesis and Fargate monitoring, which collects a lot of data by default adding up to the cost of CloudWatch.  

a) If you are using Kinesis, ensure that the retention period for the logs is set to 1 day as the cost of keeping it for more than one day can become quite expensive. Consider moving logs to S3 buckets if you need to keep them for longer.

b) If you are using Fargate, the number of vCPUs and Memory should be reviewed regularly. The individual costs are not always that high, but the overall costs can quickly mount up if its oversized.

2. EBS Snapshots: Ideally the EBS snapshot should only be kept for 1 day for best cost optimisation. If longer term retrieval is required, it should be moved to a significantly lower cost solution (e.g. S3 storage). 

3. Keep a watch on your Network regional transfers. If you see the cost is increasing at a faster rate than your demand, investigate the reason behind it. Its highly likely, that an instance has moved to a different availability zone and suddenly additional regional transfer costs start being added on to the cost.  

4. Another quick win is to ensure S3 versioning is turned off. It keeps 1000 versions by default, but you can specify less if multiple versions are required.  

5. Finally, look at changing to the latest technology. For instance, in AWS moving from Intel based chips to AMD can save 20%, and a further 20% could be saved by moving to Graviton for Linux workloads. It might require some re-testing but without even having to rightsize, it is possible to save up to 40% on an instance’s cost. Then if you add rightsizing to it, quite significant savings can be made even on smaller instances often used in Dev and Test environments.

These are some of the costs that can appear as reasonably small line items but when eliminated will add up to a large annual cost saving. This needs to be looked at in addition to the normal instance rightsizing, terminating unused instances and implementing reserved instances or savings plans. 

Talking of savings plans for any CNI in Cloud, these should only be implemented after all the rightsizing and instance terminations have been completed to maximise value.