We recently wrapped up an infrastructure development project with stringent requirements. These non-standard requirements forced us to experiment with a variety of systems and network architectures. For this kind of project, AWS provides us with the flexibility and speed we need to deploy, configure, and test our ideas.
However, our experimental pace sometimes left some EC2 instances running that we didn’t touch for days—or even weeks—at a time. We assumed we might log back in, but they were unattended if we pivoted quickly to a new idea. Unfortunately, a running development instance that is not being used is a cost without any benefit… and our monthly bill was certainly showing it!
We could have simply shut down our instances when we were finished for the day, but we work flexible hours—and occasionally, when inspiration struck, we wanted to make sure the instance was available for quick prototyping. We wanted a solution that did not require us to start the instance every time we wanted to use it but also prevented the situation where the instance went untouched for long periods of time. We decided to have development instances shut down automatically each night at a time that we would be sleeping. This would give us a cost reduction of about one-third… at least until one of us masters sleep-development!
Several solutions exist for this, including one sanctioned by AWS: the AWS Instance Scheduler (https://aws.amazon.com/solutions/instance-scheduler/). This solution was heavy-handed for our needs, though. We didn’t need a state manager. We wanted something lightweight. We also wanted something that would easily allow us to change the shut down time because we were frequently traveling internationally, changing our sleeping windows.
This solution for individual instances is better (https://aws.amazon.com/about-aws/whats-new/2013/01/08/use-amazon-cloudwatch-to-detect-and-shut-down-unused-amazon-ec2-instances/), but we wanted something that fit more naturally into our experimental workflow. Setting this for each instance would be cumbersome.
We found a CloudFormation template from a team addressing the same problem that had generously been made available. However, the template was old and their code did not work as expected, so we bit the bullet and implemented our own solution.
The solution is pretty simple. A CloudFormation template deploying the solution is https://bitbucket.org/archaedismend/aws-scheduler/src/master/.
The template generates a recurring CloudWatch event that triggers a Lambda function once every hour. The Lambda function will look for two specific tags on all the EC2 instances in the region: the environment tag and the stoptime tag. For the Lambda function to consider the instance for shut down, the environment tag must be equal to “dev” or “development”. Then, the stoptime tag is examined, and if the current time in GMT is after the stoptime, the instance is shut down.
Why not just rely on the stoptime tag? If we wanted to switch our instance to a different environment, such as test, we wanted to make sure it was not accidentally shut down after the stoptime. Yes, we could simply delete the stoptime tag; this was just a matter of our preference.
We now use this solution for our development environments and are happy with it! Feel free to use it and save some money!