AWS EC2 Reserved Instances (RIs), which provide significant discount compared to on-demand pricing, have been extensively used by enterprises and businesses of all sizes across the globe.

In this post, I am going to discuss the types of use cases where AWS EC2 Reserved Instances will fit in for optimal discount, the complete flow of reserving the RIs, preferences behind reserving RIs ( to choose capacity first or discounts first), and much more. Just so that you can choose the right RI that fits your needs.

The Backdrop

Currently, AWS offers its users to buy compute instances in 3 modes: on-demand, reserved instances, and spot instances. Let’s dive into the details of these three instances.

On-demand Instances: With on-demand instances, you pay for compute capacity by the hour with no long-term commitments or upfront payments. You can increase or decrease your compute capacity depending on the demands of your application and only pay the specified hourly rate for the instances you use. Pay-as-you-go, no commitment, pay hourly rate.

Suitable for unpredictable workloads, or developed or testing in EC2 newly. Reserved Instances: RIs provide you with a significant discount (up to 75%) compared to on-demand instance pricing. In addition, when reserved instances are assigned to a specific Availability Zone, they provide a capacity reservation thereby giving you additional confidence while launching instances when you need them. Significant discount, 1 year or 3 year commitment.

Ideal for predictable and steady usage. Spot Instances: AWS allows you to bid on spare Amazon EC2 computing capacity. These instances are known as spot instances. Spot instances are often available at a higher discounted rate compared to on-demand pricing. So you can significantly reduce the cost of running your applications, grow your application’s compute capacity and throughput for the same budget. You can bid for Spot instances using AWS API’s, AWS CLI and Web Console. Your Spot instance runs whenever your bid exceeds the current market price. Provide up to 90 % discount.

Useful for steady and flexible workloads such as batch processing.

Now, let’s discuss about how to make the most of RIs by understanding the attributes that define RI, offering class, plans of RI, and the factors that affect your savings.

Of all the AWS instances, RIs are the ones which give you massive discounts. The discounts provided will vary from 45%-75% depending on the plan and scope that you choose. RIs affinity will decide on which account the RI is actually applied. RI can provide optional capacity reservation. Reservation will be applied only in the account that purchased the RI. If you are planning to purchase capacity reservation, ensure you purchase it in the account where you are going to use it. Because while applying the RI discounts, owner account is always given the priority. AWS assigns reserved instance hours to linked accounts. It always starts first with the linked account that purchased the reservation, which is sometimes called Reserved Instance affinity. If there are hours from the capacity reservation left over, they are applied to other accounts operating identical usage types in the same Availability Zone. Again, this allocation always occurs using unblended rates.

Payment Options for AWS RI

To purchase RIs, AWS offers three payment options, namely All Upfront, Partial Upfront, No Upfront.

All Upfront: Pay full amount for the reservation term in one single payment. This one gives the highest savings.

Partial Upfront: Pay portion of amount for part of the reservation term in an upfront payment and pay the remaining in installments every month for the duration of the term. This option costs more than All Upfront, but less than No Upfront.

No Upfront: Pay for the reservation in installments throughout the term’s duration every month. This payment offers the lowest savings rate.

Apart from the discount you get individually from the above plans, if you have total active RI list value above $5,000,000 per region, you get more discount, from 5% to 10%. This discount is known as RI Volume Discount.

Note: It is highly recommended to purchase the RIs in bulk together in a single transaction. The reasons being: you can merge the RIs if reservation going to be unused due to the changing requirements over the time.

AWS RI Offering Classes

AWS offers the RIs in three modes, i.e Standard, Convertible, and Scheduled, where each have advantages and disadvantages of their own.

Standard RIs: These provide the most significant discount (up to 75% off on-demand) and are best suited for steady-state usage as shown in the below pic. If the load and infra per instance is properly estimated by load testing, and is not going to change frequently for at least an year, these RIs are recommended.

Image source: Botmeric, AWS EC2 Consistent Usage Graph

This mode of RI will give maximum discount over other modes.

Convertible RIs: These provide a discount of up to 45% over on-demand instances, and the capability to change the attributes of the RIs as long as the exchange results in the creation of Reserved Instances are of equal or greater value.

Like Standard RIs, Convertible RIs are also best suited for steady-state usage. These provide good discount but less than the standard RIs, average of 45% discount. With this offering class, you can change every attribute of RI. No limits to exchange size. You can purchase the convertible RIs only with 3 year term plan. You can check if RI is convertible or not by verifying the “Offering Class” in the AWS console.

Plus, with convertible RIs, you can exchange the RIs across the family. For example: from t2 to m4, with different OS, Windows to Linux, to new instance size. medium to large, and more.

P.S: While exchanging the convertible RIs, you may need to either exchange it with instance type/size smaller than the current one, or vice versa.

Refer the below two use cases:

Exchanging the instance with lower cost: In this scenario, you will get additional instances, which are either unused or applied to other instance types. For example, say that you are running m4.4xlarge instance in us-east-1a, as per your new requirement, if you are exchanging it with t2.large instance in us-east-1a (as t2 family instances are cheaper than m4), you will get 5 t2.large instances for exchanging 1 m4.4xlarge instance.

Exchanging instance with higher cost: While exchanging the instance with higher cost than the current one, you may need to pay true up charge, which will be reflected in your current month bill.Below is the formula used for calculating the true up charge of an RI.

True up charge = new convertible RI you receive by exchange — prorated upfront charges of current instance.

For example: say that you have an t2.micro instance in 3 year term plan partial upfront with 32 months remaining. Now, if you go for exchanging that instance with t2.small instance, then

The total upfront price of your new reservation t2.small is : $133.792, Remaining upfront value of your exchanged reservations : $109.25, True Upcharge = 133.792–109.25 = 24.54 with hourly rate of $0.006.

You can exchange with convertible RI only if the following conditions are met.

Active Not pending another exchange request Terminating in the same hour (but not minutes or seconds)

Limitations of Convertible RIs

There are few limitations to take into account while dealing with Convertible RIs:

Convertible RIs can only be exchanged for other Convertible Reserved Instances currently offered by AWS. Convertible RIs cannot be modified. You can only exchange it with other configuration. Convertible RIs can only be exchanged with the same or higher payment option. For example Partial Upfront Convertible Reserved Instances can be exchanged for All Upfront Convertible Reserved Instances but they cannot be exchanged for No Upfront Convertible Reserved Instances.

Scheduled RIs: These are available for discounts within the time windows you reserve. This option allows you to match your reservation to a predictable recurring schedule that only requires a fraction of a day, a week, or a month. These are recommended heavily when you have predictable spike for a duration or for running the batch jobs. For example, this reservation is recommended when your system generates reports at 2:00PM every day and emails to all your product users.

Note: You can purchase the RIs in this mode using AWS CLI, API’s, AWS management console.

Scope of RIs — Zonal RI & Regional RI

Zonal RIs: Any RI purchased for specific availability zone is called as zonal RI. In this scope of RI, instance capacity reserved for your use in that AZ gives better confidence while launching instances. If you want to run an instance in AZ and if AWS has reached the capacity of instance type you need, then you will not be able to launch the instance due to hardware limitation in that AZ.

With Zonal RIs, irrespective of instance being used or not, the instance capacity is assigned to you. Capacity reservation are available within that account. The attributes that decide the RIs discount are Instance Type, Tenancy (Shared/Dedicated), Availability Zone, Operating System. These RIs will be applied to the instances running with same instance type and OS in the AZ RI purchased. This is highly recommended when you are reserving the higher instances types on AWS, as they are limited.

Regional RIs: This scope is recommended if you prefer the discount over the capacity since region scope does not offer capacity reservation. But regional RIs give flexibility over managing the RIs as if it has broader applicability and flexibility. These RIs are recommended for maximum discounts. Note that based on your requirement, you can always modify the scope of RIs with no extra cost.

Instance Size Flexibility

All regional Linux/UNIX RIs with shared tenancy apply to all sizes of instances within an instance family and AWS region (even if you are using them across multiple linked accounts). This will help further in reducing the AWS costs. In this RIs are applied based on scale known as normalization factor within a particular instance family. Below is the normalization factor table for instance sizes.

Let’s say you already own an RI for a m4.16x large. This RI now applies to any usage of a Linux/UNIX C4 instance with shared tenancy in the region.

This could be applied on either:

Four m4.4xlarge instance

Eight m4.2xlarge instances

Sixteen m4.xlarge instances

Thirty two m4.large instances.

Or any combination of above instances for above family that matches to the total normalization factor.

Limitations of instance size flexibility:

This is not applied on Zonal RIs.

This is not applied on Windows, RHEL.

Rate will be applied completely if proper match is found, else it will be partially applied for the units.

How RIs are Applied?

Zonal RIs are always applied first. Regional RIs are applied next. The instance size flexibility. Applied by the first qualified instance based on the instance.

Understanding the Application of Reserved Instances

The following scenarios cover the ways in which Reserved Instances are applied.

Scenario One A customer is running the following On-Demand Instances in account A: 4 x m3.large Linux, default tenancy instances in Availability Zone us-east-1a 2 x m4.xlarge Amazon Linux, default tenancy instances in Availability Zone us-east-1b 1 x c4.xlarge Amazon Linux, default tenancy instances in Availability Zone us-east-1c The customer then purchases the following Reserved Instances in account A: 4 x m3.large Linux, default tenancy Reserved Instances in Availability Zone us-east-1a (capacity is reserved) 4 x m4.large Amazon Linux, default tenancy Reserved Instances in us-east-1 1 x c4.large Amazon Linux, default tenancy Reserved Instances in us-east-1

The Reserved Instance benefits are applied in the following ways:

The discount and capacity reservation of the four m3.large Reserved Instances is used by the four m3.large instances because the attributes (instance size, region, platform, tenancy) between them match.

The m4.large Reserved Instances provide Availability Zone and instance size flexibility, because they are Amazon Linux Reserved Instances with default tenancy.

An m4.large is equivalent to 4 normalized units/hour.

The customer has purchased four m4.large reserved instances, and in total they are equal to 16 normalized units/hour (4×4). Account A has two m4.xlarge instances running, which is equivalent to 16 normalized units/hour (2×8). In this case, the four m4.large Reserved Instances provide the billing benefit to an entire hour of usage of the two m4.xlarge instances.

The c4.large Reserved Instance in us-east-1 provides Availability Zone and instance size flexibility, because it is an Amazon Linux Reserved Instance with default tenancy, and applies to the c4.xlarge instance. A c4.large instance is equivalent to 4 normalized units/hour and a c4.xlarge is equivalent to 8 normalized units/hour.

In this case, the c4.large Reserved Instance provides partial benefit to c4.xlarge usage. This is because the c4.large Reserved Instance is equivalent to 4 normalized units/hour of usage, but the c4.xlarge instance corresponds with 8 normalized units/hour. Therefore, the c4.large Reserved Instance billing discount applies to 50% of c4.xlarge usage. The remaining c4.xlarge usage is charged at the on-demand rate.

It is interesting to note that regional Linux/Unix Reserved Instances apply to any usage matching the region, tenancy, and platform within the instance family. Reserved Instances are first applied to usage within the purchasing account, followed by qualifying usage in any other account in the payer account. In the case of Reserved Instances that offer size flexibility, there is no preference to the instance size within a family that the Reserved Instances apply. The Reserved Instance discount is applied to qualifying usage that is detected first within payer account. The following example may help explain this.

Scenario Two A customer is running the following On-Demand Instances in account A: 2 x m4.xlarge Linux, default tenancy instances in Availability Zone us-east-1a

1 x m4.2xlarge Linux, default tenancy instances in Availability Zone us-east-1b

2 x c4.xlarge Linux, default tenancy instances in Availability Zone us-east-1a

1x c4.2xlarge Linux, default tenancy instances in Availability Zone us-east-1b The customer is running the following On-Demand Instances in account B — a linked account: 2 x m4.xlarge Linux, default tenancy instances in Availability Zone us-east-1a The customer then purchases the following Reserved Instances in account A: 4 x m4.xlarge Linux, default tenancy Reserved Instances in us-east-1

2 x c4.xlarge Linux, default tenancy Reserved Instances in us-east-1

The Reserved Instance benefits are applied in the following way:

The discount of the four m4.xlarge Reserved Instances is used by the two m4.xlarge instances in account A and the m4.2xlarge instance in account A. All three instances match the attributes (instance family, region, platform, tenancy). There is no capacity reservation.

The discount of the two c4.xlarge Reserved Instances can apply to either the two c4.xlarge instances or the c4.2xlarge instance, all of which match the attributes (instance family, region, platform, tenancy), depending on which usage is detected first by the billing system. There is no preference given to a particular instance size. There is no capacity reservation.

In general, RIs that are owned by an account are applied first to usage in that account. However, if there are qualifying, unused zonal Reserved Instances in other accounts in the payer account, they are applied to the account before regional Reserved Instances owned by the account. This is done to ensure maximum Reserved Instance utilization and a lower bill. For billing purposes, all the accounts in the organization are treated as one account. The following example may help explain this.

Scenario Three The customer is running the following instance in account A 1 x m4.xlarge Linux, default tenancy instances in Availability Zone us-east-1a The customer is running the following instance in another linked account B: 1 x m4.xlarge Linux, default tenancy instances in Availability Zone us-east-1b The customer then purchases the following Reserved Instances in account A: 1 x m4.xlarge Linux, default tenancy Reserved Instance in Availability Zone us-east-1 The customer also purchases the following Reserved Instances in account C: 1 x m4.xlarge Linux, default tenancy Reserved Instances in Availability Zone us-east-1a

The Reserved Instance benefits are applied in the following way:

The discount of the m4.xlarge Reserved Instance owned by account C is applied to the m4.xlarge usage in account A.

The discount of the m4.xlarge Reserved Instance owned by account A is applied to the m4.xlarge usage in account B.

If the Reserved Instance owned by account A was first applied to the usage in account A, the Reserved Instance owned by account C remains unused and usage in account B will be charged at On-Demand rates.

Summary:

Here’re the key highlights summerizing the key aspects of AWS EC2 RIs:

Standard RIs offer you more discounts over any Convertible RIs.

Zonal RIs offer capacity reservation, recommended for larger instance types and if capacity is preferred over discounts.

Regional RIs give more flexibility in managing the RIs.

Convertible RIs give you wide range of options while exchanging but offers you lesser discounts compared to Standard RIs.

Instance size flexibility give you further discounts for Linux/Unix instances for regional RIs and shared tenancy.

Though AWS RIs give you the maximum savings in your cloud cost, if not managed properly, they might lead to unused cost. Planning and managing AWS RIs is tedious task. Analyze & forecast your usage properly before you purchase. After purchasing RIs, you must monitor the usage regularly if the discounts are applied or not.

For better understanding and analysis of RIs, you can take a look at Botmetric’s Cost and Governance RI. It provides wide range of analysis for RI Utilization, unused RI, planning RI based on the metrics like CPU, IO and number of days instance running. It has free 14 day trial.

Editorial Note: This blog post was first published on Medium. To see the original post, click here.