AWS Reserved Instances vs. Scheduling On-Demand Instances

We are frequently asked about the impact of instance scheduling on AWS Reserved Instances for EC2 and RDS.  Scheduling On Demand instances as well as Reserved Instances (RIs) are both useful techniques for cost optimization, but they are polar opposites in terms of goals.  RIs are all about getting a better price for RDS or EC2 instances that are running all the time. Scheduling is all about reducing costs by turning off instances when they are not in use.  

How should a customer choose between buying an AWS Reserved Instance and applying scheduling to the instance?  This is an important question, as usually the savings from scheduling can exceed the savings available from a Reserved Instance.  Before we dive into that though, let’s get familiar with some critical RI nuances that can help you make the decision…and make the most of your RIs.

Note: versions of this article were originally published in 2015 and 2017. It has been completely re-analyzed, rewritten, and updated! 

Where are my Reserved Instances?

First of all, it’s worth clarifying that there is no functional difference between Amazon Reserved Instances and On Demand. It’s all in the billing. <rant> I wish I had a dollar for each time someone asked me (while looking at the AWS Console) “Which ones of these are the Reserved Instances?” </rant>. You cannot be sure which instances are using a reservation until you get your bill.  You can make a good guess, based on what account you are looking at and what reservations you have purchased, but if you are using instance size flexibility with region-based RIs, it would be a pure guess.  An instance reservation is not like a hotel reservation, where you end up with a specific room for the duration of your stay. That would be a Dedicated Host Reservation – a whole other beast with its own set of limitations.

3600 Seconds per Hour

Yep – there are 3600 seconds in an hour.  I did the math. You may ask: why does that matter?  It matters because of two things: per-second billing for EC2, and the fact that AWS RIs are billed in one hour chunks.  More precisely, RIs are billed in one “clock-hour” chunks, where a clock-hour starts on the hour and up to the final second of the hour – like 04:00:00 to 04:59:59.

If you are running a number of instances that use per-second billing, and they go up or down during a (clock) hour, then multiple instances may be able to leverage the Reserved Instance pricing.

As paraphrased shamelessly from here, if you purchase one m5.large Reserved Instance and run four matching m5.large instances for 15 minutes each (900 seconds each) in the same hour, the total running time is one hour, which consumes the entire Reserved Instance allocation.  This usage pattern is illustrated below.

That said, if multiple matching instances are running at the same time, the Reserved Instance billing benefit is applied to all of the instances, up to a maximum of 3600 seconds in a clock-hour.  On-demand rates are used for any usage after that. This is illustrated below.

By the way, remember that per-second billing only applies to instances running an open-license OS like Amazon Linux or Ubuntu.  

If your instance is running any flavor of Windows, Red Hat Linux, or any pay-by-the-hour image from the AWS Marketplace, that instance is billed by the hour, and any matching reservation will be consumed by the hour, even if the instance is not.  Any overlapping instances will each need their own RI to get RI pricing.

Elastic Reserved Instances

Wait…what?  Isn’t that kind-of an oxymoron?  Elastic means it should be able to change with my usage…and aren’t reservations are a commitment to usage?  Well, maybe…but some RIs are definitely more elastic (or at least more flexible) than others.  Regional Reserved Instances can leverage “instance size flexibility.”  This is the ability of a reservation to apply up or down to other instance types in the same family.  Regional RIs are applied in priority order from the smallest instance in the region to the largest instance in the region.  This makes these AWS reservations somewhat elastic in that if you buy reservations for smaller instance types than you normally use, then those reservations are more likely to be consumed, even if you rightsize an instance or replace one server with another of a different size.

The math of how an RI of one instance type can be applied to another instance type is governed by a “normalization factor”, described here.  Putting the table in that link another way:

Some examples of how we can use this table:

  • To fully cover one t3.medium with RIs, you would buy eight t3.nano RIs.  If you stop using the t3.medium instance, the same eight t3.nano RIs could also be used to cover:
      • Two t3.small instances
      • One t3.small and two t3.micro
      • Half of a t3.large
  • To fully cover an m5.12xlarge would require 24 m5.large RIs.  Those 24 m5.large RIs could also be used for:
      • One m5.8xlarge and one m5.4xlarge
      • One m5.8xlarge and two m5.2xlarge
      • One m5.8xlarge, one m5.2xlarge, one m5.xlarge, and two m5.large
      • Three quarters of an m5.16xlarge
      • Etc.

The lesson here is that it is easiest to manage reserved instances if you buy the smallest instance size available within an instance family.  In fact, as shown below this is the exact type of recommendation you are likely to receive from the AWS Cost Explorer.

So why do we mention AWS flexible reserved instances with relation to schedules?  Recall that the allocation of RIs to instances is done by AWS each second within a clock-hour.  Each reservation is consumed by instances in its family until all 3600 seconds have been allocated.  You do not necessarily have to keep an instance up for the whole hour to use the reservation. You can still consume the whole RI, even if you are starting and stopping instances by schedule or within an auto-scaling group over the course of an hour.

Something so cool cannot be without limitations and gotchas. Here are a few we’ve noticed:

  • Instance size flexibility is ONLY available for certain instance platforms.
    • For AWS EC2 reserved instances, only open-license linux instances support flexible RIs.  It is NOT APPLICABLE to any flavor of Windows or other licensed software and OS.
    • For AWS RDS reserved instances, instance size flexibility is available for MySQL, MariaDB, PostgreSQL, and Amazon Aurora database engines as well as the “Bring your own license” (BYOL) edition of the Oracle. [That said: it is not clear as of this writing if the recent RDS per-second billing change is also applied to RDS instance size flexibility. The billing pages still state that RDS RIs are allocated to instances on a per-hour basis.]
  • Flexibility is only available within the same instance family
  • Flexibility is only available for Regional RIs 

How does AWS Reserved Instance Pricing Work?

As usual, there are a number of different decisions that need to be made before this question can be answered.  AWS RIs are available with two different levels of flexibility and several different terms of purchase. 

In terms of flexibility, RIs can either be purchased as “standard” or “convertible.” 

  • AWS Convertible Reserved Instances – allow changing the assigned availability zone, instance size/families, operating system, tenancy, and networking type. There is no fee for changing the reservation attributes, but you can only convert the RI into a new set of attributes with equal or greater cost than the original.  If the cost is greater, you will have to pay the difference.
  • Standard Reserved Instances – once purchased, cannot be changed. They can be sold on the AWS Reserved Instance Marketplace.

Both AWS Convertible RIs and Standard RIs offer:

  • Regional vs. Availability Zone assignment scope.  Regional scope offers a lot more flexibility for where your instances can reside while still leveraging RI pricing. Availability Zone scope has the bonus of a guaranteed capacity reservation (though, like RI pricing,  capacity reservation cannot be assigned to a specific instance).
  • For open-license Linux, instance size flexibility, as described earlier.

There are a few options for terms of purchase that affect AWS RI pricing. RIs can be purchased for 1 or 3-year terms, and with no upfront, partial upfront, or all upfront payment available for each. 

To get a better idea of the difference in the amount you’ll end up paying with each purchasing option, let’s take a look at some pricing scenarios for the general purpose m5.large instance in us-east-1 (US Virginia).  When you look at these on the AWS RI price list, they are usually grouped by year terms and standard vs. convertible.  Since you can already see it that way on AWS, and because time is the greatest unknown, I am going to give a bit of a different view, keeping the years together on the same comparison chart.

One-Year Term RIs

To  benefit from the discount provided by a  reservation while keeping contract terms to a minimum, look at the 1-year RIs:

You can see from this that within the Convertible vs. Standard tiers, there is not a lot of difference between the upfront cost payment options.  Your upfront cash decision here can depend on your accounting process, perhaps accounting for the difference between CapEx and OpEx (Capital Expenditures and Operating Expenditures), or based on your current and prospective cash flow.  The pricing between the Convertible vs. Standard options are so similar as to make you seriously consider if the benefit of flexibility in the AWS Reserved Instances convertible option outweighs the minor cost savings.

Three-Year Term RIs

If are confident of your three-year usage plans, look at the 3-year RIs, shown here as the cost per year:

There is a bit more visible progression between the options here, and the cost savings difference between the 1-year graph and the 3-year graph are clearly seen.  Still, the 1-year vs. 3-year decision may again come down to accounting practices.

Note that these graphs are just for one instance type in one location in about the middle of the overall performance pack.  They do not express a true profile of all instance types/families in all locations, and you should do your own comparison before buying any RIs.  That said….

AWS Reserved Instances vs. On Demand

Scheduling Break-even

FINALLY getting into the core question.  Is it better to shut an instance down or buy a reserved instance?  Let’s do the math and compare AWS On Demand vs. Reserved, with on/off scheduling applied to the On Demand option.  Given all the different pricing options it can be a bit difficult to decide how to compare these. Let’s go with the no-upfront RI options and see where the RIs break even with scheduling.

AWS On Demand vs. Reserved Instance Purchase Option Comparison

Since the hours might be judge at this scale, here are the break-even hours in a table (hours rounded-up):

So what do these hours mean?  

By way of comparison, here are a few common schedules and their hours in ParkMyCloud (with weeks converted to months on the basis of 52 weeks/12 months = 4.33 weeks/month):

  • Running 8 AM – 5 PM, Weekdays = 195 hours/month (nominally a 73% savings)
  • Running 7 AM – 7 PM, Weekdays = 260 hours/month (64% savings)
  • Running 5 AM – 9 PM, Weekdays = 347 hours/month (53% savings)

Of the above, 7 AM – 7 PM Weekdays is the second most popular schedule in our entire system, and at 260 hours, easily is more cost-effective than the least expensive RI.  

In that final schedule above, you need to run 16 hours per day, Monday-Friday before a 3-year RI starts to look like a better deal.  If you have other matching instances on another schedule in that same region/AZ, you could then buy the RI anyway, and save even more money.

Scheduled Reserved Instances

“But wait!” you say…  “There are these things called Scheduled Reserved Instances – would they not offer me the best of both worlds?”  Maybe, but note that to support Scheduled RIs, AWS has essentially set aside hardware for use as Scheduled RIs – this is a finite set of dedicated resources.  On paper, a Scheduled RI can definitely save you a bit more money, but let’s look at the limitations.  

  • Instances intended to consume a Scheduled Reservation must be launched during their scheduled time periods using a launch configuration that matches the reservation. Let’s break that down further:
      • They are launched with “a launch configuration” and terminated by EC2 three minutes before the end of the schedule window.  You cannot stop/start/suspend them, and so they cannot maintain state internally unless you do some EBS volume tweaks after launch.
      • You cannot launch a scheduled RI outside of its scheduled window.  If you try, that instance will not use the Reservation, as you would not expect it to magically jump over onto the dedicated hardware.
  • Only three regions and only a few older generation instances families are supported.
  • Limited quantities are available (as of this writing, a search for an m4.large in us-east-1 with a Monday-Friday 7 AM – 7 PM scheduled listed only two reservations being available).
  • There is a minimum reservation size of 1,200 hours/year, 100 hours/month, 24 hours/week, or 4 hours/day.  (So you are not going to be able to use a Scheduled RI to run your database backup server for just a couple hours on Sunday mornings [I just tried…dang it.])
  • Scheduled RI purchases cannot be cancelled, modified or sold on the RI Marketplace. No buyer’s remorse allowed here…
  • And finally…  AWS describes the cost savings of Scheduled RIs over on-demand as being in the 5-10% range.  Again – you have to be really sure this workload is going to be needed on this schedule, and the workload is fully utilized.  If you find this server is ever idle or under-utilized, you may have lost an opportunity to save 50% or more by simply scheduling it with ParkMyCloud and then rightsizing it.

When launched in 2016, Scheduled RIs were only available in “US East (N. Virginia), US West (Oregon), and Europe (Ireland) regions, with support for the C3, C4, M4, and R3 instance types.”  Given that this has not changed, I am guessing the feature has not taken off as AWS had hoped.  That said, if you have something that needs to run for 4 hours per day, daily, and can use an older instance family in a supported region…go for it!  This may also be a good place to leverage AWS Spot instance types.

Should You Buy Reserved Instances?

Deciding between different RI options starts with knowledge of how stable your usage is going to be in the coming years.  Most organizations have a good understanding of at least a baseline level of usage, and some actually construct portfolios of reserved instance purchases, much like how you might balance a stock portfolio.  For example, 3-year Standard Reserved Instances are for those applications that are stable and unlikely to change. Balance those with some 3-year Convertible Reserved Instances to help save money in the longer term but allow for some flexibility in use.  Use 1-year RIs to account for shorter-term usage volatility, with again maybe a balance between Standard and Convertible where needed for those loads that might shift over the short term.  

Just like with stocks, such portfolios require active management, awareness of what is being used and what is coming in both the short and long term.  Companies with these types of RI management typically have dedicated cloud cost management staff, though RI management itself does not need to be a full-time job.  One of our larger customers tells us they do a quarterly review of their RI portfolio, starting with using ParkMyCloud to schedule any instances they can, and then rebalancing their RIs and investing in more as needed.  This is a best practice for any size company.

For production workloads that run 24×7 long-term, you REALLY should be buying RIs. For production workloads with an unknown future, or for non-production workloads (dev, test, QA, training, etc.), the answer is “probably not”.  Be careful though, as often RIs are seen as a quick fix to save 30-50% on the cloud bill, but then other ways are found to save even more, and you end up with underutilized RIs. Before you buy a Standard RI, make sure you have evaluated your resources for underutilization and overprovisioning.  Also consider the following cost-saving options:

  • Choose smaller instance sizes – each size down can save 50%. Use ParkMyCloud Rightsizing to first make sure your resources are appropriately sized for their load before committing to an RI purchase. 
  • For open-license Linux instances, buy RIs for smaller instance types in the same instance family in order to leverage instance size flexibility (allows the RIs to more easily be allocated against other resources, even if they are running for short periods of time)
  • Use Spot Instances and Autoscaling when appropriate for short-term/volatile workloads.
  • Schedule on/off times for on-demand instances.  Use ParkMyCloud SmartParking to automatically create schedules for when the resources are not being used, while still giving your staff the flexibility to easily restart them if needed outside the normal hours. Even a generous 7 AM – 7 PM workday schedule will immediately save 65%!

The worst thing one can do is…nothing.  Set aside some time each quarter to review EC2 and RDS instance utilization.  Rightsize and schedule what you can – try a free trial of ParkMyCloud to see how we can help you with that.  After that, anything left running 24×7 is a candidate for an RI.  If you are risk-averse or time-crunched, stick with 1-year convertible RIs to save at least 36% on at least some of your resources.  Then take all that money you saved and put it into other things that will bring greater value to your business.

About Bill Supernor

Bill Supernor is the CTO at ParkMyCloud. Bill is a software and network engineering professional with over 20 years of engineering and management experience in enterprise-grade software products, security, and networking. Prior to joining ParkMyCloud in 2017, Bill served as the CTO at KoolSpan, where he led the development of a globally deployed secure voice communication system for smartphones. Prior to KoolSpan, Bill served in security software engineering management positions at TrustDigital, Cognio, Symantec, and McAfee/Network Associates. He also was an officer in the United States Navy. Bill has the AWS Certified Advanced Networking - Specialty, is an AWS Certified Solutions Architect – Associate and holds the CISSP and CSSLP security certifications from ISC2.

Want tips, tricks, and insights for an optimized cloud?

> No, I like wasting time and money.