6 Things You Might Not Know About Amazon Reserved Instances

Reserved instances allow you to make a one-time payment to Amazon in return for a discount on your compute costs. The rationale for reserved pricing is simple: by getting customers to commit to the usage of specific infrastructure, Amazon can better manage their capacity, and therefore pass these savings on to their customers. By now we are all likely well aware of the various options for reserved instances, including types (Heavy, Medium, Light) and terms (1 and 3 year). But here are 6 thing you may not know about reserved instances.

1 - The Dual Benefits

Reserved instances provide two benefits to customers: 1) a price reduction, and 2) a capacity reservation. While most Amazon customers are very aware of the price reduction benefit, some overlook the secondary benefit: a guarantee from Amazon that you will be able to launch an instance of this type (instance type, availability zone, operating system) at any time during the term of the reservation. Amazon is the only provider offering a capacity guarantee, so this benefit is actually a competitive differentiator.

In many ways, Amazon is a victim of its own success here: its ability to scale to support the rapidly growing demand from its customer base has enabled many of its users to assume there are few limits on capacity, and therefore devalue the capacity reservation benefit.

2 - How They Get Applied

Reserved instances get applied on an hourly basis by randomly evaluating the available reservations and running instance usage. Each usage of an instance for the hour gets evaluated to determine if there is an applicable reservation to cover it. Applicability is determined by matching instance type (e.g. m2.2xlarge), availability zone (e.g. us-east-1a) and operating system (e.g. Linux). Since multiple different reservation types and purchases can match, the selection of a reservation gives preference toward applying the lowest hour rate first. It’s also worth noting that reservations have an affinity toward the account in which they were purchased, which we will talk about in more detail later.

The randomized approach of reserved instances is both a powerful feature and a source of constant confusion for customers. I regularly talk to customers who are frustrated at purchasing an RI for a specific purpose (e.g. the marketing department), only to find its cost benefit gets applied elsewhere.

3 - Cross-Account Float

One of the more powerful features of reservations is their ability to “float” across accounts. The feature is only available to customers who have enable consolidated billing, and the “float” is limited to the billing account and its corresponding linked accounts. This feature means that if you purchase a reservation in an account, but there is no instance usage in a given hour in this account to utilize the reservation, the reservation can be applied to instance usage in any other linked account within the consolidated bill. As mentioned previously, reservations have an affinity for the account in which they were purchased, so the “float” will only occur if there is no instance usage within its account that can take advantage of the reservation.

While the price reduction benefit of reserved instances “float” across accounts within a consolidated bill, the capacity reservation does not. So if you have an available reservation in account A, Amazon will not guarantee you can launch an equivalent instance in account B, even if these accounts are linked into the same consolidated billing account.

4 - VPC Reservations

When purchasing a reservation, you must choose whether the reservation should be for a VPC or Classic (non-VPC) instance. The Amazon documentation is a little confusing as to the implications of this choice. A common question I hear is: if you choose VPC, can this reservation be applied to a Classic instance? Since this ambiguity has produced some public confusion over the expected behavior (e.g. RightScale PlanForCloud post: Amazon VPC Reserved Instances vs EC2 Reserved Instances), below is an attempt to set this straight.

The designation of Classic or VPC is irrelevant for receiving the cost reduction associated with a reservation. If you purchase a VPC reservation and no comparable instance is running in a given hour, it can be applied to an equivalent running instance usage using in Classic (non-VPC). However, the capacity reservation benefit is specific to the type of instance you launch (Classic or VPC), and so if you make a reservation for Classic, this will not guarantee the availability of capacity for launching a similar instance in a VPC (and visa versa).

5 - Availability Zone Misalignment

Availability zones are assigned to an account at the time of account creation. If you have multiple accounts, there is a good chance not all of them share the same availability zones. For example, if you have account A, B and C, the available zones for the us-east region might be as follows:

Availability Zone	Account A	Account B	Account C
us-east-1a	✓	✓
us-east-1b	✓
us-east-1c	✓	✓	✓
us-east-1d	✓	✓	✓
us-east-1e		✓	✓

If you run one account, or have only standalone accounts, this issue will not impact you. But if you have more than one account linked into a consolidated billing account, this issue is something to be aware of due to the cross-account “float” discussed previously. So in the above example, if you purchase a reservation for us-east-1a in Account A, these reservations cannot “float” to apply to usage in Account C, since this account does not have the availability zone us-east-1a.

6 - Constrained Data Centers

Data centers have walls, and so as AWS grows, physical data centers can become constrained. What Amazon calls availability zones are logical identifiers that are mapped to physical data centers independently for each account at the time of account creation. If an underlying physical data center can no longer support additional growth (a.k.a. becomes constrained), accounts that have logical availability zones that map to this data center will no longer be allowed to provision new instances. The likelihood of having a constrained data center is directly proportional to the age of your Amazon accounts. The newer the account, the less likely it is to have availability zones that map to a constrained data center; the older the account, the more likely this is to occur.

The good news is that while you may not be able to launch new instances in a constrained data center, you can still purchase reserved instances. To do this, you cannot use the standard self-service mechanism of the AWS Console or API, and instead should submit the request through your account rep or a s support trouble ticket. Also, in purchasing RIs in a constrained data center though, you should be aware that you can only purchase RIs to cover existing on-demand usage (e.g. the reservation must be directly applicable to a currently running on-demand instance).

A somewhat extreme but viable option to manage the challenges of a constrained data center is to move the entire workload and any associated RIs to an unconstrained availability zone.

Last Words

Amazon has provided its customers a powerful feature in reserved instances that can help manage the usage and cost-effectiveness of our infrastructure. But RIs have some subtle complexities that make buying, selling and modification decisions challenging. Make sure to raise the awareness of your team of the power of RIs and their subtle complexities.