We’ve decided to do a more in-depth article on additional cost-cutting measures apart from those described in a previous article. Please keep in mind this isn’t the way to do it ™, because in a perfect world everyone would have cost-tags in place in every resource created, preferably via your-favourite-Infrastructure-as-Code strategy, which would make everyone’s life easier.
In this example, we’ve divided the analysis in seven different areas, which mirror AWS Services usually higher on the billing data (in no specific order):
This looks like something out of Captain Obvious journal, but in fact is one of the ways we’ve been helping some customers cutting costs on AWS: stop them from spending.
Usually we have access to an invoice which looks somewhat like the following:
AWS Service Charges:
Data Transfer $4901
Elastic Compute Cloud $28432
Simple Storage Service $5326
There’s that big Elastic Compute Cloud line which you can drill-down on. However, in order for you to be able to do it efficiently (and possibly allocate the costs internally) you’d have to know how to identify each of the billing components. That’s where tagging comes to your rescue: deploy your infrastructure with the corresponding cost tags (Prod/Dev; Marketing/Finance/etc) on each resource and benefit from the results in the end of the following month. To make things really easy, invest some time in terraform-deploying your resources with the tags, which will ensure you’re measuring costs right from the start. Use whichever tool you like to collect and measure costs (Cost Explorer would be a good choice).
At last, a very frequent mistake is usually responsible for unusually high Data Transfer expenses: go through all existing VPCs and make sure you have Gateway Endpoints for S3 or DynamoDB; otherwise you’ll be uselessly paying for traffic regarding AWS services usage.
For more in-depth cost reduction measures, call us.