AWS reInvent participants told us they're using scripts to schedule EC2 instance start/stop times - here's why you shouldn't.The past few months have been whirlwind of activity. On September 8, we launched ParkMyCloud. A few weeks later, the application debuted at AWS re:Invent and the reception went quite well.

When we talked with prospective customers at AWS re:Invent, they confirmed that there’s a need for the ability to schedule EC2 instance on/off times (or “park” those instances). In fact, several companies we spoke with have created their own homegrown scripting solutions for AWS EC2 instance parking to control AWS spend. 

Why bother writing scripts to park AWS EC2 instances?

  • Scheduling on/off times is something that is recommended by most of the “cloud tattletales” (cloud analytics platforms) and industry analysts, but they don’t actually help customers do it
  • Amazon does not offer a “parked” state natively through the AWS console as an alternative state to “running”, “stopped”, and “terminated”
  • A few years back, AWS did announce their Data Pipeline capability, but involves…you guessed it…scripting
  • There are some cloud management platforms out there that support scheduling on/off times as one feature, but these platforms are expensive and some have a steep learning curve

So, it’s no surprise that admins fall back to their comfort zone: scripting.

As a recovering command line interface (CLI) guy, I can understand both the appeal and mystique surrounding scripting (or as we used to refer to it, “rolling your own”):

  • You are in control of your own destiny
  • You have the satisfaction of crafting something with your own hands, without “design committee” involvement
  • Plus, look at all the money you are saving your company, right?  Well, not really!

While it might only take an admin worth his/her salt a half a day or so to create the necessary scripts and cron jobs, that is only the tip of the iceberg.

But is scripting the best way?

  • These scripts will need to be maintained perpetually as your environment changes, costing your company money. For an admin who earns $70K per year, the loaded hourly rate to the company (not counting G&A overhead) is about $50/hour. So, you spend $200 to build the cron jobs and scripts, then about the same amount each month to maintain them and push them through your DevOps process, as your environment changes.
  • If you don’t keep up with revising your scripts, then EC2 instances, which could have been scheduled to park, are not, so your company wastes money on those (hundreds or thousands of dollars per day or more)!
  • At the end of it all, would you actually be able to quantify the cost savings you have achieved?  How many hours will it take you to come up with that first report for your boss, to justify the time you spent on doing all of this? And, if they like the report, how many more hours will it take you to design and build the process to provide ongoing reporting of the cost savings for your manager?
  • Will you develop a roadmap for new features and new integrations? For example, will you build in logic to recommend which systems should be parked when they show up?  Will you include same functionality for other cloud providers, such as Azure and Google Compute? How much time and effort will that take?
  • Also, my guess is that your company is not in the business of parking EC2 instances. This means the time you are spending on these parking scripts, is time you should have spent supporting your company’s main business, and who knows what the opportunity cost is on that?

dashboard10.26.15ParkMyCloud IS in the business of parking AWS EC2 instances. That is our focus. We show you both your projected savings and actual month-to-date savings, right up front. We also show you all of your AWS EC2 instances across all regions at a glance.  We recommend instances that are likely to be parkable, based upon keywords we find in the instance description or tags (keywords which you can provide) and we allow you to park instances based upon schedules you create.

We do all of this without scripting for about $1 / instance /month.

And, to support automated workflows (e.g., when provisioning DevOps, demo or other non-production environments), you can use our REST API to make our functionality, your functionality.

When I explained this to prospective customers at AWS re:Invent and asked if they could deliver as much value from their custom scripting solution, and maintain their solution for less cost, the answer was unanimously: “No!”

So, what about you? Are you ready give ParkMyCloud a shot? We offer a 30-day free trial with no strings attached. Heck, we’re effectively printing money. You’d be crazy not to try it.  All you have to lose is your scripting headache.

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.