So far in the “How to Save Money on AWS” series, we’ve looked at three ways to save using different AWS purchasing options. Today, let’s look at the first way outside of AWS: scheduling on/off times for your idle EC2 instances.

Read on, or watch the video version below:

Using AWS Scripting to Schedule On/Off Times

Often non-production environments like development and staging are running 24×7, even though they are not being used during off-peak hours like at nights and on weekends. Therefore, the simplest way to save money on these environments is to turn them off when not in use. Of course, that’s easier said than done.

For example, in AWS,  you could use data pipeline and script it up, but there isn’t anything native to the platform, and AWS has no plans to add anything.

You might also turn to any number of the cloud analytics platforms in the market. One thing they’ll recommend is for you to turn off these non-production instances when not in use. However, they’re basically like tattle tales – they tell you what’s wrong but don’t fix it for you.

AWS scriptingNow, there are some cloud management platforms that can not only identify instances but actually take action, but they can be bloated, expensive, and quite complicated, and there’s a steep learning curve associated with those.

So what do people do when there’s a lack of viable options? Well, as a recovering command-line guy, I know that when the going gets tough, the tough start scripting. Scripting tends to be in many of our comfort zones: I know I’ve scripted a lot of things, and I’m sure I’m not alone. I get the appeal: you’re in control of your own destiny, you get to get your hands dirty, and at the end of the process, you get the satisfaction of having built something from start to finish.

The Problem with AWS Scripting

However, AWS scripting is not cost-effective, for several reasons.

First, creating the script is only half the battle. Once it’s built, you have to maintain it as your environment changes. If you have a large environment that’s changing frequently, even with the help of Chef, Puppet, or SaltStack, there’s added cost to keep up with that environment. And if you don’t maintain your scripts, you’re missing out on instances you could have turned off, which has a big cost associated with it — perhaps even more than you’re spending to maintain the scripts.

Lastly, how do you justify the fact that you’re working on these scripts to your boss? That requires some way of being able to show the cost benefit and do the tracking, and that will take time. Heaven forbid that your boss actually likes the report, thus requiring you to implement a more formal cost-tracking system.

While scripting on/off times for your instances might be a relatively easy fix in the short term, it’s not a sustainable long-term solution to the cost problem.

Stay tuned for next week’s post, the final in our series on how to save money on AWS.

About Dale Wickizer

Dale brings over 30 years of technology and engineering experience to his role as co-founder and Chief Technology Office (CTO) at ParkMyCloud. After experiencing the problem of growing cloud spend first-hand, and discovering that there was no simple way to solve it, Dale teamed up with co-founder Jay Chapel to create ParkMyCloud to solve the problem of cloud waste. Before founding ParkMyCloud, Dale was the CTO of the U.S. Public Sector at NetApp, Inc. where he set the future technology and product direction and managed key customer relationships. Prior to NetApp, Dale was an Associate Partner and IT Infrastructure Architect at Accenture, where he helped large enterprises plan and execute IT transformations, data center consolidations, and application deployments. Dale holds both a Bachelor's and a Masters Degree in Electrical Engineering from the Georgia Institute of Technology. He and his wife, Barbara, reside in Springfield, VA.