Kill your AWS resources when you are done

My advice on not getting charged for unneeded resources

Stelios Moschos
FAUN — Developer Community 🐾

--

When I have free time, I like spending some time on AWS to understand and learn various concepts. It does not mean I like spending $$$ on AWS and you have guessed right — this is what I am going to talk about!

Photo by Sebastian Herrmann on Unsplash

I was looking at deploying continuously an Elastic Kubernetes Service (EKS) using Terraform and Gitlab CI. By the way, I am planning to write about this very soon. Back to our topic now, the final bill of spending some nice time and money on AWS in April 2021 is shown below:

AWS billing for month Apri — the surprise.

Obviously, we can see what services exactly I have used during this time but we can also notice the grand total of GBP 112.66. Looking for further information there are some minor costs that are not necessarily a problem:

  • AWS S3 — $0.01
  • Data Transfer — $0.07
  • Cloudwatch — $4.8

The obvious problem is the costs associated with

  • EC2 instances — $138.5
  • EKS — $11.03

At this point, I would like to mention that this post is not to complain about AWS, but rather as a way to raise awareness to people playing with and learning AWS. The problem here is the bad management of resources on my AWS account. And why is that?

Digging deeper into the problem I have realised that the unrequired EC2 instances were running in regions irrelevant to mine i.e. eu-west-1 (Ireland) and eu-west-2 (London). The following screenshot shows that I have mostly used resources in Ireland but also in Ohio and Oregon! :(

A tribute to the sacrificed cash for the Gods of AWS

The following screenshot shows the cost from another perspective, that of sudden billed costs. A bill like this would have been avoided if an Anomaly detection alarm was enabled on Cloudwatch.

How to avoid unexpected costs?

OK, let’s move to a more practical question! How can we avoid these costs in the future?

  1. Setup an alert on Cloudwatch!

In my case, although I set up a cloudwatch alert, it was not properly tested before “going live”. That brings us to the big discussion of how important is to properly test ANY functionality used, which applies not only in the context of AWS but also in the context of application development! I am pretty sure a lot of people will agree with me on that.

Testing is significant for a reason, otherwise it’s very likely to end up in a fortiutous situation!

A quick search online gave me the following results:

I set up the following alarms:

goodbye-10-dollars will email me about the obvious; “You spent $10 already — do something about it!”.

more-than-three-ec2 along the same lines, the second alarm will email me when, for some reason, I am running more than 3 EC2 instances.

2. Use resources in your nearest region!

I know it’s very obvious but it’s not impossible to follow a tutorial from someone in Tokyo or in Sydney. Before you start terraform apply-ing like there is no tomorrow, take a note of your region and add it in your scripts where required!

In summary, no matter if you are an individual skilling up on AWS or you work in a startup experimenting with various solutions to meet your business requirements, always remember, you need to ensure you have terminated/destroyed the AWS services you have used. You can also double-check by browsing through the regions you spun up a server, a cluster, your data pipeline, or anything that will get you to a surprise at the end of the month after you receive the final bill. Last but not least, always ensure you have the right Cloudwatch alert setup!

Edit 18/5/21: There is now a sequel article!

Thank you!

Before you go away, I would like to thank you for reaching this point. I really hope I have managed to transfer some knowledge to you and the people around you. Yes, that’s the plan! Sharing knowledge is my passion and I am looking forward to keeping doing it. Who knows? One day I may be able to publish a book on Cloud Infrastructure within the Telecommunication industry :)

If you liked what you read so far and you have questions feel free to reach out on LinkenIn (stelios-moschos) | Twitter (smosgr) | hiretheauthor.com/steliosmoschos | smos.gr.

Join FAUN: Website 💻|Podcast 🎙️|Twitter 🐦|Facebook 👥|Instagram 📷|Facebook Group 🗣️|Linkedin Group 💬| Slack 📱|Cloud Native News 📰|More.

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author 👇

--

--