The purpose of this article is to provide advice about how to choose the best AWS Instance types for costs savings. In this article, I introduce you to the concept of Parked Instances (briefly introduced here) and how this new state might affect your choice of AWS instance types, or more properly, purchasing options, such as On-Demand Instances, Reserved Instances and Spot Instances.

Since the launch of Amazon Web Services (AWS) in 2006, its adoption and growth has been meteoric. It has grown from about 180,000 developers using the service in 2007, to well over a 1 million customers today, many running mission critical production workloads.

When AWS first started, their core service was Elastic Cloud Computing (EC2), a service which was strictly on-demand. You paid only for the capacity you used, and could turn the service on and off at will. This revolutionized the industry, changing the entire discussion about purchasing data center infrastructure from an upfront, capital expenditure (CapEx) discussion, to monthly operational expenditure (OpEx) discussion. Infrastructure could literally be consumed “by the drink” in a pay-as-you-grow model.

AWS Instance Purchasing Options

Over the past decade, AWS has introduced 2 different alternatives for purchasing EC2 in addition to On-Demand:

Reserved Instances allow you to commit paying for resources for a year or more, by either paying nothing upfront, partially upfront, or all upfront, in return for less expensive compute pricing. The discount you receive is based upon how much you pay upfront. In a sense this moves the discussion back to one that is a combination of CapEx and OpEx.

Spot Instances allow you to get rock bottom pricing on compute time. You are essentially buying spare compute time on EC2 instances. The downside is that any time the price you are willing to pay drops below the actual spot price, those instances get terminated. Therefore, you are taking on much more risk in exchange for a much lower price.

Just in case you were not confused enough about how to choose between AWS Instance types for cost saving, Amazon introduced another concept – Auto Scaling. Auto Scaling is a service which can be applied to any of the above purchasing options.

Auto Scaling allows you to automatically scale up performance when it is needed, and scale back down when it is not needed. You can also set a minimum required performance across availability zones to ensure just that: availability.  Obviously, this helps save cost by providing the best availability and performance for a given cost.

All three of these innovations are aimed at helping AWS users save money (compared to EC2 on-demand pricing) and remain happy AWS customers.  The result has been a year-over-year growth rate for EC2 in excess of 90%, with EC2 spend making up roughly 66% of the total monthly spend on average.

The New Instance State: Parked

We recently released ParkMyCloud in the same spirit of helping AWS users save money, without requiring an upfront capital investment, like that for Reserved Instances, and without incurring the risk of Spot Instances. Essentially, this application has created a new state called Parked (in addition to stopped, running, and terminated), by scheduling the start/stop times for instances that not used all the time. 

The application allows you to discover your existing instances across all AWS regions within a given account, and apply parking schedules, which you create, to one or more of those instances.

What is the net result of Parking and how does it fit in with other AWS innovations discussed above?

The savings from Parking On-Demand Instances are the same or better than Reserved Instances you buy upfront, but without the required upfront capital investment.

Proof Point: Consider an m3.medium instance. Here is what the pricing looks like for 1 month:

m3 medium instance 1 month

Those are some pretty good savings. Of course you are committed to an annual contract for that instance size. The difference in savings is based on whether you pay it all up front or not.

Now, let’s compare the savings for the same instance, but Parked instead. Assuming a parking calendar in which the instance is running from 7 a.m. – 7 p.m., Monday – Friday, but stopped evenings and weekends, here are the savings.  Note, these savings are achieved without any annual commitment and without any upfront capital investment. The cost to achieve this is about $1/month, which is included in the instance cost below:

m3 medium with parked

I don’t show Spot Instance pricing in the comparison above, which can vary all over the place. Here is a weekly graph of the market in US-East-1. Normally an m3.medium costs $0.067 per hour. Here, if you are fortunate enough to bid a price between the spikes you can purchase instances at about ⅙ to ½ the cost. However, as soon as one of those price spikes hit, your instance is terminated.


So, What’s the Catch?

Well, the dollar savings are real, there is no catch there. However, there are some limitations on what can or should be parked. What are those limitations?

If you are running production workloads that need to be up 24 x 7, then obviously these cannot be parked.

Can you park Reserved Instances? Yes. The savings would be a combination of the above.

You cannot park Spot Instances. Why? Because instance parking requires that the instance be stopped according to the schedule you put in place. AWS does not allow Spot Instances to be stopped, only terminated.

You cannot park instances which are part of an Auto Scaling Group. Why? Because as soon as you stop one of those through the parking schedule, that instance gets terminated and another instance will be spun up to take its place.


So, what would be an effective mix moving forward?

  • For business production workloads, it makes sense to use Auto Scaling and Reserved Instances to give you the best pricing and reliability for mission critical applications. Be sure to implement our optimization engine to help maximize your RI commitments.
  • For non-production workloads, such as development, staging and sandbox environments, which don’t need to be running 24 x 7, then parking On-Demand Instances is very inexpensive and will help you save a lot of money. Parking Reserved Instances could save even more, if you are willing to make the 1 year commitment.
  • For massive scaling applications, like analytics, which process huge batch loads and then go away, Auto Scaling and Spot Instances are a killer combination.

Why Not Write Scripts for AWS Instance Types for Cost Savings?

“Why buy, when we can build?” I hear you say. Well, writing scripts for AWS Instance types for cost savings doesn´t always achieve cost savings. Once you factor in the cost of half a day´s work for writing the scripts (say $200), the same amount each month for maintaining them and pushing them through the DevOps process, and the time lost working on the business´s core projects, how much will you save?

In addition to the direct savings attributable to parking On-Demand Instances, parking On-Demand Instances can also deliver indirect savings. Better AWS Instance management, for example, will help identify unused or underused resources. These can be reassigned, allocated to cheaper pricing options or retired.

Parking AWS Instance types for cost savings can also result in better capacity forecasting and budgeting. It might even improve productivity due to development teams being more accountable for the Instances they use and how they use them. Parking does all this – and much more – without scripting, without any annual commitment and without any upfront capital investment for just a few dollars / instance /month.

If you would like to learn more about ParkMyCloud and parking instances, I recommend you sign up for free trial.

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.