A well-worn expression meaning “don’t ignore the small savings as they will soon add up to make large savings”.
This is particularly true when it comes to Cloud cost optimisation. It is all too easy to use Cost Explorer and ignore everything that is less than $1K per month as being “not worth the effort”. However, that is $12K per year, so it only takes a few of these types of savings to be worth in the region of $100’k per year.
Working as a Senior Consultant at Capacitas, I am happy to share a few quick and easy wins which we have found in recent customer engagements:
- 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 retesting, but without even having the right size, it is possible to save up to 40% on an instance’s cost. Add in some rightsizing as well and quite significant savings can be made - even on smaller instances often used in Dev and Test environments. When there are hundreds of them, it does not take long for those savings to add up to something quite substantial.
- Review what is collected in Cloudwatch. The normal cost should be around 1-2% of Cloud spending. If you are spending more than this, it is worth investigating why. Common reasons include Kinesis and Fargate monitoring which can collect a lot of data by default.
- 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.
- EBS Snapshots. Again, these should only be kept for a short period with the data being moved to a significantly lower-cost solution (e.g. S3 storage) if longer-term retrieval is required. Ideally, the EBS snapshot should only be kept for 1 day for best cost optimisation.
- Look at your Network regional transfers. If the cost is increasing more than your demand is increasing the cause of this needs to be investigated. It is often that an instance has moved to a different availability zone and suddenly additional regional transfer costs start appearing.
- If you are using Fargate the number of vCPUs and Memory should be reviewed regularly. Individual costs or not always that high, but if it becomes oversized, the overall costs can quickly mount up.
- 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.
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, these should only be implemented after all the rightsizing, and instance terminations have been completed to maximise value.
Finally, it is important to view this as an ongoing task. Cloud spending needs to be analysed on at least a monthly basis (if not daily), and any discrepancies should be investigated to determine the reasons for them.
