Reserved Instances (RIs) can save you a lot of money with Amazon Web Services (AWS). Using RIs, our customers routinely save 30% off the On-Demand price. It’s enough to make any company sit up and take notice. But there’s a catch. While RIs can yield substantial savings, a misstep can erase your hard-won ROI, or even cost you dearly.
At first glance, RIs can seem extremely complicated, but you don’t have to be afraid of them. When used correctly, they can be the one of most powerful cost-saving tools Amazon provides. Any company looking to lower their cloud costs should take the time to get truly familiar with RIs.
That’s why this e-book is here. We’ll walk you through RI basics, show you how they work, help you calculate your RI needs, and show you how to manage your RI portfolio going forward.
PART 1: The Basics
What is a Reserved Instance?
Despite the name, you’re not actually reserving a physical instance when you buy an RI. An RI is coupon that can be applied to a specific instance type. It uses the exact same resources that an On-Demand purchase uses, but at a lower rate.
Think about an RI as a bulk discount. With On-Demand, you only pay for the resources you use down to the second. With RIs, you’re purchasing resource hours in bulk, and like any bulk purchase, that comes with a substantial discount. Like any bulk purchase, it only makes sense if you’re going to use enough to make the investment worthwhile. In their system, AWS classifies RIs as a billing discount applied to your On-Demand use. We’ll go more into how that all rolls out below.
Reserved Instance Traits
There are four key attributes for every RI:
• Instance type – Broken down by the instance family (e.g. m4) and instance size (e.g. large)
• Scope – Whether the RI is flexible within a region or applies to a specific AZ (e.g. us-east-1a)
• Platform – Which operating system will be used (e.g. Linux), since some features are only available for certain platforms
• Tenancy – Determines if the RI runs on Default (shared) or Dedicated hardware
RIs are categorized by the combination of all four attributes, such as an m4.xlarge Amazon Linux, default tenancy instance in us-east-1b. When you run an instance with the same attributes as an RI, the discounted rate is applied to your usage.
Regions and Availability Zones
AWS divides its services across several different geographical areas called Regions. Each one of those is further broken down into two or more Availability Zones (AZs). Any instance can be identified by both its Region and AZ, such as us-east-1b. This is known as its scope.
When you purchase an RI, you have a couple of options for scope. If you select the Region scope, then your RI can apply to an instance in any AZ within that Region. If you select a specific AZ, then the RI will only apply to instances in that AZ. But what are the benefits of each option?
By specifying an AZ, you’re reserving capacity within that zone whether you use it or not. If your infrastructure needs capacity standing by and ready, then this is the best way to make sure your resources will be there. For example, say your application goes from 10 instances to 1,000 in an unexpected spike. The sudden demand can be tough to fulfill without reserved capacity. It’s important to note that “reserved” does not mean “guaranteed.” With a reservation, AWS puts you first in line.
With a Region scope, the RI discount applies to usage in any Availability Zone within its region. That being said, when you don’t specify an AZ, you also don’t reserve capacity. So that flexibility comes with a slightly higher risk. It’s still a very low chance that you won’t get the capacity you need, but you’ll no longer be first in line. If you’re purchasing RIs for vital systems, then it might be worth it to get the reserved capacity at the AZ level.
What About Classic Network?
If you worked with AWS before 2014, you might remember the classic network. If you don’t know what that is, it’s because AWS switched over to the Virtual Public Cloud (VPC) network in December of 2013. Some older accounts can launch EC2-Classic instances, but any account created after December 4, 2013 is VPC only. If you use EC2- Classic, don’t worry: RIs apply the same way to both networks.
How Reserved Instances are Applied
An RI discount can be applied to any one instance that matches the RI’s attributes. The RI can be used for multiple instances, but only one at a time. The important thing to remember is that you’re not purchasing a reservation for a specific instance ID, but a billing discount that can be applied to instances that fit the right attributes.
RI Application in Action:
So you’ve purchased an m5.xlarge Amazon Linux Availability Zone us-east-1b RI. Now what? If you spin up an m5.xlarge instance in us-east-1b, then the RI rate will apply to that instance. If you spin up a second m5.xlarge at the same time, it can’t use the single RI you’ve purchased because it’s already in use. So the new instance is billed at the OnDemand rate. You’d either need to purchase a second RI for the new instance or turn off the first instance so the newly-freed RI will switch over.
In that same example, if you spin up a t3.xlarge, then it will be billed as On-Demand since the instance type doesn’t match, even if the RI isn’t currently being used. Basically, an RI rate can only be used for instances that fit the same attributes and only applies to one resource at a time.
Using RIs with Consolidated Billing
RIs automatically transfer between linked accounts in a consolidated billing structure, but how it’s applied depends on the account that bought the RI. The purchasing account always gets preference, but if it’s not running any qualifying instances, the RI can be used by other linked accounts. If the reservations were purchased at the master payer level, then they’re spread out among the linked accounts on an as-needed basis.
As a note, the capacity reservation doesn’t go along with the RI when inherited. That will always stay with the account where it was purchased.