Reducing AWS costs: using AWS tags to automatically shutdown resources when not needed

Blog Single

One way to save AWS costs is to shut resources down when you don’t need them. For example, EC2 instances used by developers don’t usually need to stay running overnight. Or RDS databases used by testers don’t need to stay running at the weekend. Since AWS bills you for each hour these are running, that’s a lot of money you could be wasting!

Do not save what is left after spending, but spend what is left after saving – Warren Buffett

Of course, we need to stop then restart our resources in a way that doesn’t lose any data. The majority of AWS’s services allow you to do this: EC2 and RDS can be stopped then restarted with no data loss, old EBS and RDS snapshots can be deleted if an earlier snap is available, elastic IP addresses can be deleted if they are not assigned to an instance, etc.

This post will show you how to schedule your resources to automatically shutdown when they are not needed then restart again when you do need them – this is called “parking”. We park resources using a combination of:

  • Tagging the resources to be parked
  • Software or scripts to park the tagged resources on a schedule

Tagging the resources to be parked

You will probably already have a tagging scheme that works for you. If you don’t then we will suggest one for you. Typical tagging schemes help identify, for example:

  • Which project or department a cloud resource belongs to
  • Does the resource belong to the development, UAT or production environments

In the AWS console you can use the “Add/Edit Tags” button to add further tags to each resource:

Now you need to think about what resources you want to shut down and when. For example, you might have a blanket rule that states “all development resources will be shutdown over the weekend”. In this case, if your development resources are already identified as such via their tags, you would schedule all resources with this tag to shutdown at the weekends. We will show you how to do this in the next section.

However, you may not have such a simple scenario. There may be a mix of resources to be parked that have no common tag to identify them by. For example, you might want to park some development resources but not all, and some UAT resources but not all. In this case you will have to assign these resources another tag, like “auto park: yes”. You can take this a bit further and tag resources with specific tags that indicate when the should be started or stopped:

Its then the responsibility of the software you use to park your instances to recognise these tags and take the appropriate action or ignore any resource that doesn’t have these tags. This gives you great flexibility: you can now tell your resource owners which tags to assign to their resources if they want them automatically parked, or to remove the tags if they no longer need parked.

Now, let’s see what software we should use to park these resources given our new tagging scheme.

Parking the resources - CloudTime

CloudTime is Software as a Service that allows you to create schedules to park your resources according to their tags. You can read more about it on the CloudTime website. There are a few utilities out there that do the same thing, Cloud Custodian being one of them. You could also create your own set of scripts to do the startup and shutdown. The problem with both these solutions is that they require you to have the:

  • IT skills to create, use and maintain them
  • Time to invest in this
  • Servers, storage and schedulers just to host and run the scripts that you or Cloud Custodian creates

CloudTime is simpler than that. It provides a graphical user interface that allows you to point and click at your resources and tags, then specify the schedule to which you want them parked. It then observes your schedules, parking the resource automatically and keeping an audit trail of everything it does. Its Software as a Service (SaaS) so there is nothing to install, no scripting or other IT skills needed. You can start using it for free to park your first 100 resources, then its only $0.02 each time you park a resource. It’s cheap and easy to get started and it works with the tagging schemes discussed here.

Frugality includes all the other virtues. – Cicero

Using CloudTime to park resources to a schedule

Start off by subscribing to CloudTime through the AWS Marketplace. This doesn’t cost you anything, it just gives you access to the software and takes you through the account creation process. Once you have signed in to CloudTime, use the “Add Schedule” button to walk you through the steps necessary to park your first set of resources.

The first step it guides you through is providing CloudTime the AWS IAM credentials that it should use to park your AWS resources.

Once you have provided the credentials you then add a schedule to shutdown your resources.

For all EC2 instances tagged with “shutdown: every friday”, this schedule will stop them at 18:00 every Friday. After creating your other schedules you will be left with a CloudTime itinerary that looks something like:

CloudTime will then perform the parking actions at 09:00 and 18:00 each day depending on the AWS resources that are tagged.

How much money will I save?

CloudTime allows you to schedule the following types of resources to be parked:

  • EC2 and RDS instances. Stop, then optionally restart instances
  • AMI images. Delete images over a certain age or that have specific tags
  • EBS volumes. Delete volumes over a certain age that are not attached to an instance, optionally that have specific tags
  • EBS and RDS snapshots. Delete snapshots over a certain age, optionally that have specific tags
  • Elastic IPs. Delete EIPs that are not attached to an instance, optionally that have specific tags

Let’s take the least ambitious scenario where we only invest effort in parking a few small resources: an EC2 instance, an EBS volume and an RDS database. Assume we shut these down from 8pm to 8am every day, and leave them shutdown over a weekend. We delete the unused EBS volume at the start of the month. How much would we save compared to leaving these running all the time?

Resource Cost Hours saved Total savings
EC2 t3.medium $0.0416 per hour 60 (week nights) + 48 (weekends) * 4 weeks = 432 hours $18
RDS MSSQL db.t3.medium $0.088 per hour 432 hours $38
256GB EBS volume $0.10 per GB month 1 month $26

So that’s $82 savings per month, across a *tiny* number of resources. And that’s not the whole story. What happens in real life is that:

  • People don’t always create the smallest instance types they need. They create bigger instances that will cost more
  • RDS databases will auto restart after seven days, even if you do remember to shut them down once. Even for one small database this can cost hundreds of dollars over a couple of months
  • When people do remember to delete their instances after them, they often forget to deallocate the elastic IP address or delete their volume snapshots. You end up with many unused EIPs, volumes and snapshots

These all contribute to needlessly inflating your AWS costs by hundreds of dollars a month. With a simple tagging scheme, you can sit back and let CloudTime park your tagged resources, automatically. Now that’s a quick way to save money with very little effort.

Get started - subscribe now

Subscribe to CloudTime through the AWS Marketplace. Your first 100 parked resources are free of charge then it only costs $0.02 per parked resource. Remember there is nothing to install since its Software as a Service and no complex IT skills to learn.

You can read more about it on the CloudTime website.

Share this Post: